Динамический расчёт стоимости доставки в Битрикс

Покупатель собрал корзину, дошёл до оформления — и видит «Доставка: 500 ₽» вне зависимости от того, заказал он один шампунь или холодильник. На лёгком заказе он переплачивает и уходит, на тяжёлом магазин везёт себе в убыток. Фиксированная ставка удобна в настройке ровно один раз, а потом каждый день понемногу вредит. Решение — динамический расчёт стоимости доставки: цена считается под конкретный заказ по реальному весу, габаритам, зоне покупателя и тарифу выбранного перевозчика прямо в корзине.

Ниже — практическая настройка динамической доставки в 1С-Битрикс с нуля: как учитывать вес и объёмный вес, как разбить географию на зоны, как подключить расчёт по API перевозчиков и что делать, если внешняя служба не ответила. Это выжимка из наших проектов по интеграции 1С-Битрикс со службами доставки и внешними сервисами — без теории ради теории, только то, что реально работает в бою.

Что такое динамический расчёт доставки

Динамический расчёт доставки — это вычисление цены перевозки «на лету» для конкретного заказа, а не выбор строки из заранее заданного прайса. В момент, когда покупатель указал адрес и выбрал способ доставки, система собирает параметры корзины (суммарный вес, габариты, стоимость вложения), определяет зону по адресу и либо считает тариф по собственным правилам, либо запрашивает актуальную стоимость у перевозчика через API. Результат — точная сумма, которая соответствует реальной себестоимости перевозки.

В терминах 1С-Битрикс за доставку отвечает модуль sale и его подсистема служб доставки. Каждая служба доставки — это профиль с обработчиком (штатным или своим), набором ограничений и правилами расчёта. Обработчик получает на вход объект заказа со всеми товарами и их свойствами, а на выходе отдаёт стоимость и срок. Именно логика обработчика превращает статичную «доставку за 500 ₽» в динамический расчёт, чувствительный к содержимому корзины.

Ключевая мысль: динамическая доставка — это не одна галочка в админке, а связка из четырёх согласованных вещей. Во-первых, качественные данные о товаре (вес и габариты). Во-вторых, корректно описанная география (зоны доставки). В-третьих, источники тарифов (собственные таблицы и/или API перевозчиков). В-четвёртых, надёжная обвязка (таймауты, кэш, запасной сценарий). Выпадет любое звено — и расчёт либо врёт, либо тормозит, либо разваливается на первом же недоступном сервисе. Дальше разберём каждое звено отдельно.

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

Фиксированная стоимость доставки кажется безопасным решением: настроил одну цифру — и не думаешь. На практике она незаметно съедает и конверсию, и маржу одновременно, просто с разных сторон ассортимента.

Разберём на цифрах. Допустим, магазин поставил единую доставку 450 ₽. Клиент заказывает набор косметики за 900 ₽ — доставка «весит» половину заказа, корзина брошена. Другой клиент заказывает комплект напольной плитки на 60 кг — реальная доставка стоит 1800 ₽, но магазин по своей же ставке берёт 450 ₽ и отдаёт 1350 ₽ из прибыли. Одна и та же цифра бьёт по обоим краям: отпугивает лёгкие заказы и субсидирует тяжёлые.

Плоский тариф порождает и скрытые эффекты. Покупатели быстро учатся: тяжёлые и объёмные товары выгоднее заказывать у вас, а мелочь — у конкурента с бесплатной доставкой от суммы. Так ассортиментный микс постепенно смещается в сторону самых убыточных для логистики позиций. Динамический расчёт убирает этот перекос: каждый заказ платит за себя, и экономика доставки перестаёт зависеть от того, что именно покупают.

• Мелкие заказы. Плоская ставка завышает долю доставки в чеке и повышает процент брошенных корзин.
• Тяжёлые и объёмные заказы. Магазин везёт себе в убыток, разница ложится на прибыль.
• Дальние регионы. Единая цена не покрывает реальную стоимость плеча до отдалённых зон.
• Ассортиментный перекос. Покупатели «вымывают» выгодные для себя, но убыточные для магазина позиции.

Из чего складывается стоимость доставки

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

Динамический расчёт — это, по сути, функция от этих факторов. В простом случае она линейна: «базовая ставка зоны плюс цена за каждый килограмм сверх порога». В сложном — это ответ API перевозчика, который внутри учитывает всё то же самое плюс свои внутренние коэффициенты, топливные надбавки и акции. Наша задача при внедрении — собрать все входные параметры корректно и в нужном формате передать их в источник тарифа.

Вес, габариты и объёмный вес

Фундамент любого расчёта доставки — вес. В 1С-Битрикс вес хранится в отдельном свойстве торгового каталога (поле «Вес» единицы товара) и при формировании корзины автоматически суммируется по всем позициям с учётом количества. Если вес не заполнен, корзина считает товар невесомым, и тариф получается заниженным или нулевым.

Но одного веса мало. Пуховая подушка весит 800 грамм, а по объёму занимает в машине место как гиря на 10 кг. Чтобы перевозчику было выгодно везти лёгкий, но объёмный груз, придуман объёмный (габаритный) вес. Считается он по формуле, где объём в кубических сантиметрах делится на коэффициент перевозчика (часто 5000):

Отсюда практическое требование: у товаров, которые заметно «пустые» по плотности (мебель, крупная бытовая техника, светильники, спорттовары), в карточке обязательно должны быть заполнены длина, ширина и высота. Заводятся они как числовые свойства товара, а в обработчике доставки объёмный вес считается на лету и сравнивается с физическим.

1. Заведите свойства габаритов. В инфоблоке каталога добавьте числовые свойства «Длина», «Ширина», «Высота» в сантиметрах (или используйте штатные поля размеров товара).
2. Заполните данные. Проставьте вес и габариты хотя бы для крупногабаритных и объёмных категорий — именно там плоский расчёт врёт сильнее всего.
3. Настройте формулу объёмного веса. В обработчике доставки считайте Vвес по габаритам корзины и берите максимум из двух значений.
4. Учтите упаковку. Добавьте небольшую надбавку на коробку и наполнитель, чтобы расчётный объём соответствовал реальной посылке.

Подробно тему подготовки весогабаритных данных и разбивки на зоны мы разбираем в отдельном материале — расчёт доставки по весу, габаритам и зонам в 1С-Битрикс. Если вы только начинаете наводить порядок в каталоге, начните именно с него, а сюда возвращайтесь за динамикой и API.

Зоны доставки и адресная геопривязка

Второе слагаемое — география. Везти заказ по своему городу, в соседний регион и на Дальний Восток стоит по-разному, и динамический расчёт обязан это различать. В 1С-Битрикс география описывается через местоположения (locations) и зоны доставки. Местоположения — это иерархический справочник стран, регионов, городов; зона доставки — это группа местоположений, к которой привязываются тарифы и доступные службы.

Типовая схема зонирования выглядит так: «свой город» с самыми низкими ставками и быстрой курьеркой, «домашний регион», «города-миллионники», «остальная Россия» и отдельно дальние и труднодоступные территории с повышенными коэффициентами. Чем аккуратнее нарезаны зоны, тем точнее расчёт и тем реже приходится вручную разбираться с «почему до этого посёлка так дорого».

Чтобы зона определялась автоматически, покупатель должен указать местоположение — обычно через поле выбора города с автоподсказкой на базе справочника местоположений. Здесь важны два момента. Первый: справочник местоположений нужно держать в актуальном состоянии (Битрикс поставляет его отдельным набором данных). Второй: определение города по IP или геолокации браузера ускоряет оформление, но всегда должно оставаться редактируемым — покупатель может заказывать в другой регион.

• Иерархия местоположений. Страна → регион → город; тариф можно привязывать на любом уровне и наследовать вниз.
• Зоны как группы. Одна зона объединяет десятки местоположений с общим тарифом — не нужно прописывать цену каждому городу.
• Ограничения по зоне. В дальние зоны часть служб недоступна — это задаётся ограничениями профиля доставки.
• Автоопределение с правкой. Город подставляется автоматически, но покупатель всегда может его сменить.

Тарифы перевозчиков и расчёт по API

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

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

Расчёт по API перевозчика. Обработчик доставки отправляет в СДЭК, Boxberry, Почту России или другую службу запрос с весом, габаритами и адресом и получает в ответ актуальную стоимость и срок. Плюс — максимальная точность и отсутствие ручного сопровождения тарифов. Минус — зависимость от доступности и скорости внешнего сервиса, необходимость обрабатывать ошибки и таймауты.

Практичная стратегия — гибрид: для основных перевозчиков используем расчёт по API как источник истины, а собственные тарифы по зонам держим как запасной вариант на случай недоступности сервиса. Так покупатель всегда видит цену, а вы не зависите на сто процентов от чужого аптайма. Про то, как выбирать и подключать конкретные службы, у нас есть отдельный разбор — интеграция доставки СДЭК и Boxberry в 1С-Битрикс.

Архитектура расчёта в корзине

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

В 1С-Битрикс эта цепочка реализована через объект расчёта доставки: система создаёт «отгрузку» (shipment) на основе корзины, прогоняет её через все подходящие профили служб доставки и собирает варианты с ценами и сроками. Каждый профиль вызывает свой обработчик — штатный или ваш. Обработчик и есть то место, где вы вставляете динамическую логику: считаете объёмный вес, определяете зону, обращаетесь к API и возвращаете результат.

Реализация в 1С-Битрикс пошагово

Перейдём к практике. Динамическую доставку в 1С-Битрикс можно собрать штатными средствами процентов на восемьдесят, а оставшееся закрыть своим обработчиком. Вот порядок работ, который мы используем на проектах.

1. Наведите порядок в весогабаритных данных. Проверьте, что у товаров заполнен вес, а у объёмных категорий — длина, ширина и высота. Без этого дальше идти бессмысленно: расчёт будет врать.
2. Обновите справочник местоположений. В «Магазин → Настройки → Местоположения» загрузите актуальный набор данных и включите нужные регионы. Настройте поле выбора города с автоподсказкой на оформлении заказа.
3. Опишите зоны доставки. Сгруппируйте местоположения в зоны («свой город», «регион», «Россия», «дальние территории») в разделе служб доставки.
4. Создайте службы доставки. В «Магазин → Службы доставки» добавьте профили: собственная курьерская, самовывоз, и внешние перевозчики через их модули или свой обработчик.
5. Настройте расчёт по API. Для СДЭК, Boxberry, Почты России подключите официальные или проверенные модули из Маркетплейса либо реализуйте обработчик, обращающийся к API. Пропишите учётные данные, договор и тарифный режим.
6. Задайте ограничения. Для каждой службы укажите, в каких зонах, при каком весе и габаритах она доступна. Крупногабарит не должен предлагаться постаматом.
7. Настройте запасной расчёт. Опишите собственные тарифы по зонам и весу как fallback на случай недоступности API.
8. Добавьте правила бесплатной доставки. Через правила работы с корзиной задайте порог суммы, при котором доставка обнуляется.
9. Протестируйте на реальных заказах. Прогоните типовые корзины (лёгкая, тяжёлая, объёмная, в дальнюю зону) и сверьте расчёт с кабинетами перевозчиков.

Отдельно про подключение самих API — техническую сторону запросов, аутентификации и обработки ответов мы подробно разбираем в материале интеграция доставки по API в 1С-Битрикс. Там же — про вебхуки статусов и печать этикеток.

Как это выглядит в админке

Настройки службы доставки в 1С-Битрикс собраны на странице профиля службы: там задаются обработчик, ограничения, зоны и параметры расчёта. Схематично карточка службы с расчётом по API выглядит так:

Свой обработчик доставки

Штатных модулей и профилей хватает для большинства задач, но иногда нужна логика, которой в коробке нет: смешанный расчёт, особые надбавки, приоритет одного перевозчика над другим, кастомная упаковочная формула. Тогда пишется собственный обработчик доставки — класс, наследующий базовый класс службы доставки модуля sale.

Идея простая: обработчик получает объект отгрузки со всей корзиной и адресом, а вы в методе расчёта возвращаете результат — стоимость, срок и признак успеха. Внутри метода вы вольны делать что угодно: считать объёмный вес, определять зону, дёргать API, применять свои коэффициенты. Ключевые принципы хорошего обработчика:

• Всегда возвращайте результат. Даже при ошибке метод должен вернуть корректный объект расчёта — с ценой запасного варианта или с флагом ошибки, но не «упасть».
• Изолируйте сетевые вызовы. Обращение к API оборачивайте в таймаут и обработку исключений, чтобы медленный перевозчик не завешивал корзину.
• Кэшируйте ответы. Одинаковые запросы (та же зона, вес, габариты) не должны каждый раз ходить в сеть.
• Логируйте расчёты. Сохраняйте параметры запроса и ответ, чтобы разбирать спорные случаи «почему посчиталось столько».
• Уважайте ограничения. Проверяйте зону, вес и габариты до обращения к API — если служба тут недоступна, не тратьте сетевой запрос.

Бесплатная доставка и правила корзины

Бесплатная доставка от суммы — мощный инструмент увеличения среднего чека, и он отлично уживается с динамическим расчётом. Логика такая: расчёт всё равно происходит (вы должны знать реальную себестоимость), но покупателю при достижении порога стоимость показывается нулевой.

В 1С-Битрикс это делается двумя способами. Первый — правила работы с корзиной («Магазин → Настройки → Правила работы с корзиной»): создаётся правило «при сумме заказа от N рублей — скидка на доставку 100%». Второй — настройки самого профиля службы доставки, где можно задать порог бесплатной доставки. Первый способ гибче: правила умеют учитывать группы товаров, купоны, промежуток дат акции.

• Порог по зонам. Разумно делать порог бесплатной доставки разным для разных зон — по своему городу он ниже, для дальних регионов выше или отсутствует.
• Порог по категориям. Для габаритных товаров бесплатную доставку либо не давать, либо считать по особому порогу — иначе она съест маржу.
• Прозрачность для покупателя. Показывайте в корзине «до бесплатной доставки осталось N ₽» — это прямо стимулирует добрать корзину.
• Учёт себестоимости. Даже при «бесплатной» доставке считайте реальную стоимость внутри — это нужно для отчётности и оценки экономики акции.

Надёжность: таймауты, кэш, запасной расчёт

Расчёт по API — это зависимость от чужого сервиса, и относиться к ней надо соответственно. Внешняя служба может отвечать медленно, вернуть ошибку, уйти на техработы. Если корзина при этом «зависает» или показывает пустое место вместо цены доставки — вы теряете заказ на последнем шаге, самом дорогом с точки зрения привлечения. Поэтому обвязка надёжности — не опциональное украшение, а обязательная часть внедрения.

Три кита надёжного расчёта по API:

1. Таймаут на запрос. Ставьте жёсткий лимит 2–3 секунды. Если перевозчик не ответил — не ждём, а переходим к запасному расчёту. Лучше показать чуть менее точную цену сразу, чем точную через десять секунд (которые покупатель не будет ждать).
2. Кэширование ответов. Ответ API кэшируется по ключу «служба + зона + весовой диапазон + габариты» на короткий срок (минуты — десятки минут). Одинаковые корзины не должны каждый раз ходить в сеть, это и быстрее, и бережёт лимиты API.
3. Запасной расчёт. При ошибке или таймауте включается собственный тариф по зонам и весу. Покупатель всегда видит цену; расхождение с точным тарифом покрывается небольшим запасом в fallback-ставках.

Дополнительно полезно вести мониторинг: если доля обращений к запасному расчёту вдруг выросла, значит, у перевозчика проблемы с API, и стоит разобраться. А ещё — асинхронность: обращение к нескольким службам одновременно (параллельно, а не последовательно) заметно ускоряет вывод вариантов доставки на странице оформления.

UX корзины и вывод стоимости

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

• Показывайте несколько вариантов. Курьер, ПВЗ, постамат, самовывоз — с ценой и сроком у каждого. Выбор снижает тревогу и процент отказов.
• Сроки рядом с ценой. «290 ₽, 2–3 дня» убеждает лучше, чем просто «290 ₽». Многие готовы доплатить за скорость.
• Обновляйте цену без перезагрузки. При смене адреса или способа доставки стоимость должна пересчитываться на месте, а не после отправки формы.
• Индикатор пересчёта. Пока идёт запрос к API, показывайте лёгкий спиннер, чтобы пользователь не думал, что «зависло».
• Прогресс до бесплатной доставки. «До бесплатной доставки осталось 340 ₽» повышает средний чек лучше любого баннера.
• Понятные ошибки. Если в зону служба недоступна — так и напишите, а не показывайте пустоту.

Тонкость воспринимаемой скорости: расчёт по API занимает доли секунды, но на медленном соединении это заметно. Показывайте сначала мгновенный запасной расчёт или диапазон «от», а точную цену подгружайте — так корзина ощущается быстрой, а не «думающей».

Частые ошибки

• Не заполнены вес и габариты у товаров — расчёт занижен или нулевой, магазин везёт себе в убыток.
• Считают только физический вес и забывают про объёмный — лёгкие, но крупные заказы уходят по заниженной ставке.
• Нет запасного расчёта — при недоступности API покупатель видит пустое место вместо цены и бросает корзину.
• Запрос к API без таймаута — медленный ответ перевозчика подвешивает всё оформление заказа.
• Не кэшируют ответы API — сайт упирается в лимиты перевозчика и тормозит на пиковой нагрузке.
• Устаревший справочник местоположений — города не находятся, зона не определяется, расчёт срывается.
• Бесплатная доставка без учёта габаритов — акция съедает маржу на тяжёлых и объёмных заказах.
• Правки логики доставки прямо в ядре — при обновлении платформы доработки затираются.
• Подключили сразу десяток служб — поддержка ключей и ошибок превращается в постоянную головную боль.

Чек-лист внедрения

Сведём всё в практический список, по которому удобно принимать готовность динамической доставки перед запуском:

1. Весогабаритные данные заполнены. У товаров есть вес, у объёмных категорий — длина, ширина, высота; данные проверены на выборке.
2. Объёмный вес считается. Обработчик берёт большее из физического и объёмного веса, учтена упаковка.
3. Зоны описаны. Справочник местоположений актуален, зоны доставки нарезаны, тарифы к ним привязаны.
4. Службы подключены. Основные перевозчики считают по API, учётные данные и тарифные режимы прописаны.
5. Ограничения заданы. Для каждой службы указаны доступные зоны, предельный вес и габариты.
6. Запасной расчёт работает. При недоступности API включается собственный тариф по зонам, покупатель всегда видит цену.
7. Таймаут и кэш настроены. Запросы к API ограничены по времени, ответы кэшируются, обращения к службам идут параллельно.
8. Бесплатная доставка настроена. Пороги по суммам и зонам заданы, габаритные товары учтены отдельно.
9. UX корзины проверен. Варианты доставки с ценой и сроком, пересчёт без перезагрузки, прогресс до бесплатной доставки.
10. Расчёт сверен. Типовые корзины протестированы, цены совпали с кабинетами перевозчиков, спорные случаи логируются.

Вывод

Динамический расчёт стоимости доставки превращает логистику из статьи убытков в управляемый и честный процесс: каждый заказ платит за себя, покупатель видит справедливую цену, а магазин не субсидирует тяжёлые и дальние отправления из своей прибыли. В 1С-Битрикс это собирается из четырёх согласованных частей — качественные весогабаритные данные, аккуратные зоны, расчёт по API перевозчиков и надёжная обвязка с таймаутами, кэшем и запасным сценарием. Настройте все четыре — и доставка перестанет быть слабым местом корзины, а станет ещё одним преимуществом магазина.