Статус DELIVERED в API Яндекс Маркета не всегда означает, что покупатель забрал весь состав заказа. При частичном невыкупе заказ также может иметь этот статус. Для управленческого отчёта нужно отдельно сопоставить заказ, невыкупленные позиции и последующие возвраты, иначе продажи окажутся завышены.

Разделить заказ и возврат

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

Чтобы понять, какие позиции покупатель действительно получил при частичном невыкупе, сравните items заказа и items невыкупа. Для товаров, которые продавец исключил самостоятельно, в данных заказа count может вернуться равным нулю. Такое исключение нельзя автоматически превращать в полноценную продажу с последующим возвратом: последовательность операций отличается.

Сверить деньги без двойного вычитания

Метод business orders возвращает исходную стоимость товаров, ещё не уменьшенную на невыкупленные и возвращённые позиции. Документация предлагает вычитать amount возврата из buyerItemsTotalBeforeDiscount. Применять такую операцию следует к правильно определённому возврату, сохраняя его идентификатор. Повторная загрузка той же записи не должна ещё раз уменьшать итог.

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

Как проверить обработку частичного заказа

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

Отдельно рассмотрите поздний возврат уже доставленного товара. Заказ мог попасть в прежний отчёт, а возврат — появиться позже. Храните дату обновления и пересчитывайте связанный результат при поступлении новых сведений; не ограничивайтесь однократной загрузкой доставленных заказов. Конкретный период управленческого отражения согласуйте с принятыми правилами учёта.

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