Состав заявки FBY содержит несколько количественных показателей по каждому SKU. Их нужно сопоставлять с документами и стадией заявки, а не складывать все числовые поля в единую сумму «поставлено».

Что именно вернул API

В counters документация выделяет planCount — количество в заявке, factCount — принятое складом, defectCount — товары с браком, shortageCount — товары с недостатками и surplusCount — лишние товары. Сохраняйте названия полей рядом с понятными подписями. Не переименовывайте спорное поле по догадке разработчика и не выводите из перечисления готовую формулу баланса.

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

Как выбрать правильную заявку

Запрос товаров принимает requestId. Официальная справка предупреждает, что по этому идентификатору заявку не найти в кабинете: там используются marketplaceRequestId или warehouseRequestId. Поэтому сохраните соответствие номеров до передачи вопроса логисту. Один технический ключ в письме без пояснения может сделать поиск расхождения бессмысленно долгим.

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

Как не потерять часть товарных строк

Метод поддерживает постраничное чтение через pageToken и nextPageToken. Обработчик должен пройти весь результат, сохраняя контекст заявки. Пустую последнюю страницу или завершение пагинации не следует путать с пустой поставкой. При повторном запуске проверяйте, что строки не добавляются второй раз к уже сохранённому снимку.

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

Как разобрать обнаруженное различие

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

Закрывайте сверку после объяснения конкретных SKU, а не после совпадения общей суммы по грузу. Избыток одного артикула и отсутствие другого могут взаимно скрыться в итоговом числе. Зафиксируйте решение и ответственного по каждой спорной строке. Документация проверена 22 октября 2026 года; предложенная структура контроля не заменяет официальные документы приёмки и установленный порядок обращения.