В процессе сопровождения и доработки типовых решений на платформе «1С:Предприятие» перед разработчиком часто возникает задача расширения функционала. Например, требуется добавить несколько новых документов или справочников для хранения специфической информации. При этом крайне важно сохранить конфигурацию на поддержке поставщика, чтобы последующие обновления проходили максимально быстро, просто и в автоматическом режиме.
Многие начинающие разработчики или требовательные заказчики опасаются включать режим возможности изменения, считая, что это эквивалентно полному снятию с поддержки и приведет к колоссальным затратам времени при каждом обновлении базы. В данной статье мы подробно разберем, как устроен механизм поддержки, проанализируем различные варианты решения этой задачи и пошагово настроим точечные правила изменения, которые позволят добавлять новые объекты, сохраняя типовые элементы «на замке».
Для начала проанализируем существующие способы добавления новых объектов метаданных и выясним их сильные и слабые стороны.
Способ 1. Использование расширений конфигурации. Расширения — это современный механизм платформы, разработанный специально для кастомизации систем без изменения основной конфигурации. Однако разработчики иногда относятся к ним с недоверием. Исторически, в ранних версиях платформы 8.3, действительно наблюдались проблемы при проведении процедуры «Тестирования и исправления» (ТиИ), когда затирались связи или очищались реквизиты, добавленные через расширения. Кроме того, существует риск случайного удаления расширения администратором базы данных, что повлечет за собой безвозвратную потерю всех накопленных в нем данных (таблиц документов и справочников СУБД).
Способ 2. Нестандартные обходные пути («грязные хаки»). В профессиональных сообществах встречаются рекомендации по ручной правке XML-файлов выгруженной конфигурации (например, подмена правил поддержки в файлах выгрузки с последующей загрузкой обратно). Рассмотрим этот вариант подробнее. Начиная с версии платформы 8.3.16, фирма «1С» закрыла подобные лазейки безопасности. Теперь при частичной загрузке конфигурации из файлов XML, если в структуре отсутствует файл внешнего свойства с корректной информацией о настройках поддержки, система принудительно сбрасывает эти настройки. В результате конфигурация полностью слетает с поддержки поставщика, что делает этот путь не только опасным, но и нерабочим.
Способ 3. Штатная точечная настройка правил поддержки. Это наиболее надежный и рекомендуемый метод. Суть его заключается в том, что статус «Возможность редактирования с сохранением поддержки» не означает автоматического снятия всей конфигурации с поддержки. Платформа 1С позволяет гибко настраивать правила для каждого объекта метаданных индивидуально.
Выясним, как настроить систему таким образом, чтобы корень конфигурации позволял добавлять новые объекты, но все существующие типовые объекты поставщика оставались защищенными от изменений и не требовали ручного сопоставления при обновлениях.
Разберем этот процесс по шагам:
В результате проделанных действий мы получаем конфигурацию, у которой изменен статус только у корневого элемента. Это дает нам законное право добавлять любые собственные объекты метаданных (документы, справочники, регистры сведений), нажимая на кнопку «Добавить» в дереве конфигурации. При этом все типовые объекты остаются закрытыми для редактирования, что гарантирует их целостность.
Рассмотрим подробнее физику процесса обновления измененной конфигурации. Существует миф, что как только на конфигурации пропадает «цельный замок», время ее обновления возрастает в несколько раз. Выясним, почему в нашем случае этого не произойдет.
При стандартном обновлении через файл обновления (.cfu) или полный файл конфигурации (.cf) платформа 1С выполняет трехстороннее сравнение метаданных между тремя участниками процесса:
Если для типового объекта установлено правило поддержки «Объект поставщика не редактируется», платформа понимает, что пользователь физически не мог внести изменения в этот объект. Следовательно, трехстороннее сравнение для него сводится к тривиальному автоматическому замещению кодом новой конфигурации поставщика. Процесс проходит мгновенно, без вызова тяжелых диалогов сравнения/объединения интерактивного окна и без участия разработчика. Время обновления такой базы практически не отличается от обновления полностью заблокированной конфигурации.
Если же разработчик допускает ошибку и включает режим редактирования рекурсивно для всех объектов (все замки становятся серыми), платформа вынуждена детально анализировать свойства и модули каждого из тысяч типовых объектов. Именно это приводит к колоссальному замедлению процесса обновления и усложнению ручного контроля сопоставления метаданных.
Если внутренние регламенты вашей организации или требования заказчика категорически запрещают любое изменение структуры основной конфигурации (даже редактирование правил для корня метаданных), мы можем использовать штатные инструменты Библиотеки Стандартных Подсистем (БСП). Практически во всех современных типовых конфигурациях (1С:Бухгалтерия, 1С:ERP, 1С:Управление торговлей) встроен механизм «Дополнительные реквизиты и сведения».
Этот механизм позволяет создавать новые аналитические разрезы прямо в режиме «1С:Предприятие» без захода в Конфигуратор. Данные при этом физически записываются в стандартные таблицы основной базы данных (в табличные части дополнительных реквизитов объектов или в подчиненный регистр сведений ДополнительныеСведения).
Проанализируем пример программной работы с такими данными. Предположим, мы создали дополнительное сведение для хранения важной информации по договору контрагента. Нам необходимо программно записать в него значение:
// Запись дополнительного сведения для объекта базы данных
СвойствоДляЗаписи = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("СпецифическаяИнформация");
СсылкаНаОбъект = Справочники.ДоговорыКонтрагентов.НайтиПоРеквизиту("Номер", "ДГ-001");
Если ЗначениеЗаполнено(СвойствоДляЗаписи) И ЗначениеЗаполнено(СсылкаНаОбъект) Тогда
НаборЗаписей = РегистрыСведений.ДополнительныеСведения.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Объект.Установить(СсылкаНаОбъект);
НаборЗаписей.Отбор.Свойство.Установить(СвойствоДляЗаписи);
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.Объект = СсылкаНаОбъект;
НоваяЗапись.Свойство = СвойствоДляЗаписи;
НоваяЗапись.Значение = "Вся необходимая информация здесь";
НаборЗаписей.Записать();
КонецЕсли;
Для последующего чтения этой информации мы можем использовать стандартный метод регистра сведений:
// Чтение дополнительного сведения из регистра БСП
СвойствоДляЧтения = ПланыВидовХарактеристик.ДополнительныеРеквизитыИСведения.НайтиПоНаименованию("СпецифическаяИнформация");
СсылкаНаДоговор = Справочники.ДоговорыКонтрагентов.НайтиПоРеквизиту("Номер", "ДГ-001");
Если ЗначениеЗаполнено(СвойствоДляЧтения) И ЗначениеЗаполнено(СсылкаНаДоговор) Тогда
ЗначениеСведения = РегистрыСведений.ДополнительныеСведения.ПолучитьЗначениеСвойства(СсылкаНаДоговор, СвойствоДляЧтения);
Сообщить("Содержимое аналитики: " + ЗначениеСведения);
КонецЕсли;
Данный подход гарантирует абсолютную безопасность ваших данных при любых критических обновлениях платформы или конфигурации, поскольку не затрагивает дерево метаданных напрямую, а использует предопределенные регистры хранения информации.