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

В момент пропадания связи курьер видел активную доставку. Он передал заказ и нажал «Вручено». Пока телефон был вне сети, диспетчер отменил доставку. После подключения приложение отправило старую команду. Если сервер просто принимает последнее пришедшее изменение, отмена исчезает, а история перестаёт объяснять, что произошло.

Состояние экрана устаревает, факт действия остаётся

Офлайн-режим не означает, что телефон становится главным источником состояния заказа. Он хранит последнее известное представление и очередь действий пользователя. Для каждой команды полезны собственный идентификатор, объект, ожидаемая базовая версия, время на устройстве и необходимые доказательства выполнения. Часы телефона нельзя считать безусловно точными.

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

Таблица решений для конкретного процесса

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

Что должен видеть курьер

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

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

Четыре испытания, которых нет в обычном онлайн-демо

1. Создать действие без сети, закрыть приложение, открыть снова и восстановить соединение. Команда должна сохраниться и выполниться не более одного раза в бизнес-смысле.
2. Изменить заказ на сервере до синхронизации. Приложение должно показать предусмотренный конфликт.
3. Оборвать соединение после приёма команды сервером, но до ответа телефону. Повтор должен вернуть прежний результат.
4. Изменить часы устройства. Порядок значимых серверных изменений не должен зависеть только от этих часов.

Физическое вручение и финансовый итог проверяют раздельно. Конфликтный статус не должен автоматически запускать повторное списание или возврат. Для связанных денежных операций нужен отдельный согласованный процесс сверки.

Очередь телефона не должна исчезать при неизвестном исходе

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

Интерактивная карточка решения

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

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