Как не потерять заказы и остатки на обмене с 1С

К нам часто обращаются за рефакторингом и доработкой проектов с внешними интеграциями — чаще всего с 1С. Со штатными механизмами обычно проблем немного.

Но стоит появиться нестандартному flow — и всё начинает ломаться. И здесь важно не искать виноватого в 1С, аразобраться, где заканчиваются возможности стандартного обмена и начинается архитектура конкретного e-commerce-проекта.

Например, когда изменения происходят не сотнями, а десятками тысяч раз в день — как в одном из наших проектов. Это была продуктовая сеть: 10 магазинов, примерно по 5000 товаров в каждом. В сумме остатки менялись около 50 000 раз в день. Штатный обмен уже не справлялся с такой нагрузкой.

Мы собрали самописную шину данных на базе SQL. 1С через интерфейс записывала изменения небольшими пакетами: товар, склад, остаток. Дальше очередь разбирал отдельный обработчик.

Почему это сработало? Мы убрали ненужные данные и посредников, не переписывая весь обмен — только изменили участок, который ограничивал производительность.

Этот кейс хорошо показывает простой принцип: не стоит пытаться передавать через один механизм вообще всё: — быстрые данные (остатки и цены) должны идти одним способом, например через API или ORM. — обычные операции (заказы и изменения товаров) — другим. — тяжёлые и редкие данные (файлы и изображения) — третьим.

Кейс: как мы перестали терять заказы между сайтом и 1С Другой проект — магазин с 3–5 тысячами заказов в день через Битрикс. Проблема была неприятнее: часть заказов не доходила до 1С.

Пакеты периодически терялись между системами — хаотично и без понятной закономерности.

Мы подняли резервный канал обмена через Datareon — по сути, очередь сообщений. Сайт начал дублировать информацию о заказе туда. 1С обрабатывала очередь и при необходимости могла повторно запросить данные.

Со временем резервный канал стал основным: через него перевели обмен товарами, остатками, ценами и заказами. Штатный обмен при этом оставили как резервный.

И здесь важен не сам факт наличия 1С, а понимание, какие данные, с какой скоростью и по какому сценарию должны проходить между системами, и что произойдёт, если основной канал не сработает?

Именно это помогает избежать ситуации, когда сайт показывает клиенту товар, которого уже нет, или заказ есть у клиента и на сайте, но почему-то отсутствует в 1С.

А у вашего обмена есть план Б?