Заказ остаётся «в доставке»: сверка передачи и статусов

Содержание статьи

• Рабочий лист: одна карточка на одно отправление
• Почему название вкладки не даёт готового ответа
• Шаг 1. Убедитесь, что сравниваете один объект
• Шаг 2. Установите последнее подтверждённое место
• Шаг 3. Снимите статусы с отметками времени
• Шаг 4. Выберите действие по фактам
• Учебный пример: статус площадки изменился, локальный экран ещё нет
• Что передать поддержке и когда закрывать разбор
• Следующий шаг
• Источники и границы проверки

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

Ниже — методика для менеджера селлера и фулфилмента, работающих с FBS Wildberries и Ozon в России. Она помогает разобрать один случай без изменения остатков и повторной отгрузки. Правила realFBS, FBO и международной доставки проверяются отдельно.

Рабочий лист: одна карточка на одно отправление

Скачать пустую карточку сверки, CSV · Скачать заполненный учебный пример, CSV · Инструкция к файлам.

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

На телефоне таблицу можно прокрутить вправо.

CSV открываются импортом текста в UTF-8 с разделителем «запятая». Идентификаторы и временные отметки лучше импортировать как текст. Формат CSV сохраняет значения; оформление табличного редактора в него не входит.

Почему название вкладки не даёт готового ответа

Складское задание, физическое отправление и запись маркетплейса описывают разные стороны процесса. Упаковщик может закончить работу раньше, чем принимающая сторона подтвердит сдачу. Доставка покупателю завершается позже передачи со склада. Локальная система показывает полученные и обработанные ею сведения; их актуальность нужно проверить.

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

В Ozon для технической сверки нужны данные конкретного отправления. Официальные материалы отдельно называют status и substatus; их следует сохранять в исходном виде, когда они присутствуют в ответе. Нельзя автоматически считать текст локальной вкладки точным переводом одного поля API. Seller API FAQ, проверен 31.10.2026.

Шаг 1. Убедитесь, что сравниваете один объект

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

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

При несовпадении ID сначала исправьте предмет сверки. Иначе можно принять статус соседнего отправления за подтверждение доставки и ошибочно закрыть разбор.

Шаг 2. Установите последнее подтверждённое место

Вопрос «где товар?» разбейте на последовательные проверки:

1. Осталось ли конкретное грузоместо в зоне готовой отгрузки? Проверьте этикетку, а не только свободное место на стеллаже.
2. Кто и когда передал его следующему участнику? Найдите запись передачи, реестр или применимый документ.
3. Есть ли подтверждение принимающей стороны именно по этому отправлению? Сверьте идентификаторы и результат приёмки.
4. Есть ли расхождение по составу, количеству или состоянию? Сохраните его отдельной записью.

Запись «машина выехала», созданный PDF и фотография закрытой коробки отвечают на разные вопросы. Для разбора важна связка: конкретное место, участник, время, документ и подтверждение. Юридическую достаточность доказательств определяют применимые условия площадки и договора; эта карточка не заменяет процедуру претензии.

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

Шаг 3. Снимите статусы с отметками времени

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

При доступе к техническому журналу попросите уполномоченного специалиста проверить:

• метод и версию запроса, кабинет и искомый идентификатор;
• возвращённый статус и подстатус либо другие поля состояния;
• время получения ответа и результат его обработки локальной системой;
• ошибку запроса, неполную выборку или отсутствие нужного объекта;
• правило, по которому исходное значение превращается в локальную подпись.

Для Ozon метод POST /v3/posting/fbs/get включён в официальную роль Posting FBS read-only. Это пример того, почему безопасный способ проверки определяют по назначению метода и правам, а не по одному слову GET или POST. Перед технической работой сверяют актуальный контракт и используют уже разрешённый доступ. Маппинг ролей Seller API, проверен 31.10.2026.

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

Три разных времени

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

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

Шаг 4. Выберите действие по фактам

На телефоне таблицу можно прокрутить вправо.

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

Учебный пример: статус площадки изменился, локальный экран ещё нет

Все события ниже вымышлены. Это пример заполнения карточки, а не случай клиента Skirbo и не измерение скорости Ozon.

Отправление TRAIN-POST-001-1 связано с одним кабинетом и одним локальным заданием. Учебный документ TRAIN-ACT-09 содержит его строку и отметку принимающей стороны. Все отметки приведены в UTC+03:00.

На телефоне таблицу можно прокрутить вправо.

Факт: источники по одному объекту расходятся. Гипотеза: локальные сведения могли устареть. Но без журнала нельзя исключить ошибку сопоставления ID или отображения.

Менеджер передаёт карточку специалисту по обмену и назначает внутреннюю контрольную точку 17:30. Специалист сверяет последний ответ, обработку конкретного ID и правило подписи, затем повторно читает результат. Значение 17:30 — решение учебной команды, не SLA площадки или Skirbo. Карточка остаётся открытой до подтверждённого результата.

Из разницы между 17:12 и 17:14 нельзя получить точную задержку обмена: это два наблюдения. Неизвестно, когда площадка изменила статус и был ли ответ уже обработан локально.

Что передать поддержке и когда закрывать разбор

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

Удалите API-ключи, токены, cookies, адреса покупателей и чужие заказы. Если службе поддержки нужен идентификатор кабинета, передайте его через предусмотренный канал в пределах своих полномочий.

Разбор можно закрыть, когда сопоставлены идентификаторы и подтверждения, установлена причина расхождения, новый результат проверен чтением, а незавершённые споры по приёмке или возврату получили отдельное ответственное действие. Надпись «Доставлено» в одной системе не закрывает автоматически спор о потерянном грузоместе.

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

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

Выберите одно спорное отправление и заполните карточку сверки. Если вопрос возник при работе со Skirbo, откройте поддержку Skirbo и передайте безопасный набор фактов. Открытие ссылки само по себе не отправляет обращение.

Наличие времени обмена, исходного ответа и нужной детализации в конкретном интерфейсе нужно проверить отдельно. Карточку можно вести вручную; она не предполагает, что какая-либо интеграция или автоматическая диагностика уже включена в вашем кабинете.

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

Источники и границы проверки

Проверка источников: 31 октября 2026 года. Рабочая методика и учебные данные подготовлены редакцией; они не являются результатом испытания клиентского кабинета.

• WB: отмена заказа. Дата обновления страницы — 28.05.2026. Использована для различения вкладки и состояния готовности к отгрузке.
• Ozon: Seller API FAQ. Исходная публикация — 06.09.2023; страница сообщает о поддержании таблицы, отдельная дата последнего изменения не указана. Использованы различение status/substatus и терминология учебного примера.
• Ozon: роли и методы Seller API. Исходная публикация — 15.08.2024; таблица включает информационный метод FBS. Прочитанная справка не подтверждает работу конкретного ключа или адаптера.

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