Интеграция 1С с ИИ: как подключиться и не сломать учёт

Разбор по мотивам реального проекта на 1С:ERP — без названия компании и цифр. Для владельцев и финансистов, которые хотят отчётов и AI-агентов «на данных из 1С», но боятся тронуть учёт.

Главная мысль: 1С — источник, а не рабочая площадка

Самая частая ошибка — заставлять каждый отчёт, бота и AI-агента ходить в 1С напрямую. Это медленно (тяжёлые выборки по регистрам), рискованно (любой запрос работает на боевой базе) и хрупко (1С недоступна — встало всё).

Рабочая схема другая: данные забираются из 1С по расписанию в отдельную базу, а всё остальное — дашборды, журналы, агенты — работает уже на ней. 1С продолжает жить своей жизнью и даже не знает, что поверх неё построено что-то ещё.

Семь способов подключиться к 1С

Перед работой я разбираю все варианты по одному шаблону: что нужно включить, какие права, ограничения, подводные камни. Коротко — вердикты:

• Стандартный интерфейс OData (REST). Платформа сама публикует объекты конфигурации, кода в 1С не нужно. Права проверяются штатно: пользователь с ролью «только чтение» ничего не запишет, даже если инструмент очень захочет. Основной канал для чтения.
• HTTP-сервисы 1С. Свои REST-методы в расширении конфигурации. Полный контроль и быстрее на сложных выборках, но нужен разработчик 1С и релизный цикл. Второй этап — когда OData упрётся в скорость или понадобится запись с проверками.
• COM-соединение. Прямое подключение из Windows-процесса. Годится для скрипта на одном компьютере, не для серверной автоматизации: хрупко и расходует лицензию на сеанс.
• Web-сервисы SOAP. Формальный контракт, но громоздко. Сегодня редко оправдано.
• Файловый обмен (выгрузки в Excel/XML по расписанию). Можно начать завтра, но это задержка и ручные ошибки. Хорош как быстрый пилот, пока публикуют OData.
• 1С:Шина. Гарантированная доставка и события, но отдельный сервер, лицензии и сложность. Для среднего бизнеса обычно избыточно.
• Прямой SQL к базе 1С в обход платформы. Нарушает лицензионное соглашение 1С, а структура таблиц нестабильна. Не рассматриваю.

Почему «только чтение» — это не перестраховка

У OData нет своей модели прав: запрос выполняется под пользователем 1С, и действуют его роли. Значит, периметр безопасности — это роль в самой 1С, а не настройки внешней программы. Отдельный пользователь «ИнтеграцияИИ» с ролью только на чтение физически не может провести документ или поправить остаток.

• Отдельный пользователь на каждую интеграцию — не делить с главбухом.
• Публиковать только нужные объекты. Состав публикации — это и есть периметр.
• OData не выставлять в интернет: только внутренняя сеть или защищённый канал до сервера автоматизаций.
• Пароли — только в секретах окружения, не в сценариях и не в репозитории.

Что выгружать в свою базу

• Склад и закупки: справочники, цены, остатки с партиями и сроками годности, заказы, приходы, перемещения.
• Производство: выпуск, расход материалов, рецептуры с составом, план.
• Продажи: выручка с историей, план продаж.
• Списания — с разбором по статьям расходов: брак, технические потери.

Расписание простое: ночью — полная выгрузка, заранее, до резервного копирования самой 1С; днём — короткие обновления оперативного: остатки, заказы, свежие документы.

Подводные камни 1С, о которых узнаёшь на практике

• Единица измерения — только из карточки номенклатуры. В строке документа может стоять упаковка, а нормы рецептур записаны в базовой единице. Складывать «как есть» — получить ерунду.
• Действующая рецептура — по регистру, а не по статусу. Статус «действует» стоит лишь у малой части реально работающих рецептур.
• Составные ссылки и одинаковые ключи у разных документов. Отбор нужно вести с учётом типа документа, иначе продажи и возвраты смешаются.
• Документы будущими датами. Верхняя граница «по сегодня» тихо их теряет.
• Суммировать на стороне 1С через OData нельзя. Агрегация делается уже в своей базе.
• Остатки через OData — тяжёлые. Регистры накопления отдаются через виртуальные таблицы без периодичности; брать точечные срезы и хранить у себя.

Загрузку тоже нужно мониторить

Молча упавшая ночная выгрузка — это утренний дашборд со вчерашними цифрами, который никто не заметит. Поэтому каждую загрузку проверяю автоматически:

• не пришла вовремя по расписанию — оповещение;
• идёт слишком долго — оповещение;
• объём заметно меньше обычного для этого времени суток — оповещение (частый признак, что 1С отдала пустоту из-за прав или блокировки);
• одновременно идёт только одна загрузка — ручной запуск не наложится на плановый.

AI-ассистент, который сам спрашивает 1С

Поверх того же OData можно дать AI-ассистенту (например, Claude) доступ к данным 1С через MCP-мост — небольшой сервер, который превращает вопрос на обычном языке в запросы к 1С. Чтобы ассистент не гадал, собирается карта данных и связей между объектами: что где лежит и как одно ссылается на другое. Мост работает только на чтение и запускается на машине пользователя — по сети не слушает.

Чек-лист: что спросить у администратора 1С

1. Версия платформы и конфигурации, файловая или клиент-серверная база.
2. Опубликована ли база на веб-сервере и включён ли стандартный интерфейс OData.
3. Кто сопровождает 1С и как проходят доработки, есть ли тестовая копия базы.
4. Хватает ли лицензий на ещё один сеанс под интеграцию.
5. Можно ли завести отдельного пользователя только на чтение и какие объекты ему открыть.
6. Какими отчётами пользуются закупки, склад и финансы — чтобы найти их данные в 1С.

Удобнее всего отправить это одной готовой заявкой: пользователь, роли, состав публикуемых объектов. Так не приходится ходить к администратору по кругу.

Что в итоге работает на этих данных

Дашборды закупок и продаж (факт против нормативов, план-факт, прогноз, утренняя сводка), производственные журналы, которые собираются сами, сверка взвешиваний с рецептурой и представления с понятными русскими колонками — бухгалтерия пишет запросы сама. Расчёт экономии на закупках при этом сверен с расчётом бухгалтерии до рубля — иначе цифрам никто не поверит.

Кейс на сайте: Интеграция с 1С.