Автоматизация
Автоматизация заказов: ТЗ на статусы, повторы и исключения
Требования к обработке заказов: владельцы данных, оплата, резерв, доставка, надёжная очередь, ручные исключения и проверки после перезапуска.
Начните с жизненного цикла заказа, а не со списка интеграций
Автоматизация обработки заказов должна отвечать на конкретный вопрос: какое обязательство перед покупателем возникло, кто выполняет следующий шаг и по каким данным можно считать его завершённым. Подключённая корзина, складская программа и уведомления ещё не образуют управляемый процесс. Если каждая система по-своему понимает статус «готов», сотрудники продолжают сверять таблицы, а покупатель получает противоречивые сообщения. Требования стоит начинать с одного сквозного сценария: от подтверждённой заявки до получения товара и обработки возможного обращения после продажи.
Опишите обычный заказ и несколько важных отклонений. Клиент меняет адрес, оплачивает повторно после неясного ответа, просит разделить доставку, отменяет одну позицию, получает замену или возвращает часть покупки. Для каждого случая нужны исходное состояние, событие, ответственный и ожидаемое изменение. Отдельно укажите действия, которые запрещены: повторное списание, второй резерв того же количества, отправка отменённого товара, автоматическое закрытие неразобранной претензии. Такой перечень превращает пожелание «всё без ручного труда» в проверяемые границы проекта.
В первой очереди полезно выбрать ограниченный поток, для которого действительно известны правила. Например, стандартные заказы с одного сайта на одном складе, без предзаказов и сложных комплектов. Это учебный пример ограничения масштаба, а не универсальная рекомендация для бизнеса. Остальные случаи должны попадать в понятную ручную обработку с причиной и ответственным. Они не должны исчезать из общей картины или получать успешный статус только потому, что автоматический маршрут пока не реализован.
Разделите сущности и договоритесь об источнике каждого факта
В модели данных различайте заказ, позиции, попытки оплаты, платежи, резервы, отгрузки, доставки и возвраты. Один заказ может включать несколько оплат и отправлений. Поэтому поле «оплачен и доставлен» не заменяет историю отдельных операций. Для каждой сущности определите устойчивый идентификатор, связь с исходным каналом, допустимые изменения и способ сопоставления с внешними системами. Номер телефона или имя покупателя сами по себе не дают надёжного основания объединить два заказа, особенно при покупках для семьи или организации.
Составьте таблицу владельцев данных. Каталог может вести учётная система, доступное к продаже количество — склад, подтверждение оплаты — платёжный провайдер, а обещанную клиенту дату — служба исполнения. Зафиксируйте, что происходит при расхождении. Обновление карточки товара не должно незаметно переписать уже согласованную цену заказа. Новый адрес из профиля не должен автоматически менять отправление, переданное перевозчику. Источник истины определяется для конкретного поля и этапа, а не назначается одной программе сразу для всех обстоятельств.
Укажите единицы измерения, валюту, точность денежных значений, часовой пояс и правила хранения времени. Сохраняйте исходный идентификатор внешнего события и время его возникновения отдельно от времени получения. Запоздавшее уведомление не должно выглядеть новым действием покупателя. Для миграции подготовьте сопоставление старых статусов с новой моделью и отдельную очередь неоднозначных записей. Отсутствующие сведения лучше сохранить как неизвестные, чем массово подставить «выполнено» и затем строить на этой догадке финансовые или складские операции.
Опишите переходы состояния и приоритет ручного решения
Для каждого перехода перечислите условия входа, выполняемые действия и признаки успешного завершения. Например, подтверждение заказа может требовать проверки доступности и согласования доставки, но не обязано означать подтверждённую оплату. Отправление считается переданным перевозчику по установленному событию, а не по нажатию кнопки печати накладной. Если работа остановилась, должно быть видно последнее подтверждённое состояние и незавершённую операцию. Общий статус нужен пользователю, но его формирование должно опираться на явные факты и сохранять частичные результаты.
Договоритесь, какие действия сотрудник может выполнять во время автоматической обработки. Изменение количества после резервирования, ручная отмена и повторная отправка требуют проверки актуальной версии заказа. Иначе фоновая задача завершится по старым данным и вернёт процесс назад. В требованиях укажите приоритет ручной остановки, срок действия блокировки и способ её снятия. Для конфликтующих изменений нужен понятный ответ сотруднику: что уже произошло, почему действие не применено и какой следующий шаг безопасен.
Особенно внимательно опишите частичное исполнение. Если две позиции отправлены, а третья задерживается, нельзя одновременно считать весь заказ доставленным и весь заказ проблемным. Состояния отдельных позиций и отправлений должны объяснять итоговую сводку. Уведомление покупателю должно соответствовать тому же расчёту, который видит сотрудник. Отдельно согласуйте исключения: замену товара, отказ от части заказа, повторную доставку и изменение получателя. Именно эти ветки чаще всего обнаруживают противоречия в слишком простой схеме статусов.
Сохраните намерение до обращения к внешнему сервису
Опасный промежуток возникает, когда заказ уже записан, а сообщение для склада ещё не отправлено, либо внешний сервис принял запрос, но приложение не успело сохранить ответ. В руководстве AWS по transactional outbox рассматривается совместное сохранение бизнес-изменения и события в одной транзакции с последующей обработкой события. Это полезная основа для требования надёжности, но не обещание отсутствия повторной доставки. Получатель всё равно должен уметь распознать повтор и безопасно обработать его без второго побочного действия.
В ТЗ зафиксируйте наблюдаемые гарантии, а выбор реализации обсудите с разработчиками. Принятый заказ не теряется после перезапуска; намерение передать его на склад сохраняется; ошибка транспорта не стирает исходные данные; восстановление продолжает ту же операцию. Для каждого действия задайте ключ повторяемости и область его уникальности. Повтор одной попытки создания отгрузки должен отличаться от законного создания второй отгрузки того же заказа. Без такого различия защита от дублей способна блокировать нормальную работу.
Документация Stripe об идемпотентных запросах показывает конкретный механизм повторов API, однако его правила нельзя автоматически переносить на другого провайдера или любой метод. Проверьте поддержку, срок хранения ключа и поведение при изменении параметров в действующем контракте каждой интеграции. Когда результат отправки неизвестен, сначала нужен способ сверки по идентификатору операции. Слепой повтор допустим не всегда. Неопределённость должна иметь собственный статус и путь разбора, а не маскироваться сообщением «всё успешно».
Проверьте оплату, склад и доставку независимо
Платёжное событие необходимо сопоставлять с ожидаемым заказом, суммой, валютой и операцией. Переход пользователя на страницу успеха не заменяет подтверждение по предусмотренному интеграцией каналу. Так же нельзя считать обещание оплатить или присланное сообщение окончательным финансовым фактом. В требованиях отделите ожидаемую оплату, подтверждённый платёж, возврат и неопределённый результат. Укажите, кто разбирает расхождения и какие действия исполнения допускаются до их разрешения. Конкретные правила согласует бизнес с владельцем финансового процесса.
Для склада опишите конкурирующие заказы на последнее доступное количество, срок резерва и его освобождение. Обновление остатков должно учитывать уже принятые обязательства и задержку обмена. Если резерв не подтвердился, заказ остаётся видимым и получает определённый маршрут: ожидание, согласование замены или отмена. Автоматически предлагать несуществующее наличие нельзя. На тестах проверьте одновременные обращения, перезапуск между шагами и поздний ответ после ручной отмены. Для распределённых складов добавьте правила выбора точки исполнения и частичного резерва.
Доставка также требует собственного контракта: создание заявки, получение номера отправления, отмена, изменения и обновление состояния. Один технически успешный запрос не всегда означает, что перевозчик фактически принял груз. Зафиксируйте, какие сведения показываются покупателю до этого момента. Порядок внешних уведомлений может отличаться от порядка фактических событий, поэтому старое сообщение не должно без проверки откатывать состояние. Неизвестный код перевозчика направляйте на разбор, сохраняя исходное значение; не переводите его автоматически в наиболее удобную категорию.
Сделайте исключения частью рабочего интерфейса
Сотруднику нужна очередь случаев, требующих решения, а не бесконечный список технических ошибок. В карточке показывайте заказ, источник проблемы, последнее подтверждённое действие, время ожидания и доступные варианты. Ошибка авторизации интеграции, отсутствие товара и спор о составе заказа требуют разных действий и разных владельцев. Установите правила назначения и эскалации, чтобы случай не оставался без ответственного после смены сотрудника. Повторное появление одной причины должно обновлять существующую проблему, а не создавать десятки одинаковых задач.
Служебный журнал должен позволять восстановить последовательность: кто или что запустило действие, какие данные были актуальны, куда отправлен запрос, какой результат подтверждён и что изменено вручную. Для связи записей используйте идентификатор заказа и операции. При этом журналы не должны превращаться в бесконтрольное хранилище адресов, токенов и полных платёжных данных. Состав полей, доступ, срок хранения и маскирование согласуйте заранее. Для поддержки важнее точная связь событий, чем максимальный объём скопированной информации.
Разделите уведомления покупателю и внутренние сигналы. Повторная обработка события не должна повторно отправлять одинаковое письмо. Исправление внутреннего поля не всегда требует сообщения клиенту. Перед отправкой проверяйте актуальное состояние: если заказ уже отменён, запоздалое поздравление с подтверждением недопустимо. Для каналов с ограничениями задайте частоту, согласованный текст и поведение при недоступности. Ручное обращение сотрудника и автоматическое уведомление должны использовать общую историю, чтобы человек понимал, что уже сообщил сервис.
Принимайте систему на сбоях и восстановлении
Подготовьте изолированный набор сценариев с вымышленными покупателями и тестовыми товарами. В него включите обычную покупку, повтор запроса, два параллельных заказа, частичную оплату по принятой модели, разделённую доставку, отмену до и после резерва, частичный возврат и потерю ответа внешнего сервиса. Для каждой проверки заранее запишите ожидаемые изменения во всех связанных системах и запрещённые последствия. Проверка «экран открылся» не подтверждает сохранность заказа, правильность резерва или отсутствие повторной отправки.
Отдельно остановите обработчик между сохранением задания и внешним запросом, затем между запросом и фиксацией ответа. После восстановления проверьте очередь, статусы и журнал. Не используйте для этого реальные заказы и работающий производственный склад. Если у провайдера нет полноценной тестовой среды, зафиксируйте границы стенда и непроверенные свойства, а производственную проверку оформите отдельно с согласованным малым объёмом. Успешный ответ имитатора подтверждает логику приложения, но не реальную доставку, списание или выполнение сторонней системой.
Нагрузочные требования связывайте с профилем работы: количество заказов за интервал, всплески, число позиций, частота обновлений и допустимое время до подтверждения. Измеряйте не только скорость ответа интерфейса, но и задержку исполнения сохранённого задания. Быстрое «принято» полезно лишь тогда, когда очередь управляется и её отставание наблюдаемо. В отчёте сохраняйте условия, версию, фактические результаты и ограничения. Старый успешный прогон не заменяет проверку после изменения схемы обмена или правил резервирования.
Зафиксируйте запуск, показатели и ответственность после него
План запуска должен описывать границу старого и нового процесса. Какие заказы продолжают жить по прежним правилам, какие попадают в новую очередь, как исключается двойная обработка и кто сверяет итог? До переключения подготовьте резервные данные и порядок восстановления. Возврат старой версии приложения сам по себе не отменяет уже созданные платежи, резервы или отправления. Для таких действий нужны отдельные процедуры сверки и, где это допустимо, компенсирующие операции с ответственным владельцем.
В рабочей сводке разделяйте созданные заказы, принятые к обработке задания, выполненные операции, ожидающие попытки, неопределённые результаты и отмены. Эти показатели отвечают на разные вопросы и не должны называться одним словом «обработано». Для ошибок показывайте долю и возраст относительно понятного общего количества. Для ручного труда отслеживайте причины обращений, а не только число кликов. Сравнение до и после автоматизации требует сопоставимого периода и состава заказов; иначе сезонность или смена ассортимента исказят вывод.
Итоговое ТЗ включает модель данных, таблицу переходов, контракты интеграций, правила повторов, интерфейс исключений, сценарии приёмки и план запуска. Приложите контакты владельцев, доступы к документации и список открытых решений. В скачиваемом брифе ниже можно зафиксировать эти договорённости до оценки разработки. Полезный результат подготовки — не обещание полностью убрать человека, а ясный ответ, что система выполняет сама, где останавливается и как сотрудник безопасно продолжает работу без потери истории.
Источники
- Transactional outbox pattern
AWS Prescriptive Guidance / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Idempotent requests
Stripe Documentation / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Можно ли использовать один статус для оплаты и доставки?
Для достоверной обработки их нужно разделить. Заказ может быть оплачен частично, отправлен несколькими посылками или находиться в возврате; одна метка скрывает эти различия.
Устраняет ли очередь все дубли автоматически?
Нет. Надёжная очередь сохраняет задания, но повторная доставка возможна. Нужны идентификаторы операций, проверка повторов и правила сверки неизвестного результата у получателя.
Что значит быстро принять заказ в обработку?
Сохранить его и необходимые задания надёжно, вернуть понятное подтверждение и затем отслеживать фактическое исполнение. Созданное задание нельзя учитывать как завершённую оплату, отгрузку или доставку.
