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