How to configure a delivery workflowКак настроить процесс доставки
Begin delivery configuration with a traceable order history. Describe the facts known at acceptance, who confirms readiness, how the operator is assigned and which outcome closes fulfillment. Then map the procedure to the available SABSUS configuration and external services. The goal is for the same event to have the same meaning for packing, dispatch, couriers and support.Настройку доставки удобно начинать с одной прослеживаемой истории заказа. Опишите, какие факты известны при приёме, кто подтверждает готовность, как назначается исполнитель и какой результат завершает работу. Затем сопоставьте этот порядок с доступной конфигурацией SABSUS и внешними сервисами. Цель настройки — чтобы одинаковое событие означало одно и то же для склада, диспетчера, курьера и поддержки.
Define transitions and entry conditionsОпишите переходы и условия допуска
For every transition, record the entry state, required data, responsible role and confirming event. Readiness needs a checked package; assignment needs an eligible operator; receipt needs evidence of physical handover under the agreed procedure. Identify changes that block the next step and who may clear the hold.Для каждого перехода запишите входное состояние, обязательные данные, роль исполнителя и подтверждающий факт. Готовность требует проверенного комплекта; назначение требует подходящего исполнителя; получение требует свидетельства фактической передачи по принятому порядку. Установите, какие изменения блокируют следующий шаг и кто снимает блокировку.
Describe how an incorrect status is corrected separately. Moving from ready back to preparation should explain what changed and who received the previous information. If the interface does not support the required transition, agree a verifiable operating procedure rather than assuming the behavior will appear automatically.Отдельно опишите исправление ошибочного статуса. Возврат из «готов» в подготовку должен объяснять, что изменилось и кто уже получил старую информацию. Если интерфейс не поддерживает нужный переход, согласуйте проверяемый рабочий порядок вместо предположения, что он появится автоматически.
Name the source of every factУстановите источник каждого факта
Map order identifier, address version, window, contents, operator, external reference and delivery outcome. Name a source and correction owner for each field. Payment status must not substitute for handover status, and an external shipment number must not become an unrelated new order.Составьте карту данных: идентификатор заказа, версия адреса, окно, состав, исполнитель, внешняя ссылка и результат доставки. Укажите источник и владельца исправления каждого поля. Платёжный статус не должен заменять статус передачи, а внешний номер отправления не должен становиться новым несвязанным заказом.
When connecting a provider, verify the available integration, update direction and status mapping. A provider’s completed state may mean an attempt was closed rather than goods received. Map event meaning rather than matching similar labels.При подключении службы доставки проверьте доступный обмен, направление обновлений и соответствие статусов. Значение «завершено» у провайдера может означать закрытие попытки, а не получение товара. Сопоставляйте смысл события, а не только похожие названия.
Check permissions for routine and disputed actionsПроверьте права на обычные и спорные действия
Packing confirms the package, dispatch manages assignment, the courier reports execution and support agrees changes with the customer. Adapt this example of role separation to the actual team. For each action, verify viewing and editing permissions and access to only the necessary data.Склад подтверждает комплект, диспетчер управляет назначением, курьер сообщает исполнение, поддержка согласует изменение с клиентом. Это пример разделения ответственности, который нужно адаптировать к команде. Для каждого действия проверьте право просмотра и изменения, а также доступ только к нужным данным.
Check reassignment, address changes after release and return decisions separately. Define who accepts responsibility at shift change. A shared account obscures the author of a correction; use the available process that allows the team to establish who changed something and why.Отдельно проверьте замену исполнителя, изменение адреса после выдачи и решение о возврате. Укажите, кто принимает переданную ответственность при смене. Общая учётная запись скрывает автора исправления; используйте доступный порядок, позволяющий восстановить, кто и почему внёс изменение.
Handle repeated and delayed eventsРазберите повторные и запоздавшие события
An external update can arrive twice, arrive late or follow a manual decision. Before enabling exchange, define event precedence and how conflicts are reviewed. A repeated status should not create a new shipment or repeat a customer promise. If the service cannot distinguish versions, disputed cases need a visible review process.Внешнее обновление может прийти повторно, поздно или после ручного решения. До включения обмена определите, какое событие имеет приоритет и куда попадёт конфликт. Повторный статус не должен создавать новую отправку или повторное обещание клиенту. Если используемый сервис не различает версии, нужна видимая проверка спорных случаев.
For messages, specify a confirmed trigger, recipient, language and owner for failed delivery or customer replies. Check sending rules and channel availability. Enable automation only after those conditions are verified; a recorded order status alone does not establish that a message was sent.Для сообщений задайте подтверждённый повод, получателя, язык и ответственного за недоставку или ответ клиента. Проверяйте правила отправки и доступность канала. Автоматизацию подключайте только после прохождения этих условий; наличие статуса само по себе не подтверждает отправку сообщения.
- Exchange failure: retain the order, known fact, last-check time and owner.Сбой обмена: сохраняются заказ, известный факт, время последней проверки и ответственный.
- A repeated event does not overwrite a verified outcome without conflict review.Повторное событие не меняет уже проверенный результат без разбора конфликта.
Accept the workflow by observable outcomesПринимайте процесс по наблюдаемым исходам
Prepare scenarios for normal fulfillment, rejected assignment, address change after departure and partial return. For each, define expected permissions, states, messages and remaining work in advance. The reviewer should demonstrate the outcome against the original order rather than only a successful intermediate screen.Подготовьте сценарии обычного исполнения, отказа назначения, изменения адреса после выезда и возврата части заказа. В каждом заранее запишите ожидаемые права, состояния, сообщения и остаток работы. Исполнитель проверки должен показать результат по исходному заказу, а не только удачный экран промежуточного шага.
Document configuration limitations and assign owners to unresolved issues. Before operational use, verify how the team continues when an external status is delayed. If a suitable continuation is undefined, that scenario remains unready even when a routine delivery works correctly.Зафиксируйте выявленные ограничения конфигурации и назначьте владельцев незакрытых вопросов. Перед рабочим использованием проверьте, как команда продолжит исполнение при задержке внешнего статуса. Если безопасное продолжение не определено, соответствующий сценарий ещё не готов, даже когда обычная доставка проходит без ошибок.
Discuss workflow verification during implementationОбсудить проверку процесса при внедрении
Quick answersКороткие ответы
Must every provider be connected immediately?Нужно ли сразу подключать все внешние службы?
No. First verify the full order journey and exceptions for the selected fulfillment method. Additional providers need their own data and status checks.Нет. Сначала проверьте полный путь заказа для выбранного способа исполнения и его исключений. Дополнительные службы требуют отдельной проверки данных и статусов.
How can a repeated status be checked?Как проверить повторный статус?
Repeat an event in an agreed verification scenario and confirm that it creates neither another shipment nor an unnecessary message. The result depends on the available integration.Повторите одно событие в согласованном проверочном сценарии и убедитесь, что не создаются второе отправление и лишнее сообщение. Результат зависит от доступной интеграции.
When is configuration complete?Когда можно считать настройку завершённой?
When routine and agreed exception scenarios have verified outcomes, permissions are checked, and the team knows remaining limitations and their owners.Когда обычные и согласованные проблемные сценарии имеют проверенный исход, права подтверждены, а оставшиеся ограничения и владельцы известны команде.