Подсчет количества заказов и автомобилей

Мониторинг

Утром каждого дня анализируются все маршруты с датой route.date, равной вчерашнему дню.

При тарификации по автомобилям подсчитывается количество уникальных автомобилей vehicle.id в этих маршрутах и формируется значение счетчика Мониторинг: количество ТС.

При тарификации по заказам подсчитывается количество уникальных выполненных заказов location.id и формируется значение счетчика Мониторинг: количество заказов.

Эти счетчики доступны в Кабинете разработчика в разделе Статистика.

.

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

Сервис Планирования решает два типа задач:

• оптимальное распределение заказов и планирование маршрутов для нескольких курьеров (задачи MVRP);
• оптимизация последовательности выполнения заказов на маршруте для одного курьера (задачи SVRP).

Подробнее см. в разделе Сравнение групп методов MVRP и SVRP. Тарифы на эти два вида задач могут различаться. Для тарификации подсчитывается и количество автомобилей, и количество выполненных заказов в трех разрезах:

• для всех задач;
• только для задач MVRP;
• только для задач SVRP.

Результаты можно видеть в счетчиках Планирование: количество ТС и Планирование: количество заказов в Кабинете разработчика в разделе Статистика.

.

Определение даты

Каждое утро выставляются счета по задачам с датой options.date, равной вчерашнему дню, за исключением следующих случаев:

• в момент запроса дата маршрута не была указана;
• в момент запроса была указана дата маршрута в прошлом;
• в момент запроса была указана дата маршрута в будущем более чем через 7 дней от даты запроса.

Такие задачи будут учтены биллингом на дату выполнения запроса.

Рекомендуется планировать задачи на сегодняшний или завтрашний день либо не более чем на 7 дней вперед — в этом случае задачи будут учтены биллингом  день, указанный в поле options.date.

Пример 1

20 января 2026 года в 23:00 (GMT+3) логист запускает задачу планирования на завтрашний день (options.date = 2026-01-21).

Задача будет учтена в биллинге за 21 января 2026 года.

При этом, если 21 января 2026 года логист снова запустит задачу с теми же заказами и options.date = 2026-01-21, задача будет учтена в биллинге только 1 раз: параметры location.id, location.type и options.date совпадают, заказы будут объединены в один кластер.

Пример 2

20 января 2026 года логист запускает задачу планирования на текущий день (options.date = 2026-01-20). Позже он замечает ошибку в дате и запускает задачу планирования с теми же заказами на завтрашний день (options.date = 2026-01-21).

Задача будет учтена в биллинге дважды: за 20 и 21 января.

Пример 3

20 января 2026 года разработчик тестирует API и создает задачу планирования с options.date = 2027-01-20 (на год вперед).

Задача будет учтена в биллинге за текущую дату: в момент запроса была указана дата маршрута в будущем более чем через 7 дней от даты запроса.

Подсчет количества заказов

При подсчете количества заказов в маршрутах анализируются все элементы массива locations. Из них исключаются все элементы с типами garage, anchor и parking. Затем исключаются одинаковые заказы — те, у которых совпадают координаты (с точностью до 6 знака), поля location.id и location.type. Оставшееся количество заказов записывается в счетчик Планирование: количество заказов.

Если при планировании заказы делились на несколько частей, то тарифицируются заказы, а не отдельные части.

Пример 1

При планировании ошибочно заведены 2 заказа с совпадающими данными: location.id, location.type и координатами.

В биллинге будет учтен 1 заказ: полностью совпадающие заказы считаются дублями.

Пример 2

Курьер должен привезти 5 заказов разным получателям по одном и тому же адресу.

В биллинге будет учтено 5 заказов: несмотря на совпадение координат, у заказов разные location.id.

Пример 3

Логист запускает задачу планирования на 10 заказов. Позже он снова запускает планирование на те же заказы, но в значения параметров location.id передает обновленные данные (такое возможно в случаях, когда location.id формируется динамически).

В биллинге будет учтено 20 заказов: несмотря на совпадение координат, у заказов разные location.id. Чтобы исключить подобные ситуации, используйте в поле location.id теги, уникальные для конкретной задачи.

Пример 4

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

В биллинге будет учтено 2 заказа: несмотря на совпадение location.id и location.type у заказов разные координаты.

Пример 5

Курьер должен сначала забрать 5 заказов на одном складе (location.type = pickup), затем привезти их по 5 разным адресам.

В биллинге будет учтено 6 заказов: 1 точка pickup + 5 точек delivery.

Пример 6

При планировании заведены 2 заказа с совпадающими location.id и координатами, но разными location.type: в первом заказе location.type = pickup, во втором location.type = delivery.

В биллинге будет учтено 2 заказа: несмотря на совпадение координат и location.id, у заказов разные location.type.

Подсчет количества автомобилей

При подсчете количества автомобилей в маршрутах анализируются все элементы массива locations. Из них исключаются все элементы с типами garage, anchor и parking. Задачи со схожими множествами заказов объединяются в кластеры — это позволяет не тарифицировать повторно задачи, которые решались несколько раз с различным набором условий (см. Особенности тарификации).

Если задача меньшего размера (по числу заказов) хотя бы на 50% пересекается с большей, эти задачи будут отнесены в один кластер. При этом в итоге в один кластер могут быть отнесены задачи, вообще не имеющие общих точек. Например, на рисунке ниже задача 1 и задача 3 не имеют ни одного общего заказа, но при этом попадают в общий кластер с задачей 2.

В каждом кластере выбирается задача, в которой используется наибольшее количество автомобилей. Эти значения суммируются по всем кластерам, и получившееся количество автомобилей записывается в счетчик Планирование: количество ТС.

Пример 1

Для поиска лучшего решения доставки из 100 заказов логист запускает планирование 3 раза, меняя при этом значения штрафа за среднее время приезда и корректировку времени движения и получает следующие результаты:

• запуск 1 — 10 автомобилей;
• запуск 2 — 13 автомобилей;
• запуск 3 — 11 автомобилей.

В биллинге будет учтено 13 автомобилей: несмотря на различный набор условий, три задачи планирования с одинаковыми заказами объединяются в один кластер, при этом тарифицируется максимальное значение количества автомобилей в кластере.

Пример 2

Логист запустил задачу планирования на 50 заказов и получил решение для 10 автомобилей. Позже логист допланировал задачу и добавил в нее 20 новых заказов для 2 новых автомобилей.

В биллинге будет учтено 12 автомобилей: задачи планирования с разными заказами не могут быть объединены в один кластер.

Пример 3

При запуске задачи планирования логист передает в массиве vehicles 10 автомобилей (весь автопарк компании), в полученном решении используется только 3 автомобиля.

В биллинге будет учтено 3 автомобиля: тарифицируются только используемые автомобили, а не общее количество.

Пример 4

Для поиска лучшего решения доставки из 20 заказов логист запустил планирование, разбив заказы на части:

• запуск 1 — 10 заказов, 2 автомобиля;
• запуск 2 — 10 заказов, 3 автомобиля.

Далее логист объединил заказы и еще раз запустил планирование:

• запуск 3 — 20 заказов, 5 автомобилей.

В биллинге будет учтено 5 автомобилей: все 3 задачи будут объединены в один кластер, тарифицируется максимальное значение количества автомобилей в кластере.

Пример 5

Логист запустил задачу планирования и получил решение для 2 автомобилей. После выполнения заказов в этот же день логист запустил новую задачу планирования для тех же автомобилей.

В биллинге будет учтено 4 автомобиля: тарифицируются 2 автомобиля для первой задачи и 2 автомобиля для второй.