Как автоматизировать расчет стоимости доставки в B2B-портале

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

Такая схема увеличивает объем операционной работы и усложняет оформление заказа. Клиент не может сразу оценить итоговые расходы, а менеджеры тратят время на задачи, которые можно автоматизировать.

Интеграция с логистическим сервисом позволяет получать предварительную стоимость доставки непосредственно в корзине или на странице оформления заказа. Этот подход применим в B2B-торговле, где стоимость автоперевозки зависит от расстояния, характеристик груза и типа транспорта.

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

В рамках проекта по разработке B2B-портала для компании из сферы металлоторговли команда «Факта» автоматизировала расчет стоимости автодоставки. Для этого портал интегрировали с логистическим сервисом «АТРАКС» и учетной системой заказчика.

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

Рассмотрим, как устроен этот процесс и какие технические решения позволяют сделать расчет автоматическим.

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

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

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

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

Стоимость перевозки зависит не только от маршрута, но и от характеристик груза. Например, при доставке металлопродукции необходимо учитывать общую массу партии и длину изделий. Транспортное средство может подходить по грузоподъемности, но не соответствовать габаритам груза.

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

Тип транспорта	Вес груза	Длина груза
Легкий	До 7 т включительно	До 6 м
Средний	От 7 до 10 т	До 12 м
Тяжелый	От 10 до 20 т включительно	До 12 м

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

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

После проверки адреса и определения типа транспорта портал формирует запрос к сервису «АТРАКС». В запрос передаются адрес отправления со склада, адрес разгрузки и параметры, необходимые для определения подходящего транспорта.

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

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

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

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

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

Когда «АТРАКС» не возвращает стоимость, портал показывает сообщение: «Стоимость доставки будет рассчитана менеджером во время обработки интернет-заказа».

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

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

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

В рассматриваемом проекте для обмена данными между B2B-порталом и информационной системой «Спутник 2.0» использовалась шина сообщений RabbitMQ. Рассчитанная стоимость доставки передавалась вместе с данными заказа.

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

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

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

Интеграция логистического сервиса влияет сразу на несколько этапов работы с заказом.

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

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

Снижение риска ошибок. Стандартизация адресов и автоматизированный подбор транспорта по заданным правилам уменьшают вероятность ошибок при обработке исходных данных.

Согласованность информации. Передача стоимости доставки в учетную систему позволяет использовать результат расчета при дальнейшей работе с заказом.

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

Фактический эффект автоматизации зависит от количества заказов, доли маршрутов с доступными тарифами и трудозатрат на ручной расчет до внедрения решения. Чтобы оценить экономический результат, необходимо сравнить эти показатели до и после запуска.

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

Перед началом разработки стоит определить несколько условий.

• Требования к исходным данным. Какие сведения нужны для расчета, как проверяются адреса и какие параметры груза влияют на выбор транспорта.

• Правила подбора транспорта. Какие классы машин используются, как обрабатываются граничные значения и что делать с грузами, не подходящими под заданные условия.

• Тип получаемой стоимости. Является ли тариф предварительной оценкой или подтвержденной стоимостью перевозки.

• Сценарии отказа. Как портал работает при отсутствии тарифа, ошибке запроса или временной недоступности внешнего сервиса.

• Обмен с учетной системой. Какие данные передаются вместе с заказом, как обрабатываются повторные сообщения и как синхронизируются изменения.

• Поведение интерфейса. Как показать клиенту рассчитанную стоимость и объяснить, почему в некоторых случаях потребуется расчет менеджера.

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

Интеграция B2B-портала с логистическим сервисом позволяет автоматизировать расчет стоимости типовых перевозок и предоставить покупателю информацию о расходах на доставку еще до оформления заказа.

В рассмотренном проекте команда «Факта» объединила стандартизацию адресов, подбор транспорта по характеристикам груза, получение рыночного тарифа через API и передачу данных в учетную систему. Отдельно был предусмотрен сценарий, при котором отсутствие автоматического расчета не мешает клиенту оформить заказ.

Такой подход можно применять и в других B2B-проектах, где стоимость автодоставки зависит от маршрута и параметров груза. При этом алгоритмы подбора транспорта, правила расчета и способы обмена данными необходимо адаптировать под бизнес-процессы конкретной компании.