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

Какие связи искать

Метод supply-requests возвращает заявки магазина по campaignId с фильтрами и сортировкой. Тип SUPPLY означает поставку, WITHDRAW — вывоз, UTILIZATION — утилизацию. Статус описывает состояние на момент запроса и может измениться: сохранённый экспорт не является неизменной итоговой историей.

В родительско-дочерних процессах доступны parentLink и childrenLinks. Такие связи встречаются при поставке на склад хранения, мультипоставке, дополнительной поставке, вывозе либо утилизации непринятого товара. В собственной системе храните идентификаторы связей как структуру, а не только копируйте название заявки в комментарий. Тогда сотрудник сможет перейти от проблемы к соседним этапам.

Разделить назначение и транзит

targetLocation содержит сведения о складе хранения или ПВЗ. При перевозке через транзит появляется также transitLocation. Эти поля нельзя считать двумя независимыми местами окончательного размещения одной партии. Для отчёта о маршруте сохраняйте обе роли: откуда принят транзит и куда должен попасть товар.

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

Привязать товары и документы

Для состава предусмотрен supply-requests/items, для документов — supply-requests/documents. Оба запроса используют идентификатор магазина и requestId. Сохраняйте файлы вместе с идентификатором конкретной заявки, а не только с датой поездки: при нескольких связанных операциях одинаковая дата недостаточно точно определяет документ.

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

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