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