Використання функціональних опцій

Установлення та отримання значень функціональних опцій

Залежні функціональні опції

Обмеження на використання параметрів функціональних опцій

Див. також

1.1. Якщо деяка функціональність конфігурації є необов'язковою для використання, то для керування доступністю такої функціональності на етапі впровадження слід застосовувати функціональні опції. Для зберігання значень функціональних опцій в інформаційній базі необхідно створити в конфігурації відповідні дані (наприклад, константи).

Припустімо, у конфігурації є необов'язкова функціональність версіонування даних інформаційної бази. Для керування доступністю цієї функціональності необхідно:

• створити функціональну опцію ИспользованиеВерсионирования, яка визначає використання прикладного механізму конфігурації для поточної інформаційної бази
• створити константу ИспользоватьВерсионирование типу Булево для зберігання значення цієї функціональної опції
• у властивості Хранение функціональної опції вказати константу ИспользоватьВерсионирование.

Після цього ті чи інші об'єкти конфігурації можна «прив'язати» до функціональної опції, включивши їх до її складу, а за потреби керування доступністю коду — використовувати метод ПолучитьФункциональнуюОпцию:

ИспользуетсяМеханизмВерсионирования = ПолучитьФункциональнуюОпцию("ИспользованиеВерсионирования");

Отже, набір функціональних опцій описує функціональність конфігурації, доступність якої на етапі впровадження можна налаштувати залежно від вимог конкретного підприємства. При цьому платформа автоматично змінює інтерфейс користувача відповідно до встановлених значень функціональних опцій.

Функціональні опції також можуть впливати на бізнес-логіку. Для цього застосовуються функціональні опції не лише булевого типу, а й інших типів, наприклад посилання на довідники або значення перелічень.

1.2. Доступність функціональності може задаватися не лише для інформаційної бази загалом, а й залежно від контексту застосування цієї функціональності. Припустімо, у конфігурації необхідно керувати застосуванням функціональності складного обліку ПДВ, але не загалом для всієї інформаційної бази, а залежно від організації. Для цього необхідно:

• створити функціональну опцію УчетнаяПолитикаСложныйУчетНДС
• створити параметр функціональної опції Организация, оскільки значення функціональної опції залежить від організації (якщо такого параметра в конфігурації ще немає)
• створити регістр відомостей УчетнаяПолитикаНалоговыйУчет для зберігання значень цієї функціональної опції, з виміром Организация і ресурсами, необхідними для керування функціональністю обліку ПДВ
  
  
• у властивості Хранение функціональної опції вказати ресурс регістру відомостей СложныйУчетНДС
• для параметра функціональної опції Организация указати у властивості Использование вимір Организация регістру відомостей УчетнаяПолитикаНалоговыйУчет.

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

УстановитьПараметрыФункциональныхОпцийФормы(Новый Структура("Организация", <ТребуемаяОрганизация>));

За потреби керування доступністю коду залежно від значення такої функціональної опції її значення можна отримувати, наприклад так:

ПараметрыУчетнойПолитики = Новый Структура("УчетнаяПолитикаОрганизация", <ТребуемаяОрганизация>); 
СложныйУчетНДС = ПолучитьФункциональнуюОпцию("УчетнаяПолитикаСложныйУчетНДС", ПараметрыУчетнойПолитики); 
МоментОпределенияНалоговойБазыНДС = ПолучитьФункциональнуюОпцию("УчетнаяПолитикаМоментОпределенияНалоговойБазыНДС ", ПараметрыУчетнойПолитики);

Увага: слід враховувати, що описаний тут варіант застосування функціональних опцій не є єдиним варіантом їх використання.
Докладніше див. у документації щодо платформи 1С:Предприятие 8.2.

1.3. Не слід використовувати функціональні опції не за призначенням, наприклад:

• створювати функціональні опції для керування видимістю елементів керування конкретної форми. За допомогою функціональних опцій слід керувати доступністю тієї чи іншої функціональності для всієї конфігурації (і, як наслідок, доступністю елементів форм і команд у всій конфігурації, а не в одній окремо взятій формі);
• використовувати функціональні опції для оптимізації доступу до тих чи інших даних інформаційної бази (зберігання значень на сервері 1С:Предприятия). Для цієї мети призначені модулі з повторним використанням значень, що повертаються.

Установлення та отримання значень функціональних опцій

2.1 Платформа 1С:Предприятие 8.2 не надає жодних спеціальних засобів для встановлення значень функціональних опцій: встановлення значень функціональних опцій виконується встановленням значень відповідних констант, редагуванням елементів довідників або записів регістрів відомостей. У конфігурації слід передбачити відповідну функціональність.

2.2. Під час використання функціональних опцій із параметрами слід мати на увазі, що якщо в довіднику або регістрі відомостей немає запису, що відповідає параметру, то функціональна опція вважається вимкненою. Якщо ж параметру відповідає більше ніж один запис, то значення функціональної опції складаються за «АБО».

2.3. Якщо функціональна опція «прив'язана» до ресурсу періодичного регістру відомостей, то система використовує зріз останніх для отримання значення опції. Якщо потрібно отримувати значення опції на будь-яку іншу дату, необхідно вказати значення для параметра функціональної опції Период типу Дата, який використовуватиметься як дата отримання зрізу. Наприклад, якщо є періодичний регістр відомостей із виміром Организация, то слід використовувати такий синтаксис:

УстановитьПараметрыФункциональныхОпцийФормы(Новый Структура("Организация, Период", <ТребуемаяОрганизация>, <ТребуемаяДата>));

При цьому

• значення параметра Период необхідно попередньо привести до інтервалу періодичності регістру для виконання вимоги 2.5. Наприклад, якщо періодичність регістру — місяць, то:

НачалоМесяца(<ТребуемаяДата>)

• а сам параметр Период не слід створювати в метаданих, оскільки він надається системою автоматично.

2.4. Також необхідно мати на увазі, що встановлення значення функціональної опції не спричиняє автоматичної зміни користувацького командного інтерфейсу. Для оброблення зміни слід викликати метод ОбновитьИнтерфейс.

2.5. З погляду продуктивності системи слід мати на увазі, що значення функціональних опцій кешуються на сервері. Однак великий розмір кешу може погіршити продуктивність. Тому не рекомендується параметризувати функціональні опції такими даними, які свідомо можуть мати велику кількість значень. Наприклад, параметризація функціональної опції контрагентом або товаром неприпустима, оскільки контрагентів або товарів може бути велика кількість. Крім того, залежність застосування функціональності від контрагента є сумнівною. На практиці функціональність ставиться в залежність від виду, контрагента або іншої його ознаки. Наприклад, якщо в конфігурації існує перелічення ВидКонтрагента, то застосування тієї чи іншої функціональності слід ставити в залежність від виду контрагента, а не від самого контрагента.

Залежні функціональні опції

3.1. У деяких випадках та чи інша функціональність має бути доступною за умови використання або відмови від використання іншої функціональності. У подібних випадках складної залежності значення функціональної опції від значень інших функціональних опцій необхідно забезпечити несуперечливість даних, пов'язаних із функціональними опціями.

Наприклад, функціональність переведення співробітників з однієї організації до іншої (тобто всі пов'язані з цим документи та звіти) доступна у разі, коли одночасно доступні функціональність "багатофірмовий облік" і функціональність "кадровий облік".

У такому разі всі об'єкти метаданих, пов'язані з переведенням співробітників, не можуть і не повинні ставитися в залежність від функціональних опцій "багатофірмовий облік" і "кадровий облік". Для цього необхідно ввести функціональну опцію "переведення співробітників" і поставити в залежність від неї всі об'єкти метаданих, для яких це необхідно.

Крім того, необхідно забезпечити залежність значення цієї функціональної опції від значень "багатофірмовий облік" і "кадровий облік", наприклад, під час запису значень відповідних констант.

Значення всіх трьох наведених у прикладі функціональних опцій рекомендується показувати адміністратору системи у відповідній формі налаштувань. При цьому значення функціональної опції "переведення співробітників" має бути недоступним для редагування.

Редагувати значення таких функціональних опцій рекомендується елементами керування "Поле" виду "Поле прапорця" із заголовком, що збігається з назвою відповідної функціональної опції.

3.2. Значення взаємовиключних функціональних опцій рекомендується редагувати у відповідній формі налаштування за допомогою елементів керування "Поле перемикача", "Поле введення" (зі списком вибору) або іншого елемента керування, призначеного для вибору одного значення з багатьох. При цьому заголовки для перемикачів або значення розкривного списку для "Поля введення" мають збігатися з назвами функціональних опцій.

3.3. У тому разі, якщо та чи інша незначна функціональність складним чином залежить від значень функціональних опцій, але при цьому не може бути названа так, щоб її назва була зрозумілою кінцевому користувачеві, рекомендується утриматися від створення чергової функціональної опції. При цьому, наприклад, залежність тих чи інших елементів форм має забезпечуватися під час створення форми на сервері за рахунок аналізу значень функціональних опцій із коду вбудованою мовою.

Обмеження на використання параметрів функціональних опцій

4.1. З міркувань продуктивності не рекомендується створювати в конфігурації понад 10 параметрів функціональних опцій. Щоб контролювати їх кількість у конфігурації, не слід створювати різні параметри функціональних опцій одного смислового навантаження. Наприклад, замість двох параметрів:

• ТипВерсионируемогоОбъекта, пов'язаного з виміром ТипОбъекта регістру відомостей НастройкаВерсионированияОбъектов
• ТипОбъектаСДополнительнымиОтчетамиИОбработками, пов'язаного з виміром ТипОбъекта регістру відомостей НазначениеДополнительныхОбработок

рекомендується створити один параметр функціональних опцій ТипОбъектаКонфигурации, який пов'язаний із вимірами обох регістрів відомостей.

4.2. У загальному вигляді для ухвалення рішення щодо складу функціональних опцій та їх параметрів рекомендується дотримуватися такої схеми:

1. Визначається, яка функціональність у нашому прикладному рішенні може бути опціональною (у неї є «вимикач»).
2. Для кожного виявленого випадку визначається, чи вимикається ця функціональність одразу для всієї інформаційної системи, чи «вимикачів» має бути кілька, наприклад, по одному для кожної організації або для кожного виду товару.
3. Виписуємо список усіх параметризованих функціональних опцій, а також список їх параметрів.
4. При цьому у списку параметрів функціональних опцій не допускаємо кількох параметрів одного типу (усі функціональні опції, що залежать від організації, мають використовувати один параметр функціональної опції).
5. Якщо параметрів функціональних опцій виявляється неприйнятно багато, то складаємо їхній «рейтинг»: підсумовуємо склад усіх функціональних опцій, які параметризуються цим параметром, і беремо до уваги важливість параметризованих функціональних опцій.
6. Виключаємо менш затребувані параметри.
7. Ті функціональні опції, які «втратили» параметри:

• або робимо непараметричними (тобто вони вмикають функціональність у всій інформаційній базі загалом);
• або видаляємо, якщо керувати такою функціональністю загалом по інформаційній базі не має сенсу.

У результаті такого підходу в конфігурації буде прийнятна кількість параметрів функціональних опцій.

Див. також

• Вплив зміни значень параметрів сеансу та функціональних опцій на продуктивність механізму обмеження доступу до даних