Как настроить обмен 1С с сайтом: схема, данные и проверка
Настройка начинается не с установки модуля, а с контракта данных: какая система владеет каждым объектом, в каком направлении он движется и как обе стороны подтверждают результат. Только после этого выбирают CommerceML, готовый модуль или API и назначают расписание.
Минимальный безопасный контур передаёт товары, цены и доступные остатки на сайт, а заказы — в 1С. У каждого сообщения есть стабильный внешний идентификатор, поэтому повторная доставка не создаёт второй объект. Подробную матрицу полей разбираем в материале о составе синхронизации.
Что определить до выбора модуля
Зафиксируйте конфигурацию и релиз 1С, платформу сайта, объём каталога, число складов и заказов, допустимую задержку и ограничения сети. Проверьте, существует ли штатный обмен и поддерживает ли он ваши версии. Название модуля само по себе не доказывает совместимость с изменённой конфигурацией.
Запишите ожидаемый результат простыми операционными фразами: «остаток на сайте не старше пятнадцати минут», «заказ создаётся один раз», «ошибка видна ответственному». Эти формулировки позже становятся критериями приёмки.
Кто владеет товарами, ценами, остатками и заказами
Для каждого поля нужен один источник истины. Обычно 1С владеет SKU, ценами, складами и фактическим остатком, сайт — корзиной, пользовательскими комментариями и моментом оформления. Статус заказа может изменяться с обеих сторон, но переходы должны быть явно разрешены.
Двустороннее редактирование одного поля без правила конфликта приводит к «пинг-понгу»: сайт перезаписывает 1С, затем 1С возвращает старое значение. Матрица владельцев устраняет эту гонку до написания кода.
Типовой модуль, CommerceML или API: критерии выбора
Типовой модуль подходит, когда версии поддерживаются и бизнес-процесс близок к предусмотренному поставщиком. CommerceML удобен для пакетного каталожного обмена, но конкретную реализацию всё равно нужно проверять. API оправдан при нестандартных статусах, частом обмене, нескольких источниках и требовании подробной диагностики.
Выбирайте механизм по данным и эксплуатации, а не по модности. Даже удачный API требует авторизации, версии контракта, очереди, журнала и владельца поддержки.
Пакетный и событийный обмен
Пакетный режим запускается по расписанию и хорошо подходит для ночной полной сверки или умеренного каталога. Событийный режим быстрее сообщает об изменении заказа или остатка, но требует очереди, дедупликации и контроля порядка сообщений.
Практичный контур часто сочетает оба подхода: события поддерживают оперативность, а периодическая сверка исправляет накопившиеся расхождения. Полная выгрузка не должна блокировать продажи или создавать нагрузку в рабочее время.
Как обрабатывать повтор и недоступность системы
Каждая операция получает внешний ID и ключ идемпотентности. Если ответ потерян, отправитель повторяет запрос, а получатель возвращает прежний результат вместо создания дубля. Повторы ограничены по числу и времени, между ними растёт пауза.
После исчерпания попыток сообщение попадает в очередь исключений с безопасной причиной, временем и корреляционным ID. Пароли, токены, персональные данные и содержимое платежей в журнал не пишутся.
Сценарии приёмки
Проверьте создание и изменение товара, смену цены, несколько складов, резерв, новый заказ, отмену, возврат и повтор сообщения. Отдельно отключите одну сторону, восстановите доступ и убедитесь, что очередь догоняет состояние без дублей.
Приёмка сравнивает не только HTTP-ответ, но и итоговые объекты в обеих системах. Успешный ответ «принято» ещё не означает, что документ проведён или остаток совпал.
Когда нужен аудит
Аудит нужен до оценки, если конфигурация изменена, старый обмен нестабилен, нет тестовой базы, несколько сайтов или складов, а документация отсутствует. Его результат — схема потоков, список рисков, границы первой версии и оценка в часах.
Если задача ограничена одним поддерживаемым модулем и понятным сценарием, достаточно короткой диагностики. В обоих случаях резервная копия и план отката обязательны до изменений.
Проверочный сценарий
Сайт дважды отправляет заказ demo-order-1042, потому что первый ответ потерялся. 1С находит ранее сохранённый внешний ID, не создаёт дубль и возвращает идентификатор уже созданного документа. В журнале остаются две попытки и один бизнес-результат.
| Объект | Источник | Направление | Проверка |
|---|---|---|---|
| Товар | 1С | 1С → сайт | SKU и реквизиты совпали |
| Остаток | 1С | 1С → сайт | Склад и резерв учтены |
| Заказ | Сайт | Сайт → 1С | Один внешний ID — один документ |
Чек-лист самостоятельной проверки
- Определены версии 1С, сайта и модуля.
- Для каждого поля назначен источник истины.
- Согласованы расписание, допустимая задержка и полная сверка.
- Повтор сообщения безопасен, а число попыток ограничено.
- Есть тестовая база, журнал, уведомления и план отката.