Scope: managed applications, mobile applications, and ordinary applications.
1.1. Whenever a configuration functionality is optional, to manage its availability at the deployment stage, use functional options. To store functional option values in the infobase, create respective data in the configuration (for example, constants).
Suppose that a configuration supports infobase data versioning functionality, which is optional. To manage availability of this functionality:
- Create the UseObjectsVersioning functional optional. It defines the use of the applied configuration tool for the current infobase.
- Create the UseObjectsVersioning constant of Boolean type to store values of this functional option.
- In the Storage property of the functional option, specify the UseObjectsVersioning constant.
You will be able to link configuration objects to the functional option by including them in it. If you need to manage code availability, use the GetFunctionalOption method as follows:
VersioningMechanismUsed = GetFunctionalOption("UseObjectsVersioning");
A set of functional options details a configuration functionality. You can configure the functionality availability at the deployment stage depending on company needs. The platform automatically changes the user interface according to set functional option values.
Functional options can affect the business logic. That is why you can use functional options of not only Boolean type but also other types, for example, references to catalogs or enumeration values.
1.2. You can set functionality availability not only for the whole infobase, but also depending on the use context. For example, you need to manage complex VAT accounting functionality in a configuration not in the whole infobase but depending on the company. To do this:
- Create the AccountingPolicyComplexVATAccounting functional option.
- Create the Company functional option parameter since the functional option value is company-specific (if this parameter does not exist in the configuration).
- Create the AccountingPolicyTaxAccounting information register to store the functional option values with the Company dimension and resources required to manage the VAT accounting functionality.
- In the Storage property of this functional option, specify the ComplexVATAccounting information register resource.
- For the Company functional option parameter, in the Use property, specify the Company dimension of the AccountingPolicyTaxAccounting information register.
To make sure the functional option values correspond to the context, set functional option parameter values, for example:
SetFormFunctionalOptionsParameters(New Structure("Company",<RequiredCompany>));
If you need to manage the code availability depending on the functional option value, you can get its value, for example, as follows:
AccountingPolicyParameters = New Sructure("AccountingPolicyCompany", <RequiredCompany>);
ComplexVATAccounting = GetFunctionalOption("AccountingPolicyComplexVATAccounting", AccountingPolicyParameters);
VATBaseDeterminationMoment = GetFunctionalOption("AccountingVATBaseDeterminationMoment", AccountingPolicyParameters);
Warning: note that the method of using functional options described in this chapter is one of multiple scenarios.
For more information, see 1C:Enterprise Developer Guide.
1.3. Avoid using functional options for wrong purposes, for example:
- Create functional options to manage visibility of form controls. Use functional options to manage functionality availability on a configuration-wide basis (and thus availability of form items and commands of the whole configuration, not of a single form only).
- Use functional options to optimize access to infobase data and store values on 1C:Enterprise server. For this purpose, use modules with repeated use of return values.
Setting and getting functional option values
2.1 1C:Enterprise platform does not provide special tools to set functional option values. To set functional option values, specify values of respective constants, edit catalog items or information register records. Provide the respective functionality in the configuration.
2.2. If you use functional options with parameters, note that if there is no record in a catalog or an information register matching the parameter, the functional option is disabled. If more than one record corresponds to the parameter, OR is used to add functional option values.
2.3. If a functional option is linked to a periodic information register resource, the system uses a slice of the latest ones to get the option value. If you need to get the option value on a specific date, specify a value for the Period functional option parameter of the Date type to be used as a slice date. For example, if you have a periodic information register with the Company dimension, use the following syntax:
SetFormFunctionalOptionsParameters(New Structure("Company","Period",<RequiredCompany>,<RequiredDate>));
Preliminary
- Cast the Period parameter value to the register frequency interval to comply with clause 2.5 requirements. For example, if an information register frequency is one month:
BegOfMonth(<RequiredDate>)
- Do not create the Period parameter in metadata as it is provided by the system automatically.
2.4. When you set functional option values, the command user interface is not automatically changed. To trigger the change, call the RefreshInterface method.
2.5. As for system performance, note that functional option values are cached on the server. Large cache size can negatively affect the system performance. We do not recommended that you parameterize functional options with data that can have a large number of values. For example, avoid parameterizing functional options using counterparties or goods as the number of counterparties and goods can be numerous. Besides, functionality dependency on counterparties is doubtful. Functionality might depend on counterparty kinds or their other attributes. For example, if the CounterpartyKind enumeration exists in the configuration, make the functionality dependent on the counterparty kind, not a counterparty itself.
Dependent functional options
3.1. In some cases, a functionality can be available if another functionality is either enabled or disabled. When functional option values are dependent on other functional option values, make sure the data related to the functional options is consistent.
For example, a functionality to transfer employees from one company to another (all related documents and reports) is available if "multi-company accounting" and "HR record-keeping" functionalities are also available.
In this case, all metadata objects related to transfer of employees cannot depend on "multi-company accounting" and "HR record-keeping" functional options. Instead, implement "employee transfer" functional option and make all required metadata objects dependent on it.
Make sure the functional option values are dependent on the values of "multi-company accounting" and "HR record-keeping", for example, upon writing constant values.
We recommend that you display values of the mentioned functional options to a system administrator in a respective settings form. "Employee transfer" functional option value must be read-only.
We recommend that you edit such values using the "Field" controls of the "Check box field" kind with a title matching the functional option name.
3.2. We recommend that you edit values of mutually exclusive functional options in the settings form using the "Radio button field" , "Input field" (with a selection list), or other control designed to select one of multiple values. Titles of radio buttons or drop-down list values for "Input field" must match the functional option names.
3.3. If a minor functionality is dependent on functional option values but cannot be named to be clearly understood by end users, avoid creating such functional options. Ensure dependence of form items when you create forms on the server by analyzing functional option values from the code in 1C:Enterprise language.
Restrictions on the use of functional option parameters
4.1. To ensure high performance, avoid creating more than 10 functional option parameters in a configuration. To manage their number in the configuration, avoid creating numerous functional option parameters of similar purpose. For example, instead of the following two parameters:
- VersionizedObjectType linked to the ObjectType dimension of the ObjectsVersioningSetting information register
- ObjectTypeWithAdditionalReportsAndDataProcessors linked to the ObjectType dimension in the AdditionalDataProcessorsPurposes information register
Create a single functional option parameter (ConfigurationObjectType) linked to dimensions of both information registers.
4.2. To choose functional options and their parameters, use the following approach:
- Determine which application functionality can be optional (it can be disabled).
- In each case, determine whether this functionality can be disabled for the whole information system or separately, for example, you can disable it for a company or each category of goods.
- Make a list of all parameterized functional options and their parameters.
- Make sure you do not list several parameters of the same type. All company-dependent functional options must use a single functional option parameter.
- If there are too many functional option parameters, rate them. Sum up the content of all functional options that are parameterized by this parameter and rate parameterized functional options as important ones.
- Exclude infrequently used parameters.
- Do one of the following with the functional options whose parameters are excluded:
- Make the functional options non-parameterized. They will enable the functionality in the whole infobase.
- Delete the functional options if it makes no sense to manage this functionality for the whole infobase.
As a result, your configuration will support a reasonable number of functional option parameters.