← На главную

Разработчики, работающие с устаревшими, но все еще активно используемыми конфигурациями, такими как 1С:Управление производственным предприятием (УПП) 1.3, часто сталкиваются с задачей адаптации их к современным требованиям. Одной из таких задач является создание мобильного клиента, особенно с автономной работой, что требует использования новых возможностей платформы. Авторы темы столкнулись с дилеммой: можно ли отключить режим совместимости в УПП 1.3, чтобы задействовать функционал мобильной платформы, и какие проблемы это может вызвать? Или есть другие, более практичные пути создания мобильного клиента без масштабной переработки основной конфигурации?

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

Отключение режима совместимости в 1С:УПП 1.3: Стоит ли игра свеч?

Режим совместимости – это специальная опция платформы 1С:Предприятие, которая позволяет конфигурациям, разработанным под старые версии, корректно функционировать на более новых платформах. Например, УПП 1.3 изначально создавалась в эпоху платформы 8.2 и ранних версий 8.3. Поддержание режима совместимости гарантирует, что старый код, структуры данных и формы продолжат работать без глобальных переделок. Однако, чтобы использовать самые современные возможности платформы, в том числе для создания мобильных приложений, часто требуется отключить этот режим или повысить его до актуальной версии (например, 8.3.12 или выше).

Почему отключение режима совместимости для УПП 1.3 является крайне сложной задачей:

1. Глубокая несовместимость: УПП 1.3 – это очень большая и сложная конфигурация, разработанная с учетом архитектуры и особенностей платформы 8.2 и использования обычных форм. Новые версии платформы 8.3, особенно те, что предназначены для работы с управляемыми формами и мобильной платформой, содержат значительные изменения в объектной модели, синтаксисе, механизмах событий и работе пользовательского интерфейса. При попытке отключить совместимость или поднять ее до актуальных версий (например, до 8.3.19, как часто требуется для мобильных приложений), возникают сотни, если не тысячи, ошибок. Как отмечают пользователи, "сыпалось все в самых непредсказуемых местах", "формы уезжали", а в модулях появлялись ошибки из-за устаревших методов или конфликтов имен.
2. Объем работ, сравнимый с новой разработкой: Перевод такой конфигурации в новый режим совместимости – это не просто нажатие одной кнопки. Это масштабный проект, который может быть сопоставим по трудоемкости с внедрением новой конфигурации. Фирма "1С" даже предоставляет обширный чек-лист, который включает в себя:
   • Переименование методов и свойств, которые конфликтуют с новыми стандартными элементами платформы.
   • Устранение конфликтов имен стандартных команд и методов глобального контекста.
   • Удаление пустых обработчиков оповещения.
   • Адаптацию форм и элементов управления под принципы управляемого приложения, что для УПП, основанной на обычных формах, означает практически полную перерисовку многих интерфейсов.
   • Корректировку логики работы с объектами, которая могла измениться в новых версиях платформы.

   Для УПП это означает тысячи часов работы высококвалифицированных специалистов.

3. Потеря актуальной поддержки: Фирма "1С" прекратила выпуск обновлений УПП 1.3 для технологической платформы 8.2 с 30 июня 2019 года, требуя использования платформы не ниже 8.3.12 для продолжения получения обновлений. Однако это не означает, что конфигурация адаптирована для работы без режима совместимости на 8.3.12. В целом, поддержка УПП 1.3 постепенно сворачивается, а в 2026 году планируется полное прекращение ее поддержки. Инвестиции в столь масштабную доработку устаревшей конфигурации могут быть просто нецелесообразны с точки зрения долгосрочной стратегии развития ИТ-инфраструктуры предприятия.
4. Влияние на расширения конфигурации: Если у вас есть доработанные расширения конфигурации для УПП 1.3, их работоспособность при изменении режима совместимости основной конфигурации, скорее всего, будет нарушена. Это добавит еще один слой сложности к задаче.
5. Ограничения мобильной платформы: Для создания мобильного приложения на платформе 1С требуется, чтобы конфигурация работала в режиме совместимости не ниже 8.3.12, а для использования всех актуальных возможностей – часто 8.3.19 или выше. Таким образом, проблема отключения совместимости для УПП 1.3 становится критической, если вы хотите использовать ее как "родительскую" конфигурацию для мобильного клиента.

Исходя из всего вышесказанного, прямой ответ на вопрос "можно ли отключить режим совместимости в УПП 1.3?" – технически это возможно, но практически крайне нецелесообразно и экономически невыгодно. Это подтверждается мнением большинства экспертов на форумах 1С: "Не будет работать УПП с повышением режима совместимости" и "Работа дурная, проще обмен дописать".

Создание мобильного клиента для 1С:УПП 1.3: Практические подходы

Поскольку прямое "оживление" УПП 1.3 до состояния полной совместимости с актуальной мобильной платформой не является реальным путем, мы должны рассмотреть альтернативы. Основной подход, который предлагается экспертами и является наиболее жизнеспособным, – это создание отдельного мобильного приложения с последующим обменом данными с основной базой УПП 1.3 через сервисы.

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

Варианты мобильных решений на платформе 1С

1. Мобильное приложение (автономное):

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

   Преимущества: Полная автономность, высокая скорость работы на устройстве, независимость от качества связи.

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

2. Мобильный клиент (онлайн):

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

   Преимущества: Простота реализации (не нужно разрабатывать обмены), всегда актуальные данные.

   Недостатки: Критически зависим от качества и постоянства интернет-соединения, неприменим для автономной работы. Более того, УПП 1.3, будучи конфигурацией на обычных формах, не может быть напрямую опубликована как веб-клиент для мобильных устройств без значительной переработки всех форм под управляемый интерфейс, что возвращает нас к проблемам совместимости.

3. Мобильный клиент с автономным режимом (гибридный):

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

   Преимущества: Гибкость, сочетание преимуществ онлайн и офлайн режимов.

   Недостатки: Наиболее сложен в реализации, требует тщательной проработки логики синхронизации.

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

Общие шаги по созданию мобильного приложения с автономной работой для УПП 1.3

Если мы выбираем путь отдельного мобильного приложения, которое будет обмениваться данными с УПП 1.3, то процесс будет выглядеть следующим образом:

1. Копирование и адаптация конфигурации для мобильного приложения

   Первым шагом мы создаем новую, пустую конфигурацию или берем уже существующую, сильно упрощенную, которая будет служить основой для нашего мобильного приложения. Наша цель – получить максимально легковесную конфигурацию, содержащую только тот функционал и те данные, которые необходимы мобильным пользователям. Мы будем постепенно переносить в нее необходимые метаданные из УПП 1.3, но не всю конфигурацию целиком.

   • Выделение необходимого функционала: Определите, какие именно задачи будут выполнять мобильные пользователи. Например, это может быть ввод заказов, просмотр остатков товаров, выполнение инвентаризации, фиксация визитов к клиентам.
   • Создание объектов метаданных: В новой конфигурации мобильного приложения мы создаем только те справочники, документы, регистры, перечисления и другие объекты, которые требуются для выполнения выделенных задач. Например, если мобильный клиент будет работать с заказами покупателей, нам понадобятся справочники Номенклатура, Контрагенты, документ ЗаказПокупателя, возможно, регистр ОстаткиТоваров. При этом мы копируем структуру этих объектов, но не их код или формы из УПП.
   • Упрощение и оптимизация: Мобильное приложение должно быть максимально простым и быстрым. Удалите все ненужные поля, реквизиты, обработки, отчеты, которые не будут использоваться на мобильном устройстве. Разработайте управляемые формы с учетом особенностей мобильных интерфейсов (крупные элементы, интуитивно понятное расположение).

   Пример: Если нам нужно ввести новый заказ от покупателя, в мобильном приложении мы создадим документ ЗаказПокупателяМобильный, справочники КонтрагентыМобильный и НоменклатураМобильная. Все эти объекты будут иметь упрощенный состав реквизитов, необходимых только для мобильного сценария. Например, из Контрагентов нам может понадобиться только наименование и ИНН, а из Номенклатуры – наименование, артикул и цена.

2. Настройка свойств конфигурации

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

   • Назначение использования: Установите значение "Приложение для мобильной платформы". Это ключевое свойство, которое указывает платформе, что данная конфигурация предназначена для мобильного устройства.
   • Режим совместимости: Для мобильного приложения мы можем установить высокий режим совместимости, например, 8.3.19 или более поздний, что позволит использовать все современные возможности мобильной платформы. В данном случае это не вызовет проблем, потому что наша мобильная конфигурация создается "с нуля" или адаптируется под эти новые возможности, а не является переделанной УПП.
   • Основной режим запуска: Обычно устанавливается "Управляемое приложение".
   • Включение стандартных подсистем: Для удобства разработки и использования вы можете включить необходимые стандартные подсистемы, например, "Работа с файлами", "Обмен данными", "Пользователи", если они нужны для функционала мобильного приложения.

3. Разработка механизмов обмена данными

   Это самый критичный и сложный этап. Для автономного мобильного приложения необходимо разработать надежные и эффективные механизмы обмена данными с основной базой УПП 1.3.

   • Выбор транспорта обмена:
     • HTTP-сервисы/Веб-сервисы: Наиболее современный и гибкий способ. В основной УПП 1.3 (или в дополнительной обработке/расширении) мы создаем HTTP-сервисы, которые будут принимать запросы от мобильного приложения и отдавать/получать данные. Например, один сервис для загрузки списка товаров, другой – для выгрузки нового заказа.
     • Обмен файлами: Более простой, но менее гибкий вариант, когда данные выгружаются в файл (например, XML или JSON) на сервере и загружаются мобильным приложением, а затем мобильное приложение выгружает файл с изменениями, который загружается в УПП. Часто используется через FTP или сетевые папки.
   • Определение правил обмена:
     • Что обменивать: Определите, какие конкретно данные (справочники, документы, регистры) должны участвовать в обмене. Например, мобильное приложение может загружать список Номенклатура, Контрагенты, ДоговорыКонтрагентов и выгружать новые ЗаказыПокупателей.
     • Как обменивать:
       • Полный обмен: Вся информация по определенному объекту выгружается/загружается целиком (редко используется для больших объемов).
       • По изменениям: Обмениваются только те данные, которые были изменены с момента последнего обмена. Для этого часто используют объекты ПланыОбмена и метод ЗарегистрироватьИзменения(), которые позволяют отслеживать изменения в основной базе. Аналогично, на стороне мобильного приложения необходимо вести учет изменений.
       • Фильтрация данных: Для экономии трафика и ресурсов мобильного устройства обменивайтесь только необходимой подмножеством данных. Например, загружать только "активных" контрагентов или номенклатуру, по которой были движения за последний год.
     • Использование форматов данных: Чаще всего для обмена используются форматы XML или JSON, так как они универсальны и легко парсятся как на стороне 1С, так и в других системах.
   • Реализация логики обмена:
     • На стороне УПП 1.3 создаются процедуры и функции, которые формируют данные для выгрузки в мобильное приложение (например, запрос к базе, создание XML-строки) и принимают данные от мобильного приложения (разбор XML/JSON, запись в базу).
     • На стороне мобильного приложения реализуется логика, которая отправляет запросы к УПП, получает данные, обрабатывает их (например, записывает в локальные справочники) и отправляет свои изменения обратно.

     // Примерный псевдокод для выгрузки данных из УПП через HTTP-сервис Функция ПолучитьДанныеДляМобильногоПриложения(ТипДанных, ДатаПоследнегоОбмена) Запрос = Новый Запрос; Если ТипДанных = "Номенклатура" Тогда Запрос.Текст = "ВЫБРАТЬ Наименование, Артикул ИЗ Справочник.Номенклатура ГДЕ ДатаИзменения > &Дата"; ИначеЕсли ТипДанных = "Контрагенты" Тогда Запрос.Текст = "ВЫБРАТЬ Наименование, ИНН ИЗ Справочник.Контрагенты ГДЕ ДатаИзменения > &Дата"; КонецЕсли; Запрос.УстановитьПараметр("Дата", ДатаПоследнегоОбмена); Результат = Запрос.Выполнить().Выгрузить(); // Преобразовать Результат в JSON или XML Возврат СериализаторJSON.Записать(Результат); КонецФункции // Примерный псевдокод для записи заказа от мобильного приложения в УПП Функция ПринятьЗаказОтМобильногоПриложения(ДанныеЗаказаJSON) СтруктураЗаказа = СериализаторJSON.Прочитать(ДанныеЗаказаJSON); НовыйЗаказ = Документы.ЗаказПокупателя.СоздатьДокумент(); НовыйЗаказ.Дата = ТекущаяДата(); НовыйЗаказ.Контрагент = Справочники.Контрагенты.НайтиПоНаименованию(СтруктураЗаказа.КонтрагентНаименование); // Заполнить табличные части и другие реквизиты Попытка НовыйЗаказ.Записать(РежимЗаписиДокумента.Проведение); Возврат "Заказ успешно принят."; Исключение Возврат "Ошибка при записи заказа: " + ОписаниеОшибки(); КонецПопытки; КонецФункции

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

4. Публикация на веб-сервере

   Для того чтобы мобильное приложение могло обмениваться данными с УПП 1.3, а также для распространения самого мобильного клиента (в некоторых сценариях), информационная база УПП должна быть опубликована на веб-сервере (например, Apache или IIS). Это позволит HTTP-сервисам УПП быть доступными по сети для мобильного приложения.

Преимущества подхода с отдельным мобильным приложением и обменом

Этот подход, несмотря на необходимость разработки обменов, имеет ряд существенных преимуществ для работы с УПП 1.3:

1. Сохранение стабильности основной УПП 1.3: Мы не вмешиваемся в основную конфигурацию УПП, сохраняя ее стабильность и избегая рисков, связанных с отключением режима совместимости.
2. Гибкость и актуальность мобильного решения: Мобильное приложение разрабатывается на современной платформе 1С с высокими режимами совместимости, что позволяет использовать все актуальные возможности мобильной платформы, без привязки к устаревшей архитектуре УПП.
3. Оптимизация под мобильные задачи: Мобильное приложение содержит только необходимый функционал, что делает его более легким, быстрым и удобным для использования на мобильных устройствах.
4. Автономная работа: Возможность работы офлайн критически важна для многих мобильных сценариев.

Заключение и стратегические рекомендации

Итак, на вопрос "можно ли отключить режим совместимости в 1С:УПП 1.3?" ответ – теоретически да, но практически это нецелесообразно из-за огромного объема работ, рисков нестабильности и скорого прекращения поддержки конфигурации со стороны "1С".

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

В долгосрочной перспективе, учитывая скорое прекращение полной поддержки УПП 1.3, мы рекомендуем рассмотреть стратегический переход на более современные и актуальные конфигурации 1С, такие как 1С:ERP Управление предприятием 2, 1С:Комплексная автоматизация 2, 1С:Управление торговлей или 1С:Управление нашей фирмой (УНФ). Эти конфигурации изначально разработаны на базе управляемых форм и имеют встроенные механизмы для работы с мобильными клиентами, что значительно упрощает реализацию мобильных решений и обеспечивает актуальность вашей ИТ-инфраструктуры в будущем.