Устройство и настройка мобильного приложения 1С

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

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

Из чего собрано мобильное приложение

Любое приложение 1С на смартфоне состоит из двух слоёв:

• 📱 Мобильная платформа — среда исполнения (runtime) под Android и iOS. Это аналог обычной платформы 1cv8 для настольного компьютера, только адаптированный под мобильную ОС. Она умеет показывать формы, выполнять код, работать с локальной базой и обмениваться данными по сети.
• 🧩 Конфигурация — прикладное решение: справочники, документы, отчёты, формы. Именно она определяет, что вы видите на экране.

Готовые продукты вроде 1С:Мобильная бухгалтерия, 1С:УНФ или 1С:Касса — это как раз пара «мобильная платформа + конфигурация», упакованная в один установочный файл из магазина приложений.

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

Что мобильная платформа умеет помимо учёта

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

• 📷 Камера и сканер. Считывание штрихкодов и QR-кодов прямо из документа — приёмка товара, инвентаризация, оплата по QR. Фотографии можно прикреплять к документам как вложения.
• 📍 Геопозиция. Отметка места, где создан документ: где был торговый представитель, где оформлена доставка. Удобно для контроля выездных сотрудников.
• 🔔 Push-уведомления. Сервер может сигналить на телефон о новой задаче, согласовании, поступившем заказе — без постоянно открытого приложения.
• 📂 Локальные файлы и телефония. Работа с файлами устройства, набор номера из карточки контрагента, отправка сообщений по шаблону.
• 🔋 Фоновая работа. Синхронизация и получение уведомлений идут в фоне, пока ОС это разрешает.

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

Автономный режим и мобильный клиент: в чём разница

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

Автономное приложение — конфигурация и данные целиком живут на устройстве, в локальной СУБД (на мобильной платформе это SQLite). Приложение полностью функционально без сети. Связь нужна только в момент обмена данными с центральной базой: выгрузить накопленное, забрать обновления.

Мобильный клиент — на устройстве нет копии данных. Это тонкий клиент: формы и логику он получает с сервера, а каждое действие (открыть документ, провести, построить отчёт) идёт запросом в опубликованную базу. Без связи работать нельзя, хотя часть интерфейса кэшируется. Мобильный клиент появился в платформе ветки 8.3.14 и позволяет открывать на телефоне ту же базу, с которой работают на компьютерах, без отдельной мобильной конфигурации.

Как приложение соединяется с базой

Подключение всегда опирается на веб-сервер. На стороне центральной базы вы публикуете её средствами конфигуратора через меню Администрирование → Публикация на веб-сервере (нужен установленный Apache или IIS). После публикации у базы появляется адрес вида https://ваш-домен/имя_базы.

Дальше механика зависит от режима.

Для мобильного клиента в приложении указывается этот же адрес публикации. Клиент обращается к базе по HTTP(S) — тот же канал, что и у веб-клиента в браузере. Логин и пароль — те же, что у пользователя информационной базы.

Для автономного приложения обмен идёт не через весь интерфейс, а через опубликованные HTTP-сервисы или веб-сервисы. Приложение дёргает сервис, передаёт свою порцию данных и забирает встречную. Транспорт тот же — HTTP(S), порт 443 для защищённого соединения или 80 для открытого.

Что важно учесть по сети:

• ⚙️ Веб-сервер должен быть доступен снаружи. Если база внутри офисной сети, наружу пробрасывается порт веб-сервера, а не порты кластера 1С.
• 🔒 Для реальной работы нужен HTTPS с валидным сертификатом. По голому HTTP пароли и данные идут в открытом виде — для мобильного доступа через интернет это недопустимо.
• 🌐 Проверить доступность публикации просто: откройте её адрес в браузере телефона. Если база отвечает запросом логина — канал работает, дело за настройкой приложения.
• 🏷️ Адрес публикации должен быть постоянным. Если у офиса «серый» или меняющийся IP, заведите доменное имя и настройте проброс, иначе приложение будет терять базу при каждой смене адреса.

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

Синхронизация данных и работа без связи

Синхронизация — ключевая часть именно автономного режима. В мобильном клиенте синхронизировать нечего: данные и так на сервере.

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

Типичный цикл выглядит так:

1. На телефоне сотрудник создаёт и меняет документы офлайн — всё пишется в локальную базу.
2. Появляется связь — запускается обмен (вручную кнопкой синхронизации или по расписанию в фоне).
3. Приложение отправляет накопленные изменения на сервер и забирает встречные (новые цены, остатки, задания).
4. Локальная база обновляется, конфликты при необходимости разрешаются по заданным правилам.

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

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

Установка и первичная настройка на смартфоне

Порядок зависит от того, ставите вы готовый продукт или собственное решение.

Готовое приложение 1С (мобильная бухгалтерия, УНФ, касса, документооборот и подобные):

1. Установите его из Google Play, App Store или RuStore — как любое другое приложение.
2. При первом запуске выберите режим: вести учёт только на телефоне или подключиться к существующей базе.
3. Для подключения к своей базе укажите адрес публикации и учётные данные, затем запустите первичную синхронизацию.

Собственная мобильная конфигурация (когда разработчик собрал своё приложение):

1. Приложение собирается в конфигураторе через механизм мобильной разработки и выкладывается либо в магазин, либо как установочный файл.
2. Для внутреннего распространения на Android используют APK-файл; на iOS процесс жёстче и обычно требует публикации в магазине или корпоративного распространения.
3. Сборку своего приложения выполняют через сборщик мобильных приложений 1С — отдельный сервис, который превращает конфигурацию в готовый пакет под нужную платформу.

Безопасность и права доступа

Мобильный доступ открывает базу наружу, поэтому безопасность тут не формальность.

• 🔐 Шифрование канала. Только HTTPS. Сертификат — валидный, не самоподписанный, иначе приложение будет ругаться на доверие, а сотрудники привыкнут нажимать «игнорировать».
• 👤 Аутентификация. Вход — под учётной записью пользователя информационной базы. Для мобильных сотрудников заводите отдельных пользователей, а не общий логин: так видно, кто что сделал.
• 🧱 Права доступа . Работают те же роли, что и в основной конфигурации. Мобильному пользователю выдавайте минимум необходимого: обычно доступ к своим документам и справочникам, без администрирования и выгрузок.
• 🧩 Ограничение видимости данных. Если у каждого сотрудника должны быть только его клиенты и заказы, настраивается это на стороне центральной конфигурации (через RLS и условия обмена), а не на телефоне.

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

Типичные неполадки и диагностика

Большинство проблем с мобильным приложением — это не баги, а настройка сети и публикации. Разбирать удобно по симптому.

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