Приложение и 1С: что обязано работать без интернета

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

Что обязано работать в приложении 1С без интернета

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

Что кэшируется на устройстве

• ✓Номенклатура, цены и остатки по складам, доступным пользователю
• ✓Контрагенты и договоры, с которыми работает конкретный сотрудник
• ✓Ранее оформленные документы за отчётный период
• ✓Настройки прав доступа и шаблоны печатных форм

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

Почему приложение теряет связь с 1С на складе и в разъездах

Связь пропадает не по одной причине, а из-за совокупности типичных для Москвы и области сценариев. Склады в промышленных парках за МКАД часто стоят в зоне слабого покрытия сотовых операторов, а металлические стеллажи и бетонные перекрытия дополнительно глушат сигнал внутри здания. У курьеров разрыв случается в лифтах, подземных паркингах и в отдалённых районах, где 4G переходит в 3G или пропадает совсем. Розничные точки в подвальных помещениях торговых центров нередко работают на одном Wi-Fi роутере без резервного канала, и сбой у провайдера останавливает обмен с 1С на весь день.

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

Как исправить разрывы синхронизации между приложением и 1С

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

Как разрешаются конфликты версий

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

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

Что делать, если ошибка синхронизации повторяется после восстановления сети

Если ошибка синхронизации повторяется у одного и того же пользователя или на одном складе, причина почти никогда не в «плохом интернете» — это симптом, а не диагноз.

1. ✓Проверить журнал регистрации 1С и лог обмена: ошибка обычно указывает конкретный документ и код конфликта, а не абстрактный сбой сети
2. ✓Сверить версию узла обмена или REST-сервиса на устройстве и на сервере — рассинхронизация чаще всего возникает после обновления платформы, если мобильный модуль не обновили следом
3. ✓Проверить, не превышает ли очередь на устройстве лимит по количеству документов — переполненная очередь на старых версиях приложений начинает терять записи
4. ✓Убедиться, что часовой пояс и время на устройстве синхронизированы с сервером — расхождение ломает логику «последний по времени побеждает»
5. ✓Оценить нагрузочную готовность сервера 1С к пиковому обмену — для этого подходит тест Гилёва, который показывает реальную производительность платформы под нагрузкой, а не паспортные характеристики оборудования

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

Как предотвратить потерю данных при офлайн-работе

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

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

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

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

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

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

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

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

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

Заказ сохраняется локально в приложении с временным номером и встаёт в очередь синхронизации. Как только связь появляется, документ автоматически уходит в 1С без дублирования — курьеру не нужно вводить данные заново.

Нужно ли хранить данные клиентов на телефоне сотрудника, если это персональные данные?

Да, если приложение кэширует контакты или адреса клиентов, это персональные данные, и на них распространяется 152-ФЗ. Локальное хранилище нужно шифровать и хранить только тот объём данных, который реально нужен сотруднику для работы.

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

Доработка обмена — план обмена, REST-сервис, логика очереди — тарифицируется по факту работ, сопровождение и работа сисадмина стоят от 3800 руб/час. Итоговая стоимость зависит от числа ролей и сценариев, которые должны работать офлайн.

Как понять, что синхронизация между приложением и 1С работает некорректно?

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

Выдержит ли обычный сервер 1С резкий всплеск синхронизации после массового обрыва связи?

Слабый сервер при одновременном подключении десятков сотрудников создаёт очередь уже на своей стороне и превращается в новое узкое место. Мощность стоит проверять тестом Гилёва и закладывать запас заранее, а не после первого сбоя.