Разделение заказа на доставки: состав, стоимость и статусы

Как спроектировать разделение заказа на несколько доставок: количества, стоимость, частичное исполнение, изменения и проверка статусов.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

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

Когда нужно разделение заказа

Первый частый повод — разные точки исполнения. Товар может находиться в центральном складе и в региональном подразделении. Второй — разная готовность: часть можно отправить сейчас, часть поступит позднее. Третий — несовместимые условия перевозки. У каждой причины есть влияние на стоимость, ожидание и возможности изменения, поэтому одно техническое действие разделения не описывает весь процесс.

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

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

Заказ, часть исполнения и посылка

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

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

В документации Shopify о результате разделения fulfillment order отражено отдельное понятие задания исполнения и ограничения его состояния. Это пример технической модели. Конкретные API и переходы вашей платформы могут отличаться; совпадающее название операции не означает одинаковые последствия.

Что сохранить в модели

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

Оформление без неожиданной второй доставки

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

Цена и период должны иметь понятный статус. Предварительный расчёт отличается от подтверждённых условий. При изменении количества или адреса пересчитываются затронутые части, а пользователь видит разницу. Одна зелёная кнопка «продолжить» не должна скрывать, что условия ещё не определены или ответ перевозчика отсутствует.

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

Как меняется заказ после разделения

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

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

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

Учебные ситуации для приёмки

Одна строка разъехалась по складам

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

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

Часть покупки отменили

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

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

Общая скидка зависит от состава

Разделение исполнения само по себе не обязано менять согласованную скидку. Но отмена или замена товара может влиять на неё по правилам магазина. Отделите логистическую перегруппировку от изменения покупки. Иначе простая смена склада неожиданно пересчитает цену уже подтверждённого заказа.

Подготовьте покупку с общей скидкой и разделите её без изменения состава. Сравните исходный и итоговый расчёт. Затем отмените часть и проверьте предусмотренную корректировку. Все суммы должны объясняться одной методикой; независимый пересчёт в каждой части способен дать расхождение из-за округления или разного применения правил.

Перевозчик прислал статус не той части

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

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

Товар переместили в другую часть

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

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

Человек хочет дождаться полного комплекта

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

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

Самовывоз и изменение ожидания

Самовывоз сочетается с курьерской доставкой

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

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

Срок одной части уточнили после покупки

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

Платёж не должен размножаться вместе с доставками

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

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

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

Что видят покупатель и поддержка

В кабинете покажите общий заказ и ясные части: состав, способ, период, состояние и доступное действие. Не заставляйте разбираться во внутренних понятиях складской системы. Текст «доставка завершена» относится к конкретной части, если остальные ещё не получены. Общий итог должен объяснять незавершённый остаток, а не скрывать его успешной первой посылкой.

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

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

Сверка и показатели процесса

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

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

Границы первой реализации

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

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

Частые вопросы

Разделение создаёт несколько новых заказов?

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

Можно ли брать дополнительную стоимость доставки автоматически?

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

Как показать несколько трек-номеров?

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

Когда можно менять адрес отдельной части?

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

Что нужно для оценки разработки?

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

Начать со связей и количеств

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

Обсудить механику можно на странице разработки интернет-магазина. Связанные вопросы разобраны в материалах об интеграции доставки и резервировании товаров. Они дополняют распределение исходной покупки по частям.