Интеграция портала с 1С, ТМС и WMS: четыре способа обмена и как выбрать свой

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

На технической встрече обсуждают другое — перечисляют системы: 1С, ТМС, WMS, иногда CRM и систему брокера. Перечень уходит в техническое задание, по нему сравнивают предложения, и почти никто не спрашивает, каким способом портал будет получать данные. А решает именно способ: от него зависит, что увидит клиент, когда 1С недоступна, и почему две оценки расходятся втрое.

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

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

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

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

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

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

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

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

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

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

Это самый надёжный способ для всего, от чего зависит операционная работа, и самый требовательный к проектированию. Решать придётся неудобное: что делать, когда одно событие пришло дважды, — а оно придёт; как восстановить состояние после простоя приёмника; что показывать, если «прибыл» обогнал «вышел»; кто заметит, что очередь встала. Ни один из этих вопросов не виден на макете, и все они оплачиваются рабочим временем. На них и расходятся оценки.

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

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

Главная ценность — развязка. Замена ТМС затрагивает один слой, а не весь портал: корпоративные продукты живут годами, и хотя бы одна учётная система за это время сменится почти наверняка. Второе, менее очевидное: слой — то место, где решается спор, какая система служит источником истины для каждого поля. В портале его решать поздно.

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

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

Выпишите потоки столбиком — обычно их от восьми до двадцати — и проставьте напротив каждого способ. Это и есть техническое содержание строки «интеграции»: с такой таблицей можно идти к трём подрядчикам и сравнивать сопоставимое.

Ближе всего к теме у нас перезапуск GrandeBoutique.ru — сети мультибрендовых бутиков из Уфы с ассортиментом свыше 35 000 наименований и более чем тридцатью интеграциями в одном проекте. Тридцать с лишним обменов за одной строкой сметы — и каждый со своей частотой и своим поведением при сбое. Сам обмен заказчик вынес в задачу наравне с дизайном: постоянная связь склада и сайта ради актуальных остатков и синхронизации поставок, интеграция с CRM, запас на развитие.

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

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

TagLex работает в международной логистике третий десяток лет: офисы в Москве, Петербурге, Новороссийске и Владивостоке, агентская сеть в 50+ странах, в год — свыше 10 000 TEU и 3 800+ таможенных деклараций. По масштабу — первый кандидат на портал со статусами и обменом с ТМС.

Закрытого контура в этом проекте нет, и мы его не делали — говорим прямо, чтобы не выдавать желаемое за сделанное. Сделан публичный сайт: каждая услуга — сценарий перевозки, и обновляет всё это команда TagLex в собственной админке. Менеджеры отправляют ссылку на услугу вместо презентации, а запрос на расчёт приходит уже с параметрами груза.

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

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

Что обмен делается один раз. Учётные системы обновляются, поставщики меняют форматы, у брокера меняется процедура — и поток, работавший год, однажды замолкает. Сопровождение со сроком реакции нужно с первого дня, а не после первого сбоя.

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

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

А если предложение на портал у вас уже есть — пришлите из него только раздел про интеграции. Разберём по шести вопросам выше и скажем, какие потоки не названы и какие сценарии отказа пропущены.