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