В 1С-Битрикс не отображается доставка при оформлении заказа: что проверить

Покупатель добавил товар в корзину, указал адрес и дошёл до доставки. Для Москвы варианты есть, после выбора другого города список становится пустым. Или служба отображается, но вместо стоимости появляется ошибка. Внешне ситуации похожи, однако проверять их нужно по-разному.

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

1. Уточните, что именно исчезло и после какого действия

Фразы «доставка не работает» недостаточно для исправления. Разделите три наблюдения: способа нет в списке; способ есть, но тариф не рассчитывается; способ и цена получены, но форма не показывает результат. Отдельно проверьте выбор пункта выдачи: пустая карта ПВЗ ещё не означает, что сама служба доставки недоступна.

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

Затем повторите путь в приватном окне с одним товаром. Для сравнения используйте населённый пункт, куда магазин действительно доставляет. Меняйте одно условие за раз. Если одновременно сменить город, корзину и покупателя, будет трудно понять, какое изменение повлияло на результат.

2. Проверьте местоположение и условия доступности

В разделе «Магазин → Настройки → Службы доставки» найдите нужную службу и её профиль, если модуль использует профили. Убедитесь, что они активны. Названия пунктов меню могут отличаться в зависимости от версии и установленного решения.

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

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

Надпись в поле «Город» и местоположение заказа

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

У используемого типа плательщика проверьте свойство типа «Местоположение» и настройку «Использовать как местоположение». Именно это значение предназначено для расчёта доставки. Настройку нужно проверить отдельно для каждого типа покупателя — она описана в официальном разделе «Свойства заказов». Если модуль перевозчика требует сопоставления со своим справочником городов, проверьте и эту связь по его документации.

3. Отделите параметры посылки от ошибки расчёта

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

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

Если данные меняются после обмена или импорта, повторите проверку после очередного обновления каталога. Ручное исправление карточки не поможет надолго, если следующий обмен вернёт прежнее значение. Устройство вариантов товара и источников данных при необходимости проверяют в рамках доработки каталога.

Служба есть, а стоимость не получена

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

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

Отдельно проверьте параметры компонента оформления. В стандартном bitrix:sale.order.ajax предусмотрены настройки момента внешнего расчёта и поведения при его ошибке. Они описаны в документации компонента. Поэтому отсутствие цены сразу после открытия страницы ещё не устанавливает причину: важно увидеть, что происходит после предусмотренного действия пользователя.

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

4. Если доставка исчезает после смены адреса, проверьте пересчёт формы

Рассмотрим условный пример. Покупатель выбирает Казань вместо Москвы. Поле на экране меняется, но доставка остаётся московской; после обновления страницы список становится правильным. Здесь полезно проследить одну цепочку: выбранное значение → запрос пересчёта → ответ сервера → видимый список.

1. Значение. Совпадает ли местоположение внутри формы с выбранным городом? Не осталось ли прежнее значение в скрытом поле?
2. Запрос. Отправляется ли пересчёт после выбора подсказки? Переданы ли актуальные адрес и состав корзины?
3. Ответ. Вернулся ли он успешно и содержит ли ожидаемый результат расчёта? HTTP 200 сам по себе не подтверждает отсутствие ошибки внутри ответа.
4. Отрисовка. Появился ли результат на экране? Не мешает ли JavaScript-ошибка, повторная инициализация виджета или ответ от более раннего запроса?

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

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

5. Проверьте исправление на нескольких контрольных заказах

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

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

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

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

Частые вопросы

Почему в админке доставка доступна, а покупатель её не видит?

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

Можно ли временно снять все ограничения доставки?

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

Нужно ли сразу обновлять или переустанавливать модуль?

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

Поможет ли очистка кеша?

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

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