Доставка в Битриксе: частые ошибки настройки и расчёта

Покупатель из Казани открывает шаг «Доставка» и видит один пункт: «Самовывоз». Служба курьерской доставки в админке активна, ключи вбиты, тестовый расчёт у разработчика проходил. Очевидное решение — лезть в настройки службы и перебирать поля — почти никогда не помогает, потому что причина лежит в трёх других местах: ограничениях, местоположениях и единицах измерения веса. Ниже — ошибки, которые чаще всего ломают доставку в 1С-Битрикс, и цена каждого способа их обойти. Ориентир — новая система доставки на сборках 23.x–24.x; в проектах, которые обновлялись с версий до 2015 года, может остаться старая система с профилями без вкладки «Ограничения», и там половина пунктов называется иначе.

Служба не показывается в корзине

Это самая частая жалоба, и она почти всегда про фильтрацию, а не про расчёт. Модуль сначала отбрасывает службы по ограничениям¹ и только потом считает цену для оставшихся. Если служба отсеяна, покупатель не увидит ни её, ни текста ошибки.

• Местоположение не доехало до ограничения. Свойство заказа, в которое покупатель вводит город, должно быть отмечено как местоположение для расчёта доставки (флаг IS_LOCATION в настройках свойства). Без этого флага ограничение по местоположению получает пустое значение и режет всё.
• База местоположений не импортирована или импортирована частично. В разделе «Магазин → Настройки → Местоположения» должна быть иерархия: страна, регион, город. Если город покупателя пришёл из автодополнения, а в базе его нет, привязки к региону не будет.
• Ограничение по группе пользователей. Админ в бэкенде проходит все проверки, а анонимный покупатель — нет. Тестировать нужно в приватном окне, без авторизации.
• Ограничение на группе служб. Если службы собраны в группу, ограничения группы применяются ко всем вложенным. Настройки конкретного профиля при этом выглядят идеально.
• Ограничение по платёжной системе. Классика: наложенный платёж разрешён только для одной службы, а покупатель выбрал оплату картой на первом шаге.

Отдельно про порог суммы: ограничение «Сумма заказа» и скидки в корзине живут в разных местах, и порог может считаться не от той цифры, которую видит покупатель. Проверяйте не логикой, а тестовым заказом ровно на границе — 2 999 и 3 001 рубль.

Если доставка не видна — не правьте настройки службы. Сначала выясните, дошла ли до неё очередь расчёта вообще.

Как посмотреть расчёт глазами модуля

Быстрый способ отделить «служба отсеяна ограничением» от «служба посчитала и упала с ошибкой» — перебрать активные службы для реальной отгрузки² существующего заказа.

<?php
// Модуль sale, сборки 23.x-24.x. Скрипт с подключённым ядром.
use Bitrix\Main\Loader;
use Bitrix\Sale\Order;
use Bitrix\Sale\Delivery\Services\Manager;

Loader::includeModule('sale');

$order = Order::load(12345); // ID заказа с нужным городом и составом
$shipment = null;

foreach ($order->getShipmentCollection() as $orderShipment) {
    if (!$orderShipment->isSystem()) {
        $shipment = $orderShipment;
        break;
    }
}

foreach (Manager::getActiveList() as $serviceId => $serviceFields) {
    $deliveryService = Manager::getObjectById($serviceId);
    $calculation = $deliveryService->calculate($shipment);

    echo $serviceFields['NAME'] . ' -> ';
    echo $calculation->isSuccess()
        ? $calculation->getPrice()
        : implode('; ', $calculation->getErrorMessages());
    echo PHP_EOL;
}

Этот перебор показывает именно расчёт и его ошибки. Проверка ограничений — другой механизм (пространство имён Bitrix\Sale\Delivery\Restrictions), поэтому вывод читается так: цена есть, а в корзине службы нет — виноваты ограничения. Сигнатуры методов сверяйте с документацией вашей версии модуля: API доставки менялся между линейками.

Вес в граммах, габариты в миллиметрах

Битрикс хранит вес товара в граммах, а размеры — в миллиметрах, независимо от того, в каких единицах их показывает интерфейс. Отсюда два типичных сценария. Первый: контент-менеджер или импорт вписал в вес число 1.5, имея в виду килограммы, — служба считает тариф для посылки на полтора грамма. Второй: вес не заполнен вовсе, итоговый вес отгрузки равен нулю, и внешняя служба либо возвращает минимальный тариф, либо отказывает в расчёте.

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

Бесплатная доставка: три способа и их цена

Правило «от 3 000 рублей бесплатно» реализуется в Битриксе минимум тремя путями, и выбор определяет, сколько времени вы потом потратите на разбор странных заказов.

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

Что ломается после того, как всё настроено

1. Менеджер правит состав заказа, доставка остаётся прежней. У отгрузки есть признак ручной цены (CUSTOM_PRICE_DELIVERY). Стоило один раз вписать стоимость руками — и дальше она не пересчитывается ни при смене состава, ни при смене адреса. Проверьте этот флаг, прежде чем искать баг в расчёте.
2. Чекаут тормозит на смене города. При каждом обновлении шага оформления модуль считает все активные службы, и каждая внешняя служба — это HTTP-запрос. Десять активных служб превращаются в десять запросов в очереди. Лечится не кешем, а ограничениями: отсекайте службу по местоположению и весу до того, как дело дойдёт до вызова API, и выключайте то, чем магазин не пользуется. Смотрите время ajax-запроса компонента оформления в devtools при смене города — это и есть ваша метрика.
3. Работает у админа, не работает у покупателя. Кеш компонентов корзины и оформления плюс ограничение по группе пользователей дают ровно эту картину.
4. Тариф обновился на стороне службы, цены в магазине старые. Многие обработчики кешируют справочники тарифов и ПВЗ. После изменения договора со службой стоит сбросить кеш модуля и прогнать тестовый заказ, а не ждать, пока кеш истечёт сам.

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

Что делать дальше

Соберите короткий регрессионный сценарий и прогоняйте его после каждого обновления модуля: три города (своя область, другой регион, отдалённый регион), два веса (минимальный товар и тяжёлый), две суммы (ниже и выше порога бесплатной доставки), два способа оплаты. Шесть-восемь тестовых заказов в приватном окне ловят почти все поломки из этого списка.

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

1. Ограничение (restriction) — правило на вкладке службы доставки, которое определяет, показывать её покупателю или нет: по местоположению, сумме, весу, платёжной системе, группе пользователей. Работает как фильтр до расчёта цены.

2. Отгрузка (shipment) — объект заказа, который хранит состав посылки, выбранную службу и стоимость доставки. Служба доставки привязана к отгрузке, а не к заказу целиком, поэтому один заказ может уехать несколькими отправлениями.