Интеграция с WMS: как синхронизировать резервы, остатки и отгрузки
Сайт принял заказ, учётная система передала его на склад, а сборщик не нашёл нужный товар. В отчётах позиция есть: часть уже зарезервирована, часть лежит на проверке после возврата. Ошибка возникает не в момент сборки, а раньше — когда разные системы принимают физическое наличие за возможность отгрузки.
Интеграция с WMS должна связать обещание покупателю с фактическими действиями склада. Для этого нужно согласовать состав данных, правила резервирования, подтверждения отгрузки и восстановление после сбоев. Работающий запрос к API проверяет только небольшой участок этой цепочки.
Что должна делать WMS, а что остаётся в учётной системе
WMS — система управления складом. Она организует приёмку, размещение, подбор, упаковку и другие складские операции. ERP ведёт ресурсы и хозяйственные операции компании. При интеграции важно распределить между ними конкретные действия, а не назначить одну систему главной сразу для всех данных.
Такое разделение есть, например, в документации Microsoft: в режиме Warehouse management only складская система выполняет логистические операции, а внешняя ERP отвечает за обработку заказов и финансовую часть. Это пример архитектуры, а не требование использовать определённый продукт.
В проекте стоит отдельно зафиксировать, кто создаёт задание на отгрузку, подтверждает резерв и сообщает фактически собранное количество. Интернет-магазину нужен результат этих действий: какой товар доступен, принят ли заказ складом и что уже передано в доставку. Внутренние маршруты сборщика для витрины обычно не нужны.
До обмена заказами нужно сопоставить товары
Одного названия позиции недостаточно. Две системы должны одинаково понимать товар, вариант, единицу измерения и склад. Для части ассортимента также важны партия, срок годности, серийный номер или владелец запаса. Эти признаки определяют не только поиск позиции, но и возможность выполнить конкретный заказ.
Microsoft выделяет справочные данные в отдельную часть интеграции: товары, варианты, штрихкоды и преобразования единиц измерения передаются до операций, которые на них ссылаются. В собственной схеме полезно сохранить такую зависимость: неизвестная позиция не должна автоматически подменяться похожей.
Например, если ERP передаёт количество в коробках, а WMS хранит штуки, в обмене нужен согласованный коэффициент пересчёта. Нельзя определять его по названию упаковки. После изменения комплектации старые документы должны оставаться связаны с теми условиями, по которым они были созданы.
У товара и каждой строки заказа нужны устойчивые идентификаторы. Номер строки на экране для этого ненадёжен: после удаления позиции нумерация может измениться. Несопоставленные значения лучше останавливать на проверке и показывать ответственному, а не пропускать с условным кодом «прочее».
Резерв покупателя и складское задание нельзя вычитать дважды
Возможны разные схемы: резерв подтверждает WMS, ERP или отдельная система управления заказами. Выбор зависит от существующего процесса. Ключевое условие — все каналы должны учитывать одно обязательство перед покупателем, даже когда оно отражено в нескольких системах.
Допустим, сайт закрепил за заказом две единицы, а WMS затем назначила конкретные товары для подбора. Это не обязательно ещё один независимый резерв. Если оба значения вычесть из наличия, система скроет от продажи лишние две единицы. Поэтому в обмене нужна связь между коммерческим резервом и его складским исполнением.
Пока склад не ответил, заказ должен находиться в явно обозначенном промежуточном состоянии. При отказе резерва потребуется изменить обещание покупателю. При потере ответа — сначала проверить исходную операцию, а не автоматически освобождать запас и продавать его другому человеку.
Отмену тоже следует согласовать с этапом работы склада. До начала подбора можно снять задание по одному правилу; после упаковки понадобится другая операция. Интерфейс не должен сообщать, что товар снова свободен, пока ответственная система не подтвердила освобождение резерва.
Остатки нужно сравнивать в одинаковых разрезах
Для обмена полезно разделить физическое наличие, количество под обязательства и запас, временно недоступный для продажи. Последняя группа может включать карантин и повреждённые позиции. Ожидаемое поступление следует хранить отдельно: его нельзя незаметно прибавлять к товару, который уже можно собрать.
Формула доступности зависит от исходных данных. Если WMS отдаёт физическое наличие, из него вычитают согласованные непересекающиеся категории ограничений. Если она уже рассчитала свободный остаток, повторное вычитание резервов даст неверный результат. Название поля «остаток» без описания состава здесь недостаточно.
Представим склад с десятью единицами товара: три закреплены за заказами, две находятся на проверке, одна выделена в страховой запас. Если эти группы не пересекаются, к продаже доступны четыре единицы. Это условный пример: в рабочей модели нужно проверить, не включён ли страховой запас уже в недоступное количество.
Сверка должна учитывать момент актуальности данных и одинаковый набор признаков. Нельзя сравнивать остаток по всем складам в ERP с одним складом в WMS или вчерашний снимок с текущим количеством. Microsoft отдельно описывает отчёт для сверки запасов с выбором даты и складских измерений.
Частичная отгрузка должна сохранять фактический состав
Создание задания, завершение подбора, упаковка и отгрузка — разные события. Для каждого необходимо определить, кто его подтверждает и какое действие оно запускает в соседней системе. Иначе письмо «заказ отправлен» уйдёт, когда товар только переместили в зону комплектации.
Если из трёх заказанных позиций склад отгрузил две, в учётную систему должны вернуться именно эти строки и количества. Для оставшейся позиции нужно отдельное решение: ждать пополнения, перенести в другую отправку или отменить. Общий статус заказа не должен скрывать незавершённый остаток.
У каждой отгрузки полезно хранить собственный идентификатор и связь со строками заказа. Тогда две реальные частичные отправки не превратятся в дубль, а повтор сообщения об одной отправке не создаст ещё один расход. Финансовые документы и уведомления следует формировать из подтверждённых фактов с учётом принятого бизнес-процесса.
Возврат проходит обратную цепочку, но не отменяет историю отгрузки. Товар принимают отдельной операцией и присваивают ему состояние по результату проверки. Простое переключение старого заказа из «отгружен» в «новый» потеряет сведения о том, что фактически произошло.
Как восстановить обмен после потери связи
При проектировании стоит исходить из того, что сообщения могут повторяться. Например, стандартные очереди Amazon SQS допускают повторную доставку. Поэтому обработка события должна быть идемпотентной: повтор той же операции сохраняет результат, а не ещё раз меняет запас.
Для этого нужен ключ конкретной операции, а не только номер заказа. Один заказ может законно иметь несколько резервов, изменений и частичных отгрузок. Если объявить все события с одним номером дубликатами, система потеряет реальные складские действия.
Результат обработки и сведения о принятом событии нужно сохранять согласованно. После тайм-аута интеграция проверяет операцию по её идентификатору. Запоздавшее сообщение сравнивает с текущей версией или допустимыми переходами состояния. Время получения само по себе не доказывает, что перед ней более новое изменение.
Сверка нужна и при наличии событийного обмена. Она выявляет пропущенные операции, несовпадающий состав отгрузки и расхождения остатков. В документации Microsoft есть отдельное предупреждение: совместное использование журнала изменений и сообщений о приёмке или отгрузке не должно приводить к двойному обновлению количества.
Как подключить WMS к 1С
Сначала нужно выяснить конфигурацию и доработки 1С, способы обмена выбранной WMS и доступные операции с документами. Проверять следует не только получение справочника, но и создание задания, изменение количества, отмену и обработку частичного результата.
У платформы 1С есть REST-интерфейс на основе OData: через него можно читать и изменять данные, создавать объекты и выполнять поддерживаемые операции с документами. Наличие этого интерфейса не означает, что любая WMS подключится без настройки соответствий и правил обработки.
Готовый коннектор стоит проверять на собственных сценариях склада. Отдельная разработка может понадобиться для нестандартных документов, нескольких владельцев товара или сложных правил распределения запасов. Сравнивать варианты полезно по составу поддерживаемых операций, диагностике ошибок и стоимости сопровождения, а не только по цене подключения.
Для обмена следует выделить отдельную учётную запись с необходимыми правами. В журнале достаточно сохранять сведения, которые помогают восстановить операцию; секреты доступа туда попадать не должны. Так разбор сбоя не потребует передавать администраторские полномочия каждому участнику поддержки.
Что проверить до первого рабочего заказа
Первый запуск разумно ограничить одним складом и типом заказа, но провести весь путь: создание, резервирование, сборку, отгрузку и отмену. До переключения необходимо согласовать исходные остатки и незавершённые задания. Иначе новая интеграция начнёт работу с уже накопленными расхождениями.
Для приёмки понадобятся не только успешные запросы, но и несколько аварийных сценариев:
- Одно подтверждение отгрузки приходит дважды — расход остаётся один.
- Ответ на резерв теряется — повторная проверка находит исходную операцию.
- Склад собирает часть заказа — ERP получает фактические строки и количества.
- Отмена приходит после начала подбора — система выполняет согласованный сценарий, а не просто освобождает товар.
- После перерыва в обмене сверка находит пропуски и не применяет уже учтённые изменения повторно.
Для каждого испытания нужно записать ожидаемые остатки, состояния документов и действия сотрудника. Допустимые задержки подтверждения и восстановления согласовывают с бизнесом: интеграция, приемлемая для плановой оптовой отгрузки, может не подходить для продажи последней единицы на нескольких витринах.
Результат работы — не только коннектор, но и карта соответствий, правила резервирования, журнал операций и процедура сверки. По одному заказу должно быть понятно, сколько товара обещано, сколько закреплено, что отгружено и на каком шаге требуется вмешательство.
Qtim занимается интеграциями e-commerce с 1С, ERP и WMS. Для обсуждения задачи полезно подготовить схему текущего обмена и пример заказа, который требует ручного исправления. Передать их команде можно в Telegram.
