28 сентября Wildberries расширил детализации к отчётам реализации реквизитами B2B-покупателя и первичных документов. В ответах появились КПП покупателя, номер и дата УПД или УКД. Эти сведения помогают связать строку выгрузки с документальным контуром продажи, если внешняя учётная система их сохраняет.

Какие поля добавлены

Обновление затрагивает POST /api/finance/v1/sales-reports/detailed/{reportId} и POST /api/finance/v1/sales-reports/detailed. Поле buyerTaxRegistrationReasonCode передаёт КПП B2B-покупателя, utdUcdNumber — номер УПД или УКД, utdUcdDate — дату такого документа. Площадка сообщила об изменении состава ответа, поэтому при чтении детализаций нужно проверить обработку новых значений.

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

Как связать продажи и документы

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

Проверяйте случаи, когда несколько строк относятся к одному документу, а также ситуации с корректировками. Если приложение ошибочно считает каждую строку самостоятельным документом, оно завысит количество операций. Если, наоборот, слишком грубо объединяет записи, часть товарных позиций или изменений потеряется. Контрольная сверка должна учитывать структуру конкретной выгрузки.

Почему нельзя терять пустые значения

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

Для команды удобен отдельный список несопоставленных строк с объяснением причины. В одном случае не хватает документа во внутреннем реестре, в другом требуется уточнить кабинет или период, в третьем не совпали реквизиты. Такой список превращает сверку в конкретную рабочую очередь вместо ручного поиска по нескольким большим файлам.

Что проверить после обновления загрузки

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

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