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