Как хранить вспомогательные параметры разработчика и даты вступления алгоритмов в силу в 1С 8.3?

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

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

Вариант 1. Проверка даты или версии непосредственно в программном коде

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

Посмотрим на пример вынесения логики выбора алгоритма в специализированный общий модуль:

Функция ПолучитьВерсиюАлгоритма(МетаданныеОбъекта, ДатаДокумента) Экспорт

    Если ДатаДокумента >= '20240101' Тогда
        Возврат 2; // Новый алгоритм с 2024 года
    Иначе
        Возврат 1; // Устаревший алгоритм
    КонецЕсли;

КонецФункции

В модуле объекта или менеджера вызов будет выглядеть компактно:

ВерсияАлгоритма = ОбщегоНазначенияКлиентСервер.ПолучитьВерсиюАлгоритма(ЭтотОбъект.Метаданные(), ЭтотОбъект.Дата);

Если ВерсияАлгоритма = 2 Тогда
    ВыполнитьПроведениеПоНовойСхеме();
Иначе
    ВыполнитьПроведениеПоСтаройСхеме();
КонецЕсли;

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

Минусы: для корректировки даты или флага требуется обновление конфигурации (внесение изменений в метаданные).

Вариант 2. Справочник предопределенных настроек с кэшированием в общем модуле

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

Разберем по шагам правильную организацию этого механизма:

1. Создаем справочник ДополнительныеНастройкиРазработчика с реквизитом ДатаНачалаДействия (тип Дата) и строковым кодом/наименованием.
2. В конфигураторе создаем необходимые предопределенные элементы справочника (например, НовыйРасчетСебестоимости).
3. Создаем общий модуль с признаком «Повторное использование возвращаемых значений» (на время сеанса или вызова) для исключения постоянных обращений к базе данных.

Пример кэширующей функции в общем модуле с повторным использованием:

Функция АлгоритмАктивен(ИмяПредопределенногоЭлемента, ДатаПроверки) Экспорт

    ЭлементНастройки = Справочники.ДополнительныеНастройкиРазработчика[ИмяПредопределенногоЭлемента];
    
    Если Не ЗначениеЗаполнено(ЭлементНастройки) Тогда
        Возврат Ложь;
    КонецЕсли;
    
    ДатаНачала = ЭлементНастройки.ДатаНачалаДействия;
    
    Возврат (ДатаПроверки >= ДатаНачала);

КонецФункции

Важная деталь: кэш повторного использования сохраняет полученные значения в памяти сеанса. Если значение даты в справочнике было изменено в режиме «1С:Предприятие», для немедленного применения изменений в текущем сеансе потребуется вызов метода ОчиститьЗначенияПовторногоИспользования().

Вариант 3. Использование констант и функциональных опций

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

1. Создается константа ДатаНачалаДействияНовогоУчета (тип Дата) или ИспользоватьНовуюСхемуУчета (тип Булево).
2. Константа привязывается к функциональной опции (ФункциональнаяОпция), что позволяет централизованно управлять видимостью реквизитов на формах и поведением логики.
3. Платформа 1С автоматически кэширует значения констант в памяти сеанса, что снижает нагрузку на СУБД по сравнению с прямыми запросами к таблицам.

Вариант 4. Регистр сведений или План видов характеристик

Когда требуется хранить сложные, разнородные и периодические параметры (например, параметры учетной политики или алгоритмов), используют связку План видов характеристик (ПВХ) и Регистр сведений.

Проанализируем структуру такого решения:

1. План видов характеристик задает перечень возможных параметров (предопределенные элементы).
2. Непериодический или периодический регистр сведений хранит значения параметров в разрезе объектов метаданных или организаций.

Ограничение производительности: не рекомендуется создавать реквизиты справочников или ресурсы регистров с составным типом «Все ссылки» (любая ссылка на справочник, документ, перечисление и примитивные типы). В физической таблице СУБД для каждого возможного типа создается отдельная колонка, что приводит к разрастанию таблиц и деградации скорости выполнения запросов. При необходимости хранить произвольные данные лучше использовать сериализацию в строку/JSON или тип ХранилищеЗначения.

Вариант 5. Альтернативные системные механизмы и БСП

Если мы хотим избежать создания новых объектов метаданных, рассмотрим альтернативные системные способы:

1. Макеты конфигурации: если параметры жестко зафиксированы разработчиком, их можно описать в макете общего модуля в формате JSON или XML. Метаданные макетов считываются без обращений к таблицам базы.
2. Хранилище общих настроек: платформа позволяет сохранять произвольные структуры данных без добавления метаданных с помощью вызовов ХранилищеОбщихНастроек.Сохранить() и ХранилищеОбщихНастроек.Загрузить().
3. Подсистема БСП «Обновление информационной базы»: для версионирования алгоритмов и переходов на новые схемы данных рекомендуется использовать регистр сведений ВерсииПодсистем и штатные обработчики обновления библиотеки стандартных подсистем вместо ручных проверок дат.

Сводная рекомендация

Для выбора оптимального решения проанализируем условия задачи:

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