Доставка Яндекс, Почта России и 5Post в 1С-Битрикс: ПВЗ и постаматы

Покупатель дошёл до оформления и хочет одного: увидеть, сколько стоит доставка именно к нему, и выбрать удобную точку — постамат у дома, пункт выдачи по дороге с работы или курьера до двери. Если магазин показывает только одну службу и «ближайший ПВЗ в соседнем городе», заказ уходит к конкуренту. Решение — единый узел доставки из нескольких служб: Яндекс Доставки, Почты России и 5Post, с расчётом по API, выбором пункта выдачи и постамата на карте и трекингом прямо в заказе. Эта статья — практическое руководство, как собрать такую доставку в магазине на 1С-Битрикс.

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

Зачем магазину несколько служб доставки

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

• Покрытие территории. У каждой службы своя сеть точек. Там, где у одной пусто, у другой есть постамат в шаговой доступности. Несколько служб вместе резко снижают долю «нет ПВЗ в вашем городе».
• Честная цена по городу. Тарифы служб различаются по регионам: куда-то дешевле везёт одна, куда-то — другая. Показывая варианты рядом, вы даёте покупателю выбрать выгодный.
• Разные форматы получения. Постамат 24/7 для тех, кто ценит скорость и анонимность; ПВЗ с примеркой и оплатой для одежды; курьер до двери для крупного; почта для глубинки.
• Устойчивость к сбоям. Если у одной службы техническая проблема или тариф вырос, вторая подстрахует, и магазин не встанет.

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

Обзор служб: Яндекс, Почта, 5Post, агрегаторы

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

Яндекс Доставка

Логистический сервис Яндекса с курьерской доставкой (в том числе день-в-день и экспресс в крупных городах), сетью пунктов выдачи и постаматов, а также маршрутизацией для собственной курьерской службы. Сильна в городах-миллионниках и в скоростных сценариях. У сервиса есть API для расчёта, создания заявок, получения точек выдачи и трекинга — на нём и строится интеграция с Битриксом.

Почта России

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

5Post

Логистический оператор экосистемы X5 с обширной сетью постаматов и пунктов выдачи, в том числе в торговых сетях. Удобна для небольших посылок и сценария «забрать по пути в магазин у дома». Работает через API: расчёт, список точек, создание отправлений, статусы.

ПВЗ-агрегаторы

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

Разумный базовый набор для большинства магазинов: одна быстрая курьерско-ПВЗ-служба (Яндекс), сеть постаматов (5Post) и Почта для охвата всего остального. Агрегатор уместен, когда нужен широкий выбор точек без десятка отдельных договоров. Дальше все они собираются в единый выбор на оформлении — к этому вернёмся в разделе про агрегацию.

Модели доставки: курьер, ПВЗ, постамат

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

• Курьер до двери. Заказ привозят на адрес покупателя. Максимально удобно, но дороже и требует, чтобы получатель был на месте в интервал доставки.
• Пункт выдачи (ПВЗ). Помещение с сотрудником: выдача по коду или штрихкоду, возможна примерка, оплата, оформление возврата. Оптимально для одежды и обуви.
• Постамат. Автоматический шкаф с ячейками без персонала: код из СМС открывает ячейку, покупатель забирает заказ сам, часто круглосуточно. Удобно для небольших посылок.
• Самовывоз со своего склада. Не служба, а собственная точка магазина. Часто самый дешёвый вариант, который стоит держать рядом с внешними службами.

В Битриксе каждая модель — это профиль доставки внутри службы со своим тарифом. Обычно включают два-три профиля на службу (например, «до ПВЗ» и «курьером»), а не все подряд, чтобы не плодить в оформлении почти одинаковые строки. Ниже разберём, где именно эти профили живут.

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

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

• Служба доставки. Настройка конкретного способа (Яндекс, Почта, 5Post, самовывоз). У каждой — свой обработчик и параметры подключения.
• Обработчик расчёта. Код, который обращается к API службы: передаёт откуда, куда, вес и габариты и получает стоимость, сроки и список точек выдачи.
• Профиль доставки. Внутри одной службы — несколько вариантов: курьер, до ПВЗ, до постамата, экспресс. Каждый со своим тарифом и правилами.
• Ограничения и зоны. Правила, при которых способ доступен: по сумме заказа, весу, региону, способу оплаты, габаритам.
• Связь с заказом. Выбранный способ, точка выдачи и рассчитанная стоимость сохраняются в свойствах заказа и уходят в 1С при обмене.

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

Что подготовить до подключения

Как обычно, основная работа — это подготовка. Чтобы доставка заработала корректно, до настройки собирают несколько вещей.

Договоры и доступы служб

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

Точка отправления и параметры магазина

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

Данные о товарах

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

Отдельно продумайте картографический сервис для карты точек выдачи (обычно Яндекс.Карты) и его ключ, если он нужен, — карта ПВЗ появится в оформлении, и её тоже стоит заложить в подготовку.

Весогабариты — основа расчёта тарифа

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

На что обратить внимание:

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

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

Подключение Яндекс Доставки

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

1. Заключите договор и получите доступы. В личном кабинете сервиса возьмите ключ API (токен). Без него боевой расчёт и создание заявок не заработают.
2. Установите обработчик. В админке Битрикса в разделе «Магазин → Службы доставки» добавьте службу с обработчиком Яндекс Доставки (штатным или модулем из Маркетплейса).
3. Впишите ключ и точку отправления. Укажите токен и город/адрес склада, откуда едут заказы.
4. Выберите профили. Включите нужные варианты: курьер до двери, до пункта выдачи, до постамата, экспресс — каждый со своим тарифом.
5. Настройте выбор точки. Включите показ пунктов выдачи и постаматов на оформлении — списком или на карте по городу покупателя.
6. Проверьте расчёт. Оформите тестовые заказы в разные города и убедитесь, что стоимость, сроки и точки приходят корректно.

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

Почта России: индексы и тарифные зоны

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

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

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

5Post: постаматы и пункты выдачи

5Post — логистический оператор с большой сетью постаматов и пунктов выдачи, в том числе в торговых сетях у дома. Для покупателя это сценарий «забрать по пути в магазин», для магазина — недорогая доставка небольших посылок. Логика подключения та же, что и у других служб.

1. Получите доступы 5Post. В личном кабинете возьмите ключ/токен интеграции для API.
2. Создайте службу доставки с обработчиком 5Post в разделе служб доставки.
3. Впишите ключ и точку отправления, от которой считается тариф и передаются отправления.
4. Включите профили: доставка до постамата и до пункта выдачи — то, что реально нужно вашим покупателям.
5. Настройте выбор точки на оформлении: список или карта постаматов и ПВЗ по городу покупателя.
6. Учтите габариты ячеек. Проверьте, что крупные заказы не предлагаются в постамат, куда не влезут, — здесь снова важны габариты товара.

Зачем 5Post рядом с Яндексом? Разная сеть точек и разные тарифы: у постаматов 5Post своя география, часто в шаговой доступности там, где у другой службы пусто. Дав обе службы, вы повышаете шанс, что рядом с покупателем найдётся удобная точка. Главное — не превратить выбор в кашу: два-три понятных варианта лучше десятка почти одинаковых.

Агрегаторы и единый выбор из служб

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

Есть два пути такой агрегации.

• Несколько прямых интеграций. Каждая служба — отдельная служба доставки в Битриксе со своим договором и API. Их варианты складываются в общий список на оформлении. Плюс — прямые тарифы и договоры; минус — несколько интеграций и кабинетов.
• Агрегатор доставки. Один договор и один API дают доступ сразу к нескольким службам и их точкам. Плюс — быстрый старт и широкий выбор точек; минус — посредник в цепочке и его комиссия.

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

Расчёт стоимости и сроков по API

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

1. Битрикс собирает параметры. Точка отправления (склад), точка назначения (город/индекс покупателя), суммарный вес и габариты корзины, стоимость заказа (для страховки и наложенного платежа).
2. Обработчик обращается к API службы. Он передаёт эти параметры и профиль (курьер, ПВЗ, постамат) и ждёт ответ.
3. Служба возвращает расчёт. Стоимость доставки, ориентировочный срок, а для самовывоза — список доступных точек выдачи в этом городе.
4. Битрикс показывает результат. Вариант появляется в списке способов доставки с ценой и сроком; для ПВЗ рядом — кнопка выбора точки на карте.
5. Выбор фиксируется в заказе. Итоговая стоимость и параметры (служба, профиль, точка) сохраняются в свойствах заказа.

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

Выбор ПВЗ и постамата на карте

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

Как это работает:

1. Покупатель выбирает способ «до пункта выдачи» или «до постамата» и указывает город.
2. Обработчик службы возвращает список точек в этом городе с адресами, режимом работы и координатами.
3. Точки показываются на карте (метки) и списком; типы помечены — «постамат» или «пункт выдачи».
4. Покупатель кликает удобную точку, читает адрес и часы работы и подтверждает выбор.
5. Выбранная точка сохраняется в заказе, и по ней рассчитывается итоговая стоимость доставки.

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

Обработчики доставки: как они работают

Под каждой службой в Битриксе стоит обработчик доставки — программный компонент, который знает, как разговаривать с API конкретной службы. Понимать его устройство полезно, чтобы выбирать между готовым модулем и доработкой.

Обработчик отвечает за несколько задач:

• Расчёт. Принимает параметры заказа и возвращает стоимость и срок, обращаясь к API службы.
• Список точек. Отдаёт пункты выдачи и постаматы по городу для карты в оформлении.
• Создание отправления. Передаёт заказ в службу, получает трек-номер и данные для этикетки.
• Статусы. Запрашивает и обновляет статус доставки для трекинга на сайте.

Откуда берётся обработчик? Три варианта. Штатный — часть платформы или типового решения (для ряда служб есть из коробки). Модуль из Маркетплейса 1С-Битрикс — устанавливается и настраивается через админку, обычно поддерживается разработчиком модуля. Собственный обработчик — пишется под нестандартную службу или особую логику через REST-подсистему доставки. Для Яндекса, Почты и 5Post чаще всего берут готовые модули, а дорабатывают уже витрину выбора, карту и трекинг под конкретный магазин. Такую доработку мы обычно делаем в рамках разработки магазина с интеграцией служб доставки.

Трекинг, статусы и путь посылки

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

Путь типового отправления: заказ оформлен → передан в службу (присвоен трек-номер) → принят на складе службы → в пути → прибыл в пункт выдачи/постамат → вручён покупателю. На каждом этапе служба меняет статус, и его можно показывать на сайте.

• Трек-номер в заказе. Минимум: служба присваивает заказу трек-номер, он сохраняется в заказе и показывается покупателю со ссылкой на отслеживание у службы.
• Статусы на сайте. Продвинутее: статус подтягивается автоматически по API и показывается в личном кабинете — «в пути», «прибыл в пункт выдачи», «вручён».
• Уведомления. Покупатель получает письмо или сообщение при смене статуса — например, «заказ в постамате, код 4821, заберите за N дней».

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

Печать этикеток и наклеек

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

Как это обычно устроено:

• Создание отправления. По кнопке в заказе обработчик передаёт данные в службу через API и получает трек-номер и файл этикетки (обычно PDF).
• Печать. Этикетка печатается на обычном или термопринтере наклеек и клеится на упаковку. Формат подстраивается под размер наклейки службы.
• Пакетная обработка. Для потока заказов удобно формировать этикетки и реестр отправлений пачкой, а не по одному — это стандартный сценарий для склада.
• Реестр приёма-передачи. Многие службы требуют реестр (акт) на партию отправлений — его тоже формируют из админки при передаче заказов курьеру службы.

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

Наложенный платёж и связь с оплатой

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

Типичные связки:

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

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

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

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

• Бесплатная доставка от суммы. Классический приём поднять средний чек: «бесплатно при заказе от N ₽». Настраивается ограничением по сумме. Порог считают так, чтобы доставка не съедала маржу.
• Ограничения по весу и габаритам. Постаматы не примут крупный заказ — такой способ для него скрывают. Тяжёлые заказы уводят на курьера или транспортную компанию.
• Зоны доставки. Для своего города часто делают собственную курьерскую доставку с понятным тарифом, а для остальной страны — службы. Зоны разделяют эти сценарии.
• Честные сроки. Показывайте реальные сроки от службы, а не «1–2 дня по всей России». Завышенные ожидания бьют по доверию сильнее честного долгого срока.
• Ограничение по региону. Если в каких-то регионах вы не возите, способ там просто не показывают, а не оставляют «мёртвым» вариантом.

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

Интеграция со складом и наличием

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

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

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

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

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

• Разные города. Оформите заказы в близкий и дальний город — стоимость и сроки должны различаться и быть правдоподобными.
• Разный вес и габариты. Лёгкий и тяжёлый/объёмный заказ — проверьте, что объёмный вес учитывается, а крупный не предлагается в постамат.
• Все службы и способы. Яндекс, Почта, 5Post, самовывоз — каждый считается и показывается в едином списке корректно.
• Выбор точки на карте. Карта ПВЗ и постаматов открывается, точка выбирается и сохраняется в заказе.
• Город без ПВЗ. Проверьте населённый пункт, где у службы нет точек, — интерфейс должен корректно это отработать и предложить альтернативу.
• Наложенный платёж. Для служб и точек, где он доступен, оплата при получении предлагается; где нет — скрыта.
• Ошибка API. Смоделируйте недоступность одной службы — остальные варианты должны остаться, а шаг доставки не «падать».
• Заказ в 1С. Выбранные служба, точка и стоимость корректно уходят в учётную систему при обмене.

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

Частые ошибки при настройке

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

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

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

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

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

Вывод

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

Главное помнить: всё начинается с веса и габаритов товаров — без них расчёт не работает и постамат не отсечь по размеру, поэтому эти данные лучше вести в 1С и получать при обмене. Подключайте две-три понятные службы, показывайте точки выдачи на карте, связывайте доставку с оплатой и наличием, настраивайте трекинг и печать этикеток и обязательно тестируйте крайние случаи — города без ПВЗ и сбои API. Тогда оформление заказа перестанет терять покупателей на шаге доставки и начнёт работать на продажи. Смежные темы разбираем в статьях про расчёт доставки СДЭК и Boxberry и в рубрике «Оплата и доставка».