Международный WB API: как проверять совместимость заданий при сборке поставки
Как спроектировать проверку заданий международного WB API перед объединением: склад, признаки поставки, очередь исключений и сверка фактического состава.
Содержание статьи
В международном WB API пустая поставка получает признаки первого добавленного задания: crossBorderType, cargoType и isB2b. Последующие задания должны им соответствовать и относиться к тому же складу. Поэтому автоматическое распределение заказов стоит начинать с проверки совместимости, а не с произвольного заполнения первой свободной поставки.
Подготовьте ключ группировки
Составьте в интеграции явное правило, какие данные определяют группу. Храните исходные значения, а читаемые подписи показывайте отдельно. Не вычисляйте тип задания из названия товара: одинаковые изделия могут участвовать в разных операционных сценариях, а похожее название не объясняет происхождение конкретного заказа.
До распределения выделите задания с отсутствующими или непонятными значениями. Их нельзя автоматически присоединять к самой большой группе, чтобы очередь выглядела пустой. Для оператора такая строка должна содержать причину остановки и действие для уточнения. Это редакционный способ организовать обработку исключений, а не новый набор обязательных полей, добавленный площадкой.
Осознанно выберите первое задание
Первое добавление задаёт свойства объекта, поэтому случайный порядок поступления может мешать ожидаемой структуре отправки. Сначала определите назначение поставки, затем выберите подходящие задания. Название поставки должно помогать сотруднику, но не заменять проверку её реальных свойств и состава.
Условный пример приёмки интеграции: подготовьте две совместимые строки и третью с отличающимся признаком. Проверьте, что третья остаётся отдельным исключением и её не пытаются повторно добавить в ту же группу без изменения исходных условий. Контроль документов для отдельных трансграничных сценариев рассматривается в материале о декларациях FBS; он не заменяет проверку состава.
Сверьте результат распределения
После добавления сопоставьте план с фактической принадлежностью заданий. Сохраняйте идентификаторы заданий и поставок, а не только количество строк. Совпавший итог «десять заказов» не доказывает, что в поставку попали именно нужные десять. При неполном результате выделите неподтверждённые строки, не отмечая всю пачку выполненной.
Повторный запуск должен опираться на актуальные данные. Если часть заданий уже распределена другим сотрудником, прежний план требует пересмотра. Не пытайтесь восстановить желаемую картину путём неявного переноса из чужой рабочей поставки. Сценарий возврата задания из доставки на сборку имеет отдельное назначение и не должен запускаться как скрытое исправление группировки.
Передайте исключения ответственному
В рабочем отчёте разделите причины: неизвестные данные, несовместимость с выбранной группой, изменение состава и технический сбой. Это позволяет исправлять конкретное основание, а не перемешивать заказы до исчезновения сообщения. Сохраните первоначальное решение, проверенные значения и итоговое действие для последующего разбора.
Материал ограничен международным контуром .cn и не утверждает автоматическую применимость к российскому API. При настройке другого подключения проверьте его документацию отдельно. Хорошо организованная комплектация даёт воспроизводимый результат: каждое задание относится к объяснимой группе, исключения не теряются, а перед отправкой команда видит подтверждённый состав поставки.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы