Интеграция 1С с сайтом и приложением: когда стандартного обмена мало

Старт продаж. За вечер на сайт приходит больше заказов, чем 1С успевает принять. Выгрузка в учёт идёт ночами, иногда несколько дней, а потом бухгалтерия вручную ищет ошибки в заказах.

Так бывает, когда сайт или приложение растут быстрее, чем обмен с учётной системой. Стандартная интеграция сайта с 1С рассчитана на каталог и заказы. Когда каналов продаж становится больше, а данные нужны сразу, её перестаёт хватать.

Мы делаем сайты, приложения и B2B-порталы, которые работают поверх 1С. Саму 1С при этом не трогаем: учёт остаётся там, где его ведёт бухгалтерия. Ниже разбираем, по каким признакам видно, что обмена мало, и какие решения помогают без замены учёта.

Как устроена стандартная интеграция 1С с сайтом

Обмен с сайтом в 1С идёт по открытому протоколу, который разработали «1С» и «1С-Битрикс». Протокол описывает два процесса. В первом 1С выгружает на сайт каталог товаров. Во втором забирает с сайта заказы и потом синхронизирует их статусы. Данные идут в XML по схеме стандарта CommerceML.

Сеанс обмена в обоих случаях начинает сама 1С, а каталог уходит на сайт одним пакетом. Для каталога и обычных заказов этого хватает.

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

Признаки, что обмена мало

Проверьте свою связку по шести признакам. Если совпали два-три признака, типовой обмен с сайтом уже не справляется.

1. Заказы ждут выгрузки. В дни распродаж и старта продаж заказы уходят в 1С ночами, иногда несколько дней. Ошибки бухгалтерия находит уже после выгрузки и исправляет руками.
2. Сотрудники работают в обход учёта. Менеджерам удобнее править заказы на сайте или портале, чем в учётной системе. Правки остаются на портале и сами до 1С не доходят.
3. Остатки расходятся. Склад ведут в системе управления складом (WMS), а сайт берёт остатки из 1С. Какая система отвечает за резервы и статусы отгрузки, нигде не описано.
4. Акции расходятся. Акцию включили в магазинах, а сайту не передали. Покупатель видит на сайте одну цену, а в магазине другую.
5. Приложению нужны данные сразу. Покупатель выбирает товар, и приложение должно в ту же секунду показать остаток и цену с учётом бонусов. Ждать для этого следующего сеанса обмена нельзя.
6. Баз 1С несколько. Учёт разнесён по разным базам, и сайт собирает каталог, цены и остатки из каждой. Нагружать базы запросами нельзя.

Четыре решения без замены 1С

Все четыре решения оставляют учёт в 1С. Меняется то, как сайт, приложение и портал получают данные и возвращают заказы.

Очередь заказов между сайтом и 1С

Сайт принимает заказ сразу и кладёт его в очередь. 1С забирает заказы из очереди в своём темпе, поэтому пик продаж не тормозит учёт. У каждого заказа в очереди есть статус: принят, передан в 1С или ошибка.

Если 1С не приняла заказ, он остаётся в очереди вместе с причиной. Бухгалтерии не нужно искать его после выгрузки: ошибки видны сразу, и их разбирают по одной. Каждый заказ попадает в 1С один раз, даже если отправку пришлось повторить.

Так заказ идёт от сайта и приложения до 1С через очередь. Это модель: набор статусов в каждом проекте свой.

Слой данных поверх 1С

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

В слое удобно держать правила, которые часто меняются: персональные цены по договорам или статусы заказов на портале. Менеджер правит заказ в портале, и правка уходит в 1С документом. Работать в обход учёта больше незачем.

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

На схеме — модель слоя данных: откуда он берёт данные и кому их отдаёт.

Похожую связку мы делали в приложении Бетховена: карточку товара интегрировали с программой лояльности, складским учётом и каталогом акций. Когда покупатель выбирает фасовку, приложение в реальном времени подгружает остатки и цену с учётом бонусов и скидок.

Сверка остатков с WMS

Если склад ведут в WMS, сайту нужно знать, какая система за что отвечает. До разработки договоритесь, где живут остатки, резервы и статусы отгрузки.

Сайт и приложение берут каждое значение из той системы, которая за него отвечает. Слой сверяет остатки 1С и WMS и показывает расхождения до того, как их увидит покупатель.

Один источник акций

Акции и цены заводят в одной системе: в 1С, в программе лояльности или в слое данных. Оттуда они расходятся на сайт, в приложение и в магазины.

Если акцию включили в одном месте, её видят все каналы сразу. Цена на сайте и в магазине совпадает.

Что оставить в 1С

В 1С остаются учёт, справочники и первичные документы. Сайт и слой данных работают с копией нужных данных и возвращают в 1С заказы и документы. Бухгалтерия видит в 1С всё, что видела раньше, и работает как прежде.

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

Подробно о том, где провести границу между учётом и своей системой, — в отдельной статье.

Когда нужна интеграционная шина

Очередь и слой данных подходят, когда к 1С подключены сайт, приложение и портал. Систем вокруг учёта бывает больше: склад, CRM, программа лояльности, кассы, маркетплейсы. Если каждая связана с каждой, новое подключение ломает старые интеграции.

Тогда маршруты данных выносят в интеграционную шину (ESB). Системы перестают связываться напрямую и обмениваются сообщениями через шину. Так интеграция 1С с внешними системами остаётся управляемой, когда систем много. Для одного сайта и одной базы 1С шина избыточна.

Если сайт на 1С-Битриксе

Сайт на 1С-Битриксе обменивается с 1С через свой модуль обмена. Если сам сайт мешает запускать мобильное приложение, гибкую лояльность или нестандартные процессы, его можно заменить и сохранить связь с 1С.

При замене мы повторяем интеграции Битрикса один в один, и 1С вместе со смежными системами не замечает подмены. Неудачные интеграции перепроектируем, а совпадение проверяем тестами. Так же мы заменяем самописные порталы и бэк-офисы и сохраняем их интеграции.

С чего начать

Эти шаги можно сделать своими силами, до разговора с подрядчиком. С них начинаем и мы: перед интеграцией разбираем системы и точки, через которые они обмениваются данными.

1. Нарисовать карту обмена. Выпишите системы, связанные с сайтом и приложением, и данные, которые идут между ними: каталог, цены, остатки, заказы, акции. Отметьте, в какую сторону и как часто они идут.
2. Назначить главную систему для каждого вида данных. Для остатков это 1С или WMS, для акций — 1С или программа лояльности. Пока такой системы нет, данные будут расходиться.
3. Найти ручную работу. Отметьте, где сотрудники сверяют данные руками, правят заказы мимо учёта и ищут ошибки после выгрузки.
4. Выбрать первый поток. Начните с того, что болит сильнее: заказы в пик продаж или остатки. На одном потоке проще проверить, как новая связка работает с 1С.

Карта обмена пригодится при любом решении. По ней видно, где хватит доработки модуля обмена, а где сайту и приложению нужен свой слой поверх 1С.