Офлайн в мобильном приложении 1С: что работает, а что миф

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

Почему офлайн в приложениях с 1С обрастает завышенными обещаниями

В презентациях подрядчиков офлайн-режим часто выглядит как переключатель: выключил интернет — приложение работает точно так же, как в сети. На практике так не бывает ни у одного решения, интегрированного с 1С, потому что часть логики физически не может выполниться на телефоне. Проведение документа проверяет остатки на складе, действующие цены и скидки по договору, права пользователя по RLS — все эти данные хранятся в базе 1С и меняются другими сотрудниками в реальном времени. Локальная копия базы на устройстве всегда немного отстаёт от истины.

Характерный пример из практики внедрений: подрядчик обещает «полностью автономную работу с 1С», а при приёмке выясняется, что после подключения к сети каждую офлайн-заявку всё равно нужно вручную сверять, потому что нет гарантии, что она проведётся без ошибок — остаток мог измениться, пока сотрудник был вне сети. Заказчик получает не автономность, а отложенную ручную проверку, о которой в презентации не было ни слова. Похожая история — с push-уведомлениями о статусе заявки: в офлайне устройство физически не может получить уведомление о том, что документ провёлся с ошибкой, поэтому пользователь узнаёт об этом только после следующего выхода в сеть, а не мгновенно, как иногда обещают в рекламных материалах.

Честная формулировка того, что работает офлайн: просмотр справочников, цен и остатков на момент последней синхронизации, создание черновиков документов и заявок, сбор данных (фото, штрихкоды, подписи), которые уйдут в 1С при появлении сети. Формулировка того, что маркетинг выдаёт за офлайн, но им не является: гарантированно бесконфликтная работа нескольких сотрудников с одними и теми же остатками без сети, мгновенное списание товара «в офлайне» без риска уйти в минус.

Как на самом деле работает офлайн-синхронизация с 1С

Рабочая схема строится на четырёх компонентах:

• ✓локальная база на устройстве (SQLite или аналог) — хранит копию нужных справочников и документов;
• ✓очередь операций — журнал действий пользователя, ещё не подтверждённых сервером;
• ✓обменный слой в 1С — HTTP-сервисы или OData, принимающие пакеты изменений и отдающие дельты;
• ✓регламентное задание в 1С — фоновая обработка очереди и контроль зависших пакетов.

Приложение читает и пишет в локальную базу мгновенно, независимо от сети. Каждое действие пользователя — не прямая запись в 1С, а событие в очереди: «создать документ», «изменить количество», «отметить точку выполненной». Когда связь появляется, очередь синхронизируется с 1С пачками, а не одним большим дампом — это быстрее и меньше нагружает канал на объектах со слабым Wi-Fi или мобильным интернетом на складе.

Что 1С отдаёт «из коробки», а что приходится дорабатывать

Из коробки 1С даёт OData и HTTP-сервисы для базовых операций с объектами, но под мобильный сценарий их почти всегда нужно дорабатывать: делать легковесные методы для дельта-выгрузки (только изменения с такой-то даты), пакетную загрузку операций из очереди с проверкой на дубли, отдельную обработку конфликтов. Это не переписывание конфигурации, а точечная доработка 1С — обычно несколько HTTP-сервисов и регламентное задание для очистки очереди обмена.

Важное условие — актуальная платформа. OData и часть методов веб-сервисов корректно работают только начиная с определённых релизов платформы 8.3.x, поэтому перед проектированием офлайн-режима стоит свериться с системными требованиями 1С и при необходимости сделать обновление 1С — иначе синхронизация будет упираться в ограничения старой версии, а не в логику приложения.

Что делать, если данные расходятся после синхронизации

Конфликт возникает, когда два сотрудника офлайн изменили один и тот же объект: например, кладовщик списал остаток по накладной, а параллельно менеджер изменил количество в заказе. При восстановлении связи обе версии претендуют на то, чтобы стать актуальными. Рабочее решение — не пытаться слить изменения автоматически «по-умному», а задать понятное правило: сервер 1С по умолчанию считается источником истины, локальные изменения применяются поверх него, а спорные случаи (одновременное изменение одного и того же поля) уходят в отдельную очередь для ручного разбора, а не тихо перезаписываются.

Типичные сценарии конфликтов

На практике чаще всего повторяются три ситуации: два сотрудника офлайн списывают одну и ту же позицию склада и остаток уходит в минус; документ создан офлайн, а связанный справочник (контрагент, номенклатура) за это время был изменён или удалён на сервере; заявка отправлена дважды из-за повторной попытки синхронизации после разрыва соединения. Для каждой из них нужна отдельная проверка — не общая формулировка «синхронизация не удалась», а конкретная причина, понятная пользователю.

Каждой записи в очереди синхронизации присваивается версия или метка времени, и сервер сравнивает её с текущим состоянием документа перед применением. Если версия расходится — операция помечается как конфликтная, а не проваливается молча. Именно отсутствие такой пометки чаще всего и превращается в «пропавшие» документы, на которые жалуются пользователи.

Как предотвратить потерю данных и зависания при слабом канале связи

Три меры снимают большую часть проблем ещё на этапе проектирования.

• ✓Журнал операций на диске. Локальная запись фиксируется до того, как пользователь увидит подтверждение «сохранено» — иначе закрытие приложения или разряженный телефон на складе стирают несохранённые действия.
• ✓Пакетная синхронизация с повторами. Очередь уходит на сервер мелкими партиями, с повторными попытками и нарастающей паузой между ними, а не одним запросом на весь накопленный объём — так канал не «падает» при частичной потере связи.
• ✓Шифрование локального кэша. Если приложение хранит на устройстве контакты клиентов, адреса или номера телефонов, эти данные — персональные, и их обработка подпадает под 152-ФЗ. Локальное хранилище стоит шифровать и предусматривать удалённую очистку при утере устройства — это требование закона, а не опция.

Сколько стоит офлайн-режим и когда он оправдан

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

Цена мобильного приложения с офлайн-логикой всегда индивидуальна — от неё зависит не только клиентский интерфейс, но и объём доработки на стороне 1С. Мы называем стоимость после того, как разберём, какие документы и справочники реально нужны офлайн, а какие можно оставить только для чтения — это и определяет, войдёт ли проект в базовый бюджет от 500 000 руб. или потребует более глубокой архитектуры и, соответственно, отдельного расчёта. Прежде чем закладывать в смету полный офлайн с очередью и разбором конфликтов, имеет смысл на этапе технического задания смоделировать два-три реальных сценария потери связи и проверить, как на них отреагирует именно ваша конфигурация 1С — это дешевле, чем переделывать архитектуру синхронизации, когда приложение уже в эксплуатации у сотрудников.

Что выбрать для склада, торговых представителей и выездных сотрудников

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

Для торговых представителей и выездных сотрудников, где решения принимаются на объекте у клиента без связи (визит, замер, согласование цены), офлайн-логика сложнее: нужен локальный расчёт с последующей проверкой на сервере, потому что скидки и остатки в 1С:ERP меняются чаще, чем на складе. Если внедрение 1С:ERP уже ведётся или запланировано, имеет смысл проектировать мобильное приложение и обменные сервисы в одном проекте с внедрением — так синхронизация опирается на актуальную модель данных, а не подгоняется под неё постфактум.

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

Можно ли сделать мобильное приложение с 1С, которое работает полностью без интернета?

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

Что произойдёт, если два сотрудника офлайн изменят один и тот же документ?

Система должна пометить это как конфликт, а не перезаписать данные молча. Сервер 1С считается источником истины, а спорные изменения уходят в очередь для ручной проверки ответственным сотрудником.

Нужно ли дорабатывать типовую конфигурацию 1С под офлайн-режим?

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

Безопасно ли хранить данные клиентов в офлайн-кэше на телефоне сотрудника?

Только при шифровании локального хранилища и возможности удалённой очистки при утере устройства. Контакты и адреса клиентов — персональные данные, их обработка подпадает под 152-ФЗ.

Сколько стоит разработка офлайн-режима для мобильного приложения с 1С?

Индивидуальная разработка мобильного приложения с офлайн-логикой начинается от 500 000 руб., доработка обменных сервисов в 1С тарифицируется отдельно, от 3 800 руб/час.