qwane

обмен с учётом

Интеграция 1С с сайтом: чтобы цена на витрине была ценой в счёте

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

Интеграция сайта и 1С почти всегда начинается с одной из двух картинок. Либо менеджер каждое утро выгружает прайс и остатки в файл и заливает его на сайт руками, либо обмен «уже есть», но никто не может сказать, когда он отработал в последний раз. Обе картинки заканчиваются одинаково: клиент оформляет заказ по цене, которой больше нет, или на товар, которого на складе не осталось, и разбираться с этим приходится человеку по телефону.

Сложность здесь не в протоколе. Выгрузить XML или дёрнуть HTTP-сервис умеет любой. Сложность в том, что «цена» и «остаток» в 1С — это не по одному числу на номенклатуру. Цена зависит от типа цен и договора конкретного контрагента, остаток — от склада, резервов и того, считаете ли вы товар в пути. Пока не решено, какие именно значения из учёта имеет право видеть покупатель на сайте и покупатель в кабинете, обмен настроить нельзя — можно только выгрузить что-нибудь и надеяться.

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

Скажу прямо, на чём этот подход основан, чтобы вы не достраивали за меня. Сама машинерия обмена — очереди на Redis и BullMQ, повторы, защита приёмника от дублей, журнал недоставленного — собрана и работает в партнёрской B2B-платформе, которую я вёл: там через неё ходят amoCRM, Битрикс24 и эквайринг. Стороны 1С в том проекте не было. То есть половину этой страницы я знаю по своей работе, а вторую — по вашей конфигурации, и её мы разбираем до того, как я назову цену.

Что ломается, пока это делают руками

Что ездит между 1С и сайтом и обо что спотыкается

Что передаёмНаправлениеГде обычно ломается
Номенклатура и характеристики1С → сайтСвойства заведены текстом, у одного товара «Синий», у другого «синий »
Цены1С → сайтТип цен и договорная скидка контрагента: на витрине цена одна, в счёте другая
Остатки1С → сайтРезервы и товар в пути: «свободный остаток» надо определить один раз и письменно
Заказысайт → 1СПовтор после сбоя создаёт второй заказ, если приёмник не узнаёт уже виденный
Статусы и отгрузки1С → сайтСтатус есть в учёте, но в кабинет его никто не отдаёт — клиент звонит менеджеру
Контрагенты и договоры1С → сайтКабинет должен знать, кто вошёл, чтобы показать его цены, а не общие
Оплаты и закрывающие1С → сайтДокументы лежат в учёте, а клиент просит их в кабинете и не находит

Что входит

Для кого

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

Частые вопросы

У нас типовая конфигурация и штатный обмен с сайтом. Этого мало?
Часто достаточно, и если так — я скажу это прямо, не продавая разработку. Штатный обмен упирается в две вещи: он выгружает одну цену на всех и не умеет ваши правила свободного остатка. Пока клиенты работают по общему прайсу, всё в порядке. Как только у половины покупателей свой тип цен по договору, штатной выгрузки не хватает.
Обмен обязательно должен быть в реальном времени?
Нет, и чаще не должен. Важна не мгновенность, а совпадение с обещанием: если на витрине написано «остаток обновлён 10 минут назад», это и должно быть правдой. Заказы обычно уезжают в учёт по событию — сразу, а цены и остатки идут пакетами по расписанию, которое подбирается под темп ваших изменений.
Кто будет дорабатывать сторону 1С?
Ваш 1С-подрядчик или штатный специалист — я в чужую конфигурацию не лезу и регламентированный учёт не трогаю. Моя половина работы — сайт, кабинет и слой обмена между ними и учётом; со стороны 1С нужны выгрузка и точка приёма. Что именно должно быть на той стороне, я описываю письменно, чтобы вашему 1С-нику не пришлось угадывать.
Мы обновляем конфигурацию. Обмен переживёт?
Переживёт, если он не читает внутренности конфигурации напрямую, а работает через согласованный формат, и если у него есть журнал. Тогда изменение на той стороне видно сразу: пакеты перестают приниматься, приходит алерт, и правится маппинг, а не весь обмен. Без журнала обновление конфигурации всегда обнаруживается через несколько дней и через клиента.

Есть процесс, который держится на людях?

Опишите его — скажу, что здесь автоматизируется, а что не стоит трогать.

Обсудить проект

Смежные процессы

Все процессы автоматизации