Как устроена интеграция 1С с сайтом на практике: какие данные обычно синхронизируют, какой обмен выбрать под ваш объём заказов и на что обратить внимание при настройке, чтобы остатки и цены не расходились.
Когда сайт и 1С живут отдельно друг от друга, рано или поздно это превращается в проблему: цены на сайте не совпадают со складом, заказы приходится переносить в учётную систему вручную, а остатки «плывут» в моменты пиковых продаж. Разберём, как выглядит нормальная интеграция 1С с сайтом и какой вариант обмена подходит для разного масштаба бизнеса.
Меню по статье
Что обычно синхронизируют между 1С и сайтом
В большинстве проектов интеграция закрывает четыре потока данных: каталог товаров с характеристиками, цены (часто в разрезе нескольких прайс-листов), остатки по складам и заказы, которые нужно передать из сайта обратно в 1С для сборки и бухгалтерии. Дополнительно синхронизируют статусы заказов, чтобы клиент видел на сайте актуальную стадию — оплачен, собран, передан в доставку.
Важно на старте зафиксировать именно этот список: чем шире набор синхронизируемых сущностей, тем сложнее обмен и тем больше точек, где он может сломаться.
Способы обмена: от файлового до REST API
Для связки 1С и Bitrix есть несколько рабочих вариантов, и выбор зависит от объёма и скорости, с которой должны обновляться данные.
- обмен по CommerceML через выгрузку файлов — стандартный механизм 1С-Битрикс, хорошо подходит для каталога и остатков раз в день или несколько раз в сутки;
- HTTP-сервисы 1С — позволяют дёргать данные и передавать заказы почти в реальном времени, без ожидания расписания;
- отдельный REST API или брокер сообщений — используется, когда нагрузка и число заказов уже не укладываются в файловый обмен и нужна отказоустойчивая доставка данных.
Для небольшого и среднего магазина стандартного CommerceML обмена в 90% случаев достаточно — переходить на что-то сложнее стоит только тогда, когда есть чёткая причина: очень частые изменения остатков, высокий поток заказов или несколько сайтов на одной базе 1С.
Кто источник данных для каждой сущности
Одна из главных причин, по которой интеграции «плывут» через несколько месяцев — никто заранее не договорился, какая система главная по каждому типу данных. Практика, которая обычно снимает большинство конфликтов:
- 1С — источник истины по товарам, ценам и остаткам, сайт их только принимает;
- сайт — источник истины по факту оформления заказа и данным клиента на момент покупки;
- после передачи заказа в 1С дальнейшие изменения статуса синхронизируются в сторону сайта, а не наоборот.
Если эту иерархию нарушить и разрешить редактировать одни и те же поля в двух местах одновременно, обмен рано или поздно начнёт перезаписывать ручные правки — и найти причину расхождения станет сложно.
Типичные проблемы после настройки обмена
Даже корректно настроенная интеграция требует наблюдения. Чаще всего проблемы всплывают не в момент запуска, а спустя время, когда меняется структура каталога или растёт нагрузка.
- расхождение остатков из-за резервирования товаров в заказах, которые ещё не проведены в 1С;
- дублирование товаров при смене артикулов или структуры характеристик без синхронизации сопоставлений;
- рост времени обмена по мере расширения каталога, если обмен изначально не предполагал инкрементальную выгрузку;
- потеря заказов при сетевых сбоях без механизма повторной отправки.
С чего начать интеграцию
Прежде чем настраивать обмен, стоит описать реальный процесс на бумаге: какие сущности синхронизируются, с какой периодичностью, кто источник данных и что происходит при сбое связи. Это занимает немного времени, зато экономит недели на исправлении обмена, который спроектирован «по ходу дела».
Для большинства сайтов на Bitrix стартовая точка — это стандартный обмен CommerceML для каталога и остатков плюс отдельный сценарий передачи заказов в 1С. Если бизнес растёт, к этой базе можно добавлять HTTP-сервисы для операций, которые критичны к скорости, не переделывая интеграцию с нуля.