В 1С лежит всё, что нужно для управленческих решений: закупочные цены, остатки, долги, история отгрузок, себестоимость. Проблема не в данных, а в доступе к ним. Любой нестандартный вопрос — «а сколько мы брали этот товар в последний раз и почём» — превращается в заявку программисту, отчёт на два дня и файл в почте, который устаревает к моменту открытия.
У нашего клиента — производственно-торговой компании — работает ИИ-сотрудник в корпоративном мессенджере. Он уже собирал отчёты по продажам и разбирал рекламу, но в 1С ходить не мог: каждый вопрос про закупки и остатки упирался в стену. В 2026 году мы подключили его к боевой базе 1С через MCP-сервер. Рассказываем, что это такое, как устроено и чем отличается от привычных способов интеграции.
Проблематика: почему обычные интеграции не закрывают задачу
Способы вытащить данные из 1С существуют давно. Беда в том, что все они рассчитаны на заранее известный вопрос.
- Печатные формы и отчёты в конфигурации. Отличный инструмент, пока вопрос типовой. Каждый новый разрез — доработка.
- Выгрузка в Excel. Данные мгновенно устаревают, а сводить три выгрузки руками — отдельная работа.
- OData-интерфейс. Отдаёт таблицы, но не понимает смысла: чтобы получить «последнюю продажу по артикулу», внешней системе нужно знать структуру метаданных, уметь разыменовывать ссылки и склеивать документы. Это снова задача для разработчика.
- HTTP-сервисы под конкретную задачу. Работают идеально — ровно до первого вопроса, который в них не заложили.
Общий знаменатель: между вопросом бизнеса и ответом из базы всегда стоит человек, который переводит одно в другое. Именно этот шаг мы и хотели убрать.
Идея: дать модели не отчёт, а язык запросов
MCP (Model Context Protocol) — открытый протокол, через который ИИ-агент подключается к внешним системам как к набору инструментов. Модель не получает готовые ответы: она получает возможность спрашивать.
Ключевое решение кейса — мы отдали ИИ-агенту не пачку заранее написанных отчётов, а язык запросов 1С. Модель сама формулирует запрос на встроенном языке, сама разыменовывает поля через точку, сама группирует и считает итоги. Всё, что для этого нужно — уметь читать структуру конфигурации, и такой инструмент в наборе тоже есть.
Разницу проще показать. Вопрос «покажи динамику продаж по каналам по месяцам за год» в классической схеме — это ТЗ, разработка и тестирование. В схеме с MCP — это запрос в чате, на который агент отвечает за пару минут: он сам находит нужный вид документа, сам фильтрует по контрагентам и сам сворачивает результат по месяцам.
Реализация
Два контура: чтение и запись
Мы намеренно развели доступ на два независимых сервера.
Контур чтения — восемь инструментов: выполнение произвольного запроса на языке 1С, чтение одной таблицы по описанию без языка запросов, обзор состава конфигурации, полная структура объекта, справка и проверка связи. Этого достаточно, чтобы ответить практически на любой вопрос по учёту.
Контур записи — отдельный сервер с собственными правами: создание и изменение документов, проведение, поиск по реквизитам. Физическое удаление объектов запрещено на уровне сервера — только пометка. Любая запись идёт сначала в режиме проверки (dry run) и только потом, после подтверждения человека, реально пишется в базу.
Обезличивание персональных данных
Это, пожалуй, самая интересная часть. Модель — внешний сервис, и отдавать ей ФИО клиентов, ИНН и контакты нельзя. Поэтому сервер маскирует персональные данные до того, как они попадут в контекст модели: вместо «ООО Ромашка» приходит токен вида [ОРГ-00596], вместо ФИО — [ФЛ-00002].
Модель работает с обезличенными данными: считает суммы, строит сравнения, ищет закономерности — ей для этого настоящие имена не нужны. А когда ответ сформирован, он прогоняется через отдельный инструмент расшифровки, который подставляет реальные значения. Человек в чате видит настоящее название контрагента, модель эту строку не видела ни разу.
Побочный эффект, к которому пришлось привыкнуть: запрос не должен пытаться ветвиться по полям с персональными данными — сервер такие конструкции отклоняет. На практике это означает не один хитрый запрос с условиями по контрагентам, а несколько простых, а разметку каналов агент делает уже у себя.
Техническая обвязка
Сервер публикуется как HTTP-сервис на стороне 1С, обмен идёт по JSON-RPC поверх HTTPS с базовой авторизацией. Отдельной синхронизации и промежуточной базы нет — агент читает боевую базу напрямую, поэтому данные всегда актуальны на момент вопроса. Нагрузка регулируется лимитом строк в ответе.
Что получили
Несколько реальных сценариев, которые сейчас работают у клиента в рабочем чате.
Вопросы по товару и закупкам
Менеджер пишет в чат артикул и спрашивает про последнюю продажу. Агент находит номенклатуру, поднимает документы реализации и отдаёт номер документа, дату, клиента, количество и цену — отдельно по оптовым отгрузкам и отдельно по розничным каналам. Время ответа — около минуты, вместе с разбором по нескольким юрлицам группы.
Закупочные цены и остатки
Перед тем как поставить товар в продажу, менеджеру нужно понимать закупочную цену и наличие. Раньше это был звонок в бухгалтерию, сейчас — вопрос в чат.
Аналитика продаж
Динамика по месяцам в разрезе каналов продаж, с выгрузкой в наглядный HTML-отчёт. Собирается по запросу, а не раз в квартал.
Документы
Счёт-договор в PDF по номеру заказа из 1С — с реквизитами, печатью и условиями расчёта. Агент забирает данные заказа и собирает готовый документ, менеджеру остаётся отправить его клиенту.
Контроль дебиторки
Сводка по должникам с выгрузкой в таблицу — регулярно и без участия бухгалтера.
Сценарии: от вопроса в чате до автоматических документов
Главное, что получает компания после подключения — не конкретный отчёт, а свободу сценариев. Сервер один, он умеет читать структуру базы и писать документы, поэтому новая задача не требует новой разработки. Диапазон широкий: от простого вопроса в чате «какой остаток по этому артикулу» — до автоматического создания и проведения документов по расписанию, без участия человека.
Десять примеров из того, что уже работает:
- Последняя продажа по артикулу. Менеджер называет артикул — агент отдаёт номер документа, дату, клиента, количество и цену. Полезно, когда клиент звонит с вопросом «почём брали в прошлый раз».
- Закупочная цена и поставщик. Поднимает последние документы поступления по номенклатуре: у кого брали, когда и по какой цене.
- Остатки по складам. Сколько товара и где физически лежит — до того, как менеджер пообещает клиенту срок.
- Контроль дебиторки. Сводка по должникам с суммами и сроками, выгрузка в таблицу одной кнопкой.
- Счёт-договор в PDF. По номеру заказа собирается готовый документ с реквизитами, печатью и условиями расчёта.
- Повтор заказа копией. Клиент просит «то же самое, но 20 штук» — агент находит прошлый заказ, копирует реквизиты и создаёт новый документ с нужным количеством.
- Динамика продаж по каналам. Помесячная аналитика в разрезе направлений сбыта с наглядным отчётом — по запросу, а не раз в квартал.
- Приёмка за день. Что поступило на склад сегодня, по каким документам и от кого.
- Автоматическое создание документов по данным внешних систем. Отгрузки, прошедшие во внешней площадке, ежедневно превращаются в документы 1С по расписанию — без ручного ввода.
- Сверка расхождений. Агент сопоставляет остатки и цены в 1С с тем, что фактически выставлено во внешних системах, и показывает, где данные разошлись.
Между первым и последним пунктом — принципиальная разница в режиме работы. Первые пять запускает человек вопросом в чате. Последние — работают сами, по расписанию, а человек получает уже результат и подключается, только если агент нашёл проблему.
1С как часть общего контура: обмен с другими системами
Второй эффект, который обычно недооценивают: MCP-сервер делает 1С не конечной точкой, а участником обмена. Агент одновременно подключён и к 1С, и к другим системам — CRM, маркетплейсам, транспортным компаниям, сервисам проверки контрагентов, почте, сайту. И он способен переносить данные между ними, понимая смысл, а не просто перекладывая поля.
Из 1С наружу. Цены и остатки уезжают на сайт и торговые площадки. Статусы отгрузки подтягиваются в CRM, чтобы менеджер видел их, не открывая 1С. Данные для счёта отправляются клиенту в мессенджер. Аналитика собирается в дашборд, который читает руководитель.
Снаружи в 1С. Заказы с сайта и площадок становятся документами. Реквизиты нового контрагента подтягиваются из государственных реестров по ИНН и сразу подставляются в карточку. Данные о фактических отгрузках перевозчика ложатся в учёт. Поступления от поставщика заводятся по электронному прайсу.
Принципиальное отличие от классической интеграции — в том, кто отвечает за логику. Обычный обмен жёстко фиксирован: поле A из системы 1 кладётся в поле B системы 2, и любое изменение правил — это доработка с обеих сторон. Агент же получает описание задачи словами, сам определяет, откуда взять данные и куда положить, и сам справляется с несовпадением структур: в одной системе артикул, в другой — внутренний код, в третьей — штрихкод. Сопоставить их — как раз то, что модель делает хорошо.
Практический вывод: не нужно строить отдельную интеграцию под каждую пару систем. Достаточно один раз открыть каждую из них агенту, а дальше связки между ними собираются постановкой задачи, а не проектом разработки.
Сравнение со стандартными способами
| Критерий | Отчёты в 1С | OData | HTTP-сервис под задачу | MCP-сервер |
|---|---|---|---|---|
| Новый разрез данных | доработка | код на стороне клиента | доработка | без доработки |
| Кто формулирует запрос | программист | программист | программист | сам агент |
| Актуальность | онлайн | онлайн | онлайн | онлайн |
| Защита персональных данных | права 1С | права 1С | на усмотрение разработчика | маскирование в протоколе |
| Понимание структуры базы | заложено в отчёт | нужно знать заранее | заложено в сервис | читается на лету |
| Срок до первого ответа | дни | дни | дни | минуты |
MCP не отменяет остальные способы. Регламентные печатные формы и обмены остаются на своих местах — протокол закрывает именно зону нерегулярных вопросов, которые раньше либо ждали очереди у программиста, либо не задавались вовсе.
Честные оговорки
- Качество ответа зависит от качества учёта. Если месяц не закрыт, себестоимость в регистрах равна нулю — и никакой агент её не придумает. В этом кейсе мы столкнулись ровно с этим: посчитать чистую прибыль по заказам не удалось, потому что закрытие месяца в базе не проводилось.
- Агент может ошибиться в формулировке запроса. Поэтому ответы по деньгам мы просим сопровождать номерами документов — их легко проверить в базе за секунды.
- Доступ на запись — зона повышенного риска. У нас он включён, но действует правило: сначала проверочный прогон, потом подтверждение человека, и только затем запись. Автономных изменений в боевой базе нет.
- Это не «ИИ вместо 1С-ника». Конфигурацию по-прежнему ведут специалисты. Меняется другое: рутинные запросы к данным перестают отнимать их время.
Частые вопросы
Это программа-посредник, через которую ИИ-агент обращается к базе 1С: не «скачивает отчёт», а задаёт базе вопросы и получает данные. Для 1С это обычный HTTP-сервис, для модели — набор инструментов.
Нет. Сервер работает поверх существующей базы и обращается к стандартным объектам. Изменения в конфигурации не требуются.
При правильной схеме — да. Персональные данные маскируются до попадания в модель, права на запись выделены в отдельный контур, физическое удаление запрещено, изменения проходят через подтверждение человека. Читающий контур в принципе не может ничего испортить.
Нужен опубликованный HTTP-сервис на стороне 1С, учётная запись с нужными правами и настроенный агент на стороне клиента.
Сроки реализации и стоимость: 3 часа — создание MCP-сервера и интеграция в 1С. Это полный цикл: разработка сервера, публикация, настройка прав и подключение агента. Дальше сценарии добавляются без доработки сервера — достаточно сформулировать задачу словами.
Подход не привязан к конкретной конфигурации. Он опирается на язык запросов и метаданные, которые есть в любой конфигурации на платформе 8.3 — меняются только объекты, к которым обращается агент.
Что дальше
Ближайшие шаги по этому клиенту — подключить к тому же контуру расчёт себестоимости после закрытия месяца, чтобы отчёты показывали не валовую маржу, а чистую прибыль по заказам.
Если в вашей компании 1С работает, а данные из неё достаются через заявку программисту — задача решаема. Разберём процессы и покажем, какие вопросы ИИ-агент сможет закрывать сам уже на первой неделе.
Стек: MCP-сервер на стороне 1С (JSON-RPC/HTTPS), 1С:Предприятие 8.3, ИИ-агент на базе OpenClaw в корпоративном мессенджере.