Вопрос разделения функциональности между ПРОФ и базовыми версиями программных продуктов 1С является актуальным как для разработчиков, так и для системных администраторов. Часто возникает необходимость «понизить» версию конфигурации (например, при переходе клиента на более экономный вариант лицензирования) или разобраться, почему база внезапно перестала принимать базовый пин-код. Разберем детально, по каким критериям платформа идентифицирует тип поставки и что происходит внутри базы данных при таких изменениях.
Первое, что нам необходимо понять: платформа не просто считывает название конфигурации в заголовке. Основным идентификатором версии является цифровая подпись фирмы «1С», вшитая в файл поставки (.cf или .cfu). Проанализируем, как это работает:
Рассмотрим ситуацию, когда мы «накатываем» файл .cf от базовой версии на ПРОФ-базу через механизм «Загрузить конфигурацию из файла». В этом случае платформа видит валидную подпись 1С в новом файле и переводит состояние базы в режим «Базовая».
Интересным индикатором типа конфигурации является диалоговое окно активации лицензии. Проанализируем различия в запросах платформы:
Выясним причину, по которой это важно: базовая лицензия технически «умеет» работать только с теми базами, где структура метаданных полностью совпадает с эталонной поставкой 1С и защищена подписью. Как только подпись нарушается — 16-значный код становится бесполезным.
Помимо проверки подписи, платформа накладывает ряд жестких технологических ограничений, как только база идентифицируется как базовая. Разберем их подробнее:
1. Работа с внешними соединениями (COM и Automation):
В базовых версиях программно заблокирована возможность использования COM-соединения. Попытка создать объект типа V83.Application или V83.ComConnector для подключения к базовой базе закончится ошибкой. Это сделано для исключения возможности построения сложных сетевых систем на дешевых лицензиях.
2. Клиент-серверный вариант и многопользовательский режим:
Платформа блокирует работу в режиме «клиент-сервер». Базовая версия предназначена исключительно для файлового режима. Более того, даже если база лежит в общей сетевой папке, второй пользователь не сможет в нее зайти одновременно с первым — платформа отслеживает количество сеансов.
Рассмотрим практический кейс: у нас есть «Управление торговлей» ПРОФ, и мы хотим сделать ее базовой. Мы берем .cf от базовой версии и выполняем загрузку. Посмотрим, с какими сложностями мы столкнемся:
В отличие от «Бухгалтерии предприятия», где базовая и ПРОФ версии практически идентичны по набору объектов, в «Управлении торговлей» (УТ) или «Зарплате и управлении персоналом» (ЗУП) различия колоссальны. В базовой УТ отсутствуют целые блоки: CRM, планирование, сложный учет производства.
Когда мы выполняем команду «Загрузить конфигурацию», платформа производит реструктуризацию базы данных. Проанализируем последствия:
Помимо платформенных ограничений, разработчики конфигураций встраивают проверки непосредственно в код. Посмотрим на пример того, как конфигурация может определять свой статус через программный интерфейс:
// Пример проверки в общем модуле
Если СтандартныеПодсистемыСервер.ЭтоБазоваяВерсияКонфигурации() Тогда
// Блокируем доступ к многофирменному учету
Объект.Организация = Справочники.Организации.ОсновнаяОрганизация;
Элементы.Организация.Доступность = Ложь;
КонецЕсли;
Такие проверки пронизывают всю логику типовых решений. Поэтому даже если вам удалось запустить базу под базовой лицензией, программный код будет жестко ограничивать ваши действия, опираясь на метаданные и функциональные опции.
Важно помнить о конфигурациях со сложной архитектурой, таких как «Бухгалтерия государственного учреждения» (БГУ). Разберем, почему там простая накатка .cf может не сработать. В БГУ описание структуры метаданных часто хранится в виде XML в специальных регистрах или справочниках. После удаления «лишних» объектов метаданных при переходе на базовую версию, эти записи могут стать невалидными, что приведет к невозможности проведения даже базовых документов.
Аналогичная ситуация наблюдается с шаблонами RLS (ограничение доступа на уровне записей). В ПРОФ-версиях они настроены на группы доступа, которых в базовой версии может просто не существовать. После конвертации рекомендуется выполнить полное перепроведение документов и проверку целостности информационной базы через «Тестирование и исправление».
Подведем итог: платформа отличает версии на основе цифровой подписи поставки и типа используемой лицензии. Конвертация из ПРОФ в базовую технически возможна через загрузку .cf, но она сопряжена с безвозвратной потерей данных в тех блоках, которые не поддерживаются базовой версией. Перед такими манипуляциями всегда создавайте резервную копию и проверяйте работоспособность базы на копии без лицензии, чтобы убедиться, что платформа запрашивает именно 16-значный код.