Расчёт доставки по весу, габаритам и зонам в 1С-Битрикс

Покупатель добавил в корзину плед, подушку и постельное бельё, дошёл до оформления — и увидел «доставка: 250 ₽» на другой конец страны. Для вас это убыток: реальная отправка такого объёмного заказа стоит в разы дороже. Другой покупатель заказал одну книгу в соседний город и получил ту же ставку — теперь он переплачивает и уходит к конкуренту. Причина в обоих случаях одна: доставка считается «на глаз», без учёта веса, габаритов и зоны. Эта статья — подробный разбор того, как настроить расчёт доставки в 1С-Битрикс так, чтобы цена была честной для покупателя и не съедала вашу маржу.

Разберём по порядку: как модуль «Интернет-магазин» считает стоимость доставки, почему всё начинается с веса товара в каталоге, что такое объёмный вес и как он появляется из габаритов, как работают зоны и локации, чем ограничивают профили доставки, когда выбрать фиксированный тариф, собственную таблицу «вес × зона» или расчёт по API службы. Материал основан на нашей практике разработки магазинов с оплатой и доставкой и интеграции служб доставки — по делу, без обещаний «настроим за час».

Зачем нужен точный расчёт доставки

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

• Честная цена для покупателя. Человек видит реальную стоимость доставки именно к нему — за свой вес, свой объём и своё расстояние, а не «среднюю по стране».
• Защита маржи. Каждый заниженный тариф на объёмный или тяжёлый заказ вы доплачиваете перевозчику из прибыли. Расчёт по факту не даёт продавать доставку в убыток.
• Меньше отказов на оформлении. Мгновенная и понятная стоимость удерживает покупателя в воронке, тогда как «уточняйте у менеджера» теряет часть заказов.
• Прозрачность экономики. Когда доставка считается по реальным параметрам, вы видите настоящую себестоимость логистики и можете осознанно управлять порогами бесплатной доставки.

Иными словами, точный расчёт доставки — это одновременно про конверсию и про экономику заказа. Он убирает трение на оформлении и не даёт логистике съедать прибыль. На заметных объёмах правильная настройка окупается быстро: разница между «250 ₽ на всё» и честным тарифом на каждый заказ складывается в ощутимые суммы за месяц.

Как устроена доставка в модуле «Интернет-магазин»

Расчёт доставки в 1С-Битрикс живёт в модуле «Интернет-магазин» и собран из нескольких понятных сущностей. Разберём их, чтобы настройка была осознанной, а не «методом тыка».

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

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

Три способа задать стоимость: фиксация, расчёт, API

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

Фиксированная стоимость — самая простая: покупатель по своему городу платит, скажем, единую ставку, и вес заказа на неё не влияет. Расчётная стоимость сложнее: вы задаёте таблицу «диапазон веса × зона → цена», и Битрикс сам выбирает нужную ячейку. Расчёт по API — самый точный: обработчик службы обращается к перевозчику и возвращает его актуальный тариф для конкретного адреса и веса.

На практике грамотный магазин комбинирует все три: фиксированная ставка (или бесплатно) по своему городу собственным курьером, расчёт по API для регионов через СДЭК и Почту, самовывоз с нулевой стоимостью. Ниже разберём каждый слой подробно, начиная с фундамента — веса товара.

Вес товара — базовый параметр расчёта

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

Что важно понимать про вес в контексте расчёта:

• Вес хранится на уровне товара (или SKU). В торговом каталоге у каждого элемента есть поле веса. Если у товара есть торговые предложения, вес логично задавать у каждого предложения — размер XXL может весить заметно больше, чем S.
• Вес корзины — сумма весов позиций. Обработчик получает суммарный вес всех товаров заказа с учётом количества. Если хотя бы у части товаров вес нулевой, суммарный вес занижается, и тариф выходит неверным.
• Единицы измерения. В Битриксе вес обычно хранится в граммах. Ошибка в единицах (килограммы вместо граммов) — классическая причина расчёта «в тысячу раз дороже» или «в тысячу раз дешевле».
• Вес упаковки. Службы к массе товара добавляют вес упаковки. Это стоит закладывать либо в вес товара, либо отдельной надбавкой, чтобы расчёт совпадал с фактической отправкой.

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

Заполнение веса в каталоге

Раз вес — это фундамент, разберём отдельно, откуда он берётся и как его правильно вести. На практике встречаются три источника, и лучший из них — учётная система.

Ручное заполнение в карточке товара

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

Импорт из 1С при обмене

Идеальный вариант — вес приходит из 1С вместе с остальными данными товара при обмене по CommerceML. Тогда он ведётся в одном месте (учётной системе), не расходится с реальностью и автоматически проставляется у всех товаров, включая новые. Как устроен такой обмен, мы подробно разбираем в материалах по интеграции; здесь важно запомнить принцип: данные о товаре, включая вес и габариты, лучше держать в едином источнике, а не дублировать вручную на сайте.

Значение по умолчанию

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

Габариты и объёмный вес

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

Габариты — это длина, ширина и высота отправления. В торговом каталоге Битрикса для них есть отдельные поля на уровне товара или торгового предложения. Что важно про габариты:

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

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

Как считается объёмный вес

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

Логика применения:

1. Считаем объём. Длина × ширина × высота отправления дают его объём в кубических сантиметрах.
2. Переводим в объёмный вес. Объём делится на коэффициент плотности перевозчика — получается волюметрический вес в килограммах.
3. Сравниваем с фактическим. Берётся большее из двух значений: если объёмный вес больше реального, тариф считается по нему.
4. Считаем тариф. К «расчётному» весу применяется тарифная сетка службы по зоне назначения.

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

Зоны доставки и локации Битрикс

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

Местоположения (локации)

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

Зоны доставки

Зона доставки — это группа местоположений, объединённых по логике тарификации. Битрикс сам по себе не знает, что «Москва и область» у вас один тариф, а «остальная Россия» — другой; это вы задаёте, собирая зоны из локаций. Типичный набор зон:

• Свой город. Часто с собственной курьерской доставкой и фиксированной или бесплатной ставкой.
• Ближняя зона / область. Пригород и соседние города с отдельным тарифом.
• Регионы / вся Россия. Доставка службами с расчётом по весу и API.
• Отдалённые территории. Труднодоступные районы, куда доходит только Почта и с повышенным тарифом.

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

Тарифы по зонам

Зоны сами по себе — это только география. Стоимость появляется, когда к зоне привязывается тариф. Для собственной (не API) доставки тариф чаще всего задают таблицей «диапазон веса × зона», где на пересечении стоит цена.

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

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

Профили доставки и их устройство

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

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

Ограничения: вес, сумма, местоположение

Ограничения — это правила, которые делают доставку «умной»: по ним Битрикс решает, показывать ли способ покупателю и по какой цене. Без ограничений все профили были бы доступны всем и всегда, что приводило бы к нелепым ситуациям (доставка пункта выдачи там, где их нет, или курьер по городу для покупателя из другого региона).

Основные виды ограничений:

• По весу заказа. Способ доступен только для определённого диапазона массы. Например, доставка через пункт выдачи — до лимита веса посылки; тяжёлые заказы уходят на транспортную компанию.
• По сумме заказа. Через это ограничение реализуют бесплатную доставку от суммы, минимальную сумму для способа или, наоборот, ограничение дорогих заказов только предоплатой.
• По местоположению. Способ виден только для нужных зон или городов. Собственный курьер — только для своего города, почта — для всей страны.
• По способу оплаты. Наложенный платёж доступен не для всех способов доставки; предоплата может быть обязательной для дальних регионов.
• По габаритам. Слишком большой заказ не проходит через профили с ограничением размеров (ПВЗ, почтовые нормативы).

Ограничения работают в связке: один профиль может иметь сразу несколько условий. Например, «курьер по городу» — ограничение по местоположению (только свой город) плюс по весу (до 30 кг) плюс бесплатно от суммы. Именно совокупность ограничений формирует ту логику, которую покупатель видит как «доступные способы доставки для моего заказа».

Бесплатная доставка от суммы

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

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

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

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

Расчёт по API служб или собственные тарифы

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

Собственные тарифы (таблица вес × зона)

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

Расчёт по API служб (СДЭК, Почта, Boxberry)

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

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

Наложенный платёж и оплата при получении

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

Что важно про наложенный платёж в контексте расчёта:

• Это отдельная настройка службы. Возможность наложенного платежа задаётся в договоре с перевозчиком и включается в способе оплаты на сайте, привязанном к нужным способам доставки.
• Комиссия за перевод. Служба берёт процент за приём и перевод денег — это стоит закладывать в экономику, а иногда частично переносить в стоимость доставки для таких заказов.
• Риск невыкупа. Заказы с оплатой при получении чаще не выкупают. Для дорогих или объёмных заказов в дальние регионы иногда оставляют только предоплату, чтобы снизить риск.
• Связь способа доставки и оплаты. Наложенный платёж доступен не для всех способов: для самовывоза и ПВЗ один набор оплат, для курьера — другой. Это настраивается ограничениями.

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

Самовывоз и точки выдачи

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

• Привязка к складу. Самовывоз имеет смысл только там, где товар физически есть. Способ логично ограничивать наличием на конкретном складе или в точке выдачи.
• Несколько точек. Если у вас несколько магазинов или пунктов, покупатель выбирает удобный, а система показывает наличие именно в нём.
• Срок готовности. Даже при самовывозе стоит показывать срок, через который заказ можно забрать, — особенно если товар едет с центрального склада в точку.
• Оплата. Самовывоз хорошо сочетается и с онлайн-оплатой, и с оплатой на месте, что расширяет варианты для покупателя.

Пункты выдачи служб (ПВЗ СДЭК, Boxberry) — это, по сути, тоже «самовывоз», но со стороны перевозчика: стоимость доставки до ПВЗ считается по API, а покупатель забирает заказ из выбранной точки. Разница с классическим самовывозом в том, что до ПВЗ товар везёт служба, и это платно, а свой самовывоз бесплатен.

Экстра-сервисы: страховка, подъём, упаковка

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

• Страховка (объявленная ценность). Для дорогих заказов службы предлагают застраховать отправление — обычно это процент от объявленной стоимости. При расчёте по API страховка может добавляться автоматически.
• Подъём на этаж. Для крупногабаритных и тяжёлых товаров (мебель, техника) актуальна услуга подъёма — платная надбавка, которую задают отдельно.
• Дополнительная упаковка. Хрупкие товары требуют усиленной упаковки; её стоимость либо закладывают в тариф, либо выносят отдельной услугой.
• Примерка и частичный выкуп. Для одежды и обуви некоторые службы поддерживают примерку и частичный выкуп — это влияет на логику оплаты и расчёта.

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

Связь доставки со складом и наличием

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

• Точка отправления. Тариф считается от склада, с которого едет заказ. Если складов несколько, определяют, какой считать точкой отправления, — от этого зависит расстояние и цена.
• Наличие влияет на способы. Самовывоз доступен только там, где товар есть; при отсутствии на ближнем складе заказ может ехать с дальнего, и это меняет срок и стоимость.
• Разные склады — разные зоны. Для сети складов расчёт усложняется: логично отгружать из ближайшего к покупателю склада, где товар в наличии.
• Резерв и доставка. Выбранный способ доставки и склад отгрузки уходят в заказ и в 1С, где под них резервируется товар.

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

Отображение стоимости в корзине и checkout

Даже идеально настроенный расчёт бесполезен, если покупатель не понимает, за что платит. Поэтому важно, как стоимость доставки показывается в корзине и на странице оформления (checkout).

• Расчёт по мере ввода адреса. Как только покупатель указал город, доставка пересчитывается — он сразу видит доступные способы и их цены, а не «доставка рассчитывается после заказа».
• Понятные названия способов. «Курьер до двери, 1–2 дня», «Пункт выдачи СДЭК, от 300 ₽» понятнее, чем сухие технические профили. Название должно отвечать на вопросы «как» и «когда».
• Честные сроки. Показывайте реальные сроки от службы, а не «1–2 дня по всей стране». Завышенные ожидания бьют по доверию сильнее, чем честный долгий срок.
• Прогресс до бесплатной доставки. Подсказка «добавьте на N ₽ до бесплатной доставки» прямо в корзине повышает средний чек.
• Итог с доставкой. В финальной сумме заказа стоимость доставки должна быть выделена отдельной строкой, чтобы не было ощущения «скрытой» доплаты.

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

Настройка расчёта пошагово

Сведём всё вместе в практический порядок настройки. Последовательность важна: данные о товаре и география должны быть готовы до того, как вы настраиваете тарифы.

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

Тестирование расчёта доставки

Перед запуском расчёт прогоняют по сценариям — «вроде считает» недостаточно. Вот что стоит проверить на тестовых заказах.

• Разные города. Оформите заказы в свой город, соседний регион и на другой конец страны — стоимость и сроки должны различаться и быть правдоподобными.
• Разный вес. Лёгкий и тяжёлый заказ — тариф должен реагировать на массу, а не быть одинаковым.
• Объёмный заказ. Крупный лёгкий товар — проверьте, что объёмный вес учитывается и тариф не занижен.
• Нулевой вес. Товар без заполненного веса — убедитесь, что срабатывает вес по умолчанию, а не «доставка 0 ₽».
• Все способы. Курьер, ПВЗ, почта, самовывоз — каждый считается и показывается для подходящих адресов.
• Ограничения. Тяжёлый заказ не предлагает ПВЗ с лимитом веса; курьер по городу не виден для другого региона.
• Бесплатная доставка. При достижении порога способ становится бесплатным именно там, где задумано.
• Связь с оплатой. Для выбранного способа доставки показываются правильные способы оплаты, включая наложенный платёж там, где он разрешён.
• Заказ в 1С. Способ, адрес и стоимость доставки корректно уходят в учётную систему при обмене.

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

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

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

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

Чек-лист запуска

Короткий список, по которому удобно свериться перед открытием расчёта доставки для всех покупателей:

1. Вес и габариты товаров заполнены, лучше — из 1С; задан вес по умолчанию.
2. Местоположения проверены: нужные регионы и города есть в справочнике.
3. Зоны доставки собраны под тарификацию: свой город, область, регионы, отдалённые.
4. Тарифы заданы: таблицы «вес × зона» для своей доставки, ключи API для служб.
5. Точка отправления (склад/город) указана для расчёта.
6. Профили настроены: курьер, ПВЗ, почта, самовывоз — с нужными обработчиками.
7. Ограничения заданы: по весу, габаритам, местоположению, сумме и способу оплаты.
8. Объёмный вес учитывается для крупногабаритных категорий.
9. Бесплатная доставка от суммы настроена с оглядкой на себестоимость и зону.
10. Доставка связана с оплатой: наложенный платёж там, где разрешён; правильные оплаты для каждого способа.
11. Отображение проверено: способы, цены и сроки понятны в корзине и на checkout.
12. Тестовые сценарии пройдены: разные города, веса, объёмные заказы, края.

Вывод

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

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