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

Выбрать вопрос, на который отвечает выгрузка

В getOrdersStats dateFrom и dateTo задают период формирования заказа, а updateFrom и updateTo — период изменений, например статуса или сведений о платежах. Документация запрещает использовать эти пары одновременно. Отдельно предупреждается о возможной задержке появления статистики до 40 минут; для оперативной работы предлагается метод получения заказов.

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

Как сохранить позднее изменение

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

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

Почему статистика не заменяет очередь сборки

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

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

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

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

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