Перенос заказов с сайта в 1С: что нужно решить до запуска обмена

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

Я занимаюсь автоматизацией с августа 2026 года и использую ИИ-инструменты для разработки. Это заметки из текущего проекта, а не универсальная инструкция для любой конфигурации 1С.

1. Что именно передаём

«Передать заказ» — слишком общее описание. Нужно перечислить данные: номер заказа, покупатель, товарные позиции, количество, цены и скидки. Затем определить, куда каждое значение попадёт в 1С и какие поля обязательны. Отдельно решить, создаём ли только новый заказ или также обновляем уже перенесённый.

В моём проекте заказ попадает в 1С с покупателем, договором, товарами, скидками, складом и резервом. Этот состав относится к конкретному процессу магазина: переносить его на другой бизнес без разбора нельзя.

2. Как узнаём один и тот же товар

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

Если совпадение неоднозначно или товар не найден, полезнее показать проблему человеку, чем автоматически выбрать похожую позицию. Это правило стоит определить до запуска.

3. Что делать с повторной передачей

Одно событие может быть обработано повторно: например, после перезапуска или повторной попытки при сбое. Значит, нужен способ определить, переносили ли этот заказ раньше. Иначе технический повтор может стать вторым заказом в учётной системе.

4. Что происходит при ошибке

Важно различать два случая: система явно отказала в создании заказа или ответ вообще не пришёл. Во втором случае нельзя сразу считать, что заказ не создан, и без проверки повторять запись.

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

5. Как проверяем результат

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

Что я вынесла из этой работы

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

Работающий перенос заказов не означает, что автоматизированы все оплаты, возвраты, доставка и складские процессы. Для каждого следующего участка нужны свои правила и проверка. Измеренную экономию времени я пока не считала, поэтому не привожу цифры окупаемости.

А какие ситуации в обмене между сайтом и учётной системой чаще всего требуют ручного вмешательства у вас?