Мобильное приложение на 1С для клиентов: разбор правил лицензирования, монетизации и архитектуры обмена данными

← На главную

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

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

1. Юридический аспект: Лицензирование мобильных решений 1С

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

Рассмотрим два основных технологических варианта, которые предлагает платформа 1С для мобильных устройств:

Мобильный клиент (МК) — это, по сути, "тонкий клиент" для мобильного устройства. Он работает в режиме постоянного онлайн-соединения с центральной информационной базой. Главный недостаток для клиентских решений: мобильный клиент требует стандартную клиентскую лицензию 1С на каждый сеанс связи. Лицензия выдается сервером "1С" из общего пула. Если у вашей клиники 10 000 пациентов, и хотя бы 500 из них одновременно откроют приложение, вам потребуется приобрести 500 клиентских лицензий 1С, что экономически нецелесообразно. Поэтому мобильный клиент сразу отпадает для массовых внешних пользователей.
Мобильная платформа (МП) — это полноценное автономное приложение. На мобильном устройстве разворачивается локальная база данных (под управлением СУБД SQLite), в которой работает собственная конфигурация. Приложение функционирует независимо от наличия интернета, а обмен данными с центральной базой происходит сеансово по мере необходимости.

Согласно официальным правилам лицензирования фирмы "1С" для мобильной платформы:

Тиражные бесплатные решения для третьих лиц: Если вы разрабатываете мобильное приложение на базе Мобильной платформы для неограниченного круга лиц (пациентов, покупателей) и распространяете его бесплатно через маркеты приложений (App Store, Google Play, RuStore и др.), то никаких лицензионных соглашений с фирмой "1С" заключать не требуется, никаких финансовых обязательств перед "1С" у вас не возникает. Вы можете иметь сотни тысяч пользователей абсолютно бесплатно.
Заказные решения для собственных нужд: Если приложение создается только для внутренних сотрудников вашей организации (например, для врачей, проводящих обход, или курьеров), вы обязаны приобрести мобильные лицензии на каждое рабочее место (устройство).

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

2. Что считается монетизацией приложения?

Часто возникает вопрос: если клиент записывается на платный прием через приложение и оплачивает его банковской картой прямо в интерфейсе — считается ли это монетизацией приложения, требующей отчислений в пользу "1С"?

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

Продажа самого приложения в маркете (платное скачивание);
Встроенная реклама внутри интерфейса;
Платная подписка на функции программы (например, отключение рекламы или доступ к VIP-разделам);
Продажа внутриигровой валюты или виртуальных товаров.

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

3. Производительность мобильной платформы: потянет ли база нагрузку?

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

Мобильная платформа 1С использует легковесную базу данных SQLite. Локальная база на устройстве пациента должна содержать минимальный объем информации:

Список медицинских услуг (несколько сотен или тысяч позиций);
Актуальное расписание врачей (на ближайшие 2–4 недели);
Информацию о текущих и прошлых записях конкретного пациента;
Персональные данные и политику их обработки.

Такой объем данных составляет не более нескольких мегабайт. Платформа 1С с легкостью обрабатывает базы данных размером в сотни мегабайт с десятками тысяч записей. В качестве примера из практики автоматизации торговых представителей: мобильные устройства без проблем справляются с каталогами на 10 000 active SKU, тысячами контрагентов и ежедневным формированием сотен документов продаж с фоновым обменом каждые 20 минут. Для клиентского приложения клиники нагрузка на самом устройстве будет в разы ниже.

4. Проектирование обмена данными: Планы обмена против HTTP-сервисов

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

Представьте, что у вас 20 000 зарегистрированных пациентов. Если для каждого из них в центральной базе будет создан узел плана обмена, таблицы регистрации изменений разрастутся до гигантских размеров. Любое обновление каталога услуг или расписания приведет к записи миллионов строк в таблицы регистрации изменений, что парализует работу СУБД центральной базы.

Правильное архитектурное решение: организация обмена через легковесные HTTP-сервисы (REST API), развернутые на стороне центральной базы 1С.

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

Пример 1: HTTP-сервис в центральной базе для получения расписания

В конфигурации центральной базы создается объект HTTP-сервис с шаблоном URL /v1/schedule. Ниже приведен пример серверного кода, обрабатывающего GET-запрос от мобильного приложения для получения свободных слотов времени врача:


Функция ПолучитьРасписаниеВрача(Запрос)
    
    Ответ = Новый HTTPСервисОтвет(200);
    Ответ.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    
    // Получаем параметры запроса из URL
    IDВрача = Запрос.ПараметрыЗапроса.Получить("doctor_id");
    ДатаПриема = Запрос.ПараметрыЗапроса.Получить("date");
    
    // Преобразуем входящую дату из формата YYYY-MM-DD
    ДатаПриемаКурс = Дата(СтрЗаменить(ДатаПриема, "-", ""));
    
    // Формируем запрос к регистрам или документам центральной базы
    ЗапросКБ = Новый Запрос;
    ЗапросКБ.Текст = 
        "ВЫБРАТЬ
        |   СвободноеВремяПриема.ВремяНачала КАК Время
        |ИЗ
        |   РегистрСведений.СвободноеВремяПриема КАК СвободноеВремяПриема
        |ГДЕ
        |   СвободноеВремяПриема.Врач.Идентификатор = &IDВрача
        |   И НАЧАЛОПЕРИОДА(СвободноеВремяПриема.Дата, ДЕНЬ) = &ДатаПриема";
        
    ЗапросКБ.УстановитьПараметр("IDВрача", IDВрача);
    ЗапросКБ.УстановитьПараметр("ДатаПриема", ДатаПриемаКурс);
    
    РезультатЗапроса = ЗапросКБ.Выполнить().Выгрузить();
    
    // Сериализуем данные в массив структур для JSON
    МассивВремени = Новый Массив;
    Для Каждого Строка Из РезультатЗапроса Цикл
        СтруктураВремени = Новый Структура;
        СтруктураВремени.Вставить("time", Формат(Строка.Время, "ДФ=ЧЧ:мм"));
        СтруктураВремени.Вставить("available", Истина);
        МассивВремени.Добавить(СтруктураВремени);
    КонецЦикла;
    
    // Записываем ответ в тело HTTP-ответа в формате JSON
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, МассивВремени);
    
    Ответ.УстановитьТелоИзСтроки(ЗаписьJSON.Закрыть(), КодировкаТекста.UTF8);
    
    Возврат Ответ;
    
КонецФункции

Пример 2: Отправка запроса на запись на прием из мобильного приложения

В мобильном приложении, когда пользователь нажимает кнопку "Подтвердить запись", отрабатывает процедура отправки POST-запроса на веб-сервер клиники:


&НаКлиенте
Процедура ЗаписатьсяНаПриемНаСервере(ДанныеЗаписи)
    
    // ДанныеЗаписи - это структура, содержащая ID врача, дату, время и данные пациента
    
    // Настраиваем защищенное соединение SSL
    Защита = Новый ЗащищенноеСоединениеOpenSSL;
    Соединение = Новый HTTPСоединение("api.myclinic.ru", 443, , , , 15, Защита);
    
    HTTPЗапрос = Новый HTTPЗапрос("/v1/book");
    HTTPЗапрос.Заголовки.Вставить("Content-Type", "application/json; charset=utf-8");
    
    // Сериализуем структуру данных в JSON
    ЗаписьJSON = Новый ЗаписьJSON;
    ЗаписьJSON.УстановитьСтроку();
    ЗаписатьJSON(ЗаписьJSON, ДанныеЗаписи);
    СтрокаJSON = ЗаписьJSON.Закрыть();
    
    HTTPЗапрос.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8);
    
    Попытка
        HTTPОтвет = Соединение.ОтправитьДляОбъекта(HTTPЗапрос);
        Если HTTPОтвет.КодСостояния = 200 Или HTTPОтвет.КодСостояния = 201 Тогда
            // Успешно записано
            ПоказатьПредупреждение(, "Вы успешно записаны на прием!");
        Иначе
            // Сервер вернул ошибку обработки
            ПоказатьПредупреждение(, "Не удалось записаться: " + HTTPОтвет.ПолучитьТелоКакСтроку());
        EndIf;
    Исключение
        // Ошибка сети или недоступности сервера
        ПоказатьПредупреждение(, "Ошибка связи с сервером. Пожалуйста, попробуйте позже.");
    КонецПопытки;
    
КонецПроцедуры

Такой подход полностью разгружает базу данных мобильного устройства и не перегружает транзакционную систему центральной базы метаданными планов обмена. Все обращения происходят в реальном времени ("на лету"), что обеспечивает актуальность отображаемого расписания и исключает проблему "двойной записи" на одно и то же время.

5. Реализация онлайн-оплаты в мобильном приложении

Запись на прием часто требует внесения предоплаты. Насколько сложно реализовать онлайн-эквайринг в мобильном приложении на 1С? На практике это решается стандартными механизмами интеграции с платежными шлюзами.

Разберем классический сценарий интеграции через технологию WebView с использованием встроенного элемента управления 1С ПолеHTMLДокумента:

Мобильное приложение отправляет HTTP-запрос на ваш сервер 1С с запросом на создание счета (указывается сумма и идентификатор записи).
Сервер 1С обращается к API банка-эквайера (например, Сбербанк, ВТБ, ЮKassa) и получает уникальную платежную ссылку для данной транзакции.
Сервер возвращает эту платежную ссылку обратно в мобильное приложение.
Мобильное приложение открывает форму, содержащую ПолеHTMLДокумента, и перенаправляет пользователя по этой ссылке.
Пациент вводит данные карты или выбирает оплату через СБП прямо на защищенной странице банка.
После успешной оплаты банк отправляет Webhook (уведомление) на веб-сервер вашей клиники. Центральная база 1С фиксирует оплату и меняет статус записи на "Оплачено".
Мобильное приложение отслеживает статус завершения операции и закрывает форму оплаты, возвращая пользователя на главный экран с подтверждением.

Пример кода мобильного приложения для инициализации формы оплаты в элементе ПолеHTMLДокумента:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Получаем платежную ссылку, переданную в параметрах формы
    ПараметрСсылка = Параметры.СсылкаНаОплату;
    
    // Загружаем страницу платежного шлюза банка в элемент формы
    АдресПлатежнойСтраницы = ПараметрСсылка;
    
КонецПроцедуры

В модуле формы мобильного приложения достаточно разместить реквизит типа Строка, связанный с элементом формы ПолеHTMLДокумента, и присвоить ему полученный URL. Это надежный и безопасный способ, так как данные банковских карт не проходят через инфраструктуру 1С и обрабатываются исключительно на стороне серверов банка, соответствующих стандартам безопасности PCI DSS.

Резюме и рекомендации

Подводя итоги нашего анализа, можно сделать следующие выводы:

Разработка бесплатного мобильного приложения для клиентов на Мобильной платформе 1С полностью легальна и не требует покупки лицензий или отчислений в пользу фирмы "1С".
Прием онлайн-платежей за реальные медицинские или иные физические услуги через мобильное приложение не признается монетизацией программного обеспечения со стороны "1С".
Использование Мобильного клиента для массовых внешних приложений недопустимо из-за жестких ограничений серверного лицензирования сеансов.
Архитектуру обмена данными следует строить на базе современных веб-технологий: HTTP-сервисов (REST API) и формата JSON, отказавшись от тяжеловесных планов обмена 1С на мобильных устройствах.
Технология ПолеHTMLДокумента позволяет легко внедрить любой современный интернет-эквайринг или СБП непосредственно внутрь мобильного интерфейса 1С.

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

← На главную