Яндекс Маркет добавил лист «Приемка поставки» в отчёт API: что проверить продавцу

Что именно изменил Яндекс Маркет 20 августа

В официальном журнале Partner API за 20 августа появилось точечное, но практическое изменение. Для метода генерации отчёта по стоимости услуг добавлен лист «Приемка поставки». В машинных форматах этот раздел обозначается именем goods_acceptance. Речь идёт не о новом endpoint и не о замене старого отчёта, а о расширении состава результата, который возвращается после формирования документа.

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

Маркет не опубликовал в записи журнала отдельную миграционную инструкцию. Поэтому безопасная реакция состоит не в угадывании колонок, а в получении собственного свежего отчёта и сравнении его структуры с тем, что обрабатывает ваша система. Особенно это касается самописных загрузчиков, шаблонов Power Query и обменов с учётом маркетплейсов в 1С.

Кого касается новый лист goods_acceptance

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

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

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

Почему это не просто косметическое изменение файла

Финансовая автоматизация часто строится вокруг предположения, что структура отчёта стабильна. В XLSX код может искать листы по точным названиям и завершать работу, если их количество изменилось. В CSV или JSON загрузчик может распаковывать только заранее перечисленные файлы. Есть и опасный мягкий вариант: неизвестный файл просто игнорируется, основная загрузка считается успешной, а часть данных исчезает без сигнала.

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

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

Как сейчас получается отчёт через Partner API

Рабочая последовательность остаётся асинхронной. Сначала интеграция отправляет POST-запрос на генерацию отчёта и передаёт настройки периода и магазинов. В ответ она получает идентификатор reportId. Затем отдельным GET-запросом проверяется статус. Когда документ готов, сервис возвращает ссылку на скачивание.

Ссылка ограничена по времени: официальная инструкция указывает 60 минут с момента её получения. Поэтому сохранять URL в очередь «на потом» нельзя. Сценарий должен скачать файл сразу, проверить HTTP-ответ, размер и тип содержимого, а уже затем передать документ в обработку. Повторный запрос статуса формирует новую подписанную ссылку, но это не повод строить процесс на просроченных адресах.

Метод допускает несколько форматов. FILE означает XLSX, CSV и JSON приходят как ZIP-архивы с отдельными файлами для листов отчёта. Язык можно выбрать русский или английский. Для API-Key требуется доступ к финансовой информации и отчётности либо более широкий разрешённый доступ. Ключ нельзя записывать в лог вместе с телом ошибки.

Фильтры позволяют указать кабинет, магазины, ИНН, модели размещения и период. Для интервала дат документация ограничивает максимальный период тремя месяцами. Если ваш процесс запрашивает год одним вызовом, ошибку надо исправить отдельно от сегодняшней новости.

Что проверить, если вы забираете отчёт в XLSX

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

Если используется Power Query, проверьте шаг навигации к объекту и список ожидаемых таблиц. Если файл читает Python, PHP или Node.js, добавьте журналирование обнаруженных листов и отдельное правило для goods_acceptance. Исходный XLSX сохраняйте до преобразований. Это даст возможность повторить загрузку после исправления схемы и не запрашивать тот же период заново.

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

Что проверить для CSV и JSON

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

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

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

Как не сломать импорт из-за нового листа

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

Добавьте идемпотентность: повторная загрузка того же отчёта не должна удваивать строки. Для этого используйте идентификатор отчёта, период, магазин и контрольную сумму исходника. Если Маркет перегенерировал документ с исправлениями, сохраните новую версию отдельно и покажите отличие. Простая перезапись файла лишает вас возможности объяснить, откуда появилось расхождение.

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

Как сверить данные о приёмке с учётом продавца

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

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

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

Практические сценарии для продавца и интегратора

Сценарий 1. Самописный скрипт ожидает шесть CSV-файлов и падает при седьмом. Интегратор меняет проверку: обязательные файлы должны присутствовать, а неизвестные регистрируются и сохраняются. Для goods_acceptance создаётся отдельная таблица и тест на повторный импорт.

Сценарий 2. Power Query выбирает лист по номеру. После обновления данные прежнего листа попадают в неправильную таблицу. Команда переводит навигацию на имя, добавляет проверку заголовков и уведомление при изменении структуры. Итоговая сумма сравнивается с кабинетом за тот же период.

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

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

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

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

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

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

Подтверждённая хронология изменения

До 20 августа 2026 года. Метод уже формировал отчёт по стоимости услуг и поддерживал XLSX, CSV и JSON. Процесс состоял из запуска генерации, проверки статуса и скачивания готового документа по временной ссылке. Документация предупреждала, что состав отчёта может расширяться.

20 августа 2026 года. В официальном журнале Partner API указано добавление листа «Приемка поставки» и файла goods_acceptance для метода POST v2/reports/united-marketplace-services/generate. Адрес метода не изменился.

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

Что делать прямо сейчас

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

После теста обновите документацию интеграции. Запишите дату изменения, версию преобразователя, пример входного файла и решение по новому набору данных. Если отчёты обрабатывает подрядчик, запросите у него короткий протокол проверки, а не устное «всё работает».

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

Вывод KGAM

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

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

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