Доставка в пункт выдачи и постамат давно обогнала курьера по популярности: людям удобно забирать заказ рядом с домом, без ожидания курьера в четырёхчасовом окне. Но всё это работает, только если выбор пункта на сайте удобен. Когда покупателя заставляют вводить точный адрес ПВЗ вручную или показывают простыню из сотен строк без карты, он теряется — и заказ рискует не дойти до оплаты.
В этой статье разберём, как встроить выбор пункта выдачи на карте в оформление заказа на 1С-Битрикс: карта против списка, готовый виджет службы против своей реализации, как считать стоимость, учитывать габариты и корректно сохранять выбранный ПВЗ в заказе и передавать его в 1С и перевозчику. Настройку доставки и обмена мы закрываем услугой автоматизации продаж и склада на 1С.
Коротко
- Выбор ПВЗ на карте удобнее списка: человек мыслит географически и ищет пункт «по пути».
- Чаще выгоднее готовый виджет службы доставки — он знает актуальные точки, тарифы и ограничения.
- Считайте стоимость и учитывайте габариты до оформления, а не «сюрпризом» в конце.
- Сохраняйте в заказе ID пункта, а не только адрес, чтобы он корректно ушёл в 1С и перевозчику.
Почему выбор ПВЗ важен для конверсии
Шаг выбора доставки — одно из самых «дырявых» мест оформления. Именно здесь покупатель сталкивается с реальностью: сколько стоит доставка, куда и когда он получит заказ. Если выбор пункта неудобен, человек либо ошибается, либо бросает корзину. А поскольку ПВЗ и постаматы стали основным способом получения, качество этого шага прямо влияет на выручку.
Удобный выбор пункта решает сразу несколько задач: снимает тревогу «а где я это заберу», показывает честную стоимость и превращает абстрактную «доставку» в понятную точку на карте рядом с домом. Плохой выбор ПВЗ, наоборот, — типичная причина брошенных корзин на шаге доставки, о которых мы подробно писали в блоге. Поэтому вкладываться в этот экран так же важно, как в кнопку «Оформить заказ».
Карта, список или гибрид
Первый вопрос — как вообще показывать пункты. Есть три подхода:
| Вариант | Когда хорош | Минусы |
|---|---|---|
| Карта с метками | Много пунктов, город | Тяжелее, нужен виджет карты |
| Список пунктов | Пунктов мало | Неудобно искать «по пути» |
| Гибрид: карта + список | Большинство магазинов | Чуть сложнее в вёрстке |
Оптимум для большинства — гибрид: карта с метками ПВЗ и рядом список с фильтром и поиском по адресу. Человек, который мыслит географически, кликает по карте; тот, кто предпочитает текст, ищет в списке. Главное правило — не заставлять вводить точный адрес пункта вручную: покупатель не помнит адрес ПВЗ, он знает только «где-то у метро».
Готовый виджет или своя карта
Второй ключевой выбор — брать готовый виджет службы доставки или рисовать карту самому. У каждого пути своя цена.
- Готовый виджет службы. Знает актуальные точки, графики, габаритные лимиты и стоимость; обновляется на стороне перевозчика. Быстрее внедрить и дешевле поддерживать.
- Своя карта. Даёт единый фирменный вид и позволяет объединить пункты нескольких служб, но требует самостоятельно получать и обновлять данные о ПВЗ через API.
В большинстве случаев выгоднее готовый виджет: перевозчик сам поддерживает актуальность точек и ограничений, а вам не нужно синхронизировать тысячи адресов. Своя карта оправдана, когда важно свести пункты нескольких служб в один интерфейс или выдержать строгий фирменный стиль — это уже кастомная разработка поверх штатных служб.
Как устроены службы доставки в 1С-Битрикс
Технически всё опирается на подсистему доставки модуля «Интернет-магазин». Её полезно понимать, чтобы правильно встроить выбор ПВЗ:
- Служба доставки. Настраивается как отдельная служба со своим обработчиком и профилями (курьер, ПВЗ, постамат).
- Обработчик. Код, который считает стоимость и сроки, обращаясь к API перевозчика.
- Профили. Разновидности доставки внутри службы — например, «до пункта выдачи» и «до постамата».
- Свойства заказа. Куда сохраняются выбранный пункт, адрес и параметры доставки.
Многие крупные службы предоставляют готовые модули для Битрикс с виджетом карты «из коробки». Если же нужен нестандартный сценарий, пишут собственный обработчик доставки — по сути, отдельный модуль. Принципы такой разработки мы разбираем в статье про разработку модуля для Битрикс.
Стоимость доставки до пункта
Цена доставки до конкретного ПВЗ — не константа: она зависит от габаритов, веса, тарифа и удалённости точки. Правильный сценарий такой:
- Клиент выбирает пункт. На карте или в списке отмечает конкретный ПВЗ.
- Система пересчитывает доставку. Обработчик обращается к API службы и получает стоимость и срок именно до этой точки.
- Итог показывается сразу. Цена и срок отображаются до оформления, а не «сюрпризом» в конце.
Скрытая до последнего шага стоимость доставки — причина №1 брошенных корзин. Поэтому пересчёт после выбора ПВЗ и честный показ итога — обязательное требование, а не «приятная опция».
Габариты, вес и ограничения точек
Не в каждый пункт можно доставить любой товар. У постаматов ограничены ячейки, у ПВЗ бывают лимиты по весу и габаритам. Если это игнорировать, клиент выберет точку, куда его заказ физически не доедет, и получит отмену уже после оформления.
Хорошие виджеты служб фильтруют точки по габаритам автоматически. Если делаете свою карту, ограничения нужно запрашивать у API и учитывать при показе. Данные о габаритах товара при этом должны корректно приходить из учётной системы — это часть качественного обмена с 1С.
Сохранение выбранного ПВЗ в заказе
Выбрали пункт — его нужно правильно сохранить. Ключевой момент: хранить не только текстовый адрес, но и идентификатор пункта. В свойства заказа записывают:
- Код/ID пункта. Уникальный идентификатор ПВЗ в системе перевозчика — по нему точка определяется однозначно.
- Адрес и название. Для отображения клиенту и в документах.
- Служба и профиль. Какой перевозчик и какой тип выдачи выбран.
- Координаты. При необходимости — для отображения на карте в кабинете и уведомлениях.
Если хранить только адрес текстом, заказ невозможно корректно передать перевозчику: у службы пункт определяется по коду, а не по строке адреса, которую легко записать неоднозначно. Поэтому идентификатор — обязателен.
Передача пункта в 1С и службу
Заказ живёт не только на сайте: он уходит в 1С для учёта и в систему перевозчика для отгрузки. Выбранный ПВЗ должен доехать до обеих систем без искажений.
При обмене с 1С по CommerceML свойства заказа, включая код пункта и службу, передаются вместе с заказом, чтобы менеджер и складская логистика видели, куда отгружать. В систему перевозчика пункт уходит по его коду через API. Надёжность этих обменов критична: если код пункта теряется или искажается, заказ уедет не туда. Как безопасно строить такие интеграции, мы разбираем в статье про REST, вебхуки и безопасность в Битрикс, а быстрые выборки данных заказа — в материале про D7 и ORM.
Мобильная версия и производительность
Больше половины заказов оформляют с телефона, а карта — тяжёлый элемент. Требования к мобильному выбору ПВЗ:
- Удобство на сенсоре. Крупные метки, плавное масштабирование, определение геолокации, поиск по адресу.
- Читаемая карточка пункта. Адрес, график, стоимость и кнопка выбора видны без прокрутки в бесконечность.
- Карта не на весь экран. Кнопка «Продолжить» всегда доступна, карта не «съедает» интерфейс.
- Ленивая загрузка. Виджет карты подгружается только на шаге доставки, а не на всех страницах.
Тяжёлые карты бьют по скорости оформления, а медленный checkout — снова про брошенные корзины. Общую скорость витрины держат кэширование и грамотная инфраструктура — про неё мы пишем в статье про хостинг на BitrixVM.
Пошаговое внедрение
- Выберите службы. Определите перевозчиков и типы выдачи (ПВЗ, постаматы), которые вам нужны.
- Подключите виджеты. Установите готовые модули служб или спроектируйте свою карту при мультисервисном сценарии.
- Настройте обработчики. Стоимость и сроки считаются через API перевозчика в подсистеме доставки.
- Включите фильтр габаритов. Неподходящие точки скрываются по параметрам корзины.
- Настройте сохранение. В свойства заказа пишутся ID пункта, адрес, служба и профиль.
- Свяжите обмены. Пункт корректно уходит в 1С и в систему перевозчика.
- Проверьте на телефоне. Карта, поиск, геолокация и выбор работают удобно и быстро.
Частые ошибки
- Ручной ввод адреса ПВЗ. Покупатель не помнит адрес пункта — ему нужна карта, а не поле.
- Список без карты. Сотни строк без географии — искать «по пути» невозможно.
- Стоимость в конце. Цену доставки прячут до последнего шага — брошенная корзина.
- Игнор габаритов. Крупный товар предлагают к выдаче в маленький постамат — отмена.
- Хранят только адрес. Без ID пункта заказ невозможно корректно передать перевозчику.
- Устаревший список точек. «Зашитые» ПВЗ вместо актуальных из API — доставка в закрытый пункт.
- Тяжёлая карта везде. Виджет грузится на всех страницах и тормозит сайт.
Чек-лист внедрения
- Карта с пунктами. Гибрид «карта + список» с поиском по адресу, без ручного ввода ПВЗ.
- Актуальные точки. Пункты приходят из API службы, а не «зашиты».
- Стоимость до оформления. Цена и срок пересчитываются после выбора и показаны сразу.
- Фильтр по габаритам. Неподходящие точки скрыты заранее.
- Сохранён ID пункта. В заказе есть код ПВЗ, адрес, служба и профиль.
- Обмены настроены. Пункт корректно уходит в 1С и перевозчику.
- Мобайл проверен. Карта удобна на сенсоре и не тормозит оформление.
Вывод
Выбор пункта выдачи на карте — это шаг, на котором магазин либо помогает клиенту завершить заказ, либо теряет его. Люди мыслят географически, поэтому карта с метками ПВЗ и постаматов почти всегда лучше сухого списка, а готовый виджет службы избавляет от боли с актуальностью точек, тарифов и ограничений.
Технически важно считать стоимость и учитывать габариты до оформления, а выбранный пункт сохранять по идентификатору и без искажений передавать в 1С и перевозчику. Добавьте удобную мобильную карту и ленивую загрузку — и шаг доставки на вашем 1С-Битрикс перестанет быть местом потерь и станет одной из причин, по которым у вас удобно покупать.
