Большинство обменов 1С с внешними системами, которые мне приходилось поддерживать, устроены одинаково: в конфигурации или во внешней обработке лежит процедура на несколько сотен строк, которая разбирает JSON и заполняет документ. Работает она, пока никто не трогает ни источник, ни 1С. После обновления типовой или нового поля в источнике ее чинят, и обычно это может сделать только тот, кто ее писал.

Я попробовал описывать обмен не кодом, а данными. Настройка интеграции хранит направление, метод, правила «откуда взять → куда положить» и небольшие обработчики для того, что правилами не выражается. Все это живет в расширении, а типовая остается на поддержке.

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

1. Проблема: обмен как код

У обмена «в коде» три слабых места:

• Обновления. Правка типовой снимает ее с поддержки или превращает каждое обновление в сравнение-объединение.

• Непрозрачность. Чтобы понять, откуда в заказе взялась цена, нужно читать процедуру.

• Количество источников. Сайт, CRM, почта с прайсами, бот, программа клиники: на каждый пишется свой обмен со своими ошибками и своим логированием.

2. Подход: обмен как данные

В расширении четыре сущности:

• Настройка интеграции: направление (получение/отправка), метод, ключ идентификации сообщения, объект 1С.

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

• Обработчики событий: короткие процедуры для того, что не выражается таблицей.

• Журнал сообщений: каждое входящее и исходящее сообщение, статус, ошибка, повтор.

HTTP-сервис расширения принимает сообщение, по методу находит настройку, применяет правила и пишет результат в журнал. Конфигурация не меняется.

3. Что получает помощник

Три входа:

1. Текст задачи. Например: «Сайт присылает заказ. Создать Заказ клиента, покупателя найти по телефону, при отсутствии создать, товары найти по артикулу».

2. Пример сообщения. Реальный JSON заказа.

3. Объект-образец. Существующий документ из базы. Из него берутся метаданные (реквизиты, табличные части, типы) и то, какие поля в этой базе реально заполняются.

Образец важен: одна и та же задача в УТ и УНФ раскладывается по разным реквизитам, и описание словами этого не передает.

4. Что он возвращает

• направление обмена и имя метода (например, inЗаказКлиента);

• таблицу правил «путь в JSON → реквизит»;

• правила поиска: номенклатура по артикулу, партнер по телефону;

• обработчик формирования объекта.

Упрощенный пример обработчика (для статьи):

Процедура ПриФормированииОбъекта(Сообщение, Объект, Отказ)
	Данные = Сообщение.Данные;
	Объект.НомерПоДаннымКлиента = Данные.number;
	Для Каждого Строка Из Данные.items Цикл
		НоваяСтрока = Объект.Товары.Добавить();
		НоваяСтрока.Номенклатура = НайтиПоАртикулу(Строка.sku);
		НоваяСтрока.Количество = Строка.qty;
		НоваяСтрока.Цена = Строка.price;
	КонецЦикла;
КонецПроцедуры

5. Почему ответ не исполняется вслепую

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

6. Грабли из реальной съемки

Я записывал минутный ролик на живой базе, и помощник ошибался там, где ошибся бы и человек без контекста:

• Направление. Пока в пояснении не было сказано, что сообщение входящее, он предложил настройку отправки. Лечится одной фразой в задаче.

• Типы. Ошибка «по пути customer ожидался Массив»: в примере покупатель был объектом, а правило ждало массив. Видно на тестовой обработке.

• Ключ поиска. Поиск покупателя по имени вместо телефона. Синтаксически верно, по смыслу плохо. Такое ловит только человек, поэтому проверка обязательна.

7. Исполнение

HTTP-сервис расширения, очередь, журнал, повтор при ошибке, защита от дублей по ключу сообщения (для заказа это номер заказа на сайте). Повторная доставка того же сообщения не создает второй документ.

8. Источники кроме сайта

Механизм не знает, что такое «сайт». Ему нужен формат сообщения и объект 1С. Поэтому так же описываются: письма и вложения, файлы в папке (прайсы, УПД поставщиков), Telegram-боты и формы, нишевые CRM, программы клиник и салонов, любой сервис с API. И обратное направление: статусы и остатки из 1С наружу.

9. Ограничения

• OAuth2, подписи запросов и сертификаты требуют разработчика.

• Глубоко вложенные массивы и нетривиальные преобразования уходят в обработчики, а не в правила.

• Ответственность за маппинг на человеке: помощник предлагает, человек утверждает.

Итог

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

Минутный ролик с этим сценарием: https://svjazka.com. Разборы обменов пишу в канале @belenya_1c.