Как подключить ИИ к 1С: три варианта и схема из реального проекта

Подключить ИИ к 1С можно через стандартный OData-интерфейс, собственный HTTP-сервис в конфигурации или контролируемый обмен файлами. Выбор зависит от задачи. Для чтения справочника и статусов подходит OData. Для бизнес-операций с проверками удобнее отдельный HTTP-сервис. Если менять 1С нельзя, начните с регулярной выгрузки номенклатуры и возврата готового Excel. Модель не должна получать административный доступ к инфобазе или сама составлять произвольные запросы. Между ней и 1С нужен обычный сервис, который проверяет права, структуру данных и результат каждой операции. Первый пилот безопаснее запускать только на чтение и черновики.

Сначала решить, что именно должен делать агент

Фраза «подключить ИИ к 1С» слишком широкая. За ней могут стоять разные процессы:

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

Для первого пилота лучше выбрать одну операцию с понятным входом и результатом. Например: получить Excel от клиента, сопоставить строки со справочником и вернуть менеджеру проверенный файл. Запись документа в 1С можно добавить позже, когда подбор уже измерен на реальных заявках.

До разработки нужны четыре решения:

1. Какие объекты 1С разрешено читать.
2. Какие операции можно выполнять автоматически.
3. Что всегда подтверждает менеджер.
4. По какому признаку система понимает, что действие действительно завершилось.

Вариант 1. OData для чтения стандартных объектов

Платформа 1С умеет публиковать стандартный REST/OData-интерфейс. Внешний сервис может читать разрешённые справочники и документы через HTTP. По данным официальной документации, OData также позволяет создавать и изменять объекты, однако для первого этапа разумнее дать техническому пользователю только чтение.

Начинать стоит с документа метаданных:

GET https://1c.example/BASE/odata/standard.odata/$metadata
Authorization: Basic <service-user-credentials>

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

GET https://1c.example/BASE/odata/standard.odata/Catalog_Номенклатура
    ?$select=Ref_Key,Description
    &$top=100

Имена объектов зависят от конфигурации. Их нельзя переносить из примера вслепую. Пароль или access token хранятся в секретах сервера, запросы идут по HTTPS, а журнал фиксирует время, пользователя, объект и код ответа.

Простейший клиент на Python:

import os
import requests

base_url = os.environ["ONEC_ODATA_URL"].rstrip("/")

response = requests.get(
    f"{base_url}/Catalog_Номенклатура",
    params={"$select": "Ref_Key,Description", "$top": 100},
    auth=(os.environ["ONEC_USER"], os.environ["ONEC_PASSWORD"]),
    timeout=20,
)
response.raise_for_status()
items = response.json()["value"]

Такой код читает данные. Решение о том, какой товар соответствует фразе клиента, остаётся в отдельном модуле сопоставления.

Вариант 2. Собственный HTTP-сервис для бизнес-операций

Если агент должен создать заказ, проверить обязательные реквизиты или провести документ, одного универсального OData-доступа часто слишком много. В конфигурации 1С можно сделать собственный HTTP-сервис с узкими методами.

Например, внешний агент передаёт уже структурированный черновик:

POST https://1c.example/BASE/hs/ai/orders/preview
Authorization: Bearer <service-token>
Content-Type: application/json

{
  "external_id": "request-2026-001",
  "items": [
    {"ref_key": "catalog-item-id", "quantity": 12}
  ]
}

Путь /hs/ai/orders/preview здесь вымышленный. Его создаёт разработчик 1С под конкретную конфигурацию. Обработчик внутри 1С проверяет номенклатуру, количество, контрагента и права пользователя. Ответ должен содержать машинный статус и идентификатор черновика, а не только фразу «успешно».

Для проведения документа можно выделить второй метод и требовать явное подтверждение менеджера. Так модель не получает право на произвольную запись.

Вариант 3. Обмен файлами, если 1С пока нельзя менять

В одном из наших проектов компания получала заявки на вентиляционное оборудование в Excel и текстом. Названия клиентов не совпадали с внутренней номенклатурой, а в справочнике было больше 30 000 строк.

Мы начали без прямого API к инфобазе:

выгрузка номенклатуры 1С
  → локальный справочник и поисковый индекс
  → Excel или текст клиента
  → подбор кандидатов
  → проверка менеджера
  → итоговый Excel для рабочего процесса

Выгрузка переводится в локальный JSON-справочник. Для смыслового поиска по нему строится векторный индекс. При обновлении номенклатуры индекс пересобирается. Сама 1С в момент подбора не вызывается.

У этого подхода есть плюсы: можно сделать пилот без доработки конфигурации, ограничить доступ и проверить качество сопоставления на реальных файлах. Ограничение тоже заметное. Цены, остатки и новые позиции не обновятся до следующей выгрузки. Это файловая интеграция, а не онлайн-синхронизация.

Как проходит одна заявка

В рабочей системе менеджер выбирает контекст клиента и загружает Excel. Backend сначала разбирает файл и показывает число найденных строк. Обработка начинается после подтверждения.

Затем каждая строка проходит каскад:

1. известное соответствие конкретного клиента;
2. ранее подтверждённый маппинг;
3. нечёткий поиск по тексту;
4. поиск точной маркировки модели;
5. смысловой поиск по локальному индексу;
6. LLM выбирает из ограниченного списка кандидатов;
7. код сверяет числа и маркировки.

Высокая похожесть ещё не означает автоматическое принятие. Если размеры расходятся или вариантов несколько, строка остаётся менеджеру. После проверки система формирует Excel с оригинальным названием, выбранной позицией 1С, количеством и статусом.

Новые соответствия не начинают работать сразу. Менеджер предлагает пару, администратор принимает, заменяет или отклоняет её. Это защищает справочник от случайной ошибки в одной заявке.

Что пришлось исправлять

Семантический поиск пропускал точные модели

В запросе могла быть маркировка SM 300, но смысловой поиск сильнее реагировал на слова вокруг неё. Нужная позиция выпадала из верхних результатов. Мы добавили отдельное извлечение буквенно-цифровых моделей и стали подмешивать найденные по маркировке товары в список кандидатов.

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

Парсер принимал количество за название

Клиентские Excel отличаются заголовками и порядком колонок. В одном из вариантов числовой столбец мог стать названием товара. Теперь строка считается шапкой только при наличии нескольких смысловых колонок, а столбец, заполненный числами, не используется как наименование.

Отклонённая подсказка возвращалась в итог

В ранней версии запасная логика могла сохранить кандидата модели даже после отказа менеджера. Исправили финальный статус: красная строка остаётся пустой, пока человек не выбрал позицию. В словарь попадают только явно утверждённые пары.

Права и авторизация

В нашей панели менеджеры входят по JWT, а backend фильтрует список клиентов по роли. Изменение справочника и утверждение новых маппингов доступны администратору.

При прямом соединении с 1С принцип тот же:

• отдельный технический пользователь;
• минимальный набор объектов и операций;
• HTTPS;
• секреты вне репозитория;
• ограничение по сети, если это возможно;
• идемпотентный внешний идентификатор для операций записи;
• журнал запроса, ответа и решения человека.

Официальное руководство 1С описывает несколько вариантов HTTP-аутентификации, включая Basic и Bearer access token. Конкретный способ зависит от публикации инфобазы и политики компании.

Как проверить интеграцию до запуска

Не начинайте с демонстрационной фразы из пяти слов. Соберите набор реальных заявок с разными шапками, сокращениями, размерами и единицами.

Проверка должна ответить на конкретные вопросы:

• сколько строк распарсилось и сколько было в исходнике;
• какая версия справочника использована;
• откуда взялся каждый кандидат;
• совпали ли модель и числовые параметры;
• какие строки система оставила человеку;
• какой документ или файл появился на выходе;
• что случится при повторной отправке того же запроса;
• как система поведёт себя при недоступной 1С или модели.

Для операций записи нужен отдельный тест: получить технический идентификатор созданного объекта, прочитать его обратно и убедиться, что повторный вызов не создаёт дубль.

Какой вариант выбрать

Файловый обмен подходит для пилота и процессов, где справочник обновляется контролируемо. OData удобен для чтения стандартных объектов. Собственный HTTP-сервис нужен, когда операция имеет бизнес-правила и должна возвращать точный результат.

Во многих проектах схема получается гибридной: каталог читается по OData или выгрузке, модель готовит структурированное предложение, а узкий HTTP-метод создаёт черновик только после подтверждения менеджера.

Geron Labs может разобрать один реальный процесс вокруг 1С и собрать пилот без права на запись. На вход нужны пример заявки, описание нужного результата и безопасная выгрузка справочника.

Источники

• REST/OData-интерфейс платформы 1С, проверено 28.09.2026.
• Собственные HTTP-сервисы 1С, проверено 28.09.2026.
• Руководство администратора 1С: публикация OData и HTTP-аутентификация, проверено 28.09.2026.
• Кейс Geron Labs о сопоставлении заявок с номенклатурой 1С.