Где AI-настройка обмена с 1С работает, а где нет: честный разбор

Под прошлой статьей справедливо заметили: обмены бывают разными, и порой они совсем не простые, особенно те, что построены на правилах обмена. Согласен. Здесь разберу, какие обмены «Связка» закрывает настройкой с AI-помощником, какие нет и почему. Без обещаний «любой API одной фразой».

Два разных мира обменов

1. Обмен 1С ↔ 1С по правилам. Это КД 2/3, EnterpriseData, планы обмена, «Обмен данными» БСП. Здесь две базы с богатыми объектными моделями, а значит:

• сопоставление справочников, порой многие ко многим;

• регистрация изменений и квитирование;

• конфликты, коллизии, порядок загрузки;

• перенос движений и закрытых периодов;

• обработчики событий на стороне каждой базы.

Это инженерный проект. AI-помощник его не заменяет, и «Связка» на это не претендует. Если у вас работает КД3 или шина, их и оставляйте.

2. Точечный обмен 1С ↔ внешняя система по API. Сайт отдает заказ в JSON, CRM переводит сделку в «Оплачено», программа салона вечером отдает оплаты, приходит письмо с темой «Заявка», появляется файл в папке. Схема почти всегда одна:

1. получить сообщение;

2. найти объект по ключу (телефон, артикул, ИНН, внешний id);

3. создать или обновить документ по правилам;

4. не создать дубль при повторе;

5. записать в журнал.

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

Что делает AI-помощник

На входе текст задачи по-русски и пример сообщения. На выходе черновик настройки, а не кода:

• метод получения: HTTP-запрос, почта, папка;

• ключевой реквизит для поиска;

• правила записи полей в реквизиты и табличные части.

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

Сам обмен работает без AI: очередь, фон, повтор при ошибке ^[1], защита от второго документа при повторе сообщения, журнал запросов и ответов в базе.

Где помощник справляется сам

• Плоский или умеренно вложенный JSON. Список товаров заказа разбирается по строкам.

• Поиск по одному понятному ключу.

• Простой API с ключом в заголовке.

• Однонаправленный поток: «пришло → создать документ» или «провели → отправить статус».

Где нужен программист

Эти случаи мы доделываем руками:

• OAuth и обновление токенов;

• банковские сертификаты и подписанные запросы;

• входящие вебхуки, когда система сама присылает данные;

• массивы в массивах, сложная иерархия;

• нестабильные ключи, где защита от дублей требует отдельной логики;

• нестандартные форматы, большие объемы;

• сложные обработчики: помощник дает черновик, а программист дописывает обработчики там, где нужна логика ^[2].

Где «Связка» не подходит совсем

• Полноценная синхронизация 1С ↔ 1С с регистрацией изменений: это КД и EnterpriseData.

• Замена корпоративной шины.

• 1С:Фреш и платформы без поддержки расширений.

• Базовые редакции: для внешних вызовов нужна ПРОФ.

Про «вы тестировщики»

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

Как проверить на своей задаче

Опишите в комментариях задачу и пример сообщения (без персональных данных). Отвечу, что подключится настройкой сразу, а что потребует ручной работы. Начинаем всегда с копии базы.