Практический гид
Offline-first SFA позволяет выполнить согласованный полевой сценарий при нестабильной связи, сохранить данные визита на устройстве и синхронизировать их после восстановления соединения. Надёжность зависит от заранее заданного состава локальных данных и правил разрешения конфликтов.
Три этапа: подготовить данные, сохранить разрешённые действия и получить итог обмена. Используйте схему, чтобы согласовать доступные действия и правила обмена для вашего проекта.
Перед выходом устройство получает данные, разрешённые роли, территории и версии правил для ближайшего рабочего сценария.
Сотрудник выполняет согласованные шаги визита, а каждое событие получает устойчивый идентификатор, время и связь с торговой точкой.
Проверьте итог каждой записи и её вложений. Возврат сети ещё не означает завершённую отправку: на пилоте проверяют и фоновую работу устройства.
Для руководителя полевой команды офлайн-сценарий решает конкретную задачу: сотрудник продолжает разрешённые действия визита при слабой связи, а руководитель различает локальные записи и принятые системой операции. Доступ к справочнику без интернета ещё не означает, что без связи можно создать заказ, зарегистрировать оплату или оформить возврат.
До маршрута нужно загрузить рабочий набор и проверить его актуальность: торговые точки, товары, цены, задачи и ограничения по роли. Пустой или устаревший набор нельзя считать готовым к работе. Для критичных данных заранее определяют срок допустимой давности и действие при его превышении: предупредить, ограничить операцию или запросить обновление.
Схема показывает путь одной операции. Сверяйте её идентификатор и подтверждение, а не только значок сети. Резерв, отгрузка и обмен с учётной системой проверяются отдельно.
Операция получает локальный ID, время, пользователя и контекст торговой точки.
Первичный факт сохранёнФото должно остаться связано со своим визитом. Порядок передачи и сохранность этой связи проверяют после перезапуска.
Порядок известенПовтор той же операции использует прежний идентификатор. Это помогает серверу отличить повтор от нового документа.
Повтор контролируетсяСервер сверяет версии, права, дубли и актуальные бизнес-правила.
Решение объяснимоУстройство получает итог: принято, отклонено или требуется действие ответственного.
Статус видимСохранено на телефоне, отправлено и принято сервером - разные состояния. Если после отправки ответ не пришёл, результат неизвестен: сервер мог уже принять операцию. Для повторной отправки той же операции сохраняют её идентификатор; заново оформлять документ вслепую нельзя. Если содержание изменилось, нужен отдельный согласованный порядок обработки. При разборе сверяют идентификатор, содержание и последний подтверждённый результат, а не только значок сети.
Сетевая ошибка, изменение цены и неполное вложение требуют разных действий. Ниже - ситуации для проверки и ответственные за следующий шаг.
Конфликт бизнес-правил не исправляется повторной отправкой: после визита могла измениться цена или доступность клиента для заказа. Нужны видимая причина и ответственный за решение. Итог проверяют по каждой записи и её связям. Например, визит принят, а обязательное фото ещё не доставлено: повторяют передачу вложения с привязкой к этому визиту, не создавая визит заново. Ошибка вложения сама по себе не подтверждает отмену визита. Итог записи и допустимый порядок дозагрузки проверяют по правилам проекта; обмен пока неполный. Принятый заказ также не означает резерв, отгрузку или отражение в учётной системе.
По каждой роли зафиксировано, что можно создать, изменить и только прочитать локально.
Время обновления и допустимая давность критичных данных видимы. Заранее определено, что делать с устаревшим набором.
Согласовано, как отличать повтор той же операции от нового или изменённого документа.
До переустановки, передачи устройства или смены аккаунта определён порядок обработки очереди. При потере устройства нельзя полагаться на локальную копию.
Ожидающие и отклонённые операции доступны пользователю и владельцу разбора до закрытия.
Проверьте на согласованных устройствах сохранение записи, отправку в фоне, потерянный ответ и неполный обмен. Поддержку сценария подтверждают результатом пилота.
Проверьте пустой и устаревший набор: сотрудник должен понимать, какие действия доступны и что нужно обновить.
После перезапуска проверьте очередь, затем отправку с заблокированным экраном и экономией заряда. Истёкший доступ разберите отдельно от сетевого сбоя.
Проверьте случай, когда сервер принял операцию, а устройство не получило ответ: повтор не должен создавать второй документ.
Измените правило между записью и отправкой. Проверьте причину конфликта, ответственного и согласованный порядок решения.
Сверьте подтверждённый визит и ожидающее фото. Проверьте согласованную дозагрузку: привязка сохраняется, визит не дублируется, незавершённый обмен виден.
На пилоте проверьте сохранность очереди после перезапуска, отправку при заблокированном экране и экономии заряда, а также истёкший доступ. Возвращение сети само по себе не гарантирует немедленную фоновую отправку. До переустановки приложения или передачи устройства согласуйте обработку неподтверждённых записей; отдельно проверьте, что происходит с ними при смене аккаунта. Локальная очередь не является резервной копией на случай потери устройства. Пока запись или обязательное вложение не подтверждены, обмен не завершён.
Для обсуждения Smartup SFA выберите один маршрут и операцию, которая застревает при слабой связи. Подготовьте обезличенный пример, устройство и версию приложения, ожидаемый итог и последние видимые статусы. Такой пример поможет отделить проблему данных, доступа или передачи и выбрать проверку для пилота. Не передавайте пароли и полную клиентскую базу. Доступные офлайн-действия, фоновая отправка, обмен с учётной системой и условия пилота согласуются для проекта.
Опишите маршрут, роль сотрудника и этап визита, который не удаётся завершить при слабой связи. Разделите чтение данных и создание операции.
Покажите последовательность на одном примере: запись на устройстве, отправка, ответ сервера и зависимое вложение. Для каждого шага укажите ожидаемый статус.
Укажите устройство, ОС, версию приложения и рабочий набор до маршрута. Включите в проверку перезапуск, блокировку экрана, режим экономии заряда и истёкший доступ.
Для зависшей операции подготовьте обезличенные идентификаторы, время, последние статусы и текст ошибки. Сохраните связь визита с вложением; согласуйте обработку очереди до переустановки или передачи устройства.
Назначьте владельца разбора и критерии пилота: запись сохраняется, повтор не создаёт дубль, частичный обмен виден, решение по конфликту понятно. Фактическую поддержку каждого сценария подтвердите на согласованных устройствах.
Нельзя обещать одинаковый офлайн-сценарий для любого устройства, срока отсутствия связи и набора модулей. Состав локальных данных, период актуальности и правила синхронизации согласуются для конкретного проекта.
