Global configuration version

Scope: managed applications, mobile applications, and ordinary applications.

Applicable to localizable configurations and embedded libraries used for creating applications for different countries and regions.

To simplify the work of localization specialists during the initial configuration localization and further updates, it is important to release a global configuration version. The recommended approach is to develop localizable configuration versions based on the global version.

All guidelines in the Localization requirements section equally apply to both configuration versions. Localized versions can also be released with a multilingual interface. For example, the Turkish edition of Drive includes an English interface so that foreigners can work in the same infobase as Turkish-speaking users.

To prepare a global configuration version, follow these steps:

1. Identify local specifics in the application code and forms as separate metadata objects. Do not include them in the global version.

Incorrect:

Correct:

1.1. Keep locally specific attributes in the objects but ensure that the configuration remains operational in case they are deleted.

1.2. For object forms where only some items are locally specific, place such items into a separate form.
For example:

1.3. Some algorithms, such as the import of exchange rates, can also be locally specific. Identify them as separate metadata objects.

1.4. In case a subsystem or an object is mostly international but requires some local adjustments, create common modules with the Localization postfix. In algorithms where behavior needs to be supplemented or redefined, provide the required calls to these modules. In the global version, modules with the Localization postfix must not contain any applied code.

For example, if you have a global month-end closing functionality but need to supplement the list of stages with locally-specific ones, use the following approach.

Add the MonthEndClosingLocalization common module to your configuration. In the MonthEndClosing.AddMonthClosingStages procedure, call the corresponding method of the MonthEndClosingLocalization module. In this case, the MonthEndClosingLocalization common module of the global version will contain only the definition of the AddMonthClosingStages method.

1.5. If most of the subsystem is specific to a particular country or region, consider designating the entire subsystem as locally specific. For example, the "Declension tool" subsystem is entirely country-specific.

1.6. List locally specific metadata objects in the LocalizableObjects<...>.txt file. Include this file in the standard configuration distribution package.

The LocalizableObjects<...>.txt file contains metadata object names as returned by the MetadataObject.FullName() function. Place each object name on a new line. If necessary, add comments as in the configuration code.

Example:

// Banks.

DataProcessor.ImportBankClassifier

ScheduledJob.ImportBankClassifier

Catalog.BankClassifier.Attribute.TIN

// Currencies.

DataProcessor.ImportCurrencyRates

ScheduledJob.ImportCurrencyRates

2. Ensure that meeting the first requirement does not have a negative impact on the usability of the user interface. If moving part of the form to separate forms significantly impairs form usability, consider designating the entire form as locally specific.

3. In procedures of overridable modules, place only calls to configuration procedures that contain the application code. This approach makes it easier to develop overridable modules during localization.

Incorrect:

// The ReportsOptionsOverridable module.

Procedure DefineSectionsWithReportOptions(Sections) Export

Sections.Add(ReportsOptionsClientServer.HomePageID(),

NStr("en = 'Main'"));

Sections.Add(Metadata.Subsystems.CRMAndMarketing,

NStr("en = 'CRM and marketing reports'"));

Sections.Add(Metadata.Subsystems.Purchases,

NStr("en= 'Purchasing reports'"));

Sections.Add(Metadata.Subsystems.CashFlow,

NStr("en= 'Cash flow reports'"));

Sections.Add(Metadata.Subsystems.Sales,

NStr("en= 'Sales reports'"));

Sections.Add(Metadata.Subsystems.Warehouse,

NStr("en= 'Warehouse reports'"));

Sections.Add(Metadata.Subsystems.FinancialResultAndControlling,

NStr("en= 'Financial result reports'"));

EndProcedure

Correct:

// The ReportsOptionsOverridable module.

Procedure DefineSectionsWithReportOptions(Sections) Export

ReportOptionsTM.DefineSectionsWithReportOptions(Sections);

EndProcedure

// The ReportOptionsTM module.

Procedure DefineSectionsWithReportOptions(Sections) Export

Sections.Add(ReportsOptionsClientServer.HomePageID(),

NStr("en = 'Main'"));

Sections.Add(Metadata.Subsystems.CRMAndMarketing,

NStr("en = 'CRM and marketing reports'"));

Sections.Add(Metadata.Subsystems.Purchases,

NStr("en= 'Purchasing reports'"));

Sections.Add(Metadata.Subsystems.CashFlow,

NStr("en= 'Cash flow reports'"));

Sections.Add(Metadata.Subsystems.Sales,

NStr("en= 'Sales reports'"));

Sections.Add(Metadata.Subsystems.Warehouse,

NStr("en= 'Warehouse reports'"));

Sections.Add(Metadata.Subsystems.FinancialResultAndControlling,

NStr("en= 'Financial result reports'"));

EndProcedure

4. Ensure the global configuration functions properly.

5. Release the global and national configuration versions simultaneously. Consider using one of the following development approaches:

a. Develop the national version in a single repository. Automatically create a global version from the national version when building a distribution. When doing so, delete metadata objects with national specifics and remove code inside procedures of common modules with the Localization postfix.

b. Develop the national and global versions in two repositories. Set up the national version to be supported by the global version and add metadata objects with national specifics. Implement the required logic in the objects and modules with the Localization postfix.

Localization specialists are advised to develop localizable versions based on the global version. To do this:

Set up the localizable version to be supported by the global version.
Add objects listed in the LocalizableObjects<...>.txt file to the configuration.
Implement local specifics in procedures of common modules with the Localization postfix.

If a localizable version is developed based on the national version, follow these steps:

Set up the localizable version to be supported by the national version.
Disable support for objects listed in the LocalizableObjects<...>.txt file and localize them.
Disable support for algorithms in common modules with the Localization postfix and localize them.

To simplify the preparation of the global configuration distribution package, use the merge settings file.

See also: