Работа завершена offline: когда результат действительно получен офисом

Определите состав результата конкретного выезда

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

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

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

Проверьте готовность устройства до потери связи

Автономная работа начинается с нужных данных на устройстве. Проверьте доступность назначенного задания, объекта, допустимых действий, справочников и используемой формы. Наличие приложения и открывающийся список вчерашних работ не доказывают, что сегодняшнее задание доступно без сети.

В Microsoft Field Service администратор настраивает offline profile, определяющий загружаемые данные. Первоначальная синхронизация занимает время. При этом текущая документация прямо указывает: new mobile experience не поддерживает работу offline. Возможности одного мобильного режима нельзя переносить на другой. Microsoft: работа offline.

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

Разведите четыре состояния

Первое состояние — работа физически выполнена по заявлению исполнителя. Второе — результат сохранён локально на устройстве. Третье — требуемые данные получены центральной системой. Четвёртое — ответственная роль проверила их и приняла бизнес-результат.

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

В Power Apps отдельно отображаются состояние сети, синхронизация, изменения, ожидающие загрузки, и ошибки. Документация также предупреждает: число pending changes относится к отдельным обновлениям строк, файлов и изображений, а не к числу уникальных изменённых объектов. По нему нельзя прямо посчитать незакрытые выезды. Microsoft: состояние синхронизации.

Для управления работой нужен список заданий с недостающими компонентами. Технический счётчик помогает диагностике, но не заменяет этот список. Если система не предоставляет нужного подтверждения, согласуйте доступный способ проверки, не придумывая точность отчёта.

Учебный пример: четыре выезда и двадцать компонентов

Вымышленная команда завершила четыре выезда A–D. Для каждого учебная процедура требует пять компонентов: итоговый статус, запись времени, одну строку использованного материала и две фотографии. Все двадцать сохранены локально. Пример предполагает, что каждый выезд действительно использовал материал и требует этих фотографий.

На контрольный момент центральный получатель подтверждает следующее:

• A: все пять компонентов получены;
• B: статус, время и материал получены, две фотографии ожидают передачи;
• C: четыре компонента получены, строка материала отклонена;
• D: все пять компонентов ожидают передачи.

Баланс: 20 = 12 полученных + 7 ожидающих + 1 отклонённый. Передано 12 / 20 = 60% требуемых компонентов. Но полный пакет имеется только у A: 1 / 4 = 25% выездов. Даже A ещё должен пройти принятую проверку результата, если она предусмотрена.

Когда две фотографии B поступили и доступны получателю, получено 14 / 20 = 70% компонентов. Полных пакетов теперь два из четырёх, или 50%. После исправления и подтверждённого приёма строки C получено 15 / 20 = 75%, полных пакетов три из четырёх, также 75%.

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

Разбирайте ожидание и отказ по-разному

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

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

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

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

Не принимайте фоновые ожидания за гарантию

После появления сети сотрудник должен иметь понятный способ проверить ход передачи. Microsoft описывает надёжную синхронизацию при открытом приложении на переднем плане и разблокированном экране; возможность фоновой работы Windows рассматривается отдельно. Это не обещание одинаковой доставки при любых настройках телефона. Microsoft: фоновая синхронизация.

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

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

Минимальные данные для сверки

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

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

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

Приёмочный чек-лист

1. Подготовленное задание реально доступно после отключения сети.
2. Локально сохранённое выполнение не выдаётся за центральную приёмку.
3. Статус и две фотографии можно проверить раздельно.
4. Сценарий A–D воспроизводит баланс 12 + 7 + 1 = 20 и один полный пакет.
5. Ошибка материала остаётся видимой после успешной передачи фотографий.
6. Технические обновления не считаются количеством выездов.
7. Перезапуск и возвращение сети не теряют перечень ожидающих компонентов.
8. Непереданные данные не удаляются ради попытки восстановления.

Для SABSUS обсудите связь заказов, документов и задач. Автономное сохранение, обработку вложений и подтверждения приёмки необходимо проверить отдельно.

Частые вопросы

Мастер нажал «готово». Выезд уже принят?

Только если выполнены условия вашего процесса. Локальное сохранение, получение пакета и содержательная приёмка имеют разные подтверждения.

Почему двадцать ожидающих обновлений не означают двадцать работ?

Одна работа может менять несколько строк и файлов, иногда неоднократно. Смысл счётчика определяется документацией конкретного приложения.

Можно повторить физическое действие, если его не видно офису?

Сначала выясните фактический результат и состояние передачи. Отсутствующая запись не доказывает, что работа не была выполнена.

Источники

• Microsoft: Work offline.
• Microsoft: View offline sync status.
• Microsoft: Sync data offline in the background.

Проверено 9 октября 2026 года. Состав пакета и четыре выезда являются учебным примером.