Время отгрузки FBS: как проверить интервал в ответе ИИ
Если ИИ разбирает отгрузку Яндекс Маркета, проверяй обе границы и их
UTC-смещения: planIntervalFrom — начало,
planIntervalTo — конец планового интервала по getShipment.
Ниже — офлайн-проверка на девяти вымышленных примерах, не проверка
просрочки конкретного заказа.
Что подготовить
Нужны компьютер с Python 3 и возможность сохранить файлы в одну папку. Кабинет продавца, токен API, тариф нейросети и платные запросы для этого упражнения не требуются: скрипт работает локально, без сторонних пакетов и сети. Время самого запуска указано в записи прогона; время установки Python и твоей проверки в него не входит.
Начинай с учебных файлов. Если потом сверяешь извлечение ИИ, используй только две нужные временные строки без заказов, покупателей и ключей доступа. Результат упражнения — сохранённые исходные значения, их перевод в UTC и список конфликтов, а не действие в кабинете.
Шаг 1. Убедись, что это нужные поля
В документации метода обе границы описаны как дата и время в ISO 8601 со смещением относительно UTC. Не отбрасывай часть после времени.
Поле в result метода getShipment |
Что проверяем | Опора |
|---|---|---|
planIntervalFrom |
Начало планового интервала, включая дату и смещение | API Маркета |
planIntervalTo |
Конец планового интервала, включая дату и смещение | API Маркета |
Ожидаемый результат: у тебя есть две исходные строки из одного
интервала, а не одно «время отгрузки». Если вместо них даны
shipmentDate и shipmentTime, наш нормализатор оставит
результат неизвестным: у этих полей в упражнении нет подтверждённого
контракта. Не подменяй ими нужную пару.
Шаг 2. Запусти учебную проверку
Сохрани скрипт и учебные входы в одну папку. Открой в ней терминал и выполни:
python3 normalize.pyОжидаемый итог — checked: 9, passed: 9;
счётчики known: 4, unknown: 4,
conflict: 1. Рядом появятся JSON с результатом и таблица
Markdown. Сверь их с полным результатом и таблицей исходных строк. Это
совпадение расчёта с девятью учебными эталонами, не точность ИИ на
заказах.
В таблице ниже даты сокращены только для чтения: у строк одна учебная дата, кроме перехода на следующий местный день. Полные строки, даты и UTC сохранены в JSON.
| Пример | Исходное время со смещением | Интервал UTC | Длительность | Опора расчёта |
|---|---|---|---|---|
offset-03 |
15:00+03:00 → 16:00+03:00 | 12:00 → 13:00 | 60 минут | Результат |
cross-midnight |
23:30+03:00 → 00:30+03:00 следующего дня | 20:30 → 21:30 одного дня | 60 минут | Результат |
different-offsets |
18:00+03:00 → 15:30Z | 15:00 → 15:30 | 30 минут | Результат |
offset-05 |
15:00+05:00 → 16:00+05:00 | 10:00 → 11:00 | 60 минут | Результат |
В третьем примере сравнение часов без зон дало бы обратный порядок: 18:00 выглядит позже 15:30. После перевода обеих границ в UTC длительность положительная — это видно в расчёте. Поэтому нельзя просто удалить смещения и вычесть часы.
Шаг 3. Разбери неизвестное и конфликт
known, unknown и conflict —
метки нашей учебной проверки, не статусы API Маркета. Четыре неизвестных
входа и один конфликт из корпуса разбираются так:
| Пример | Что мешает расчёту | Что исправить | Опора |
|---|---|---|---|
missing-offset |
Нет UTC-смещения | Запросить исходные строки со смещением; не подставлять московское | Результат |
date-only |
Есть даты, но нет времени | Получить полные значения обеих границ | Результат |
missing-end |
Нет конца интервала | Найти planIntervalTo, не копировать начало |
Результат |
wrong-field |
Переданы другие поля | Вернуться к контракту нужного метода | Результат |
inverted |
Конец раньше начала после перевода в UTC | Проверить исходный документ и извлечение; не переставлять границы автоматически | Результат |
Ожидаемый результат: неизвестное осталось неизвестным, а обратный интервал отмечен конфликтом. Если ИИ добавил недостающую зону или «починил» границы, вернись к исходным строкам и укажи конкретное расхождение. Этот совет не требует пересылать модели реальный заказ.
Шаг 4. Сверь смысл результата
Расчёт UTC не отвечает на вопрос, вовремя ли передан товар. В справке FBS дата и время отгрузки отнесены к странице отгрузки в кабинете. Сверь нужную отгрузку там; не считай начало интервала универсальным дедлайном и не делай вывод о санкции из одного расчёта длительности.
Конечный результат упражнения — таблица нормализации, а не подтверждение приёма товара. Ожидаемая проверка: исходная пара сохранена, обе зоны учтены, порядок проверен в UTC, неизвестные поля не достроены. Для вывода о фактической отгрузке потребуются другие свидетельства; локальные файлы их не создают.
Если задача — объяснить отмену DBS по истории событий, это другой разбор: см. тест причин отмены.
Как мы проверяли
Редакция запустила локальный скрипт на девяти синтетических примерах из собственного корпуса; полный вход, выход, среда, время и хеши файлов — в записи прогона. В указанную дату редакция проверила оба официальных документа и расчёты. Нейросеть, интерфейс кабинета и seller API не запускались; для офлайн-вычисления нет версии веб-интерфейса или тарифа. Примеры не моделируют все допустимые форматы API.
Редакция не оплачивала внешние сервисы для этого упражнения. Для подготовки текста и проверки редакция использовала свою подписку. Полную стоимость этой работы не измеряли.
Источники
- getShipment — назначение полей и формат дат; проверено 30 октября 2026 года.
- Обработка заказов FBS — где смотреть дату и время отгрузки; проверено 30 октября 2026 года.
- Код и запись расчёта — учебные данные редакции, не сведения о реальных заказах.