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