На полке осталась одна вещь, а в работу пришли два заказа — из Ozon и Wildberries. Перед исправлением остатка нужно ответить на конкретный вопрос: где возникло лишнее обещание товара — в каталоге, складском учёте, резервировании, публикации или обработке событий? У каждой причины свой способ исправления. Ускорение обмена не исправит связь с другим размером, а пересчёт не устранит повторное создание резерва.

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

Три отдельных доказательства
Резерв записанНайдена принятая операция с заказом и изменением количества.
Запрос отправленСохранены адрес, версия, время и ответ по строке товара.
Состояние прочитаноAPI канала вернул значение в конкретный момент наблюдения.
Ответ на запрос и последующее чтение не устанавливают момент доступности покупателю. Неизвестное время остаётся неизвестным; источник и наблюдение записываются раздельно.

Скачайте паспорт и журнал

Документ Пустой вариант Заполненный учебный пример
Паспорт инцидента: товар, исходные количества, вывод и следующая проверка Паспорт CSV Пример паспорта CSV
Журнал: заказ, резерв, отправка, ответ, последующее чтение Журнал CSV Пример журнала CSV

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

Инструкция и словарь всех полей объясняют импорт CSV, значения колонок и проверку чисел. В примере все события, идентификаторы и времена вымышлены. Это учебный разбор, а не клиентский кейс и не тест конкретной WMS.

CSV открывайте через импорт данных. Идентификаторы и временные отметки оставляйте текстом, чтобы сохранить ведущие нули и часовой пояс. Пустая ячейка означает, что факт не получен или поле неприменимо; она не означает нулевое количество.

1. Зафиксируйте границы инцидента

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

В паспорте также нужны единица измерения, границы времени и подтверждение исходного количества. «Одна штука» и «одна упаковка из двух штук» — разные величины. Если связь между карточками сомнительна, сначала разберите дубли SKU и штрихкодов: журнал обмена по неправильному товару даст убедительную, но неверную картину.

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

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

2. Сверьте смысл четырёх чисел

Для этого протокола используется определённая модель:

Величина Что входит
Годный физический остаток Годные единицы выбранного владельца на выбранном складе, включая зарезервированные
Активный резерв Подтверждённые обязательства, уже занявшие часть этого годного остатка
Отдельный блок Годный товар, временно недоступный по другой причине и не включённый в активный резерв
Буфер Количество, которое по принятому правилу не предлагают к продаже

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

Доступно до ограничения = годный физический остаток − активный резерв − отдельный блок − буфер.

Для учебной одной единицы после первого принятого резерва: 1 − 1 − 0 − 0 = 0. Физически вещь ещё может лежать в ячейке, но уже обеспечивать заказ.

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

Отрицательный результат сохраните в журнале как расхождение. Автоматическая замена отрицательного значения нулём на этапе диагностики скроет нехватку. Значение, допустимое для отправки площадке, определяется отдельно по её текущему контракту.

3. Соберите цепочку фактов

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

  1. Исходный срез. Сколько было годного товара, резервов и блоков; кто и каким способом подтвердил количество.
  2. Входящий заказ. Заказ и кабинет, вариант, количество, исходное время события и время получения вашей системой.
  3. Решение по резерву. Заявка на резерв, принятие либо отказ, фактическое изменение количества и ссылка на записанную операцию.
  4. Исходящая публикация. Конкретные кабинет, склад и вариант, отправленное абсолютное значение, версия локального состояния и идентификатор попытки.
  5. Ответ. HTTP-код, ошибки по позиции и бизнес-результат, если такой результат возвращается.
  6. Последующее чтение. Какое значение вернул тот же канал по тому же ключу и когда это наблюдалось.

Запись «заказ обработан» не заменяет пункт 3. Нужен факт сохранённого резерва. Аналогично запись «остаток отправлен» не заменяет пункты 5 и 6.

В примере поле request_id обозначает локальный идентификатор для связи запроса и ответа. Оно не предполагает, что площадка поддерживает одноимённое поле или ключ идемпотентности. Если источник не даёт event_id, специалист описывает используемый составной ключ и его границы. Номер заказа без кабинета может оказаться недостаточным.

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

4. Не смешивайте время события и время получения

У заказа могут быть время создания на площадке и время, когда его увидел коннектор. У публикации — время постановки в очередь, отправки, ответа и чтения результата. Если записать всё одним временем, задержка исчезнет из расследования.

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

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

5. Разделяйте отправку, ответ и наблюдение результата

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

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

В доступной англоязычной документации WB API отдельно описано, что при неверных названиях параметров возможен ответ 204 без обновления количества; для проверки состояния предусмотрено чтение остатков. Поэтому один успешный HTTP-код не заменяет проверку содержимого запроса и полученного состояния.

Проверка источников выполнена 31.10.2026. Для WB прочитана версия документации на домене .cn; российская страница при проверке не отдала текст. Схему запроса и ограничения конкретного кабинета сверяйте с его текущей документацией. Готовых API-запросов и обещаний времени синхронизации этот протокол не содержит.

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

6. Учебный разбор: два заказа, один внутренний резерв

Условный продавец хранит одну годную единицу одного размера. Два кабинета связаны с ней, исходные резервы и блоки равны нулю. В примере все времена ниже — время наблюдения одного учебного журнала, UTC+03:00. Часы площадок не сверены.

Время Факт и строка журнала Резерв / доступно в учёте Что можно заключить
10:00:00 Пересчёт: одна единица, E01 0 / 1 Есть подтверждённая начальная величина
10:00:01–02 Поочерёдное чтение WB и Ozon: 1, E02–E03 0 / 1 В API каждого канала наблюдалась 1 в свой момент. Одновременная доступность покупателю не установлена
10:00:04.100 Получен заказ A из Ozon, E04 0 / 1 Заказ появился во входящем потоке
10:00:04.150 Резерв A записан, E05 1 / 0 Первая единица занята
10:00:04.200 В WB отправлен остаток 0, E06 1 / 0 Запрос отправлен; применение ещё неизвестно
10:00:04.900 Получен HTTP 204, E07 1 / 0 Есть ответ, но обратного чтения ещё нет
10:00:05.000–05.050 Получен заказ B из WB; внутренний резерв отклонён, E08–E09 1 / 0 Второй заказ не получил второй резерв
10:00:05.200 Повторно пришло событие заказа A, E10 1 / 0 Учебная обработка не удвоила резерв
10:00:06.000 Чтение WB вернуло 0, E11 1 / 0 Ноль подтверждён только в этот момент наблюдения
10:00:06.100 Старая публикация значения 1 снята до отправки, E12 1 / 0 Учебная очередь не вернула старое число

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

Установлено: поступили два разных заказа, а учёт принял только один резерв. В этом журнале нет доказательства сбоя внутреннего резервирования. Есть основания исследовать окно внешней доступности и задержку получения заказа. Точное время применения нуля на WB и его причина не установлены.

В поле паспорта order_resolution оба заказа пока имеют статус pending: для A резерв принят, но дальнейшее исполнение ещё не подтверждено; для B резерв отклонён и требуется решение ответственного по правилам площадки. Это оставляет незавершённую работу видимой. Отказ внутреннего резерва не означает автоматическую отмену внешнего заказа.

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

7. Выберите действие по найденному доказательству

Что обнаружено Что проверять и исправлять Как проверить результат
Разные варианты ошибочно связаны с одной складской позицией Связи каталога, владельца, единицы и историю изменений Входящие заказы каждого варианта обращаются к правильному остатку
Пересчёт даёт меньше годного товара, чем учёт Непроведённые движения, пересорт, блоки, фактическое место; корректировку делать по принятому основанию Новый срез и журнал движений объясняют разницу
Две операции приняли резерв на одну единицу Общий пул резерва и защиту конкурирующих операций; два независимых чтения «есть 1» недостаточны Два конкурирующих запроса дают один резерв; отказ не меняет запас
Резерв принят, но публикация осталась в очереди либо отклонена Причину задержки, лимит, правильность ключа, ответ по позиции и владельца повторной попытки Текущая версия дошла до нужного ключа; старое задание не отправлено позже
После актуального значения пришло старое Порядок очереди, версии, ручные записи и все системы, меняющие этот остаток Поздняя старая команда не заменяет актуальное состояние; решение видно в журнале
Повтор сообщения создал второй резерв Ключ исходного события, область кабинета и сохранение результата первого применения Повтор сохраняет прежние количества и не создаёт новую операцию
Заказ получен после ответа на публикацию, других доказательств нет Время создания заказа, время применения, часы источников и данные последующего чтения Причина остаётся открытой до получения фактов; виновник не назначается по одному времени получения

На узком экране таблицу можно прокрутить вправо. С клавиатуры: Tab до таблицы, затем стрелки.

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

8. Три исключения, которые стоит проверить отдельно

Тайм-аут и повтор запроса

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

Отмена после подбора или упаковки

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

Для учёта возможен переход: резерв 1, блок 0 → резерв 0, блок 1. Доступность останется нулевой. После подтверждённой распаковки и проверки блок снимается, и годная единица становится доступной. Это пример модели без двойного вычитания, а не инструкция вручную менять поля конкретной WMS. Ozon отдельно указывает, что отправка нулевого остатка не изменяет уже существующий резерв площадки.

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

Неполная выгрузка или пропавшая строка

Отсутствующая строка не равна остатку 0. Уточните, полный ли это срез, как обозначено удаление и какие фильтры применены. Если один источник прислал только изменённые позиции, его нельзя использовать как полный перечень товара. Запишите пределы данных и запросите нужный срез. Не выводите из неизвестного положительный доступный остаток.

9. Что считать завершённым разбором

В итоговом паспорте должны быть: доказанная часть цепочки, причина либо явная гипотеза, недостающие сведения, решение по каждому заказу в order_resolution, адресное исправление, ответственный и проверка обычного/повторного/задержанного события. Для каждого order_id укажите результат и основание либо pending с конкретным следующим действием; пустое поле не означает завершённый заказ. Остаток и действующие резервы должны сходиться по одному владельцу, варианту, складу и моменту времени.

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

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

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