Расчёт стоимости доставки прямо в корзине: как реализовать

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

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

Зачем показывать доставку до оформления

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

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

Кому это особенно важно

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

Как устроена доставка в 1С-Битрикс

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

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

Точный расчёт или ориентир: что честнее

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

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

Что нужно для расчёта: город, вес, габариты

Даже упрощённый расчёт опирается на конкретные данные. Минимальный набор для предварительной оценки в корзине:

• Местоположение. Хотя бы город или регион — от него зависит зона и тариф. Часто город определяют по IP и дают поменять вручную.
• Вес корзины. Сумма весов товаров с учётом количества. Вес берётся из свойства товара в 1С-Битрикс.
• Сумма корзины. Нужна для порогов бесплатной доставки и тарифов «по сумме».
• Габариты и объём. Для крупногабаритных позиций — отдельные правила; часто используют усреднённый объём упаковки.
• Склад отгрузки. Если складов несколько, тариф зависит от того, откуда едет товар.

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

Зоны доставки и способы получения

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

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

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

Внешние API транспортных компаний

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

Что важно учитывать при работе с внешними API:

• Задержки. Ответ приходит за сотни миллисекунд, иногда секунды — синхронный вызов при загрузке корзины недопустим.
• Таймауты и сбои. API периодически недоступно; нужен запасной тариф и понятное сообщение, а не ошибка.
• Лимиты запросов. У сервисов есть ограничения; без кэша вы быстро упрётесь в лимит.
• Безопасность ключей. Токены доступа хранят на сервере, а не в JS; запросы к API идут с бэкенда.

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

Кэш и производительность расчёта

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

1. Кэшируйте по ключу. Ключ кэша — «город + округлённый вес + диапазон суммы + способ». Один и тот же расчёт не повторяется десятки раз.
2. Считайте асинхронно. Цена доставки подгружается AJAX-запросом после выбора города, а не блокирует загрузку корзины.
3. Держите TTL разумным. Тарифы меняются нечасто — кэш на несколько часов снимает нагрузку без риска устаревания.
4. Готовьте запасной путь. Если API не ответило за таймаут — отдавайте базовый тариф зоны, а не ошибку.

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

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

Порог бесплатной доставки — сильный конверсионный инструмент, и его логичнее всего показывать именно в корзине. Если до бесплатной доставки не хватает суммы, покажите прогресс: «до бесплатной доставки осталось 800 ₽». Это мягко подталкивает добрать товар и поднимает средний чек без скидок.

Несколько правил, чтобы приём работал честно:

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

Данные из 1С: вес, склад, упаковка

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

Что стоит держать под контролем на стороне 1С и обмена:

• Вес и габариты номенклатуры. Заполнены и актуальны, а не «по умолчанию 1 кг».
• Склад отгрузки. При нескольких складах тариф зависит от того, откуда едет товар клиенту.
• Признак крупногабаритного товара. Отдельные правила доставки и исключения из бесплатных порогов.
• Упаковка и кратность. Как товар пакуется — от этого зависит вес и объём места.

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

Реализация в корзине пошагово

Названия настроек зависят от редакции и шаблона, но общая последовательность внедрения такова:

1. Проверьте данные товара. Вес, габариты и склад отгрузки заполнены и приходят обменом из 1С.
2. Настройте службы и зоны. Способы получения, местоположения и тарифы описаны в модуле «Интернет-магазин».
3. Сделайте предрасчёт. В корзине по городу и весу вызывайте расчёт служб доставки и показывайте ориентир или цену по способам.
4. Вынесите внешние API на бэкенд. Запросы к транспортным компаниям идут с сервера, с кэшем и таймаутами.
5. Добавьте порог бесплатной доставки. Прогресс-индикатор «осталось добрать» из тех же правил, что и на оформлении.
6. Синхронизируйте с оформлением. Убедитесь, что корзина и sale.order считают доставку одинаково.
7. Протестируйте на реальных данных. Разные города, вес, крупногабарит, падение API — везде корректный и не завышенный ответ.

Чтобы такие изменения выкатывались без риска для боевой корзины, полезно иметь настроенный процесс деплоя. Как выстроить безопасную выкладку правок, мы описали в статье про CI/CD и деплой в Битрикс.

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

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

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

1. Данные товара чистые. Вес, габариты, склад и признак крупногабарита приходят из 1С и актуальны.
2. Службы и зоны настроены. Способы получения и тарифы описаны в модуле «Интернет-магазин».
3. Предрасчёт в корзине работает. По городу и весу показывается ориентир или цена по способам.
4. Внешние API на бэкенде. Кэш по ключу, таймауты, запасной тариф, ключи на сервере.
5. Порог бесплатной доставки виден. Прогресс-индикатор согласован с правилами оформления.
6. Корзина и оформление совпадают. Единая логика расчёта, предварительная цена не ниже финальной.
7. Протестировано на пиках и сбоях. Разные города, вес, падение API — корректный ответ и стабильная скорость.

Вывод

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

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