--- metadata: - name: generator content: Diplodoc Platform v5.52.0 alternate: - https://yandex.kz/routing/doc/kk/billing/calculations.md - https://yandex.kz/routing/doc/ru/billing/calculations.md - href: ru/billing/calculations.md type: text/markdown title: Markdown version - href: llms.txt type: text/markdown title: llms.txt --- > **Documentation Index:** Fetch the complete configuration index at https://yandex.kz/routing/doc/ru/llms.txt # Подсчет количества заказов и автомобилей ## Мониторинг {#calc-monitoring} Утром каждого дня анализируются все маршруты с датой `route.date`, равной вчерашнему дню. При тарификации по автомобилям подсчитывается количество уникальных автомобилей `vehicle.id` в этих маршрутах и формируется значение счетчика **Мониторинг: количество ТС**. При тарификации по заказам подсчитывается количество уникальных выполненных заказов `location.id` и формируется значение счетчика **Мониторинг: количество заказов**. Эти счетчики доступны в [Кабинете разработчика](https://developer.tech.yandex.ru/) в разделе **Статистика**. ![](_images/statistics-monitoring.png). ## Планирование {#calc-planning} Сервис Планирования решает два типа задач: - оптимальное распределение заказов и планирование маршрутов для нескольких курьеров (задачи [MVRP](https://yandex.ru/routing/doc/ru/vrp/redoc/index.html#tag/Multiple-Vehicles-Routing-(MVRP))); - оптимизация последовательности выполнения заказов на маршруте для одного курьера (задачи [SVRP](https://yandex.ru/routing/doc/ru/vrp/redoc/index.html#tag/Single-Vehicle-Routing-(SVRP))). Подробнее см. в разделе [Сравнение групп методов MVRP и SVRP](https://yandex.kz/routing/doc/ru/vrp/mvrp-svrp-specifics.md). Тарифы на эти два вида задач могут различаться. Для тарификации подсчитывается и количество автомобилей, и количество выполненных заказов в трех разрезах: - для всех задач; - только для задач MVRP; - только для задач SVRP. Результаты можно видеть в счетчиках **Планирование: количество ТС** и **Планирование: количество заказов** в [Кабинете разработчика](https://developer.tech.yandex.ru/) в разделе **Статистика**. ![](_images/statistics-planning.png). ### Определение даты {#calc-dates} Каждое утро потребление по задачам с датой `options.date`, равной вчерашнему дню, записывается в биллинг. Исключения: - в момент запроса дата маршрута не была указана; - в момент запроса была указана дата маршрута в прошлом; - в момент запроса была указана дата маршрута в будущем более чем через 7 дней от даты запроса. Такие задачи будут учтены биллингом на дату выполнения запроса. Рекомендуется планировать задачи на сегодняшний или завтрашний день либо не более чем на 7 дней вперед — в этом случае задачи будут учтены биллингом в день, указанный в поле `options.date`. {% note warning %} Мы настоятельно рекомендуем указывать в поле `options.date` реальную дату поездки курьера. Это позволит не только избежать неправильно выставленных счетов, но и получать максимально корректные и оптимально спланированные маршруты, так как в разные дни маршруты могут существенно различаться. {% endnote %} #### Пример 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 дней от даты запроса. ### Подсчет количества заказов {#calc-orders} При подсчете количества заказов в маршрутах анализируются все элементы массива `locations`. Из них исключаются все элементы с типами `garage`, `anchor` и `parking`. Затем исключаются одинаковые заказы — те, у которых совпадают координаты (с точностью до 6 знака), поля `location.id` и `location.type`. Оставшееся количество заказов записывается в счетчик **Планирование: количество заказов**. Если при планировании заказы делились на несколько частей, то тарифицируются заказы, а не отдельные части. {% note info %} Сложные заказы `pickup&delivery` (необходимо сначала забрать заказ в одной или нескольких точках, а затем доставить в точку получения) тарифицируются как несколько заказов — по количеству разных точек. {% endnote %} {% note warning %} Не рекомендуется использовать в поле `location.id` какие-либо теги или другие вставки, уникальные для конкретной задачи, иначе один и тот же заказ будет посчитан несколько раз. {% endnote %} #### Пример 1 При планировании ошибочно заведены 2 заказа с совпадающими данными: `location.id`, `location.type` и координатами. В биллинге будет учтен 1 заказ: полностью совпадающие заказы считаются дублями. #### Пример 2 Курьер должен привезти 5 заказов разным получателям по одном и тому же адресу. В биллинге будет учтено 5 заказов: несмотря на совпадение координат, у заказов разные `location.id`. #### Пример 3 Логист запускает задачу планирования на 10 заказов. Позже он снова запускает планирование на те же заказы, но в значения параметров `location.id` передает обновленные данные (такое возможно в случаях, когда `location.id` формируется динамически). В биллинге будет учтено 20 заказов: несмотря на совпадение координат, у заказов разные `location.id`. Чтобы исключить подобные ситуации, используйте в поле `location.id` теги, уникальные для конкретной задачи. #### Пример 4 После прибытия на адрес доставки курьер [уточнил координаты](https://yandex.kz/routing/doc/ru/rq-app/orders.md#order-coordinates) заказа, так как получатель перенес доставку к другому подъезду здания. В биллинге будет учтено 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`. ### Подсчет количества автомобилей {#calc-vehicles} При подсчете количества автомобилей в маршрутах анализируются все элементы массива `locations`. Из них исключаются все элементы с типами `garage`, `anchor` и `parking`. Затем исключаются одинаковые заказы — те, у которых совпадают координаты (с точностью до 6 знака), поля `location.id` и `location.type`. Задачи со схожими множествами заказов объединяются в кластеры — это позволяет не тарифицировать повторно задачи, которые решались несколько раз с различным набором условий (см. [Особенности тарификации](https://yandex.kz/routing/doc/ru/billing/index.md#specifics)). Если задача меньшего размера (по числу заказов) хотя бы на 50% пересекается с большей, эти задачи будут отнесены в один кластер. При этом в итоге в один кластер могут быть отнесены задачи, вообще не имеющие общих точек. Например, на рисунке ниже задача 1 и задача 3 не имеют ни одного общего заказа, но при этом попадают в общий кластер с задачей 2. ![](_images/billing-clusters.svg) В каждом кластере выбирается задача, в которой используется наибольшее количество автомобилей. Эти значения суммируются по всем кластерам, и получившееся количество автомобилей записывается в счетчик **Планирование: количество ТС**. {% note info %} При подсчете учитываются именно используемые автомобили, а не все перечисленные в запросе. {% endnote %} #### Пример 1 Для поиска лучшего решения доставки из 100 заказов логист запускает планирование 3 раза, меняя при этом значения штрафа за среднее время приезда и корректировку времени движения и получает следующие результаты: * запуск 1 — 10 автомобилей; * запуск 2 — 13 автомобилей; * запуск 3 — 11 автомобилей. В биллинге будет учтено 13 автомобилей: несмотря на различный набор условий, три задачи планирования с одинаковыми заказами объединяются в один кластер, при этом тарифицируется максимальное значение количества автомобилей в кластере. #### Пример 2 Логист запустил задачу планирования на 50 заказов и получил решение для 10 автомобилей. Позже логист [допланировал](https://yandex.kz/routing/doc/ru/vrp/additional-planning.md) задачу и добавил в нее 20 новых заказов для 2 новых автомобилей. В биллинге будет учтено 12 автомобилей: задачи планирования с разными заказами не могут быть объединены в один кластер. #### Пример 3 При запуске задачи планирования логист передает в [массиве](https://yandex.kz/routing/doc/ru/vrp/reference.md#vehicles) `vehicles` 10 автомобилей (весь автопарк компании), в полученном решении используется только 3 автомобиля. В биллинге будет учтено 3 автомобиля: тарифицируются только используемые автомобили, а не общее количество. #### Пример 4 Для поиска лучшего решения доставки из 20 заказов логист запустил планирование, разбив заказы на части: * запуск 1 — 10 заказов, 2 автомобиля; * запуск 2 — 10 заказов, 3 автомобиля. Далее логист объединил заказы и еще раз запустил планирование: * запуск 3 — 20 заказов, 5 автомобилей. В биллинге будет учтено 5 автомобилей: все 3 задачи будут объединены в один кластер, тарифицируется максимальное значение количества автомобилей в кластере. #### Пример 5 Логист запустил задачу планирования и получил решение для 2 автомобилей. После выполнения заказов в этот же день логист запустил новую задачу планирования для тех же автомобилей. В биллинге будет учтено 4 автомобиля: тарифицируются 2 автомобиля для первой задачи и 2 автомобиля для второй.