Заказ без интернета: что должно уметь приложение, кроме сохранения корзины

Представим торгового представителя на складе клиента. Ему нужно найти товар, собрать позиции и сохранить договорённости, хотя связь нестабильна. Не все функции приложения обязаны работать офлайн. Важнее определить минимальный сценарий, который помогает закончить встречу и не потерять введённые данные.

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

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

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

Сервер принял запрос, но телефон не получил ответ. Приложение повторяет отправку — и без устойчивого идентификатора возникают два заказа. Нужно различать новую операцию и повтор доставки уже существующей. Это правило должно поддерживаться на стороне принимающей системы, а не только блокировкой кнопки на экране.

Храните состояние очереди и результат подтверждения. Если часть позиций не прошла проверку, объясните, что принято и что требует решения пользователя. Бесконечные незаметные повторы неудобны: при постоянной ошибке сотрудник должен увидеть причину и доступный следующий шаг.

Пока устройство было офлайн, товар могли продать, а условия клиента — изменить. При синхронизации система должна применить заранее выбранное правило: запросить подтверждение новой суммы, отправить заказ на согласование или обработать его иначе. Нельзя незаметно заменить согласованную с клиентом цену и считать это технической деталью.

Определите источник актуальных данных и последовательность проверки. Для связи с сайтом и 1С важно сохранить единый идентификатор заказа и понятную историю статусов. Если приложение, сайт и учётная система по-разному трактуют подтверждение, сотрудникам придётся вручную выяснять судьбу каждой спорной операции.

Для веб-приложений PWA офлайн-работа требует специально реализованных механизмов хранения и обработки запросов. Документация MDN описывает соответствующие подходы и ограничения фоновых операций. Наличие установленной иконки само по себе не означает, что заказ сохранится или отправится после закрытия приложения.

На целевых устройствах проверьте потерю связи до отправки и во время неё, повторный запуск, истечение авторизации и конфликт после синхронизации. Учитывайте ограничения браузеров и операционных систем. Результат теста должен отвечать на простой вопрос: может ли сотрудник понять состояние заказа и безопасно продолжить работу?