Добрый день. Прошу помощи в получении отчетов реализации.

Моя цель - получить отчет реализации за период с 2024-01-29 по 2025-08-31.

Поскольку количество строк в итоговом отчете превышает 100 000, то я использую метод выгрузки отчета через параметр rrd_id (id строки в предыдущем отчете).

Распишу, что я получаю по шагам:

1. Формирую первый запрос с параметрами:

"dateFrom": 2024-01-29T00:00:00,
"dateTo": 2025-08-31T23:59:59,
"rrdid": 0

В ответе я получаю отчет реализации за период

date_from: 2024-01-29
date_to: 2024-12-08
rrd_id: 4141247912

На этом этапе все ок.

2. Формирую второй запрос:

"dateFrom": 2024-01-29T00:00:00,
"dateTo": 2025-08-31T23:59:59,
"rrdid": 4141247912

В ответе я получаю отчет реализации за период

date_from: 2024-12-02
date_to: 2024-12-15
rrd_id: 4242339810

На этом этапе возникает ошибка: пересеклись недели с предыдущим запросом. Ок, идем дальше.

3. Формирую третий запрос:

"dateFrom": 2024-01-29T00:00:00,
"dateTo": 2025-08-31T23:59:59,
"rrdid": 4242339810

Я получаю пустой отчет.

Таким образом, я смог получить отчеты за период с 2024-01-29 по 2024-12-15. Куда делся остальной период? Если передавать запросы через даты, то отчеты за оставшийся период выгружаются, но при использовании подхода через использование id последней строки предыдущего отчета не работает. Приходится на каждом шаге определять максимальную дату и формировать период следующего запроса вручную. Причем формировать его таким образом, чтобы случайно не получить больше 100 000 строк, поскольку метод выгрузки через rrd_id не работает.

Добрый день!

Коротко: с отчётом всё ок — «остаток периода» никуда не делся. Проблема в том, что пагинация по rrd_id у /api/v5/supplier/reportDetailByPeriod не гарантирует строгую «возрастающую по датам» выборку на длинных интервалах. После очередной «границы» (неделя/репорт) в вашем кейсе записи за 2025 год имеют rrd_id меньше, чем последний rrd_id декабрьского блока — поэтому запрос с rrdid=4242339810 отсекает их, и вы получаете пустой ответ. В документации сказано лишь, что rrdid — это уникальный ID строки для разбиения отчёта и что нужно вызывать метод до пустого массива, но не обещано соответствие хронологии датам. Отчёт еженедельный, данные доступны «с 29.01.2024» и dateTo — это дата (день), а не дата-время, время считается по Мск (UTC+3). 

Как надёжно вытянуть весь период >100 000 строк

Используйте гибрид: даты + rrd_id.

1. Базовые параметры

• endpoint: /api/v5/supplier/reportDetailByPeriod
• dateFrom — RFC3339 (можно с временем), dateTo — дата в формате YYYY-MM-DD; лучше без T23:59:59. Время — по Мск.
• limit оставьте 100000 (по умолчанию). 

1. Итерация по “недельным окнам”

• Старт: cursorStart = 2024-01-29, end = 2025-08-31.
• Запускаете цикл:
  • Делаете запрос с dateFrom=cursorStart, dateTo=end, rrdid=0.
  • Если ответ пуст — стоп (мы исчерпали период для этого окна).
  • Сохраняете строки + maxDateTo = max(date_to) из ответа.
  • Пока ответ не пуст:
    • Берёте maxRrd = max(rrd_id) из последнего ответа и вызываете тот же запрос, но с rrdid = maxRrd.
    • Если получили пусто — выходим из rrd-цикла.
  • Обновляете cursorStart = maxDateTo + 1 день и повторяете, пока cursorStart <= end.

1. Анти-дубликаты Пересечения недель — это нормально (вы сами это заметили). Дедуплируйте по ключу rrd_id (на всякий случай можно по паре (realizationreport_id, rrd_id)). 
2. Автодробление, если внутри окна >100 000 строк Если первое обращение к окну вернуло ровно 100 000 строк и вы видите, что maxDateTo почти не сдвигается, включайте «двоичный поиск по дате»: временно уменьшаете tempEnd (середина между cursorStart и end) до тех пор, пока очередное окно стабильно не отдаёт <100 000 строк; после выгрузки этого куска сдвигаете cursorStart = maxDateTo + 1 и продолжаете.

Почему это работает

• Метод возвращает «детализацию к еженедельным отчётам» и разрешает кусочить массив по rrd_id, но не гарантирует, что rrd_id монотонно растёт вместе с календарной датой на длинных периодах — из-за чего возможен «обрыв» при простом наращивании rrd_id. Документация формально описывает только поведение rrdid как механизма дозагрузки и отсутствие записей как сигнал завершения; строгого SLA по хронологии нет. 

Частые мелочи, которые помогают

• dateTo передавайте как дату (2025-08-31), а не ...T23:59:59. Так ближе к спецификации (для dateFrom допускается дата-время, для dateTo — дата). 
• Учитывайте, что всё считается в UTC+3 (Мск) — это важно, если вы строите «+1 день» 
• Дедуп по rrd_id снимет «пересечение недель» (это ожидаемо).

Здравствуйте!

Если вы не можете выгрузить данные после 2024-12-15, значит ранее вам в колокольчик было отправлено уведомление (в декабре 2024), о том что для выгрузки недельных отчетов после 2024-12-15 по техническим причинам нужно указывать dateFrom = 2024-12-16.

Соответственно если вы хотите выгрузить все данные, вам нужно сделать 2 вида запросов, одни с dateFrom 2024-01-29, пока не получите все данные, и второй вид с dateFrom = 2024-12-16