Мобильная платформа 1С:Предприятие: что это такое и как её использовать

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

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

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

Как устроена мобильная платформа 1С

Архитектурно мобильная платформа повторяет устройство «взрослой» платформы 1С:Предприятие, но адаптирована под мобильные операционные системы. Внутри приложения работает компактный вариант ядра платформы, встроенная СУБД для локального хранения данных и исполнитель встроенного языка. Прикладная конфигурация — справочники, документы, регистры, отчёты, формы — описывается теми же объектами метаданных, что и в обычной конфигурации.

Процесс создания приложения выглядит так. Разработчик проектирует мобильную конфигурацию в конфигураторе (обычно это сильно упрощённая версия основной конфигурации с ограниченным набором объектов), затем с помощью специального инструмента — сборщика мобильных приложений — упаковывает её в установочный файл APK для Android или в пакет для iOS. На устройстве приложение устанавливается как обычная программа и работает под своей иконкой.

Обмен данными с центральной системой не встроен «сам по себе» — его проектирует разработчик. Типовые механизмы: веб-сервисы (HTTP или SOAP), публикация HTTP-сервисов на стороне центральной базы, файловый обмен. Чаще всего используют планы обмена и сериализацию данных в XML или JSON, передавая пакеты при появлении связи.

Чем мобильная платформа отличается от мобильного клиента и веб-клиента

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

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

Маршрут решения

Как выбрать подход

Сотрудники работают без стабильного интернета и вводят данные в полеРазрабатывайте приложение на мобильной платформе с синхронизацией

Нужен доступ к центральной базе с телефона при постоянной связиОпубликуйте базу и используйте мобильный клиент

Доступ нужен редко и с любых устройств без установкиНастройте веб-клиент через браузер

Типовые сценарии применения

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

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

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

Возможности и ограничения технологии

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

Ограничения существенны, и их нужно учитывать на этапе проектирования. Мобильная платформа поддерживает не весь состав объектов метаданных и не все возможности встроенного языка: ряд механизмов «большой» платформы (например, часть серверных функций, COM-объекты, внешние компоненты для Windows) на устройстве недоступны. Конфигурацию приходится проектировать специально под мобильное исполнение, а не переносить готовую учётную систему «как есть».

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

Третья группа ограничений — инфраструктурная. Сборка под iOS требует компьютера с macOS, учётной записи разработчика Apple и сертификатов. Распространение приложений внутри компании для Android проще (установка APK напрямую или через MDM), для iOS — через корпоративные механизмы распространения или магазин приложений с соблюдением правил площадки.

Как организовать обмен данными с центральной базой

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

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

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

Порядок создания первого мобильного приложения

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

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

1. 1
   Опишите сценарий: роли пользователей, перечень документов и справочников, правила обмена
2. 2
   Создайте мобильную конфигурацию с минимальным набором объектов и простыми формами
3. 3
   Настройте план обмена и HTTP-сервисы на стороне центральной базы
4. 4
   Отладьте приложение на устройстве в режиме разработчика через подключение к конфигуратору
5. 5
   Соберите установочный пакет сборщиком мобильных приложений
6. 6
   Проведите пилот на 2–3 устройствах, проверьте обмен и автономную работу
7. 7
   Разверните приложение на все устройства и настройте процедуру обновлений

Отдельно спланируйте жизненный цикл после внедрения: конфигурация будет развиваться, и нужен механизм доставки обновлений на устройства. Для Android обновления обычно рассылают новым APK через MDM или внутренний каталог; процедуру обновления стоит отработать заранее, чтобы не блокировать работу полевых сотрудников в середине дня.

Как проверить, что решение работает правильно

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

Контрольные точки

Как проверить результат

Автономная работа

Норма

Документы создаются и сохраняются при выключенной сети

Тревожный признак

Приложение требует соединения или теряет введённые данные

Синхронизация

Норма

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

Тревожный признак

Документы дублируются, часть изменений не доходит

Скорость обмена

Норма

Синхронизация занимает приемлемое время при реальном объёме данных

Тревожный признак

Обмен длится десятки минут или зависает

Конфликты

Норма

Одновременное изменение объекта обрабатывается по заданному правилу

Тревожный признак

Данные затираются молча, без журнала и уведомления

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

Частые вопросы о мобильной платформе 1С

Нужно ли покупать отдельную лицензию на каждое мобильное устройство?

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

Можно ли перенести существующую конфигурацию 1С на телефон без доработки?

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

Работает ли приложение на мобильной платформе без интернета?

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

Чем собрать приложение для iOS, если в компании нет Mac?

Сборка под iOS технически требует среды macOS и действующей учётной записи разработчика Apple. Без компьютера с macOS собрать и подписать приложение не получится — либо приобретается такой компьютер, либо сборку поручают подрядчику, у которого инфраструктура уже есть.

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

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

Подходит ли мобильная платформа для доступа руководителя к отчётам?

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