Содержание
История заказов Маркета через API: проверьте стыки интервалов
Полный проход по страницам API не исправит неверно заданный период. Если нужна история заказов за несколько месяцев, сначала составьте план интервалов, а затем выгружайте каждый из них.
Этот порядок предназначен для аналитика и интегратора, которые получают заказы кабинета через метод POST /v1/businesses/{businessId}/orders. Он помогает проверить границы истории по дате оформления, не меняя заказы на площадке.
На какие поля смотреть
В текущей схеме метода Маркета фильтр dates содержит creationDateFrom и creationDateTo. Для них используется формат ГГГГ-ММ-ДД, а расстояние между начальной и конечной датой ограничено 30 днями. Начальная дата включается в выборку, конечная не включается.
Это относится к дате оформления. Для отбора по отгрузке предусмотрены отдельные поля, а обновление заказа имеет собственные параметры с датой и временем. Не заменяйте один смысл даты другим ради получения большего числа строк.
Составьте карту интервалов
Запишите первый нужный день и первый день, который уже не должен входить в историю. Далее разделите весь промежуток на соседние части допустимой длины. Конец предыдущей части должен совпадать с началом следующей: исключённая справа дата попадёт в следующую часть слева.
Календарный месяц не всегда укладывается в ограничение 30 дней. Поэтому не используйте правило «один месяц равен одному запросу» без проверки длительности. Для последней части выберите фактическую конечную границу задачи.
Для каждой части заранее сохраните:
- обе даты и смысл фильтра;
- кабинет и нужные магазины;
- одинаковый набор остальных условий отбора;
- состояние выполнения и время получения данных.
Это журнал вашей интеграции, а не дополнительный параметр метода. Не записывайте в него ключ авторизации.
Проверьте один стык до большой выгрузки
Возьмите заказы около выбранной границы и сравните исходное поле creationDate с условиями двух соседних частей. Сохраняйте исходную дату и время со смещением UTC: отрезание строки или неявное преобразование в локальный часовой пояс компьютера затруднит поиск ошибки.
Не выводите правило часового пояса календарного фильтра только из одного примера ответа. Если пограничный заказ оказался не там, где ожидалось, сохраните его идентификатор, исходную дату, параметры обоих запросов и фактические ответы. Передайте этот набор интегратору для проверки трактовки даты по контракту метода.
Разделите две проверки полноты
У каждой части должны завершиться все страницы, но это только первый уровень контроля. Второй уровень: все запланированные интервалы выполнены без пропусков и с одинаковыми условиями.
| Наблюдение | Что проверять дальше |
|---|---|
| Один промежуток отсутствует в журнале | Запуск соответствующей части, а не преобразование итогового файла |
| Часть началась, но не завершилась | Ошибку запроса и сохранённый прогресс страниц |
| Один заказ найден дважды | Пересечение дат, повтор загрузки или объединение наборов |
| Ответы содержат заказ, а таблица нет | Преобразование и фильтры после получения ответа |
Объединяйте данные по устойчивым идентификаторам заказа с сохранением магазина и происхождения записи. Не считайте повторно полученную версию новым заказом. Если версии отличаются, сохраните исходные ответы и примените заранее установленное правило обновления данных.
Когда можно передать историю в аналитику
Проверьте непрерывность карты интервалов, завершение каждой части и наличие контрольных заказов на стыках. В итоговой выгрузке укажите смысл даты, границы, фильтры и время получения. Если часть не прошла проверку, явно обозначьте неполный период.
История по дате оформления сама по себе не является отчётом о выручке за тот же период. Для финансового показателя отдельно нужны правила статусов, отмен, возвратов и момента признания операции. Сначала подтвердите состав заказов, затем рассчитывайте выбранный показатель.
Комментарии 0