Свойства временных окон

При формулировании задачи маршрутизации часто нужно ограничить временное окно доставки заказа, время работы склада или время смены водителя.

Для ограничения времени в Маршрутизации используется поле time_window («временное окно»), представляющее из себя текстовое описание диапазона времени.

Временные окна могут быть заданы в абсолютном и относительных форматах, подробно рассмотренных ниже.

Относительный формат временных оконОтносительный формат временных окон

Этот формат временных окон не содержит абсолютной даты и определяется как пара значений времени, например, 07:00:00 – 23:00:00 для временного окна, которое начинается в 7 утра и заканчивается в 23 вечера текущего дня.

Для окон, начинающихся или заканчивающихся на следующий день (или любой день в будущем), формат даты указывается как [D.]HH:MM – [D.]HH:MM, где D — сдвиг даты относительно даты начала маршрута. Например, 07:00:00 – 1.03:00:00 для окна, которое начинается в 7 утра текущего дня и заканчивается в 3 ночи следующего дня. Или 1.07:00:00 – 1.15:00:00 для окна, которое начинается в 7 утра следующего дня и заканчивается в 15 часов следующего дня.

Верхняя граница временного окна всегда должна быть больше или равна нижней границе. Окно 07:00:00 – 03:00:00 приведет к ошибке. Особенно часто такая ошибка возникает при указании окон, переходящих на следующие сутки, или для окон, которые заканчиваются в полночь — так, окно 10:00:00 – 00:00:00 будет воспринято с ошибкой, необходимо указать 10:00:00 – 1.00:00:00.

Форматы временных окон без даты будут интерпретированы сервисом относительно текущей даты и часового пояса GMT+3 (Москва), либо относительно даты маршрута, заданной в поле options.date и часового пояса, заданного в поле options.time_zone.

Дату маршрута важно задавать корректно, если планируются отгрузки в разные сутки. В этом случае в поле options.date указывается дата самого раннего маршрута планирования. Например, планирование выполняется 20.09, и в нем есть отгрузки на вечер 20.09 и день 21.09. Тогда options.date = 2021-09-20, а для заказов с отгрузой на следующий день, 21 сентября, временные окна должны указываться в формате 1.НН:ММ – 1.НН:ММ.

Пример

В примере ниже определен часовой пояс для запроса (московское время), а также временные окна склада и заказов без указания даты. Маршрут строится на дату 20 Января 2019 года (или на текущую дату, если не указано поле options.date).

Запрос API (JSON) ⋅ Ответ API ⋅ Открыть на карте

Абсолютный формат временных оконАбсолютный формат временных окон

Этот формат содержит полную дату и время начала и окончания временного окна в формате ISO 8601. Например, 2019-10-10T07:00:00+03:00/2019-10-10T18:00:00+03:00 для окна, которое начинается в 7 утра по московскому времени и заканчивается в 18 часов также по московскому времени.

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

Пример

В примере ниже временные окна склада, заказов и смен указаны с датой и временной зоной в формате ISO 8601. Маршрут строится на дату 21 Января 2018 года, указанную в каждом временном окне.

Запрос API (JSON) ⋅ Ответ API ⋅ Открыть на карте

Жесткие и мягкие окнаЖесткие и мягкие окна

Временное окно — это ограничение, которое необходимо выполнить при построении маршрута. Например, для временного окна заказа, выполнение ограничения означает доставку в указанном диапазоне времени.

Допустимо определение жестких и мягких временных окон.

Жесткое окно — это ограничение, которое необходимо выполнить без нарушений. Если при построении маршрута такое ограничение нарушается, заказ полностью исключается из маршрута и попадает в поле dropped_locations в ответе Маршрутизации.

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

Для управления жесткими временными окнами используется поле hard_window:

• true — временное окно будет жестким.

• false — временное окно будет мягким.

На практике мягкие окна позволяют:

• сбалансировать ранние прибытия или опоздания между несколькими заказами, если заданное количество автомобилей не позволяет доставить все заказы точно в срок;

• прибыть на склад раньше или опоздать при возвращении, если необходимо доставить все заказы в течение дня;

• превысить время смены водителя, если ранний выезд или опоздание необходимы и допустимы бизнес-процессами.

При определении мягких окон используются штрафы:

• За нарушение временного окна:

  • penalty.out_of_time.fixed — штраф за факт нарушения временного окна.
  • penalty.out_of_time.minute — штраф за минуту нарушения временного окна.

• За ранее прибытие:

  • penalty.early.fixed — штраф за факт раннего прибытия.
  • penalty.early.minute — штраф за минуту раннего прибытия.

• За опоздание:

  • penalty.late.fixed — штраф за факт опоздания.
  • penalty.late.minute — штраф за минуту опоздания.

Штрафы добавляются к стоимости маршрута при наличии нарушения (fixed) или за каждую минуту нарушения (minute). Раннее прибытие и опоздание — частные случаи нарушения.

Если ваш бизнес-процесс не допускает нарушений временных окон, мы рекомендуем следующее:

• при начальной формулировке задачи маршрутизации использовать жесткие окна;

• при последующей работе использовать мягкие окна с настраиваемым значением штрафов за нарушение временного окна или жесткое окно вокруг мягкого (например, опоздание или раннее прибытие на 1-5 минут могут быть допустимы).

Где определяются временные окнаГде определяются временные окна

Маршрутизация позволяет определять временные окна для следующих сущностей:

• Заказы (locations) — допустимое время прибытия на заказ.

• Склад (depot) — время работы склада; время на загрузку, дозагрузку и разгрузку.

• Смена водителя (vehicles[].shift) — допустимый диапазон времени смены.

Жесткое окно вокруг мягкого окнаЖесткое окно вокруг мягкого окна

Кроме основного временного окна time_window, для заказов, складов и смен курьера можно задать дополнительное (внешнее) жесткое окно. Оно используется, чтобы ограничить допустимое время нарушения основного окна, и определяется с помощью параметра hard_time_window.

У параметра есть следующие ограничения:

• Внешнее жесткое окно должно полностью включать в себя основное окно, которое указано в параметре time_window.

• При использовании внешнего жесткого окна запрещено указывать параметр hard_window.

Если используются несколько временных окон (параметр time_windows), то внешние жесткие окна должны соответствовать следующим требованиям:

• определяться на одном уровне с дочерним параметром time_window;

• использоваться для каждого временного окна или не использоваться ни для одного;

• не пересекаться, как и основные временные окна.

Пример 1.1

Маршрут состоит из трех заказов без ограничений на опоздание (внешние жесткие окна не используются). В решении два заказа без нарушений временного окна и один заказ (с id = 2) с опозданием в 23 минуты.

Пример Excel ⋅ Запрос API (JSON) ⋅ Ответ API ⋅ Открыть на карте

Пример 1.2

То же, что и в примере 1.1, но для каждого заказа при помощи параметра hard_time_window ограничено допустимое нарушение временного окна. Ограничения предполагают опоздание не более, чем на 10 минут, но разрешают ранний приезд. В результате планирования один заказ доставлен вовремя, а два других — с опережением или опозданием, но в пределах установленных ограничений.

Пример Excel ⋅ Запрос API (JSON) ⋅ Ответ API ⋅ Открыть на карте

Пример 2

Маршрут состоит из трех заказов с возможной доставкой в двух временных окнах. При помощи параметра hard_time_window ограничено допустимое нарушение для каждого временного окна. Тогда все заказы будут доставлены без нарушений, но один заказ (с id = 0) — во втором временном окне.

Пример Excel ⋅ Запрос API (JSON) ⋅ Ответ API ⋅ Открыть на карте

Написать в службу поддержки