Подключение СДЭК (сравнение по системам)

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

Три способа подключить СДЭК

На практике интеграция СДЭК с 1С-Битрикс сводится к трём сценариям. Каждый решает свой набор задач и по-разному нагружает поддержку.

В основе любого варианта лежит штатный модуль sale и сущность «Служба доставки» (Bitrix\Sale\Delivery). Модуль СДЭК регистрируется как обработчик доставки и добавляет свои профили: склад-склад, склад-дверь, дверь-дверь и обратные комбинации.

Как устроен API СДЭК 2.0

Современная интеграция строится на СДЭК API 2.0. Доступ выдаётся в личном кабинете: вы получаете пару account и secure_password, по которым запрашивается OAuth-токен на эндпоинте /v2/oauth/token. Токен живёт около часа, поэтому его нужно кэшировать и обновлять по истечении.

• Расчёт тарифа — /v2/calculator/tariff и /calculator/tarifflist: передаёте код тарифа, габариты, вес и коды городов.
• Создание заказа — /v2/orders: формирует отправление и возвращает UUID и трек-номер.
• Пункты выдачи — /v2/deliverypoints: список ПВЗ и постаматов с координатами.
• Вебхуки — регистрируются на /v2/webhooks и присылают смену статусов на ваш URL.

Расчёт стоимости и сроков в корзине

Ключевой момент — корректный расчёт в момент оформления. СДЭК считает тариф по кодам городов (не по названиям), поэтому нужно надёжно определить город получателя. Используйте виджет ПВЗ, который возвращает city_code, либо справочник населённых пунктов СДЭК.

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

1. Определяем город и код ПВЗ получателя.
2. Собираем корзину: суммарный вес и габариты мест.
3. Дёргаем калькулятор по выбранным тарифам.
4. Показываем варианты: до двери и до ПВЗ, с разными сроками.

Виджет ПВЗ и постаматов

Выбор пункта выдачи на карте — то, ради чего покупатели любят СДЭК. У службы есть готовый JS-виджет карты, который встраивается в шаг доставки. Он отдаёт выбранный ПВЗ: код, адрес, режим работы, признак приёма наличных и примерки.

Технически это выглядит так: виджет пишет выбранный пункт в скрытое поле формы, а при отправке заказа код ПВЗ сохраняется в свойство заказа (например, CDEK_PVZ_CODE). При создании накладной этот код уходит в поле delivery_point запроса на /v2/orders.

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

Накладные, статусы и связка с CRM

После оплаты заказ нужно передать в СДЭК как отправление. При прямой интеграции менеджер жмёт кнопку в карточке заказа, а обработчик отправляет POST на /v2/orders и сохраняет вернувшийся трек-номер в заказ. Печать наклейки идёт запросом на /v2/print/orders, который отдаёт PDF.

Статусы доставки лучше принимать вебхуками, а не опросом: СДЭК шлёт события «принят», «в пути», «прибыл в ПВЗ», «вручён». Обработчик вебхука меняет статус заказа в Битриксе и, при необходимости, шлёт уведомление клиенту.

Подводные камни

За годы внедрений накопился список мест, где интеграция СДЭК чаще всего ломается.

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

Итог

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

Мы в B2Bsite подключаем СДЭК под конкретный процесс магазина: настраиваем расчёт по реальным габаритам, встраиваем виджет ПВЗ, автоматизируем накладные и трек-номера, связываем доставку с 1С и CRM. Если СДЭК — не единственная служба, собираем расчёт всех перевозчиков в едином окне чекаута.