Интеграция сайта со СДЭК: что передавать кроме адреса

Почему оплаченный заказ ещё может ждать отправки

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

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

Расчёт не создаёт накладную. Цена на странице отвечает на вопрос о предполагаемой доставке, тогда как регистрация передаёт перевозчику сведения о конкретной посылке.

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

Пункт выдачи и доставка до двери требуют разных данных

При доставке в пункт выдачи покупатель выбирает объект СДЭК, а при курьерской доставке вводит адрес получателя. Без конкретного выбора сотруднику придётся повторно выяснять место получения. Тариф мог относиться к другому способу. Поэтому в заказе остаётся конкретный выбор покупателя вместе с данными, которые нужны перевозчику для направления посылки. Изменение города или способа получения означает, что прежний выбор требуется пересмотреть: пункт выдачи и расчёт были связаны с прежними условиями, а не с обновлённым адресом.

Для пункта выдачи нужен код. В описании регистрации заказа в API СДЭК ему соответствует поле delivery_point, по которому перевозчик определяет место получения.

Адрес доставки до двери передают через to_location. Это поле нельзя отправлять одновременно с кодом пункта выдачи: система получает один выбранный способ получения, а не два противоречащих друг другу назначения. Эти названия помогут отличить данные карты пунктов от адреса для курьера в задании интегратору.

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

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

Грузовые места появляются после упаковки

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

СДЭК принимает список грузовых мест. По документации регистрации поле packages содержит от 1 до 255 упаковок, каждая из которых относится к отдельному месту отправления.

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

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

Оплата товара и оплата перевозки идут по своим правилам

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

Тип заказа связан с договором. В API СДЭК тип 1 — «интернет-магазин» — доступен для соответствующего договора, поэтому название сайта ещё не определяет, какое значение передавать.

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

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

После приёма запроса остаются два исхода регистрации

Регистрация через API СДЭК выполняется асинхронно: сервис сначала принимает запрос, а затем обрабатывает его и возвращает результат создания. В этот промежуток магазин ещё ждёт подтверждения. Если модуль сразу показывает готовое отправление, склад может начать работу с записью, которая позднее получит отказ. Для ожидания требуется отдельное видимое состояние заказа. Оно позволяет сотруднику отличить посылку, зарегистрированную у перевозчика, от запроса, по которому ответ ещё не получен.

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

Успешное создание обозначается SUCCESSFUL. Значение INVALID сообщает об ошибке создания: сведения исправляют и повторяют регистрацию, когда причина отказа устранена.

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

Как повторить запрос после сбоя без лишнего отправления

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

Номер помогает найти исходную покупку. В документации API СДЭК поле number для заказов интернет-магазина ограничено 40 символами, поэтому интегратор заранее оценивает формат номера вашего магазина.

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

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

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

Что покрывает готовый модуль на вашей платформе

Готовое решение сокращает объём разработки, если покрывает процесс магазина. Функции оценивают для выбранной платформы и версии. Например, официальное описание сервиса СДЭК для InSales отдельно указывает, что после оформления покупки в корзине отправление автоматически не создаётся. Его регистрируют со страницы заказа или из виджета в интерфейсе магазина. При оценке такого модуля учитывают участие сотрудника после оформления покупки. Заказ магазина уже существует, но передать его перевозчику предстоит отдельным действием: этот шаг включают в работу склада.

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

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

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

Выбирать модуль по покрытию оплаты и упаковки полезнее, чем по виду карты пунктов выдачи: удобная карта поможет покупателю выбрать место, но не исправит ошибки в суммах и не сообщит складу об отказе в регистрации.

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

Опишите действия магазина между оплатой и отгрузкой

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

Доступы передают интегратору по отдельному закрытому каналу, чтобы ключи API не попали в публичные примеры, страницы сайта и общее описание работ.

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

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

Для обсуждения интеграции сайта в ШТАБ ИТ пригодятся выбранная платформа и описание этих действий. По ним легче определить необходимые работы и принять результат по тому, сможет ли магазин отправить заказ и объяснить его состояние покупателю.