Global configuration requirements

Code writing standards for easier localization
General requirements to configurations
Shared configuration development workflow
Using session parameters
Common module naming rules
Using functional options
Thick client support in managed applications that run in the client/server mode
Using common attributes
Metadata object names in configurations
Business process route map layout recommendations
User settings
Time zone differences
Configuration initialization
Using defined types
Specifics of configuration development for Linux
Restrictions to renaming metadata objects
Using subsystems

Code writing standards for easier localization

This article describes code writing standards for easier localization. All of the listed recommendations are mandatory unless noted otherwise.

1. If configuration modules contain strings intended for displaying in the user interface (messages to users, form texts, command names, tooltips, and so on), take measures to facilitate future localization.

Use the NStr function instead of specifying string literals explicitly. Do not use strings intended for displaying in the user interface in any other way.

Incorrect:

DoMessageBox("This action requires installing a file extension.");

Correct:

DoMessageBox(NStr("en='This action requires installing a file extension.'"));

Also ensure that the NStr function is used correctly.
Incorrect:

MessageText = "en='This action requires installing a file extension.'";
DoMessageBox(NStr(MessageText));

Correct:

MessageText = NStr("en='This action requires installing a file extension.'");
DoMessageBox(MessageText);

2. If a string consists of multiple text segments and variables, we strongly recommend writing it as a complete sentence instead of assembling it from segments on the go. Use variable substitution as shown in the following example.

Incorrect:

MessageItemShortage = "Not enough " + ItemDescription + " items in " + WarehouseDescription + " warehouse.";

Correct:

MessageItemShortage = NStr("en='Not enough %Item% items in %Warehouse% warehouse.'") 
MessageItemShortage = StrReplace(MessageItemShortage, "%Item%", ItemDescription); 
MessageItemShortage = StrReplace(MessageItemShortage, "%Warehouse%", WarehouseDescription);

There are two reasons for this. First, parameters might have different positions in different languages. Therefore, localizing a concatenated string might require swapping positions of its segments. Second, incomplete segments are difficult to translate.

Note. In rare cases when substituted values are variables themselves or they include variables (such as %Warehouse%), the method described above that uses StrReplace might give incorrect results. If your configuration includes 1C:Subsystems Library, you can use the function StringFunctionsClientServer.SubstituteParametersInString to bypass the restriction:

MessageItemShortage = StringFunctionsClientServer.SubstituteParametersInString(
    NStr("en='Not enough %1 items in %2 warehouse.'"), ItemDescription,  WarehouseDescription);

3. In the NStr function, the string must be enclosed in single straight quotation marks, because string literals often include regular quotation marks.
Incorrect:

DoMessageBox(NStr("en=Variable of ""String"" type")); 
DoMessageBox(NStr("en=""Variable of ""String"" type"""));

Correct:

DoMessageBox(NStr("en='Variable of ""String"" type'"));

4. However, if you decide to use a concatenated string instead of a string with variable substitution, present characters that are not language-specific (spaces, tabs, and so on) as individual string literals, which do not require translation.

Incorrect:

MessageText = NStr("en = 'Balance of funds issued to person accountable: '")
  + QueryResultSelection.BalanceOfPersonAccountable;

Correct:

MessageText = NStr("en = 'Balance of funds issued to person accountable:'")
  + " " + QueryResultSelection.BalanceOfPersonAccountable;

5. Rarely string literals displayed in the user interface are defined in queries. Define such literals as parameters instead of defining them explicitly in the query text.
Incorrect:

QueryByVersions = New Query(" 
  |SELECT 
  |Versions.Ref, 
  |CASE WHEN Versions.Released = TRUE 
  | THEN ""(released)"" 
  | ELSE ""(in development)"" 
  |END AS TextAnnotation
  | FROM 
  | Catalog.Versions AS Versions");

Correct:

QueryByVersions = New Query("
  |SELECT 
  |Versions.Ref, 
  |CASE WHEN Versions.Released = TRUE 
  | THEN &TextReleasedVersion 
  | ELSE &TextNotReleasedVersion 
  |END AS TextAnnotation
  | FROM 
  | Catalog.Versions AS Versions");

QueryByVersions.SetParameter("&TextReleasedVersion", NStr("en='(released)'")); 
QueryByVersions.SetParameter("&TextNotReleasedVersion", NStr("en='(in development)'"));

6. When you use the Format function for displaying dates, remember that the date and time format varies between countries and regions. For example, you can write the same date as 12/20/2012 (US format) or 20.12.2012 (Russian format).

Therefore, instead of specifying dates explicitly

Format(Date, "DF=MM/dd/yyyy")

use the local date format:

Format(Date, "DLF=D")

Another incorrect usage example:

Format(ApprovalDate, "DF='MMMM dd, yyyy'")

Correct:

Format(ApprovalDate, "DLF=DD")

7.1. When you specify date format in form input fields or in data composition schema-based report fields, also use local date format.

7.2. In form fields with choice lists always set the ListChoiceMode property to True. Then the fields will display localized presentations (which is correct) instead of choice list values.

7.3. When you redefine standard field presentations in data composition schema-based reports, follow the same rules as when writing module script. For example, this is incorrect:

"No. " + Number + " from " + Format(Date, "DF=MM/dd/yyyy")

And this is the correct expression for calculating field presentation:

StringFunctionsClientServer.SubstituteParametersInString(
  NStr("en = 'No. %1 from %2'"),
  Number,
  Format(Date, "DLF=D"))

Note. The StringFunctionsClientServer.SubstituteParametersInString function is available if 1C:Subsystems Library is included in your configuration.

8. Exceptions from the listed rules are:

8.1. Strings generated by the script that are recorded to the infobase and displayed to users.
For example, an autogenerated comment to a posting operation, or the EventName parameter of the WriteLogEvent method.

Make such strings available for localization but explicitly specify the default configuration language for them. If you do not, you can encounter issues like this: a document is posted by a user with English interface and then reposted by a user with German interface, and the accounting register records change (which is incorrect).
We recommend that for each script fragment that generates such strings you add a comment explaining the exception from general localization rules:

Comment = NStr("en = 'Comment to posting'", Metadata.DefaultLanguage.LanguageCode); // this string is recorded to the infobase

8.2. Do not localize string constants that store internal IDs and are never displayed to users. Do not apply the NStr function to these constants.
Examples:

Type("Array")
Return "OperationCompletedSuccessfully";
Notify("Write_File", New Structure("Event", "VersionSaved"), FileRef);
OpenForm("Catalog.AdditionalAttributeAndDataSets.Form.EditSetsContent");

8.3. Do not localize query texts.

General requirements to configurations

1.1. Configurations must use standard and documented 1C:Enterprise features only.

1.2. Configurations must be compatible with all DBMS, operating systems, web browsers, and operation modes supported by 1C:Enterprise. In the web client, all of the key configuration features must be available without the file system extension installed, and the user interaction must be asynchronous. For more information, see the following:

List of supported operating systems and databases
"Operation of various DBMS" appendix of 1C:Enterprise Developer Guide.
"Special characteristics of low connection speed mode" and "Specific characteristics of web client" in the "System behavior in various modes" appendix of 1C:Enterprise Developer Guide.
Specifics of configuration development for Linux

In particular, the configuration check must not show any errors.

1.3. While designing technical solutions, user interface, reports and so on, we strongly recommend that you stick to the defaults of 1C:Enterprise platform. Implementation of alternate technical solutions is only acceptable in specific justified cases.

2.1. Names, synonyms, and comments of metadata objects and common modules, and any other textual information (which is visible to users or intended for developers) must comply with the language rules and, in particular, must not contain grammatical errors.

2.2. The configuration must not contain any unused metadata objects (catalogs, documents, command interface sections, and so on).

2.3. Top-level metadata objects like Catalogs, Documents, or Common modules must be sorted by name in the metadata tree. Subordinate metadata objects like attributes, dimensions, or forms must be ordered according to the implementation logic.

This rule has the following exceptions:

Common attributes (because the order of common attributes that serve as separators must be based on the order of setting session parameters)
Objects with the Delete prefix, which can be placed at the end of respective metadata branches

Shared configuration development workflow

This recommendation is optional

This recommendation has the following purposes:

Improve the quality of configurations being developed
Streamline development and testing workflows
Facilitate continuous configuration development with strict deadlines

1. Definitions

A planned release is an applied solution version featuring significant functionality development, its release is scheduled in advance.

A patch is a version intended for urgent fixing of critical issues. In rare cases a patch might include new functionality (for example, enhancements that reflect legislation changes). The release date is defined based on the number of issues discovered in the planned release and their importance.
A design project is a task that describes additions and changes to the applied solution. Each design project includes a clearly defined goal and a list of changes required to achieve the goal.

2. Patch development

2.1. For each patch, create a new configuration repository based on the latest released version.

Important! Do not copy the main repository, create a new one.

2.2. A patch must not contain changes that require significant development time. If you need to implement such changes, consider revising the planned release date.

2.3. All of the records in the patch repository version must have comments.

The requirements to these comments are identical to the requirements to planned release comments (see paragraph 3.4).

2.4. All of the changes implemented in the patch repository must be applied to the main repository. If you add new objects or object attributes in the patch repository, apply the changes only by comparing and merging configurations to preserve internal configuration object IDs.

2.5. When you build a patch version, we recommend that you assign a label with a build number to the revision in the repository that you use for building the patch. It is usually the latest revision in the repository.

3. Planned release development

3.1. Perform the development of planned versions in the main configuration repository.

3.2. Each revision in the main repository must switch the stored configuration from a functional (ready-for-release) state to another functional state.
Committing revisions that are not fully debiggued is not allowed! The main repository must always stay in the functional state to ensure that the building of the release version can be started at any time.

3.3. You can perform the following tasks in the main repository:

fixing issues when this does not require design changes or significant development and testing time. Otherwise the development requires a design project (in this scenario use the procedure of working with the repository that you use for other design projects).
including new library versions;
including fully debugged projects;
in exceptional cases, you can perform project development in the main repository (such as mass refactoring).

3.4. All of the revisions in the main repository must have comments.

The comment content depends on the changes included in the revision:

if you fixed an issue, provide the issue number and brief description from the bug tracking system;
if you included a new library version, provide the library name and its full version number;
if you included a new design project, provide the project number and brief description from the design document storage system;
if the new revision includes changes based on a design project, in addition to the project number and brief description, provide the description of changes included in the revision.

3.5. Apply all of the changes based on a design project to the main repository as a single revision. If you need to apply the changes several times, open several projects.

3.6. Once you apply the changes to the main repository, you can fix the issues caused by the changes made in this project. To review the design, open a new project.

3.7. When you build a planned release, we recommend that you assign a label with a build number to the revision in the repository that you use for building the release. It is usually the latest revision in the repository.

4. Design project development

4.1. Develop each design project in a separate repository.

Create the design project repository according to the procedure described in Appendix 1.

4.2. When you specify that a configuration stored in the design project repository is supported based on the configuration stored in the main repository, the platform sets the "Vendor object changes not allowed" rule. To be able to work with the design project, change the rule to "Vendor object changes allowed w/o breaking support".

Set the "Vendor object changes allowed w/o breaking support" rule only for objects that will be changed during the development of the design project. Use this rule as sparingly as possible. For example, if the design project changes affect a form, set the rule for the form but keep the "Vendor object changes not allowed" rule for the form's parent object.

In order to change the support rules, you only need to lock the configuration root. You do not have to lock the objects whose support rules you want to change.

These recommendations simplify the process of replicating the changes between the main repository and the design project repository.

4.3. The person responsible for the design project can update the design project configuration periodically. It is up to them to decide how often they perform the updates.

The following factors might affect the update frequency:

whether the design project affects objects that are in the responsibility of other developers;
whether refactoring of common code is being performed;
whether mass fixing of issues is performed in the main repository.

The design project update procedure is described in Appendix 2.

4.4. Once the development is finished, the person responsible for the project gets approval for the deadlines for debugging and for applying the design project changes to the main repository. We recommend that for projects that include modification of a great number of objects, you apply the changes at the end of the development cycle to reduce their impact on other projects.

People responsible for other projects can submit requests to postpone the deadlines.

4.5. Apply the project changes to the main repository when the project debugging is complete. We recommend that, once the debugging of the design project is finished, you generate a file with a comparison of the design project configuration and the main configuration.

4.6. Applying design project changes to the main repository must not lead to prolonged object lockouts in the main repository. To achieve that, first update the design project repository from the main repository using the procedure described in Appendix 2. In case of numerous changes, the update might take significant time (up to several days) and the main repository configuration might change during this period. Therefore, the update process will include several iterations, each reducing the number of changes until only the changes introduced in the design project are left.

We recommend that you perform a quick design project functionality check after each update iteration.

Start applying changes to the main repository (which requires locking the main repository objects) only when the majority of the differences between the repositories come from the changes introduced by the design project.

4.7. The person responsible for the design project must be careful with applying changes to the main repository. They should remember that the main repository must be ready for building a planned release at all times.

Once the changes are applied to the main repository, the design project developers and testers perform a quick check to ensure that the changes are applied correctly and they do not have any impact on the related functionality. The person responsible for the project defines what exactly requires checking, as well as how the check is performed.

4.8. After the check is performed and before the changes are committed to the main repository, the person responsible must run a configuration check with all of the check options enabled.
Committing the changes to the main repository is only allowed when all of the errors introduced by the design project and found during the configuration check are successfully resolved.

4.9. Once the changes are applied to the main repository, the person responsible for the design project deletes the project repository.

5. Build numbering

The version numbering standards are described in Version and revision numbering.
The following additional rules apply to the build number (the fourth part of the full number).

5.1. Increment the build number both in the main repository and in the patch repository in the following cases:

before building a release version. This is required to ensure that the release number is different from the previous release number;
when an infobase update handler is added. This is required to ensure that all of the developers will have the handler started automatically (only available for configurations based on 1C:Subsystems Library).

5.2.1. When you add infobase update handlers to a repository, increment the build number for this revision. The following scenarios are available:

The update handler is added to the design project repository during the development of the design project. When you apply the changes to the main repository, increment the build number in the main repository.
The update handler is added when fixing an issue. If the issue is fixed in a single repository (either the main repository or the patch repository), increment the build number in that repository. If the issue is fixed in both repositories, increment the build number is both repositories.

5.2.2. The handler and the build number increment must belong to the same revision. The update handler must be "tied" to the build number that is added to the repository together with the handler.

5.2.3. If available update handlers belong to different subsystems within a configuration, increment both the handler's subsystem build number and the configuration build number.

5.3. Increment the build number:

In the configuration properties.
In the InfoBaseUpdate<LibraryName>.OnAddSubsystem procedure (only for configurations based on 1C:Subsystems Library 2.0).

Appendix 1. Creating a design project repository

Update the configuration bound to the main repository from that repository.
Create a distribution file (*.cf) for the configuration from the main repository.
Load the configuration from the distribution file to the infobase that you want to use for the design project development. The loaded configuration is supported and changing this option is not allowed.
Create a configuration repository in a shared folder. Once the repository is created, the platform allows making changes to the configuration.
Add the ReadOnly user (no password, no right to lock objects). Do not use this user for binding the infobase to the repository; use it only for updating the configuration from the repository.
Add the users involved in the project as repository users (the logon name matches the employee surname, no password, with the right to lock objects). Do not use the ReadOnly user for project development.

Appendix 2. Procedure of updating a design project repository from the main repository

Before applying changes from the design project repository (hereafter, DPR) to the main repository (hereafter, MR), update DPR from MR.
To update DPR from MR, perform the following actions:

Update the infobase bound to MR.
Create a distribution file for the MR configuration.
Lock all of the objects in DPR.
Compare the main configuration with the vendor configuration (on the Configuration menu, click Compare configurations). Save the comparison result to a file, it will contain the changes introduced by the design project. On the Actions menu, click Configuration comparison report. We recommend that you save the file both in text and spreadsheet formats for future use.
Update the configuration (on the Configuration menu, point to Support and click Update configuration. Click Select update file and specify the configuration distribution file created during step 2).

In the configuration comparison and merge window that is opened, click the Filter button and select the Show only properties that were changed twice check box.

When merging the configurations, pay attention to the listed objects. You can merge the rest of the objects without any additional checks.
In the window that is opened when you click Execute in the configuration comparison and merge window, set the Object not editable rule for all of the vendor objects (for both objects with the Changes not recommended rule and objects with the Changes allowed rule). For the rest of the objects, select the Keep current mode check box (it is selected by default).
Once the comparison is complete, correct the objects where changes introduced by the design project were overwritten during the update. This actually means that you have to redo all of the design projects changes to these configuration objects.
Run the comparison of the main design project configuration and the updated vendor configuration (on the Configuration menu, click Compare configurations).
Save the comparison result to a file. The file name must be different from the file name from step 4. On the Actions menu, click Configuration comparison report. We recommend that you save the file in text format for future use.
Compare the files created during steps 4 and 9. If the update is performed correctly, the files will be identical.

Using session parameters

This article describes standards that apply to session parameters. All of the listed recommendations are mandatory unless noted otherwise.

1.1. Session parameters are intended for storing values within a session. We recommend that you intialize the parameters in the session module (see section 2.1 later in this article) and that you use their values in session queries and data access restrictions.
Example session parameters:

CurrentUser. Type: CatalogRef.Users
DataExchangeEnabled. Type: Boolean
ClientWorkstation. Type: CatalogRef.ClientWorkstations

You can access session parameters using 1C:Enterprise script, as in the following example:

CurrentUserValue = SessionParameters.CurrentUser;

In this scenario the current user can read or write the value only if they are granted the corresponding right.

You can also use them in access restrictions, as in the following example:

WHERE Document.User = &CurrentUser

In the latter scenario the current user does not need the right to read the session parameter value.

1.2. We recommend that you do not use session parameters for storing values that are only needed on the client. In the client/server mode 1C:Enterprise stores session parameters on the server, so reading or changing them on the client requires making a server call, which increases the traffic between the server and the client.

We recommend that you use global variables of the managed application module (or the ordinary application module if your application runs in the ordinary mode).

1.3 We recommend that you do not use session parameters for caching calculated values that can be reused by server algorithms. Instead, declare your function in a common server module with reusable return values, except scenarios where the function result calculation time in a module with reusable values is comparable to the cache clearing timeout.

Setting session parameters "on demand"

2.1. Do not initialize session parameters during the application startup because:

during the startup the platform does not read all of the session parameters from the configuration code;
the application algorithms might include explicit deletion of session parameter values using 1C:Enterprise script tools.

The correct method os setting session parameter values is setting them "on demand" in the SessionParametersSetting handler of the session module. In other words, session parameters must be initialized when they are accessed for the first time.

Example of setting session parameters "on demand":

Procedure SetSessionParameters(SessionParametersNames)

If SessionParametersNames = Undefined Then
  // Session parameter initialization at startup (SessionParametersNames = Undefined)
  //
  // Assign values to session parameters that can be initialized at startup

Else
  // Session parameter initialization "on demand"
  //
  // If initialization of multiple session parameters requires accessing
  // the same set of data, initialize all of them at once.
  // To avoid duplicate initializations, names of the initialized
  // session parameters are stored to the InitializedParameters array.
  InitializedParameters = New Array;
  For Each ParameterName FROM SessionParametersNames Do
   SetSessionParameterValue(ParameterName, InitializedParameters);
  EndDo;

EndIf;

EndProcedure

// Set session parameter values and write the names of the initialized parameters
// to the InitializedParameters parameter.
//
// Parameters
// ParameterName - String - name of the session parameter to be initialized.
// InitializedParameters - Array - array that stores names of initialized parameters.
//
Procedure SetSessionParameterValue(Val ParameterName, InitializedParameters)

// If the ParameterName parameter is already initialized in this SetSessionParameters
// call, then return.
If InitializedParameters.Find(ParameterName) <> Undefined Then
  Return;
EndIf;

If ParameterName <> "CurrentUser" Then
   SessionParameters.CurrentUser = <value>;
   SessionParameters.<another session parameter> = <value>;
   InitializedParameters.Add(ParameterName);
   InitializedParameters.Add("<another session parameter>");
EndIf;

EndProcedure

See also:

How the changing of values of session parameters and functional options impacts performance of data access restrictions mechanism

Common module naming rules

This article describes the standards that apply to common module naming. All of the listed recommendations are mandatory unless noted otherwise.

1.1. Common modules are intended for implementation of procedures and functions that have something in common. As a rule, a common module contains procedures and functions belonging to a single subsystem (such as Sales or Purchases), or procedures and functions having similar functionality (such as string operations or general-purpose functionality).

1.2. Select one of the following four contexts for your common modules:

	Common module type	Naming example	Server call	Server	External connection	Client (ordinary application)	Client (managed applicatuion)
1.	Server	CommonUse (or CommonUseServer)		+	+	+
2.	Server, called from client	CommonUseServerCall	+	+
3.	Client	CommonUseClient (or CommonUseGlobal)				+	+
4.	Client/server	CommonUseClientServer		+	+	+	+

2.1. Server common modules contain procedures and functions that cannot be called from the client code. They implement the internal server business logic of the application.
To ensure correct functioning of your configuration in external connection, ordinary, and managed modes, implement server procedures and functions in common modules with the following flags:

Server (clear the Server call check box)
Client (ordinary application)
External connection

This ensures that calling server procedures and functions with parameters of mutable types (such as CatalogObject or DocumentObject) is available. Normally such procedures and functions include:

Event subscription handlers for catalogs, documents, and similar objects whose parameters include mutable values (objects)
Server procedures and functions whose parameters include objects from modules of catalogs, documents, and similar objects, as well as from modules that include event subscription handlers

Use the common metadata object naming rules for server common modules.
Examples: FileOperations, CommonUse

In some cases you can add the Server postfix to avoid naming conflicts with global context properties.
Examples: ScheduledJobsServer, FullTextSearchServer.

2.2. Server common modules called from client contain procedures and functions that can be called from the client code. They form the client programming interface of the applied solution server.
Implement such procedures and functions in modules with the following flag:

Server (select the Server call check box)

Use the common metadata object naming rules for server common modules that are called from server and add the ServerCall postfix.
Example: FileOperationsServerCall

Note that export procedures and functions implemented in such modules must hot have parameters of mutable types (such as CatalogObject or DocumentObject) because they cannot be passed to or from client code.

2.3. Client common modules describe the client business logic (the functionality that is only available on the client). They have the following flags:

Client (managed application)
Client (ordinary application)

The only exception is the scenario where client procedures and functions must be only available in the managed application mode (or ordinary application mode, or external connection mode). In this scenario you can use a different combination of these two flags.

Add the Client postfix to client common module names.
Examples: FileOperationsClient, CommonUseClient.

2.4. In rare cases creating common server modules with procedures and functions that have identical client and server contents is acceptable. Implement such procedures and functions in modules with the following flag:

Client (managed application)
Server (clear the Server call check box)
Client (ordinary application)
External connection

Add the ClientServer postfix to names of such common modules.
Examples: FileOperationsClientServer, CommonUseClientServer.

In general, we recommend that you do not define common modules that are intended for both the server and the client (managed application). We recommend that you implement the functionality available both on the client and on the server in different common modules (see paragraphs 2.1 and 2.3). Separating the server and the client logics improves the applied solution modularity, simplifies developer control over the client/server interaction, and reduces the risk of errors related to essential differences in the requirements to client and server code (such as minimizing the code executed on the client, differences in the object and type availability, and so on). Note that this inevitably increases the total number of modules in your configuration.

Form and command modules are considered a special case of mixed client and server modules, they are intended for implementing server and client logics in a single module.

3.1. Use the common metadata object naming rules for naming common modules. A common module name must be identical to the name of the subsystem or feature whose procedures and functions are implemented in the module. We recommend that you avoid vague words, such as Procedures, Functions, Handlers, Module, or Functionality, except for rare cases when they add accuracy to the description of the module purpose.

We recommend that, in order to distinguish common modules of a single subsystem with different execution contexts, you name them using postfixes as described in paragraphs 2.1-2.4.

3.2. You can use additional postfixes to clarify the module purpose.

3.2.1. Add the Global postfix to global module names. In this case do not add the Client postfix.
Example: FileOperationsGlobal.

2.2. Add the FullRights postfix to names of modules executed in privileged mode (modules that have the Privileged flag).
Example: FileOperationsFullRights.

3.2.3. Add the Cashed or ClientCashed postfix, respectively, to names of server or client modules with reusable return values (values that can be reused during a session).
Example: FileOperationsClientCached.

3.2.4. Add the Overridable or ClientOverridable postfix, respectively, to server and client modules of library configurations (configurations intended not for independent use but for development of other configurations). Such modules contain procedures and functions whose implementations can be modified.
Example: FileOperationsClientOverridable.

See also:

Using functional options

This article describes functional option usage rules. All of the listed recommendations are mandatory unless noted otherwise.

1.1 If your configuration includes optional features, we recommend that you implement functional options that allow enabling or disabling them at the deployment stage. Your infobase must include data for storing functional option values (such as constants).

For example, your configuration includes optional infobase data versioning functionality. To manage the availability of this feature, do the following:

Create the UseVersioning functional option, which defines whether the feature is available in the current infobase.
Create the UseVersioning constant of the Boolean type for storing the functional option value.
In the Data path property of the functional option, specify the UseVersioning constant.

Then link configuration objects to the functional option by including them in its content. If you need to check the feature availability using 1C:Enterprise script, use the GetFunctionalOption method:

VersioningAvailable = GetFunctionalOption("UseVersioning");

So, a set of functional options describes the configuration functionality whose availability can be configured at the deployment stage according to the company needs. The platform modifies the user interface automatically based on the functional option values.

Functional options can affect the business logic. Such scenarios imply using functional options that have not only Boolean type but also other types, such as references to catalogs or enumeration values.

1.2. You can specify feature availability not only for the entire infobase but also depending on the context where the feature is required. For example, the availability of the "charge sales tax" feature can depend on company. To implement this, do the following:

Create the AccountingPolicyChargeSalesTax functional option.
Create the Company functional option parameter (if you have not created it earlier).
Create the AccountingPolicyTaxAccounting information register for storing the functional option values, with the Company dimension and resources required to manage the "charge sales tax" feature.
In the Data path property of the functional option, specify the ChargeSalesTax register resource.
For the Company functional option parameter, in the Use property, specify the Company dimension of the AccountingPolicyTaxAccounting information register.

Then you can set the functional option value depending on the context, as in the following example:

SetFormFunctionalOptionParameters(New Structure("Company", <CompanyName>));

If you need to check the feature availability using 1C:Enterprise script, you can get the functional option value as in the following example:

AccountingPolicyParameters = New Structure("AccountingPolicyCompany", <CompanyName>);
ChargeSalesTax = GetFunctionalOption("AccountingPolicyChargeSalesTax", AccountingPolicyParameters);
SalesTaxDefinitionTime = GetFunctionalOption("AccountingPolicySalesTaxDefinitionTime", AccountingPolicyParameters);

Important! In addition to the described scenario, other functional option usage scenarios are available. For more information, see the 1C:Enterprise documentation.

1.3. Use functional options according to their intended purpose.

Do not use functional options for managing visibility of form controls. Functional options are intended for managing feature availability in the entire configuration, not in a single form (and therefore for managing the form control availability in the entire configuration, not in a single form).
Do not use functional options for optimizing access to infobase data (for storing values on the server). Use modules with reusable return values instead.

Setting and getting functional option values

2.1 The 1C:Enterprise platform does not provide any dedicated features for setting functional option values. You can set their values by assigning values to related constants, catalog items, or information register records.

2.2. If you use functional option parameters and a catalog or information register does not have records linked to the parameter, the functional option is considered disabled. If multiple records are linked to a single parameter, the functional option values are combined using the OR operator.

2.3. If a functional option is linked to a periodic information register resource, the platform uses the "slice last" option for getting the functional option value. To get the functional option value for a different date, you have to specify a value of the Date type for the Period functional option parameter. For example, use the following syntax for a periodic information register with the Company dimension:

SetFormFunctionalOptionParameters(New Structure("Company, Period", <CompanyName>, <Date>));

Note that

The Period parameter value must be converted to the register periodicity value in order to comply with the recommendation described in paragraph 2.5. For example, for a monthly periodicity use:

BegOfMonth(<Date>)

and do not create the Period metadata object because the platform provides this functional option parameter automatically.

2.4. Changing a functional option value does not cause automatic refreshing of the user interface. To refresh the interface, run the RefreshInterface method.

2.5. Functional option values are cached on the server, which might affect the performance. A large cache size can reduce the performance. That is why we do not recommend parameterizing functional options with data that can have a large number of values. For example, do not use contractors or products as functional option parameters. Besides, dependence of feature availability on a contractor does not make sense anyway, in practice developers use dependence on contractor type or other contractor properties. For example, if you configuration includes the ContractorType enumeration, link functional options to this enumeration instead of linking them to the contractor.

Functional option dependencies

3.1 In some scenarios some features should only be available when some other features are available or not available. If your configuration includes such complex dependencies between functional option values, you have to ensure the consistency of data linked to the functional options.

For example, the "move employees between companies" feature (all related documents and reports) should only be available if the "multiple companies" and "human resource management" features are available.

In this scenario all of the metadata objects related to employee movement should not depend on the "multiple companies" and "human resource management" fucntional options. You have to create the "employee movement" functional option and link all metadata objects related to this feature directly to this functional option.

You also have to ensure that the value of this functional option is changed when the values of the "multiple companies" and "human resource management" functional options are changed (for example, when the values of the linked constants are written).

We recommend that you make the values of all three functional options available to the applied solution administator in a settings form. The value of the "employee movement" functional option should be unavailable for editing.

We recommend that you use check box fields for such functional option values, with their titles indentical to the functional option names.

3.2. For mutually exclusive functional options, we recommend that you use radio button fields, input fields with drop-down lists, or other controls that imply selection of a single value from a list. The radio button titles or drop-down list items should be identical to functional option names.

3.3. If the availability of some minor feature depends on multiple functional options in a complicated way and you cannot think of a simple and clear name for it, we recommend that you avoid creating a functional option for this feature. Instead, you can check the availability of form controls on the server based on the functional option values using 1C:Enterprise script.

Functional option parameter limitations

4.1. We recommend that you implement no more than 10 functional option parameters in your configuration due to possible performance issues. To reduce the number of functional options, ensure that you do not create multiple functional option parameters with similar meaning. For example, instead of the following two parameters:

ObjectTypeToBeVersioned, linked to the ObjectType dimension of the ObjectVersioningSettings information register
ObjectTypeWithAdditionalReportsAndDataProcessors, linked to the ObjectType dimension of the AdditionalDataProcessorPurposes information register

we recommend that you create a single ConfigurationObjectType functional option parameter linked to both information register dimensions.

4.2. Use the following generic algorithm for designing the list of functional options and their parameters:

Define which applied solution features can be optional (can have switches for enabling and disabling them).
For each feature, define whether it needs a single switch for the entire infobase or multiple switches (for example, one per company or one per product).
Create the list of all parameterized functional options, as well as the list of their parameters.
Ensure that the list of functional option parameters does not include multiple parameters of a single type (for example, all functional options that depend on company must use a single parameter).
If the total number of functional option parameters is still too big, set parameter priorities based on the number of usage instances and on the importance of parameterized functional options.
Remove the parameters with lower priorities.
For functional options that had their parameters removed, do one of the following:
- Implement them without parameters (so that they affect the entire infobase)
- Remove them (if these features do not make sense when applied to the entire infobase)

As a result, you will end up with a reasonable number of functional option parameters.

See also:

How the changing of values of session parameters and functional options impacts performance of data access restrictions mechanism

Thick client support in managed applications that run in the client/server mode

This article describes the standards that apply to implementation of thick client support in managed applications that run in the client/server mode. All of the listed recommendations are mandatory unless noted otherwise.

1. When you implement the thick client support in managed client/server applications, keep in mind that in this scenario the server code might be executed on the client.

You might need to implement the thick client support in the managed mode because some of the platform features are not available in the thin client.

2. You might need to implement the execution of some server code fragments on the client:

Event handlers in manager modules (ChoiceDataGetProcessing, FormGetProcessing, and so on)
Subscriptions to these manager module events

Enclose the rest of the server code, which is located in the session module, object modules, managed modules, and modules of other metadata objects (except form, command, and common modules), in the following preprocessor instruction:

#If Server Or ThickClientOrdinaryApplication Or ExternalConnection Then
…
#EndIf

To perform a quick configuration integrity check for the scenario where a managed application running in the client/server mode is accessed using a thick client, you can use the configuration check feature.

3. If you need to call server procedures or functions from the client code, implement them in common server modules with the Server call flag. Ensure that values of mutable types (CatalogObject, DocumentObject, and so on) are not passed to the procedure parameters and function return values.

Incorrect example of ChoiceDataGetProcessing event handler:

Procedure ChoiceDataGetProcessing(ChoiceData, Parameters, StandardProcessing)

Interactions.ChoiceDataGetProcessing(ChoiceData, Parameters);
StandardProcessing = False;

EndProcedure

The correct example includes a server call (and no values of mutable types are passed):

Procedure ChoiceDataGetProcessing(ChoiceData, Parameters, StandardProcessing)

InteractionsServerCall.ChoiceDataGetProcessing(ChoiceData, Parameters);
StandardProcessing = False;

EndProcedure

Using common attributes

1. Common attributes are intended for being added to multiple metadata objects (catalogs, documents, registers, and so on). They are intended for solving one of the following tasks:

Data separation (the Data split property is set to Split)
Extending attribute sets of multiple objects (the Data split property is set to Do not use).

2. Common atributes that are not related to data separation are intended for adding functionality that is not a part of applied object business logic (for example, it is intended for solving tasks related to the entire configuration) but requires storing data in applied objects (instead of using other data storages, such as linked registers).

Common attributes are not intended for facilitating addition of identical attributes to different applied objects. For example, moving regular document attributes, such as PersonResponsible, Comment, or Company, to the common attributes branch is incorrect. Also note that common attribute access rights are specified independently of access rights for objects that have these attributes.

3. The order of common attributes that serve as separators in the configuration object tree should be based on the order of setting session parameters related to these attributes.

Metadata object names in configurations

See also: common metadata naming rules.

This article describes metadata object naming rules. All of the listed recommendations are mandatory unless noted otherwise.

No.

Metadata object

Naming rules

Subsystem

Use common metadata naming rules.
Examples: Purchases, Accounting, Settings.

See also:

Restrictions to renaming metadata objects

Business process route map layout recommendations

This article describes the standards that apply to business process route map layouts. All of the listed recommendations are mandatory unless noted otherwise.

Business process layout example:

1. General recommendations

1.1 The recommended business process direction is top-to-bottom. Other directions are allowed if they provide a better description of the business process.

1.2 Use the standard grid, which consists of lines with a 20-pixel step.

1.3 Do not use bold or colored fonts.

1.4 Minimize the number of connector line bends. Use no more than a single bend per line whenever posible (this might require adjusting the sizes and positions of the route points).

1.5 When placing decorations and route points, leave 1-square margins at the left and at the top.

1.6 Make the route point width equal to an even number of squares. This is required to reduce the number of connector line bends. The route point and decoration proportions must be close to matchbox proportions (for example, 3x6 squares). Avoid long and narrow route rectagles because they make route maps harder to read.

1.7 Use the "center" text alignment in route points and decorations, except for comments where the "left" alignment is preferable.

1.8 We recommend that in the print layout the page breaks do not cross decorations and route points (on the Graphical schema menu, click Page view mode).

2. Recommendations for specific graphical schema items

2.1 The Start and End points are 2x2 squares and have no names. The number of start and end points is not limited, it is defined by the business process logic. The recommended gap between a start or end point and another business process point is 2 squares:

2.2 The size of the Activity, Processing, and Subordinate business process points is defined by the text they contain. The text must be a short directive describing the activity, such as "Issue invoice" (not "Issuing invoice"). To the left of such points, place decorations that describe source (incoming) data required to perform the activity. To the right of such points, place decorations that describe resulting (outgoing) data that is generated by the activity.

2.3 Place shapes of incoming documents that are required by route point activities to the left of route points with a 2-square gap and connect them with dotted lines with arrows. Place shapes of outgoing documents that describe the route point activity results to the right of route points with a 2-square gap and connect them with dotted lines with arrows. Use the Document shape for documents.

The proportions of the document decoration should be close to A4 proportions whenever possible (for example, 4x5 squares or 3x4 squares).

2.4 Place comments related to incoming documents to the left of route points with a 2-square gap. Place comments related to outgoing documents to the right of route points with a 2-square gap. Use the Vertical brackets or Horizontal brackets shape and connect it with the left or right border of the route point with a dotted line that does not have an arrow:

2.5 Condition points include a short question ending with a question mark. The wording should presume only Yes and No answers (for example, Is invoice available?, Is shipping allowed?, OK?). Make condition points as compact as possible but ensure that the scheme remains clear. This recommendation is based on the fact that condition points are transition points, they are less important than activity points. Condition connector lines, both incoming and outgoing, must be at least 2 squares long to ensure that the Yes and No words fit:

User settings

1.1. Use the common settings storage for storing personal user settings. For example, reading and writing of the setting "Confirmation is required upon exiting the application" is implemented in 1C:Enterprise script using the CommonSettingsStorage object:

SettingValue = CommonSettingsStorage.Load("ApplicationSettings", "DisplayExitConfirmation");
CommonSettingsStorage.Save("ApplicationSettings", "DisplayExitConfirmation", SettingValue);

Do not use any other methods for storing user settings. For example, do not use metadata objects (registers, attributes, catalog tabular sections, and so on) or external files.

1.2. To access user settings, a user must have the Saving user data right.

See also: Standard roles

1.3. To access a setting in a common settings storage, use the unique setting key. For example, the default company and the default warehouse for a specific user are different settings that have the DefaultCompany and DefaultWarehouse keys.

At the same time, you can combine some settings into a structure, array, or mapping, provided that they are always accessed together as a whole. For example, proxy server parameters include multiple values (server address, user name, and password), which are stored in a structure (in a single setting).

2.1. The configuration must include a single place for editing all of the user settings. Normally, it is a common user settings form.

You can see a personal settings form implementation example in the 1C:Subsustems Library demo.

2.2. The user settings form might not be the only place for editing the settings. For user convenience fields with individual settings can be added to the forms affected by the settings. For example, the Do not show file editing tooltips check box can be located in the form that displays those tooltips.

2.3. The user settings form, other forms that contain the settings, and individual form items that contains the settings must be only available to the users with the Saving user data right.

See also: Standard roles

3.1. When using the common settings storage, remember that the settings are node-specific and they are not synchronized between nodes. You can implement the synchronization using 1C:Enterprise script.

3.2. All of the settings in the common settings storage are tied to specific users (to user name strings). When a user is renamed, its settings are lost. If a new user whose name matches a previously available user name is created, the new user inherits their settings. To avoid this, implement the settings migration when users are renamed, and implement the settings deletion when users are deleted.

If your configuration includes 1C:Subsystems Library, you have the handlers for saving and deleting infobase users where you can implement the settings migration and deletion (see the OnWriteInfoBaseUser and AfterInfoBaseUserDelete procedures in the UsersOverridable common module). An example is available in the 1C:Subsystems Libtary demo.

Time zone differences

This article describes the standards that apply to applied solution that can run in different time zones. All of the listed recommendations are mandatory unless noted otherwise.

1. Configurations must support scenarios where the server time zone is different from the user time zone. For example, users in a Denver company access a server located in Boston and all system operations must be recorded in the local (Denver) time.

This scenario is often required in client/server infobases and in SaaS applied solutions.

2.1. Do not use the CurrentDate function, which returns the server date and time, in server procedures and functions. Use the CurrentSessionDate function instead, which converts the server time to the user session time.

2.2. When you need a universal time value that does not depend on the user time zone, use the ToUniversalTime function. For example, you might need this for defining the cache overflow time or getting the time when a scheduled job was last executed.

2.3. When using platform methods that return the local server date, convert it either to the universal time or the the user session time, as in the following example:

UpdateDateUniversal = ToUniversalTime(FullTextSearch.UpdateDate());
UpdateDate = ToLocalTime(UpdateDateUniversal, SessionTimeZone());

3.1. Do not use the CurrentDate function in the client code. This is required because the current time calculated in the client code must be identical to the current time calculated in the server code.

For example, a server is located in New York and users access it from Chicago. The CurrentDate function returns 10:00 on the client and 11:00 on the server. At the same time the CurrentSessionDate function returns 10:00 on the server, provided that the Chicago time is set in the infobase (using the SetInfoBaseTimeZone method).

Normally, instead of calling the CurrentDate function on the client you have to:

pass the date and time converted to the user session time zone from the server to the client;
for document operations on the client, use the document date.

The following examples illustrate some typical scenarios.

3.2. In a month closing algorithm a date is passed from the client to the server. This date defines which month is closed.

Incorrect:

&AtClient
Procedure CommandOpenMonthClosing(Command)
CurrentData = Items.List.CurrentData;
If CurrentData = Undefined Then
CurDate = CurrentDate(); // calling CurrentDate() on the client
Else
CurDate = CurrentData.Date;
EndIf;
FormParameters = New Structure;
FormParameters.Insert("RegistrationPeriod", CurDate);
OpenForm("DataProcessor.MonthClosing.Form.Form", FormParameters, ThisObject);
…

and then in the data processor form:

&AtServer
Procedure OnCreateAtServer(Cancel, StandardProcessing)
FillPropertyValues(Object, Parameters);
If Not ValueIsFilled(Object.RegistrationPeriod) Then
Object.RegistrationPeriod = BegOfMonth(CurrentDate());
EndIf;
…

Correct (the current date is retrieved on the server):

&AtClient
Procedure CommandOpenMonthClosing(Command)
CurrentData = Items.List.CurrentData;
  If CurrentData = Undefined Then
  CurDate = Undefined; // CurrentDate() is not called on the client
Else
  CurDate = CurrentData.Date;
EndIf;
FormParameters = New Structure;
FormParameters.Insert("RegistrationPeriod", CurDate);
OpenForm("DataProcessor.MonthClosing.Form.Form", FormParameters, ThisObject);
…

and use the CurrentSessionDate function in the data processor form:

3.3. During document operations, consider using the document date instead of the current date.

In the following example the calculation date, which is used for displaying prices and balances as of this date, is passed to the tabular section of the product list filling form.

Incorrect:

&AtClient
Procedure FillProducts(Command)
FillParameters = New Structure;
CalculationDate = ?(BegOfDay(Object.Date) = BegOfDay(CurrentDate()),
Undefined, Object.Date); // CurrentDate() is called on the client
FillParameters.Insert("CalculationDate", CalculationDate);
...
OpenForm("DataProcessor.ProductFilling.Form.Form", FillParameters,
ThisObject, UUID);
…

The correct method is passing the document date to the server and calculate the calculation date on the server:

&AtClient
Procedure FillProducts(Command)
FillParameters = New Structure;
FillParameters.Insert("CalculationDate", Object.Date);
...
OpenForm("DataProcessor.ProductFilling.Form.Form", FillParameters,
ThisObject, UUID);

Another example. When the list of sales orders that can be closed by a sales invoice is filled, the "document date is less or equal to the date passed to the form" filter is set in the form where the list is filled.

Incorrect:

&AtClient
Procedure OrderClosingStartOrderDocumentSelection(Item, ChoiceData, StandardProcessing)
StandardProcessing = False;
FormParameters = New Structure;
FormParameters.Insert("EndOfPeriod",
?(ValueIsFilled(Parameters.Key), Object.Date - 1, EndOfDay(CurrentDate()))); // CurrentDate() is called on the client
...
OpenForm("Document.SalesOrder.ChoiceForm",
FormParameters, Item);
...

The correct method is calculating the EndOfPeriod parameter by document date:

&AtClient
Procedure OrderClosingStartOrderDocumentSelection(Item, ChoiceData, StandardProcessing)
StandardProcessing = False;
  FormParameters = New Structure;
  FormParameters.Insert("EndOfPeriod", ?(ValueIsFilled(Parameters.Key),
  Object.Date - 1, EndOfDay(Object.Date)));
...
  OpenForm("Document.SalesOrder.ChoiceForm", FormParameters, Item);

4. Exceptions from rules described in paragraphs 2 and 3 are allowed in rare specific cases when you actually need to use the current server time. Explain each exception in the comments to the function call.

5. Avoid multiple calls of CurrentSessionDate or CurrentDate in a single procedure or function because they will return different values.

Incorrect:

LastNotificationDate = CurrentSessionDate();
NextNotificationDate = CalculateDate() + CurrentSessionDate();

The correct method is using the previously calculated date and time:

LastNotificationDate = CurrentSessionDate();
NextNotificationDate = CalculateDate() + LastNotificationDate;

Configuration initialization

This article is applicable to: managed application, mobile application, ordinary application.

This article describes the standards that apply to the actions performed during the first start of a configuration. All of the listed recommendations are mandatory unless noted otherwise.

1. The configuration must include a check whether it is started for the first time (if true, the infobase is empty and must be filled with the required minumum of data). It must also include a check whether a new release is started for the first time (if true, required infobase data updates must be executed).

If your configuration includes 1C:Subsystems Library, implement the checks using the "Infobase version update" subsystem.

If your configuration does not include 1C:Subsystems Library, follow the recommendations provided below.

This recommendation is optional

2. The initial infobase filling can be split into mandatory and optional parts. The mandatory part is required for the configuration functioning, while the optional part is not required but streamlines the first steps with the product.

3. Once the infobase processing during the first start of a configuration (or a new configuration release) is complete, we recommend that you display the configuration desciption or the change log to the administrator.

4. The configuration must control situations where the processing is not fully complete. If this is the case, a warning must be displayed to a user. For recording details of performed operations and errors that occurred during the processing, use the event log.

5. If the configuration is intended to run in distributed infobase mode, implement the infobase data update logic in subordinate nodes as follows:

update the subordinate node data after loading updated data from the main node;
exclude repeated processing and especially repeated creation of a single piece of data. In other words, ensure correct operation of the infobase processing during its second run.

Otherwise:

in the event of unconditional data creation during the subordinate node update, this data is created in each node and duplicated many times during the next exchange;
in the event of unconditional data change during the subordinate node update, the changed data is exported back to the main node, which provides additional load to the communication link between the nodes.

Incorrect:

ProfileObject = Catalogs.AccessGroupProfiles.CreateItem();
ProfileObject.Description = NStr("en = 'Accountant'");
ProfileObject.Predefined = True;
ProfileObject.Write();

Correct:

ProfileDescription = Nstr("en = 'Accountant'");
Query = New Query(
"SELECT
| TRUE
|FROM
| Catalog.AccessGroupProfiles AS AccessGroupProfiles
|WHERE
| AccessGroupProfiles.Description = &Description AND
| AccessGroupProfiles.Predefined = TRUE");
Query.SetParameter("Description", ProfileDescription);
// If the item is not found, create it.
If Query.Execute().IsEmpty() Then
  ProfileObject = Catalogs.AccessGroupProfiles.CreateItem();
  ProfileObject.Description = ProfileDescription;
  ProfileObject.Predefined = True;
  ProfileObject.Write();
EndIf;

Using defined types

This article describes the standards that apply to defined types. All of the listed recommendations are mandatory unless noted otherwise.

1. Defined types are intended for defining data types that describe frequently used entities or have high chances to be modified during the applied solution deployment. You can use the type or the set of types described by a defined type in multiple configuration parts (in attributes, object properties, forms, and so on).

See also the "Defined types" section of the "Configuration objects" chapter of 1C:Enterprise Developer Guide.

2. We recommend that you use defined types in the following scenarios:

2.1. Defining a simple type and its qualifiers when the type describes an applied entity and is used in various attributes, resources, form attributes, templates, and so on within a single subsystem or in the entire applied solution. This guarantees uniform data length and precision in all data usage instances, as well as simplifies development in the event of requirement changes.

Examples:

EAN13. String, 13. Describes the barcode format in various documents: Shipment, GoodsReceipt, SalesInvoice, Bill, and more.
ZIP code. String, length: 5. The ZIP code that is used in the GoodsReceipt and WarehouseTransfer documents, in the SalesHelper data processor, in the ReturnAddress attribute of the GoodsReturn document, and more.

2.2. Defining a composite type that is widely used in objects of a single subsystem or in the entire applied solution. This guarantees uniform data content (type) in all data usage instances, as well as simplifies development and deployment.

For example, the configuration includes the Interactions subsystem, which is intended for processing email and recording calls and meetings. During the deployment of the subsystem the developer determines the metadata object types that can serve as contacts: items of the Individuals, Partners, and PartnerContacts catalogs. Then the developer creates the InteractionContact defined type, which includes all these types and belongs to the subsystem. This defined type is widely used in the attributes of objects and forms included in the subsystem: the Attendees tabular section of the Meeting and PlannedInteraction documents, the To tabular section of the TextMessage document, the Caller attrinbute of the Call document, the ContactsByCategory attribute of the AddressBook and ContactSelection common forms, the InteractionHierarchyContact template parameter of the Interactions document journal, and more. If the InteractionContact defined type had not been created, this would require disabling support for all of the listed objects and correcting the type content manually in each object.

2.3. In the development of a subsystem that is intended for building into a configuration: defining a type that can be redefeined at the deployment stage.
For example, the Vendors type might be changed to the Counterparties type during the deployment.

3. Do not use defined types for creating "aliases" of available types, for substitution of entities, for a single usage in a single subsystem or configuration that is not intended for building into other configurations, despite the fact that it might simplify future development. In fact, the need to do any of these usually indicates that the applied solution has design errors or the initial type name is methodologically incorrect.

For example, a configuration includes the Counterparty catalog that is referenced from several information registers, form attributes, and other configuration objects. But the catalog is not a part of a subsystem intended for building into other configurations, nor it is an applied entity that can be expanded with other types. In this scenario you do not need an additional composite defined type that consists of the single Counterparties type "just in case" of possible future optimizations because this obscures the applied meaning of the entity.

Specifics of configuration development for Linux

This article describes standards that apply to configuration development for Linux. All of the listed recommendations are mandatory unless noted otherwise.

1. In most scenarios you do not need additional development efforts to ensure that your configuration (the client application and the server) can run on Linux. This article contains recommendations for specific scenarios described in the "System behavior in various modes" appendix of 1C:Enterprise Developer Guide.

2. During the implementation of the key applied solution features, use the cross-platform development capabilities available in the 1C:Enterprise platform.

2.1. Instead of Windows COM technology (COMObject object), use the following cross-platform technologies:

For administering the 1C:Enterprise server cluster, instead of managing the server object model using the v83.ComConnector COM object, use the administration server (ras) and the administration utility (rac).
For getting directory paths, instead of Windows COM objects, use the following global context methods: UserDataWorkDir, DocumentsDir, and TempFilesDir.

In other scenarios consider using other alternatives to the COM technology, such as the NativeAPI add-in development technology.

2.2. Use the Native API technology for the development of add-ins (both client and server ones) delivered with the configuration. With this technology you can create add-ins for Windows and Linux operating system families, as well as for the web client, which can run in browsers supported by 1C:Enterprise.

An add-in must include executable files (.so) for 32-bit and 64-bit Linux versions. For more information on add-in development, see the "Add-ins" chapter of 1C:Enterprise Developer Guide.

2.3. Instead of using the Mail object, consider the following:

Use the InternetMail object
Develop Linux add-ins that support the mail clients available on Linux.

2.4. The appearance of the HTMLDocumentField control might vary depending on the operating system: Windows or Linux. This is because the Linux version of this control is based on the WebKit library, while the Windows version is Internet Explorer-based.

Note that the appearance and the object model of the HTML document (DOM model), which can be accessed using the HTMLDocumentField.Document property, might differ on Linux and in Windows client applications:

Use only standard DOM model elements that are available in all operation modes.
Use the web development standards for HTML content generation and do not use browser-specific methods and properties.

Incorrect:

Elements.HTMLField.Document.execCommand("SaveAs");

because some browsers do not support the SaveAs command (see http://help.dottoro.com/larpvnhw.php).

Correct:

TempStorageAddress = GetTemplate(...);
GetFile(TempStorageAddress, "Manual.html");

2.5. If your configuration includes pictures in WMF or EMF format (Windows metafiles), replace them with raster pictures, such as PNG or JPG.

2.6. Use the cross-platform development capabilities related to the file system operations:

2.6.1. Since the file names in Linux are case-sensitive, use the same case in all file name (or path) usage instances.

2.6.2. Do not specify file path separators and the file mask manually (i.e. "/" or "*.*"). Use the GetPathSeparator and GetAllFilesMask functions instead.

If your configuration includes 1C:Subsystems Library, use the CommonUseClientServer module functions for file name operations.

3. You can disable less important (service) features of your applied solution on Linux. For applied solutions that automates sales, examples of less important features are synchronizaton with other applications using direct connection and importing email from third-party clients.

Implement this by hiding the controls related to these features from the Linux user interface. If there is no way to hide them, ensure that a message like "<Operation> is not available on Linux" is displayed.

Example:

&AtClient
Procedure CommandProcessing(CommandParameter, CommandExecutionParameters)
    Info = New SystemInfo;
    If Info.PlatformType = PlatformType.Linux_x86 Or Info.PlatformType = PlatformType.Linux_x86_64 Then
        ShowMessageBox(, NStr("en = 'Cannot print to Microsoft Word on Linux.'"));
        Return;
    EndIf;

    <...>
EndProcedure

See also:

General requirements to configurations
"Specifics of cross-platform applied solution development" chapter of 1C:Enterprise Developer Guide.

Restrictions to renaming metadata objects

This article describes standards that apply to renaming metadata objects. All of the listed recommendations are mandatory unless noted otherwise.

1. Renaming a common module and then creating another module with its old name is not allowed. Instead, create a module with a new name and move the script from the old module to the new one.

If you do not follow this recommendation, you might encounter configuration comparison and merging issues. For example, event subscriptions that refer to a common module will be linked by name to the new common module (which does not contain the required procedures) instead of the renamed one.

2. In some scenarios, when you change metadata structure, you might want to delete a metadata object and create a new one with the same name. An example of such scenario is reducing the number of register dimensions. We recommend that you rename the obsolete metadata object by adding the Delete prefix.

If you do not follow this recommendation, this might cause some issues during the update of a supported configuration. If the obsolete object was changed in the customer configuration without canceling the support (for example, they redefined the object behavior or fixed some bugs), the obsolete object is not deleted during the configuration merging and the update cannot be successfully completed because two objects have identical names.

See also: Deleting obsolete metadata objects from configurations

This recommendation is optional

3. If you need to store refecences to metadata objects in your configuration, we recommend the following:

3.1. If your configuration does not use 1C:Subsystems Library, use string attributes (String, 255) for storing full metadata object names. For example, the DocumentGenerationParameterTypeFullName attribute of the MessageTemplates catalog, the ObjectType dimension of the ObjectPrintSettings information register, and so on.

If you rename or delete some configuration objects, ensure that the stored names are renamed or deleted during the infobase update. Otherwise you will have broken links to metadata objects, which will lead to various issues within subsystems that rely on metadata object names.

3.2. If your configuration uses 1C:Subsystems Library, use references to the MetadataObjectIDs catalog, which:

stores all references to metadata object names, handles adding, renaming, and deleting metadata objects, and elininates the need of bulk name replacements in tables;
reduces the table record size (references instead of 255-character strings), which improves the performance.

The only exception is renaming of roles and subsystems, which is not handled automatically, so you have to handle this manually.

If you do not describe the renaming rules, this will result in broken links in the MetadataObjectIDs catalog (old catalog items will be marked for deletion and new ones created), which will lead to various issues within subsystems that rely on metadata object names stored in the catalog, for example:

report options related to the renamed subsystem will disappear from the report list;
additonal reports and data processors displayed in the section linked to the renamed subsytem will disappear from the list;
renamed roles specifed in the access group profiles will not be assigned to users.

3.3. The MetadataObjectIDs catalog is not intended for storing references to metadata objects belonging to other configurations (for example, they might appear if you are implementing integration with other systems). Instead, use string attributes and implement algorithms for keeping their values up-to-date.

3.4. If several configuration branches are in development (for example, you are simultaneously developing versions 2.0 and 3.0, or you are developing patches together with the new releases), consider the following: renaming an object an then creating a new object with the same name, as well as double renaming, is not allowed in the current configuration version and earlier versions. You can only rename objects in this manner in the latest version (3.0 in this example).

Otherwise during the upgrade from an earlier version to the latest one such objects will be renamed twice, which breaks the links to the metadata objects.

If you use references to the MetadataObjectIDs catalog of 1C:Subsystems Library, this restriction only applies to roles and subsystems.

Using subsystems

This article describes subsystem usage standards. All of the listed recommendations are optonal.

1.1. Subsystems are intended for solving the following methodical tasks:

Generate the command interface of the main application window, which provides an overview of the application functionality
Group metadata objects by functionality to streamline the development

In a simple scenario the configuration subsystem structure can satisfy both requirements.

For example, the Sales and Purchases sections, which represent command interface sections available to users, can also be used during the development for quick filtering in Designer mode metadata objects window, for moving objects to other configurations, for narrowing the search area when performing global configuration search, and so on.

Such subsystems should have the Include in command interface check box selected.

1.2. In general, a subsystem that logically groups a set of metadata objects might not have an exact match among the application sections. If this is the case, we recommend that you specify a separate subsystem hierarchy for logical grouping of metadata objects. These subsystems should not be included in the command interface (should have the Include in command interface check box cleared).

Examples:

The Products catalog logically belongs to the Lists subsystem but it is available in two command interface sections: Lists and Marketing.
The Administration command inteface section includes commands that open lists of objects logically related to various "functional" subsystems where customization by adiministrators is available.

1.3. We recommend that you include modules, sceduled jobs, constants, event subscriptions, and other objects that do not have visual presentations to "functional" subsystems only.

<< Prev Next >>