Пятый фактор Обсудить задачу
CRM, 1С и интеграции

Доработка поставок Ozon FBO кросс-докинг под macrolocal_cluster_id

С 16 февраля 2026 года Ozon изменил Seller API для кросс-докинговых поставок FBO. Методы /v3/supply-order/get и /v1/supply-order/details возвращают macrolocal_cluster_id, значение storage_warehouse.arrival_date приходит как null, а планирование кросс-докинга строится по кластеру. Расчёт черновика, таймслоты и заявка на поставку также привязаны к кластеру.

Мы находим места, где WMS, ERP или внутренний кабинет хранит конкретный warehouse_id как основу маршрута, и переводим их на устойчивый идентификатор macrolocal_cluster_id. Справочник связывает кластер Ozon с внутренним направлением поставки, зоной обслуживания и ответственным складским процессом. Обработка ответа спокойно принимает пустой arrival_date и использует актуальные данные выбранного таймслота.

Готовый процесс проводит поставку по всей цепочке: товары и объёмы попадают в расчёт, сотрудник выбирает допустимый кластер и таймслот, система создаёт заявку и получает её детали. Журнал сохраняет cluster ID, идентификаторы черновика и supply order, выбранное окно и результат каждого шага. Логист может проверить маршрут в одном экране и быстро найти этап, который требует внимания.

Срок: 10 рабочих дней

Когда стоит обратиться

Обычно к нам обращаются в таких ситуациях:

  • Расчёт кросс-докинговой поставки ищет конкретный склад Ozon и перестал возвращать ожидаемый вариант после 16 февраля 2026 года.
  • Обработчик /v3/supply-order/get или /v1/supply-order/details падает, когда storage_warehouse.arrival_date содержит null.
  • WMS хранит warehouse_id в качестве ключа маршрута, а новый ответ Ozon содержит macrolocal_cluster_id.
  • Сотрудник создаёт черновик и таймслот в кабинете, потому что внутренняя система ещё работает по старой складской модели.

Что именно мы сделаем

01

Находим использование warehouse_id и arrival_date в расчёте, таймслотах, создании и чтении FBO-поставок.

02

Добавляем macrolocal_cluster_id в модель данных и связываем кластеры Ozon с внутренними направлениями логистики.

03

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

04

Корректируем ответы supply-order, обработку null, статусы, журнал и повтор временных ошибок.

05

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

Что входит в стоимость

59 900 ₽ за всю работу

Разбираем интеграцию поставок FBO кросс-докинг, методы /v3/supply-order/get и /v1/supply-order/details, расчёт черновика, получение таймслотов и создание заявки. Переносим логику выбора с конкретного склада на macrolocal_cluster_id, корректируем обработку arrival_date: null и сопоставление с WMS, ERP или кабинетом. Проверяем действующую поставку по всей цепочке.

Что будет готово

Материалы

Передадим вам

  • Обновлённая интеграция поставок Ozon FBO кросс-докинг с поддержкой macrolocal_cluster_id.
  • Справочник соответствия кластеров Ozon и внутренних логистических направлений WMS или ERP.
  • Рабочая цепочка расчёта, таймслота, создания и чтения supply order с журналом идентификаторов.
  • Протокол контрольной поставки и инструкция диагностики расчёта, окна и статуса заявки.
Проверка

Перед сдачей проверим

  • Расчёт черновика и список таймслотов формируются для выбранного macrolocal_cluster_id.
  • Кросс-докинговая заявка создаётся с кластерной привязкой и сохраняет supply order во внутренней системе.
  • Ответы /v3/supply-order/get и /v1/supply-order/details обрабатываются при arrival_date: null и сохраняют cluster ID.
  • Позиции, объёмы, кластер, временное окно и статусы совпадают между Ozon и контрольной записью WMS либо ERP.

Как это выглядит на практике

Доработка Ozon FBO кросс-докинга под macrolocal_cluster_id

WMS формирует кросс-докинговую поставку через выбранный кластер

  1. 01

    Логист выбирает товары и объёмы, а WMS запрашивает расчёт доступного маршрута кросс-докинга Ozon.

  2. 02

    Интеграция сохраняет macrolocal_cluster_id и показывает таймслоты, относящиеся к выбранному кластеру.

  3. 03

    После подтверждения окна система создаёт supply order и связывает его ID с внутренним документом поставки.

  4. 04

    Повторное чтение деталей принимает пустой arrival_date, сверяет кластер и обновляет статус для склада.

Что понадобится для работы

От вас

  • Код и настройки интеграции Ozon Seller API, которая рассчитывает или создаёт FBO-поставки кросс-докинг.
  • Токен продавца с нужным доступом и возможность провести контрольную поставку в доступном контуре.
  • Примеры ответов supply-order, внутренние записи warehouse_id, черновиков, таймслотов и заявок.
  • Описание маршрутов WMS или ERP и логист, который подтвердит кластер, окно, товары и статусы.

Если у вас немного другая ситуация

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

Стоимость работ 59 900 ₽ полная стоимость известна заранее
  1. 3 000 ₽после подписания договора через Диадок
  2. 56 900 ₽после выполнения, демонстрации и приёмки результата

Предоплата входит в общую стоимость. Оставшуюся сумму оплачиваете после демонстрации и приёмки готовой работы.

Часто спрашивают

Об этой услуге

Что изменилось в Ozon FBO кросс-докинге 16 февраля 2026 года?

Планирование кросс-докинговых поставок перешло к кластерной модели. В ответах появился macrolocal_cluster_id, а расчёт черновика, таймслоты и создание заявки выполняются для кластера.

В каких методах появился macrolocal_cluster_id?

Ozon указал изменение для /v3/supply-order/get и /v1/supply-order/details. Мы читаем новое поле, сохраняем его в модели поставки и связываем с черновиком и внутренним маршрутом.

Что делать с warehouse_id в старой интеграции?

Находим все решения, где этот ID определяет кросс-докинговый маршрут, и переводим логику на macrolocal_cluster_id. Историческое поле можно сохранить для сопоставления ранее созданных записей.

Почему arrival_date теперь приходит как null?

Ozon объявил такое значение для storage_warehouse.arrival_date в указанных методах поставок. Обработчик принимает null, а выбранное время хранит по выбранному таймслоту.

Изменение касается обычных FBO-поставок?

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

Можно связать кластер Ozon с WMS или ERP?

Да. Создаём справочник cluster ID и внутренних направлений, сохраняем его в настройках и показываем логисту понятные названия при выборе маршрута.

Что произойдёт с уже созданными поставками?

Чтение исторических и действующих записей проверяем отдельно. Интеграция сохраняет доступные старые идентификаторы и добавляет cluster ID в актуальную модель, чтобы журнал отражал обе версии данных.

Как принимается доработка FBO кросс-докинга?

Проходим расчёт, выбор кластера и таймслота, создание supply order и чтение деталей. Затем сверяем товары, объёмы, macrolocal_cluster_id, окно и статусы с внутренней записью.

Цена и изменения по ходу работы

Цена на странице окончательная?

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

Что означает резерв незапланированных работ?

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

Резерв рассчитывается по формуле: стоимость услуги × 30% ÷ 1 500 ₽. Для услуги за 30 000 ₽ это 6 часов. Эти часы относятся только к дополнительным, заранее незапланированным уточнениям. Они не являются сроком проекта и не ограничивают время на основную работу: согласованный результат мы выполняем полностью.

Можно уточнять детали уже во время работы?

Да. Небольшие связанные изменения обычно помещаются во включённый резерв и не требуют доплаты. Если новая идея заметно меняет результат или превращается в самостоятельную задачу, сначала обсудим подход и стоимость. Любое решение согласуем до выполнения.

Начало работы и оплата

Как оформляются договор и оплата?

Подписываем договор через Диадок. Предоплата составляет 3 000 ₽ и входит в общую стоимость услуги. Остаток оплачивается после демонстрации и приёмки готового результата.

Когда начинается срок выполнения?

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

Как учитываются платные лицензии и внешние сервисы?

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

Проверка результата и гарантия

Как принимается готовая работа?

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

Какая гарантия действует после сдачи?

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

Следующий шаг

Опишите задачу

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

Для безопасности не отправляйте в заявке пароли, коды доступа, токены, паспортные и медицинские данные.