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

Какие документы решают разные задачи

Метод getSupplyRequestDocuments возвращает для FBY и LaaS список документов заявки. У каждой записи есть тип, ссылка и время создания. Среди типов отдельно предусмотрены список поставки SUPPLY, ошибки VALIDATION_ERRORS, акт приёма-передачи ACT_OF_RECEPTION_TRANSFER, акт расхождений ACT_OF_DISCREPANCY и акт вторичной приёмки SECONDARY_RECEPTION_ACT.

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

Сначала связать файл с нужной заявкой

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

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

Как хранить версии и изменения

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

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

Что проверять при расхождении

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

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

Документация проверена 22 октября 2026 года. Предложенный порядок архивирования является способом внутреннего контроля магазина. Он помогает воспроизвести сверку и объяснить выбор документа, но не объявляет новые правила приёмки Маркета и не устанавливает сроки рассмотрения претензий.