Мобильное приложение с интеграцией 1С: 3 способа обмена и где они ломаются

Мобильное приложение подключают к 1С тремя способами: через HTTP-сервисы самой 1С, через промежуточный сервер обмена или на 1С:Мобильной платформе. Для торговых агентов и курьеров обычно хватает HTTP-сервисов с офлайн-очередью: заказ не пропадает без сети, а база 1С не торчит в интернет. Разработка стартует от 500 000 ₽.

Заказ из цоколя торгового центра: где интеграция ломается

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

Причина почти всегда одна: приложение сделали как окно в 1С. Каждое нажатие превращается в запрос к серверу, и без ответа экран не работает. Поэтому интеграция отлично выглядит на демонстрации в офисе с Wi-Fi и разваливается в поле.

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

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

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

Способ определяет две вещи: переживёт ли приложение потерю сети и сколько нагрузки ляжет на рабочую базу. Вариантов три.

HTTP-сервисы и OData

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

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

Промежуточный сервер обмена

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

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

1С:Мобильная платформа

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

Сравнение способов по тому, что болит в поле 📊

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

Если приложением будут пользоваться не сотрудники, а покупатели, сервер обмена почти обязателен: внешних пользователей нельзя пускать даже к HTTP-сервисам рабочей базы. Так устроено B2B-приложение с 1С: покупатель видит свой прайс, свои остатки и свои взаиморасчёты, а к самой базе доступа не имеет.

Почему не подключить приложение прямо к SQL-базе

Этот вариант предлагают чаще, чем кажется. У разработчика есть доступ к SQL-серверу, и читать таблицы напрямую выглядит проще, чем писать сервисы. Но таблицы 1С называются служебными именами вроде _Document123, их структура меняется вместе с конфигурацией, а запись мимо платформы обходит проведение документов.

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

Офлайн-режим по шагам: что заложить в обмен ⚙️

Офлайн не добавляют перед релизом. Его закладывают в схему обмена с первого дня, и вот что в эту схему входит.

1. ✓Телефон создаёт документ с собственным идентификатором (GUID) и не ждёт номер от 1С. Тогда повторная отправка после обрыва не плодит дубли.
2. ✓Документ попадает в локальную очередь со статусом «не отправлен» и уходит, как только появляется связь.
3. ✓1С принимает документ с проверкой идентификатора: если такой уже есть, она возвращает существующий, а не создаёт новый.
4. ✓Остатки и цены хранятся на телефоне копией с отметкой времени, и агент видит, насколько они свежие.
5. ✓Перед проведением 1С заново проверяет остаток. При расхождении она возвращает приложению причину, и агент видит её в списке заказов, а не узнаёт вечером от диспетчера.
6. ✓Справочники загружаются порциями с момента последней синхронизации, а не целиком при каждом открытии.

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

Вот как это выглядит на деле. Два агента в разных магазинах берут последние 10 коробок одного товара, оба заказа создаются без связи. Первый, дошедший до 1С, получает резерв, второй получает отказ с причиной. Агент видит отказ в списке заказов и предлагает клиенту замену, пока не ушёл из магазина.

Персональные данные клиентов на телефоне агента 🔒

В приложении лежат ФИО контактных лиц, телефоны, адреса доставки. Это персональные данные, и на них действует 152-ФЗ. Закон требует хранить базы с данными граждан РФ на территории России, поэтому сервер обмена и база 1С должны стоять в российском дата-центре.

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

Сколько стоит и от чего зависит цена 💰

Разработка мобильного приложения с интеграцией 1С у нас начинается от 500 000 ₽. Итог зависит от четырёх вещей: сколько сущностей 1С нужно вывести в приложение (заказы, склады, взаиморасчёты, фото), нужна ли работа без сети, на каких платформах оно будет работать и насколько сильно доработана ваша конфигурация. Ставки и тарифы собраны на странице цен и тарифов.

Отдельный вопрос: где живёт база. Если 1С стоит на компьютере в офисе, снаружи она недоступна, а перезагрузка роутера останавливает всех агентов. Рабочая база для приложения должна быть доступна круглосуточно, а мощность сервера стоит сверить с системными требованиями 1С. Мы переносим базу на арендованный сервер: от 1 100 ₽ в месяц за пользователя. Правки HTTP-сервисов и поддержка 1С после запуска стоят 3 800 ₽ в час.

Как мы ведём такой проект

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

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

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

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

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

Можно ли подключить мобильное приложение к 1С без доработки конфигурации?

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

Работает ли приложение с 1С без интернета?

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

Сколько стоит мобильное приложение с интеграцией 1С?

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

Нужно ли переносить базу 1С на сервер для работы приложения?

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

Как защитить персональные данные клиентов в мобильном приложении?

Храните базу и сервер обмена на территории РФ, как требует 152-ФЗ, шифруйте данные на телефоне, закрывайте вход ПИН-кодом или биометрией и отзывайте токен доступа в день увольнения сотрудника. Проверьте SDK аналитики и push-уведомлений: они не должны отправлять персональные данные на зарубежные серверы.