Использование функциональных опций
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. В случае если некоторая функциональность конфигурации является необязательной для использования, то для управления доступностью такой функциональности на стадии внедрения следует применять функциональные опции. Для хранения значений функциональных опций в информационной базе необходимо завести в конфигурации соответствующие данные (например, константы).
Допустим, в конфигурации есть функциональность версионирования данных информационной базы, которая является необязательной. Для управления доступностью этой функциональности необходимо:
- создать функциональную опцию ИспользоватьВерсионированиеОбъектов , которая определяет использование прикладного механизма конфигурации для текущей информационной базы
- создать константу ИспользоватьВерсионированиеОбъектов типа Булево для хранения значения этой функциональной опции
- в свойстве Хранение функциональной опции указать константу ИспользоватьВерсионированиеОбъектов .
После этого, те или иные объекты конфигурации можно «привязать» к функциональной опции, включив их в ее состав, а в случае необходимости управления доступностью кода – использовать метод ПолучитьФункциональнуюОпцию :
ИспользуетсяМеханизмВерсионирования = ПолучитьФункциональнуюОпцию(» ИспользоватьВерсионированиеОбъектов «);
Таким образом, набор функциональных опций описывает функциональность конфигурации, доступность которой на этапе внедрения можно настроить в зависимости от требований конкретного предприятия. При этом платформа автоматически изменяет пользовательский интерфейс в соответствии с установленными значениями функциональных опций.
Функциональные опции могут также влиять на бизнес-логику. Для чего применяются функциональные опции не только булева типа, но и других типов, например, ссылки на справочники или значения перечислений.
1.2. Доступность функциональности может задаваться не только для информационной базы в целом, но и в зависимости от контекста применения этой функциональности. Допустим, в конфигурации необходимо управлять применением функциональности сложного учета НДС, но не в целом для всей информационной базы, а в зависимости от организации. Для этого необходимо:
- создать функциональную опцию УчетнаяПолитикаСложныйУчетНДС
- создать параметр функциональной опции Организация , поскольку значение функциональной опции зависит от организации (если такого параметра в конфигурации еще нет)
- создать регистр сведений УчетнаяПолитикаНалоговыйУчет для хранения значений этой функциональной опции, с измерением Организация и ресурсами, которые необходимы для управления функциональностью учета НДС
После этого, для того чтобы в той или иной форме значение функциональной опции соответствовало контексту, необходимо устанавливать значения параметров функциональной опции, например, так:
В случае необходимости управления доступностью кода в зависимости от значения такой функциональной опции, ее значение можно получать, например, так:
ПараметрыУчетнойПолитики = Новый Структура(«УчетнаяПолитикаОрганизация», );
СложныйУчетНДС = ПолучитьФункциональнуюОпцию(«УчетнаяПолитикаСложныйУчетНДС», ПараметрыУчетнойПолитики);
МоментОпределенияНалоговойБазыНДС = ПолучитьФункциональнуюОпцию(«УчетнаяПолитикаМоментОпределенияНалоговойБазыНДС «, ПараметрыУчетнойПолитики);
Внимание: следует учитывать, что описанный здесь вариант применения функциональных опций не является единственным вариантом их использования.
Подробнее см. в документации по платформе 1С:Предприятие .
1.3. Не следует использовать функциональные опции не по назначению, например:
- создавать функциональные опции ради управления видимостью элементов управления конкретной формы. С помощью функциональных опций следует управлять доступностью той или иной функциональности для всей конфигурации (и, как следствие, доступностью элементов форм и команд во всей конфигурации, а не в одной отдельно взятой форме);
- использовать функциональные опции для оптимизации доступа к тем или иным данным информационной базы (хранения значений на сервере 1С:Предприятия). Для этой цели предназначены модули с повторным использованием возвращаемых значений.
Установка и получение значений функциональных опций
2.1 Платформа 1С:Предприятие не предоставляет каких-либо специальных средств для установки значений функциональных опций: установка значений функциональных опций производится установкой значений соответствующих констант, редактированием элементов справочников или записей регистров сведений. В конфигурации следует предусмотреть соответствующую функциональность.
2.2. При использовании функциональных опций с параметрами, следует иметь в виду, что если в справочнике или регистре сведений нет записи, соответствующей параметру, то функциональная опция считается выключенной. Если же параметру соответствует больше, чем одна запись, то значения функциональной опции складываются по «ИЛИ».
2.3. Если функциональная опция «привязана» к ресурсу периодического регистра сведений, то система использует срез последних для получения значения опции. Если требуется получать значение опции на какую-либо другую дату, необходимо указать значение для параметра функциональной опции Период типа Дата , который будет использоваться как дата получения среза. Например, если имеется периодический регистр сведений с измерением Организация , то следует использовать следующий синтаксис:
УстановитьПараметрыФункциональныхОпцийФормы(Новый Структура(«Организация, Период», , ));
- значение параметра Период необходимо предварительно привести к интервалу периодичности регистра для выполнения требования 2.5 . Например, если периодичность регистра – месяц, то:
- а сам параметр Период не следует создавать в метаданных, так как он предоставляется системой автоматически.
2.4. Также необходимо иметь в виду, что установка значения функциональной опции не вызывает автоматического изменения пользовательского командного интерфейса. Для отработки изменения следует вызвать метод ОбновитьИнтерфейс .
2.5. С точки зрения производительности системы следует иметь в виду, что значения функциональных опций кешируются на сервере. Однако большой размер кеша может ухудшить производительность. Поэтому не рекомендуется параметризовать функциональные опции такими данными, которые заведомо могут иметь большое число значений. Например, параметризация функциональной опции контрагентом или товаром не допустима, так как контрагентов или товаров может быть большое количество. Кроме того, зависимость применения функциональности от контрагента сомнительна. На практике функциональность ставится в зависимость от вида, контрагента или иного его признака. Например, если в конфигурации существует перечисление ВидКонтрагента , то применение той или иной функциональности следует ставить в зависимость от вида контрагента, а не от самого контрагента.
Зависимые функциональные опции
3.1. В некоторых случаях та или иная функциональность должна быть доступна при условии использования или отказа от использования другой функциональности. В подобных случаях сложной зависимости значения функциональной опции от значений других функциональных опций необходимо обеспечить непротиворечивость данных, связанных с функциональными опциями.
Например, функциональность перевода сотрудников из одной организации в другую (т.е. все связанные с этим документы и отчеты) доступна в случае, когда одновременно доступны функциональность «многофирменный учет» и функциональность «кадровый учет».
В таком случае, все объекты метаданных, связанные с переводом сотрудников, не могут и не должны ставиться в зависимость от функциональных опций «многофирменный учет» и «кадровый учет». Для этого необходимо ввести функциональную опцию «перевод сотрудников» и поставить в зависимость от нее все объекты метаданных, для которых это необходимо.
Кроме того, необходимо обеспечить зависимость значения этой функциональной опции от значений «многофирменный учет» и «кадровый учет», например, при записи значений соответствующих констант.
Значения всех трех приведенных в примере функциональных опций рекомендуется показывать администратору системы в соответствующей форме настроек. При этом значение функциональной опции «перевод сотрудников» должно быть недоступно для редактирования.
Редактировать значения таких функциональных опций рекомендуется элементами управления «Поле» вида «Поле флажка» с заголовком, совпадающим с названием соответствующей функциональной опции.
3.2. Значения взаимоисключающих функциональных опций, рекомендуется редактировать в соответствующей форме настройки при помощи элементов управления «Поле переключателя» , «Поле ввода» (со списком выбора) или иной элемент управления, предназначенный для выбора одного значения из многих. При этом, заголовки для переключателей или значения выпадающего списка для «Поле ввода» должны совпадать с названиями функциональных опций.
3.3. В том случае, если та или иная незначительная функциональность сложным образом зависит от значений функциональных опций, но при этом не может быть названа так, чтобы ее название было понятно конечному пользователю, рекомендуется воздержаться от создания очередной функциональной опции. При этом, например, зависимость тех или иных элементов форм должна обеспечиваться при создании формы на сервере за счет анализа значений функциональных опций из кода на встроенном языке.
Ограничения на использование параметров функциональных опций
4.1. По соображениям производительности не рекомендуется заводить в конфигурации более 10 параметров функциональных опций. Для того чтобы контролировать их количество в конфигурации, не следует создавать различные параметры функциональных опций одной смысловой нагрузки. Например, вместо двух параметров:
- ТипВерсионируемогоОбъекта , связанный с измерением ТипОбъекта регистра сведений НастройкаВерсионированияОбъектов
- ТипОбъектаСДополнительнымиОтчетамиИОбработками , связанный с измерением ТипОбъекта регистра сведений НазначениеДополнительныхОбработок
рекомендуется создать один параметр функциональных опций ТипОбъектаКонфигурации , который связан с измерениями обоих регистров сведений.
4.2. В общем виде, для принятия решения по поводу состава функциональных опций и их параметров рекомендуется придерживаться следующей схемы:
- Определяется, какая функциональность в нашем прикладном решении может быть опциональной (у нее есть «выключатель»).
- По каждому выявленному случаю определяется, выключается ли эта функциональность сразу для всей информационной системы или «выключателей» должно быть несколько, например, по одному на каждую организацию или на каждый вид товара.
- Выписываем список всех параметризуемых функциональных опций, а также список их параметров.
- При этом в списке параметров функциональных опций не допускаем нескольких параметров одного типа (все функциональные опции, зависящие от организации должны использовать один параметр функциональной опции).
- Если параметров функциональных опций оказывается неприемлемо много, то составляем их «рейтинг»: суммируем состав всех функциональных опций, которые параметризуются данным параметром и принимаем во внимание важность параметризуемых функциональных опций.
- Исключаем менее востребованные параметры.
- Те функциональные опции, которые «лишились» параметров:
- либо делаем непараметрическими (т.е. они включают функциональность во всей информационной базе в целом);
- либо удаляем, если управлять такой функциональностью в целом по информационной базе не имеет смысла.
В результате такого подхода, в конфигурации окажется приемлемое количество параметров функциональных опций.