Сценарии использования

Планирование

Типовой сценарий планирования состоит из 3-х этапов, которые рассмотрены ниже.

Подготовка данных

• Подготовка заказов - конвертируются все заказы на необходимое количество часов вперед (от часа до 4 месяцев), которые готовы для планирования.

• Подготовка ресурсов - конвертируются все ресурсы (исполнители, транспорт), которые доступны на X часов вперед.

Запуск планировщика

• Вызов метода планирования - в метод планирования передается подготовленный json (который содержит Заказы и Ресурсы) и токен авторизации (api_key)

• Обработка ошибок - если код ответа отличается от 200, то необходимо обработать ошибку - ее номер и детализация придет в ответ на запрос.

• Получение ответа - если код ответа равен 200, то полученные данные необходимо сохранить для дальнейшей обработки.

Обработка результата

• Рейсы - структура содержит назначения заказов на исполнителей.

• Статистика - структура содержит общую статистическую информацию о всех рейсах.

• Валидации - структура содержит информацию о валидности входных данных.

Режимы работы

Запросы на планирования возможно выполнять в синхронном и асинхронном режиме.

Синхронный

В синхронном варианте результат приходит в ответ на входные данные.

warning

Данный вариант рекомендуется только для разработки и тестирования на небольших задачах (до 100 сущностей, до 1 минуты планирования).

Асинхронный

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

Данный вариант рекомендуется для использования в основной системе.

Качество планирования

Качество планирование зависит от следующих основных параметров:

1. Качество исходных данных
2. Верная конвертация исходных данных в бизнес задачу
3. Настройки планирования, включая время планирования
4. Конфигурация планирования
5. Выделенные серверные мощности

Актуализация и перепланирование

Рейс состоит из двух важных частей:

• states (запланированные действия с заказами)
• waitlist (назначенные, но не запланированные заказы)

Для актуализации рейсов, пересчета хвоста и перепланирования заказов есть возможность передать уже существующие рейсы во входных данных в сервис планирования.

В этом случае переданные в states и waitlist заказы будут планироваться только на того исполнителя, на которого назначен соответствующий рейс.

Переданные в states, waitlist и новые свободные заказы планируются вместе и не имеют особого приоритета, поэтому при передаче рейса во входных данных нужно учитывать важные моменты:

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

Учет запланированных заказов

При планировании есть возможность учесть заранее назначенные заказы (исходя из внутренних бизнес процессов или запланированные ранее) несколькими способами:

1. Закрепить заказ за определенным исполнителем в любую смену

Этот случай решается через механизм совместимостей - необходимо задать у заказа идентификатор исполнителя в качестве необходимого для выполнения заказа условия order.restrictions. Данный идентификатор также нужно указать в перечне возможностей у самого исполнителя performer.features.

2. Запретить выполнение заказа определенным исполнителем в любую смену

Этот случай аналогичен первому и также решается через механизм совместимостей, только идентификатор исполнителя у заказа нужно поместить в черный список order.blacklist.

3. Закрепить заказ за определенным исполнителем в конкретную смену

В этом случае сам заказ нужно передавать не в списке незапланированных заказов orders, а непосредственно в списке назначенных на смену заказов у конкретной смены конкретного исполнителя performer.shift.trip.waitlist.

4. Закрепить заказ за определенным исполнителем в конкретную смену на конкретное время

В этом случае необходимо сам заказ передать в поле запланированных заказов в конкретном рейсе performer.shift.trip.states, а также заполнить поля location_time и order_time, указывающие точные времена нахождения на локации и выполнения заказа.

Важное уточнение - что назначение выполнения заказа на конкретное время не позволяет производить оптимизацию данного заказа и сильно влияет на оптимальность решения в целом, поэтому рекомендуется использовать назначение на смену.