Архитектура мобильного приложения для 1С: где ломается синхронизация

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

склад без сети: где ломается типовая архитектура

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

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

Цена ошибки не абстрактная. Пересорт и задвоенные приходы бухгалтер и кладовщик потом разбирают вручную — это конкретные часы каждую неделю, которые не попадают ни в один отчёт о продуктивности склада. А если задвоенная позиция уедет клиенту в отгрузке, разговор идёт уже не про архитектуру приложения, а про претензию, возврат и испорченные отношения с покупателем.

слой данных: три модели синхронизации с 1С

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

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

когда офлайн-first не оправдан

Офлайн-first не значит «всегда лучше». Если сотрудники работают в офисе с одним стабильным Wi-Fi и открывают приложение раз в день для сверки остатков, полноценная локальная база — это лишние недели разработки и лишняя точка, где могут разойтись версии данных на разных устройствах. Разбираться, почему у двух менеджеров показывается разный остаток по одному товару, дороже, чем один раз честно признать, что офлайн-режим здесь не нужен.

слой бизнес-логики: что нельзя отдавать на телефон

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

пример: скидка, посчитанная дважды

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

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

слой интеграции: как приложение слышит 1С

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

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

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

чек-лист: пять признаков, что архитектуру пора менять

Не каждое неудобство требует переписывать приложение с нуля. Но если совпадает три пункта из пяти ниже — латать точечно уже дороже, чем спроектировать слои заново.

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

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

сколько стоит спроектировать архитектуру правильно

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

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

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

Чем офлайн-режим отличается от обычной мобильной версии 1С?

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

Можно ли добавить офлайн-режим в уже готовое приложение?

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

Сколько стоит разработка мобильного приложения с архитектурой под 1С?

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

Почему после обновления 1С мобильное приложение перестаёт работать?

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

Что выбрать для склада — офлайн-first или гибридную модель?

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