- Сначала договоритесь, какая система — источник истины по каждому виду данных.
- Идентификаторы и справочники важнее протокола обмена.
- Ошибки обмена — не исключение, а штатный режим: их нужно проектировать.
Обмен сайта с 1С кажется технической задачей, но почти все сложности в нём — управленческие. Если ответы на вопросы ниже зафиксированы до старта, разработка проходит спокойно; если нет — команда неделями выясняет, почему цены на сайте не такие, как в учётной системе.
1. Какие данные обмениваются и в какую сторону
Составьте таблицу: сущность, направление, частота. Обычно набор такой:
- номенклатура, характеристики, описания и изображения — из 1С на сайт;
- цены и типы цен, остатки по складам — из 1С на сайт, чаще всего отдельным быстрым обменом;
- заказы и их статусы — с сайта в 1С и обратно;
- контрагенты и договоры — в обе стороны, особенно в B2B-сценариях;
- документы отгрузки и оплаты — из 1С на сайт для личного кабинета.
2. Кто источник истины
По каждой сущности должен быть один владелец. Если менеджер правит описание товара в 1С, а контент-менеджер — на сайте, следующая выгрузка сотрёт чью-то работу. Обычно 1С владеет ценами, остатками и учётными данными, сайт — маркетинговым контентом, SEO-полями и структурой каталога. Это решение нужно записать и донести до обеих команд.
3. Идентификаторы и справочники
Самая частая причина «поехавшего» каталога — привязка по названию или артикулу, которые меняются. Связь должна строиться на неизменном идентификаторе из 1С. Отдельно проговорите:
- как сопоставляются разделы каталога и группы номенклатуры;
- что делать с товарами, удалёнными или помеченными на удаление в 1С;
- как переносятся единицы измерения, кратность, НДС;
- как обрабатываются торговые предложения: размеры, цвета, комплектации.
4. Частота и объём
Полная выгрузка каталога — тяжёлая операция. Разделите обмены по скорости: цены и остатки часто и небольшими порциями, номенклатура и описания — реже, ночью. Заказы передавайте по событию, а не по расписанию, чтобы менеджер видел их сразу. Обмен обязательно должен работать порциями: пакет, подтверждение, следующий пакет.
5. Ошибки и повторные отправки
Сеть недоступна, 1С на обновлении, товар не прошёл валидацию — это штатные ситуации. Заранее решите:
- что происходит с заказом, если 1С не ответила: очередь и повтор, а не потеря;
- как обеспечивается идемпотентность — повторная передача не должна создавать дубль;
- кто получает уведомление об ошибке и как быстро;
- где смотреть журнал обмена: и техническая команда, и бизнес должны видеть, что и когда прошло.
6. Нагрузка и окна обмена
Тяжёлый обмен в часы пик замедляет сайт для покупателей. Договоритесь об окнах, ограничьте параллельность, следите за длительностью сессий. Если бизнес требует актуальных остатков в реальном времени, это отдельное архитектурное решение — обычно очередь сообщений или промежуточный сервис, а не учащение полной выгрузки.
7. Тестовый контур
Нужны тестовая база 1С и копия сайта с обезличенными данными. Проверять обмен на боевых данных — верный способ однажды выгрузить в магазин нулевые цены. В контуре прогоняются сценарии: новый товар, изменение цены, удаление, заказ, отмена заказа, возврат.
8. Что зафиксировать в документации
Короткого описания достаточно, но оно должно быть: перечень сущностей и полей, правила сопоставления, расписание, поведение при ошибках, контакты ответственных с обеих сторон. Через год этот документ сэкономит недели — особенно если команда сменится.
Итог
Хороший обмен — это не «настроили и забыли», а часть эксплуатации: за ним нужно наблюдать, его нужно чинить и развивать вместе с бизнес-процессами. Если вы только начинаете проект, начните с этой таблицы сущностей — она снимает большую часть будущих споров.