Для заказа с обязательной маркировкой недостаточно успешно передать коробки в API Яндекс Маркета. Перед готовностью к отгрузке нужно проверить результат для каждого обязательного кода. Справка проверена 18 октября 2026 года; это дата проверки инструкции, а не объявления новой функции.

Отделить ответ запроса от результата по экземпляру

Метод identifiers/status доступен для FBS, Экспресса и LaaS. Он возвращает позиции заказа с массивами CIS и УИН. Внешний status со значением OK описывает обработку запроса, но не заменяет проверку внутренних состояний. Маркет разрешает READY_TO_SHIP только после передачи всех необходимых идентификаторов через boxes и успешной проверки кодов.

В рабочей системе связывайте результат с заказом, позицией и конкретным экземпляром. Не присваивайте всему заказу зелёный индикатор по первой успешной строке: остальные единицы могут требовать исправления. Саму передачу состава рассматривает инструкция о согласовании раскладки FBS по коробкам; здесь задача начинается после неё.

Развести техническую ошибку и отрицательную проверку CIS

Для CIS состояние FAILED означает, что проверить код не удалось; документация предлагает повторить попытку позже. INVALID означает отрицательный результат и запрет продажи экземпляра с этим кодом. IN_PROGRESS обозначает ожидание проверки, NOT_ON_VALIDATION — отсутствие отправки, OK — успешный результат.

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

Для ювелирных изделий читать отдельные статусы УИН

У УИН значение FAILED уже означает непрохождение проверки. NOT_ON_VALIDATION может означать отсутствие отправки или неполный набор УИН в заказе. Поэтому общий обработчик одинаковых названий статусов для CIS и УИН опасен: одинаковая строка не гарантирует одинакового действия.

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

Принять интеграцию на смешанном заказе

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

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