Интеграция: Службы доставки + 1С

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

Типовые системы на этом конце: СДЭК, Boxberry, Почта России, DPD, Яндекс Доставка, 5Post, собственная курьерская служба.

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

Как с ней работать технически: Обмен идёт HTTP-сервисами (REST), типовым обменом EnterpriseData или CommerceML, реже — через OData и файловый обмен. У каждого варианта свои ограничения по объёму и частоте: массовую выгрузку каталога нельзя выполнять через тот же канал, что онлайн-запрос остатка.

В службу доставки уходят габариты и вес, адрес, состав заказа и объявленная ценность; обратно — тариф, срок, номер отправления, статусы и сумма к оплате при получении.

Мы всегда описываем обмен в виде таблицы «сущность — направление — частота — владелец данных». Без этого документа интеграция работает до первой нештатной ситуации, после чего расхождения ищут вручную.

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

Реализация зависит от того, есть ли у системы открытый API и какие у него лимиты. Если API нет или он ограничен, обмен строим через промежуточный слой: очередь, промежуточную базу или файловый обмен по расписанию с журналом обработки.

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

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

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

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

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

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

Первый шаг — обследование: смотрим, какие данные уже ведутся, кто владелец каждой сущности и какие ограничения есть у API. Затем делаем прототип обмена на тестовом контуре, проверяем нештатные сценарии (повтор, отмена, частичное выполнение) и только после этого выводим интеграцию в продуктив.

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