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