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