1C:Standard Subsystems Library 3.1. What’s new in versions

Version 3.1.11

Version 3.1.10

Version 3.1.9

Version 3.1.8

Version 3.1.7

Version 3.1.6

Version 3.1.5

Version 3.1.4

Version 3.1.3

Version 3.1.2

Version 3.1.1

Version 3.1.11

Version 3.1.11 is a development of version 3.1 of 1C:Standard Subsystems Library (SSL). This SSL version requires 1C:Enterprise v.8.3.24 or later running in the Version 8.3.24 - Version 8.3.27 compatibility modes. For a complete list of new features, see sections What’s new in version 3.1.11 and What’s new for developers. Developers will also find an upgrade guide in section Migrating from version 3.1.10 to version 3.1.11 with mandatory steps for migration.

Developing configurations on 1C:Enterprise versions later than 8.3.27 may result in some bugs or limitations, as the current library version may not be able to handle certain new features. For example, introducing a new type of metadata object into the configuration could cause the library’s algorithms, which are not designed to handle such changes, to fail. In addition, it is recommended that configuration extensions with compatibility modes higher than 8.3.27 not be developed or attached to configurations based on this version of the library. Instead, use the next version of the library that is specifically designed to handle the new compatibility modes and features of the 1C:Enterprise platform.

What’s new in version 3.1.11

Core

Contact information

Data exchange

Conversations

Scheduled jobs

Access management

Message templates

Digital signature

What’s new for developers in version 3.1.11

Core

Try
    DownloadFile(...);
Except
    ErrorInfo = ErrorInfo();
    Refinement = CommonClientServer.ExceptionClarification(ErrorInfo,
       NStr("en = 'Cannot download the file:'"));
    Refinement.Text = Refinement.Text + Chars.LF + NStr("en = 'Possible reasons:
       | • No Internet connection.
       | • Problems on the web node.
       | • Firewall or another middleware (antivirus software, etc.) locks attempts to connect to the Internet.
       | • Internet connection is established through a proxy server, but its parameters are not specified in the application.'");
    ForAdministrator = InternetConnectionDiagnostics(); // Detailed error presentation for the event log.
    Raise(Refinement.Text, Refinement.Category,, ForAdministrator, ErrorInfo);
EndTry;
Try
    RunUpdate();
Except
    If CommonClientServer.IsExceptionWithErrorCode(ErrorInfo(),
            "StandardSubsystems.Core.ConfigurationModifiedDynamically
            |StandardSubsystems.Core.ExtensionsModifiedDynamically") Then
        RestartBackgroundJob();
        Return;
    EndIf;
    Raise;
EndTry;

Report options

Add-ins

Contact information

Data integrity

National language support

Data exchange

Infobase version update

Network download

Licensed update verification

File management

Properties

Access management

Source document tracking

Digital signature

Migrating from version 3.1.10 to version 3.1.11

Mandatory steps

In this section, you can read about additional migration instructions for each subsystem that you need to perform in Designer after comparison and merging. See Chapter 2 in the Library integration guide.

To update the following overridable and localizable common modules, copy the new export procedures from the library distribution package and delete the obsolete ones. Also, make sure that comments, the number of parameters, and the parameter names of each procedure match their library equivalents:

Modified localizable common modules:

For recommendations on how to use the new features of overridable and localizable common modules, see What’s new for developers above.

Using the API makes it easier to update to new library versions without having to revise the application code. In this section, you can read about the necessary instructions for the rare cases when such compatibility is not provided and you need to customize the configuration for a new library API. However, the section does not describe changes in internal library procedures and functions that are not related to the API even if these are export procedures and functions. When you call these functions and procedures from the configuration, note that they can be changed, moved, or deleted in the next library version as they represent its internal implementation.

Core
Banks
Data exchange
Configuration update
Totals and aggregates
Scheduled jobs
Source document tracking
Digital signature

Optional steps

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Core
Business processes and tasks
Add-ins
Period-end closing dates
Additional reports and data processors

Contact information

File management
Source document tracking
Digital signature

Migrating from earlier versions to version 3.1.11

When migrating from earlier library versions to version 3.1.11:

Migrating to patch releases 3.1.11

Patch releases of the library differ only in the fourth number of the full version number, for example: 3.1.11.1, 3.1.11.20, 3.1.11.300, and so on. To update to patch releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will save you a lot of time during regular (for example, weekly) updates.

Run the data processor in an infobase with a configuration that contains the previous library release, specify the CF distribution file for the new library version, and click Update to hotfix version. This automatically compares and merges the previous and new library configurations according to the settings described in the documentation. All built-in library objects will be copied, and objects overridden during integration will be merged prioritizing new vendor configuration (for example, type collections) or skipped (for example, overridable modules). The database configuration is not updated automatically after comparison and merging. So, you can compare new data with the database configuration and make changes to the modified objects: overridable modules, various local fixes, and enhancements.

Another option is to generate a comparison and merging settings file by clicking Generate settings file. After that, you can open this file in Designer to compare and merge configurations manually.

After you have compared and merged the configurations, we strongly recommend that you use the SSL integration check tool distributed with the library as an external report SSLImplementationCheck.erf.

Version 3.1.10

This SSL version requires 1C:Enterprise v.8.3.21 or later running in the Version 8.3.21, Version 8.3.22, Version 8.3.23 and Version 8.3.24 compatibility modes.

The subsystem Event log analysis was renamed into User monitoring, and the following features were added: - With Data access log, you can track what data a user viewed. To enable the feature, configure the logging of the Access.Access event in Administration > Users and rights settings > Data access audit. - To track the changes in the setting, the event Data access audit.Change event logging settings was introduced, containing data as XML. - New event log reports were added, which enhance your analytical insights. Besides user activity, error monitoring, and scheduled job duration, you can now generate the following reports: Department activity, User account change history, Changes in user group membership, Changes in access group membership, Changes in allowed access group values, and Changes in profile roles.

Below are the updates related to other subsystems.

New features and updates introduced in SSL v.3.1.10

Core

Bulk edit

National language support

User reminders

Conversations

Users

File management

Access management

Message templates

Digital signature

What’s new for developers in version 3.1.10

Core

Currencies

Calendar schedules

Contact information

To identify and fix issues, use the latest report version.

User monitoring

National language support

User reminders

Infobase version update

Configuration update

Attachable commands

Duplicate cleaner

Network download

Example:

Procedure PrintDocumentsOnCreateAtServer(Form, Cancel, StandardProcessing) Export
  FormCommand = Form.Commands.Add("MyCustomSendCommand");
  FormCommand.Action = "Attachable_ExecuteCommand";
  FormCommand.Title = NStr("en = 'Custom send command'");
  FormButton = Form.Items.Add(FormCommand.Name, Type("FormButton"), Form.Items.SubmenuSend);
  FormButton.Kind = FormButtonType.CommandBarButton;
  FormButton.CommandName = FormCommand.Name;
EndProcedure

Users

File management

Email management

Message templates

Digital signature

Migrating from version 3.1.9 to version 3.1.10

Mandatory steps

In this section, you can find additional migration instructions for each subsystem. Follow these instructions after comparison and merging (see Chapter 2 of the Library integration guide) (in Russian).

To update the following overridable and localizable common modules, copy the new export procedures from the library distribution package and delete the obsolete ones. Also, make sure that comments, the number of parameters, and the parameter names of each procedure match their library equivalents:

For recommendations on how to use the new features of overridable and localizable common modules, see What’s new for developers above.

Using the API makes it easier to update to new library versions without having to revise the application code. For the rare cases when such compatibility is not ensured, and you need to adjust the application for the new library API, this section provides instructions. However, changes to internal library procedures and functions (even if they are export ones) that are not part of the API are not documented. If you call these procedures and functions directly from the application, be aware that they can be changed, moved, or deleted in future versions of the library, as they represent its internal implementation.

Once the migration is complete, we recommend that you use the SSL integration check tool distributed with the library as an external report SSLImplementationCheck.erf.

Core
Notes
User monitoring
Application settings
User reminders
Users
File management
Access management
Message templates

Optional steps

The actions listed below are not required for migration, but we recommend that you perform them in the future.

Core
Additional reports and data processors
Banks
Contact information
User reminders
Infobase version update
Configuration update
Users
Properties

Migrating from earlier versions to version 3.1.10

When migrating from earlier library versions (up to 3.1.10):

Migrating to patch releases 3.1.10

Patch releases of the library differ only in the fourth digit of the full version number, for example: 3.1.10.1, 3.1.10.20, 3.1.10.300, and so on. To update to patch releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will significantly save your time during regular (for example, weekly) updates.

Run the data processor in an infobase with a configuration that contains the previous library release, specify the CF distribution file for the new library version, and click Update to hotfix version. This automatically compares and merges the previous and the new library configurations according to the settings described in the documentation. All built-in library objects will be copied, and objects overridden during integration will be merged prioritizing new vendor configuration (for example, type collections) or skipped (for example, overridable modules). The database configuration is not updated automatically after comparison and merging. So, you can compare new data with the database configuration and make changes to the modified objects: overridable modules, various local fixes, and enhancements.

Another option is to generate a comparison and merging settings file by clicking Generate settings file. After that, you can open this file in Designer to compare and merge configurations manually.

After you have compared and merged the configurations, we strongly recommend that you use the SSL integration check tool distributed with the library as an external report SSLImplementationCheck.erf.

Migrating from version 3.1.10.357 and earlier

Additional reports and data processors

The process for managing settings stored in the SettingsStorage attribute of the AdditionalReportsAndDataProcessors catalog has been updated. To save and retrieve these settings, use the ShouldSaveSettings and LoadSettings procedures from the `AdditionalReportsAndDataProcessors common module.

Migrating from version 3.1.10.344 and earlier

Digital signature

The DigitalSignatureClientOverridable.AfterAddToDigitalSignatureCertificatesCatalog procedure is introduced to help users update certificate settings and replace certificates when they add new certificates to the DigitalSignatureAndEncryptionKeysCertificates catalog.

Migrating from version 3.1.10.308 and earlier

To improve remote server authentication when connecting via HTTPS, the minimum platform version for using the library has been increased. See Readme.txt for the specific version number.

Migrating from version 3.1.10.256 and earlier

Digital signature

Migrating from version 3.1.10.248 and earlier

Calendar schedules

Migrating from version 3.1.10.226 and earlier

Access management
Digital signature

Migrating from version 3.1.10.211 and earlier

Message templates

Migrating from version 3.1.10.206 and earlier

Digital signature

User monitoring

Migrating from version 3.1.10.141 and earlier

Contact information

Migrating from version 3.1.10.123 and earlier

Core

The performance of SSL integration check (distributed with the library as an external report SSLImplementationCheck.erf) is improved:

Properties

Version 3.1.9

Version 3.1.9 is designed for development on 1C:Enterprise platform 8.3.21 or higher in Version 8.3.21 compatibility mode.

For the entire list of new features, see What’s new in version 3.1.9 below.

What’s new in version 3.1.9

Surveys

Report options

Add-ins

Bulk edit

Data integrity

Duplicate cleaner

Report distribution

File management

Properties

What’s new for developers in version 3.1.9

Core

Report options

  1. ForComputersAndTablets. A report option must be displayed on report panels only in the thin client, thick client, or web client of 1C:Enterprise. This is a default value.
  2. ForSmartphones. A report option must be displayed on report panels only in the mobile application.
  3. ForAnyDevice. A report option must be displayed in any 1C:Enterprise applications.
  OptionDetails = ReportsOptions.OptionDetails(Settings, DescriptionOfReport, "IncomeAndExpensesForEnterpriseMobileClient");
  OptionDetails.Description = NStr("en='Company's income and expenses (mobile)'");
  OptionDetails.LongDesc = NStr("en= 'Itemized analysis of income and expenses for the entire company with dimension selection.'");
  OptionDetails.Purpose = Enums.ReportOptionPurposes.ForSmartphones;
  1. Configure object registration in the exchange plan when saving the objects above. For example, you can use the OnWrite event subscription. You can find the example in the demo configuration: EventSubscriptions._DemoRegisterChangesForStandaloneMode and EventSubscriptions._DemoRegisterChangesForStandaloneModeRegisters.
  2. Configure the data exchange start in the background with enabling the idle handler at the start of the mobile client session if the main server is available. You can find the example in the demo configuration: the OnStart procedure of the CommonClientOverridable common module.
  3. Extend the offline configuration with all metadata objects (for example, common modules) used in the algorithm of data export and import to the offline configuration. You can find the example in the demo configuration: the _DemoExchangeMobileClientOfflineServerCall common module.
  4. Add a role that grants full rights to the exchange plan to exchange data with the offline configuration. You can find the example in the demo configuration: the _DemoExchangeMobileClient role. Add access rights for metadata objects involved in the exchange to this role. You can find the example in the demo configuration: Constants._DemoExchangePlanNewNodeCode. Add this role and the AddEditReportsSnapshots role to access group profiles of mobile client users.

Import data from spreadsheets

Contact information

Data exchange

Users

File management

Report distribution

Properties

// StandardSubsystems.Properties
PropertyManager.BeforeDeleteObjectKind(ThisObject);
// End StandardSubsystems.Properties

Digital signature

Migrating from version 3.1.8 to version 3.1.9

Required migration actions

In this section, you can read about additional migration instructions for each subsystem that you need to perform in Designer after comparison and merging. See Chapter 2 in the Library Integration Guide.

To update the following overridable common modules, copy the new export procedures from the library distribution package and delete the obsolete ones. Also, make sure that comments, the number of parameters, and the parameter names of each procedure match their library equivalents:

For the recommendations on how to use the new features of the overridable common modules, see the What’s new for developers section above.

Using an API requires much less rewriting of configuration code when upgrading to new library versions. In this section, you can read about necessary instructions for rare cases when such compatibility is not provided and you need to customize the configuration to a new library API. However, the section does not describe changes in internal procedures and functions of the library that are not related to the API even if these are export procedures and functions. When you call these functions and procedures from the configuration, note that they can be changed, moved, or deleted in the next library version as they represent its internal implementation.

Core
#Region EventsHandlers

Procedure BeforeStart()

#If MobileClient Then
    If IsMainServerAvailable() = False Then
        Return;
    EndIf;
#EndIf

    // StandardSubsystems
#If MobileClient Then
    Execute("StandardSubsystemsClient.BeforeStart()");
#Else
    StandardSubsystemsClient.BeforeStart();
#EndIf
    // End StandardSubsystems

EndProcedure

Procedure OnStart()

    // StandardSubsystems
#If MobileClient Then
    Execute("StandardSubsystemsClient.OnStart()");
#Else
    StandardSubsystemsClient.OnStart();
#EndIf
    // End StandardSubsystems

EndProcedure

Procedure BeforeExit(Cancel, WarningText)

    // StandardSubsystems
#If MobileClient Then
    Execute("StandardSubsystemsClient.BeforeExit(Cancel, WarningText)");
#Else
    StandardSubsystemsClient.BeforeExit(Cancel, WarningText);
#EndIf
    // End StandardSubsystems

EndProcedure

Procedure CollaborationSystemUsersChoiceFormGetProcessing(ChoicePurpose,
            Form, ConversationID, Parameters, SelectedForm, StandardProcessing)

    // StandardSubsystems
#If MobileClient Then
    Execute("StandardSubsystemsClient.CollaborationSystemUsersChoiceFormGetProcessing(ChoicePurpose,
        |Form, ConversationID, Parameters, SelectedForm, StandardProcessing)");
#Else
    StandardSubsystemsClient.CollaborationSystemUsersChoiceFormGetProcessing(ChoicePurpose,
        Form, ConversationID, Parameters, SelectedForm, StandardProcessing);
#EndIf
    // End StandardSubsystems

EndProcedure

#EndRegion
Data exchange
Procedure OnRegisterDataImportHandlers(HandlersTable) Export

    DataExchangeEvents.OnRegisterDataImportHandlers(HandlersTable);

EndProcedure
Report distribution

Optional migration actions

The actions listed below are not required for migration, but we recommend that you perform them in the future.

Migrating from earlier versions to version 3.1.9

When you migrate from earlier versions to version 3.1.9:

Starting from version 3.1.9.113 and earlier

Core

Migrating to patch releases 3.1.9

Patch releases of the library differ only in the fourth digit of the full version number, for example: 3.1.9.1, 3.1.9.20, 3.1.9.300, and so on. To update to patch releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will significantly save your time during regular (for example, weekly) updates.

Run the data processor in an infobase with a configuration that contains the previous library release, specify the CF distribution file of the new library version, and click Update to corrective version. This automatically compares and merges the previous and the new library configurations according to the settings described in the documentation. All built-in library objects will be copied, and objects overridden during integration will be merged prioritizing new vendor configuration (for example, type collections) or skipped (for example, overridable modules). The database configuration is not updated automatically after comparison and merging. So, you can compare new data with the database configuration and make changes to the modified objects: overridable modules, various local fixes, and enhancements.

Another option is to generate a comparison and merging settings file by clicking Generate a settings file. After that, you can open this file in Designer to compare and merge configurations manually.

Version 3.1.8

Version 3.1.8 is designed for development on 1C:Enterprise platform 8.3.21 or higher in Version 8.3.21 compatibility mode.

For the entire list of new features, see What’s new in version 3.1.8 below.

What’s new in version 3.1.8

Core

Business interactions

Object attribute lock

Formula editor

Contact information

Users

Email management

Report distribution

Infobase version update

Message templates

What’s new for developers in version 3.1.8

Core

Banks

Business interactions

Add-ins

Bulk attribute edit

Object attribute lock

Formula editor

Contact information

User reminders

Data exchange

Infobase version update

Conversations

Text messaging

Attachable commands

Duplicate cleaner

Users

SaaS

Email management

File management

Properties

Message templates

Migrating from version 3.1.7 to version 3.1.8

Required migration actions

In this section, you can read about additional migration instructions for each subsystem that you need to perform in Designer after comparison or merging. See Chapter 2.Library integration guide in SSL documentation.

To update the following overridable common modules, copy the new export procedures from the library distribution package, delete the obsolete ones, and make sure that comments, the number of parameters, and the parameter names of each procedure match their library equivalents:

For the recommendations on how to use the new features of overridable common modules, see the What’s new for developers section above.

If you use an API, you need to rewrite the configuration code when updating to new library versions significantly less often. In this section, you can read about the necessary instructions for rare cases when such compatibility is not provided and you need to adapt the configuration to a new library API. However, the section does not describe changes in internal procedures and functions of the library that are not related to the API even if these are export procedures and functions. When you call these functions and procedures from the configuration, note that they can be changed, moved, or deleted in the next library version as they represent its internal implementation.

Core
Contact information
Data exchange
Infobase version update
Users

Report distribution

Optional migration actions

The actions listed below are not required for migration but we recommend that you perform them in the future.

Core
Object attribute lock
Contact information
Data exchange
Users

Report distribution

Migrating from earlier versions to version 3.1.8

When you migrate from earlier versions to version 3.1.8:

Migrating to patch releases 3.1.8

Patch releases of the library differ only in the fourth digit of the full version number, for example: 3.1.8.1, 3.1.8.20, 3.1.8.300, and so on. To update to patch releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will significantly save your time during regular (for example, weekly) updates.

Run the data processor in an infobase with a configuration that contains the previous library release, specify the CF distribution file of the new library version, and click Update to corrective version. This automatically compares and merges the previous and the new library configurations according to the settings described in the documentation. All built-in library objects will be copied, and objects overridden during integration will be merged prioritizing new vendor configuration (for example, type collections) or skipped (for example, overridable modules). The database configuration is not updated automatically after comparison and merging. So, you can compare new data with the database configuration and make changes to the modified objects: overridable modules, various local fixes, and enhancements.

Another option is to generate a comparison and merging settings file by clicking Generate a settings file. After that, you can open this file in Designer to compare and merge configurations manually.

Starting from version 3.1.8.102 and earlier

SaaS

Version 3.1.7

Use version 3.1.7 to develop on 1C:Enterprise platform 8.3.17 or higher. Compatibility modes from Version 8.3.14 to Version 8.3.21 (inclusive) are available.

For a complete list of what’s new, see the What’s new in version 3.1.7 section below.

What’s new in version 3.1.7

Core

Users

What’s new for developers in version 3.1.7

Core

Migration from version 3.1.6 to version 3.1.7

Mandatory migration actions

In this section, you can find additional instructions on migrating for each subsystem. Follow these instructions after comparison and merging (see Chapter 2 Library integration guide) (in Russian).

To update the following overridable common modules, move the new export procedures from the library distribution package, remove the missing ones, and make sure the comments, number, and names of the procedure parameters are the same as in the library distribution package:

See What’s new for developers above for recommendations on how to take advantage of the new features of the overridable common modules.

If you use the API, there is less need to revise the application code on update to new library versions. In exceptional cases, when such compatibility is not ensured and it is required to adapt the application to the new API of the library, follow the instructions in this section. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Core

Optional migration actions

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Core
Additional reports and data processors
To-do list

How to migrate from earlier versions to version 3.1.7

When migrating from earlier library versions (up to 3.1.7):

Migration to corrective releases 3.1.7

Corrective library releases differ only in the fourth digit in the full version number. For example, 3.1.7.1, 3.1.7.20, 3.1.7.300, and so on. To migrate to the corrective releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will help save your time on regular updates (for example, every week).

Start the data processor in the infobase with the application that contains the previous library release. Specify the CF delivery file for the new library version and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

As an alternative, you can click Generate a settings file and generate a comparison and merging setting file. You can import this file to Designer for manual comparison or merging.

From version 3.1.7.79 and earlier

Data exchange

Version 3.1.6

Use version 3.1.6 to develop on 1C:Enterprise platform 8.3.17 or higher. Compatibility modes from Version 8.3.14 to Version 8.3.21 (inclusive) are available.

For a complete list of what’s new, see What’s new in version 3.1.6 section below.

What’s new in version 3.1.6

Core

Report options

Business interactions

Data exchange

Infobase version update

Print

Users

Email management

Report distribution

Access management

Digital signature

What’s new for developers in version 3.1.6

Core

Report options

Contact information

Data integrity

National language support

User reminders

Data exchange

·  The OnStandaloneModeOptionChange procedure of the DataExchangeOverridable common module is called when changing an infobase mode and allows you to perform additional actions, for example, initialize related constants and settings.

·  When you synchronize data using the universal EnterpriseData format, you can execute registration rules located in the common module of an application or an extension. To do this, in the WhenReceivingSettings procedure of the exchange plan manager, specify the RulesForRegisteringInManager and RegistrationManager settings. Setup example:

Procedure WhenReceivingSettings(Settings) Export 
     …
    Settings.RulesForRegisteringInManager = True;
    Settings.RegistrationManager = "_DemoRegistrationManagerForUniversalFormat";
EndProcedure

To create a common module, use the Data conversion application version 3.1.1 or later. Set the following execution contexts for the common module: Server, External connection, Client (ordinary application).

·  In the Import/export EnterpriseData data processor in Developer mode, you can operate with a shared temporary file directory (optional). You can find this option in the More actionsmenu and access it in the data import mode.

Infobase version update

Users

Email management

Properties

Marked objects deletion

Access management

Digital signature

DSS service digital signature

Migration from version 3.1.5 to version 3.1.6

Mandatory migration actions

In this section, you can find additional instructions on migrating for each subsystem. Follow these instructions after comparison and merging (see Chapter 2 Library integration guide) (in Russian).

To update the following overridable common modules, move the new export procedures from the library distribution package, remove the missing ones, and make sure the comments, number, and names of the procedure parameters are the same as in the library distribution package:

See What’s new for developers above for recommendations on how to take advantage of the new features of the overridable common modules.

If you use the API, there is less need to revise the application code on update to new library versions. In exceptional cases, when such compatibility is not ensured and it is required to adapt the application to the new API of the library, follow the instructions in this section. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Core
Report options
Data exchange
Infobase version update
National language support
Companies
Users
Email management
Digital signature

Optional migration actions

Core

Report options

How to migrate from earlier versions to version 3.1.6

When migrating from earlier library versions (up to 3.1.6):

Core

Migration to corrective releases 3.1.6

Corrective library releases differ only in the fourth digit in the full version number, for example, 3.1.6.1, 3.1.6.20, 3.1.6.300, and so on. To migrate to the corrective releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will help save your time on regular updates (for example, every week).

Start the data processor in the infobase with the application that contains the previous library release. Specify the CF delivery file for the new library version and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

As an alternative, you can click Generate a settings file and generate a comparison and merging setting file. You can import this file to Designer for manual comparison or merging.

From version 3.1.6.257 and earlier

Data exchange

From version 3.1.6.209 and earlier

Data exchange

From version 3.1.6.198 and earlier

Digital signature

From version 3.1.6.180 and earlier

Infobase version update

From version 3.1.6.159 and earlier

Companies

From version 3.1.6.118 and earlier

Digital signature

Version 3.1.5

Use version 3.1.5 to develop on 1C:Enterprise platform in the mode of compatibility with versions 8.3.14, 8.3.15, 8.3.16, or 8.3.17, that means

For a complete list of what’s new, see the What’s new in version 3.1.5 section below.

What’s new in version 3.1.5

Report options

User sessions

Data exchange

File management

Access management

Source document originals recording

Digital signature

New features for developers in version 3.1.5

Core

Report options

User sessions

Import data from spreadsheets

Object attribute lock

Data exchange

Infobase version update

Scheduled jobs

Access management

Source document originals recording

Message templates

Digital signature

Migration from version 3.1.4 to version 3.1.5

Required migration actions

In this section, you can find additional migration instructions for each subsystem. Follow the instructions in Designer after the comparison/merge is complete (see Chapter 2 Library integration instructions).

To update the following overridable common modules, move the new export procedures from the library distribution package, remove the missing ones, and make sure that the comments, number, and names of the procedure parameters are the same as in the library distribution package:

See New features for developers above for recommendations on how to take advantage of the new features of the overridable common modules.

If you use the API, there is less need to revise the application code on update to new library versions. In exceptional (rare) cases, when such compatibility is not ensured, and it is required to adapt the application to the new API of the library, this section contains the necessary instructions. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Report options

Business interactions
Data exchange
Users

File management

Access management

Optional migration actions

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Contact information
Data exchange
Digital signature

How to migrate from earlier versions to version 3.1.5

When migrating from earlier library versions (up to 3.1.4):

Common module names:

Previous name Current name
AddInClient AddInsClient
AddInServerCall AddInsServerCall
BankOperationsOverridable BankManagerOverridable
CallOnlineSupportClient ContactOnlineSupportClient
CallOnlineSupportOverridable ContactOnlineSupportOverridable
ContactInformationManagementOverridable ContactsManagerOverridable
ContactInformationManagementOverridable ContactsManagerOverridable
CurrenciesExchangeRatesClientServer CurrencyRateOperationsClientServer
CurrenciesExchangeRatesOverridable CurrencyRateOperationsOverridable
DependenciesOverridable SubordinationStructureOverridable
DuplicateObjectDetection DuplicateObjectsDetection
EmailClientOverridable EmailOperationsClientOverridable
EmailOverridable EmailOperationsOverridable
EventLogOperations EventLog
FindAndDeleteDuplicatesDuplicatesClient DuplicateObjectsDetectionClient
MessagesTemplatesServer MessageTemplatesServer
ObjectPrefixationClientServer ObjectsPrefixesClientServer
ObjectsAttributesEditBlockedOverridable ObjectAttributesLockOverridable
SafeModeManagerOverride SafeModeManagerOverridable
SendSMSMessagesClientOverridable SendSMSMessageOverridable
SMSClient SendSMSMessageClient
SMSOverridable SendSMSMessageOverridable

Procedure and function names:

Previous name Current name
AddInClient.InstallationParameters AddInsClient.ConnectionParameters
ContactsManagerClient.CreateEmail ContactsManagerClient.CreateEmailMessage
FilesOperationsClient.CopyFile FilesOperationsClient.CopyAttachedFile
SendSMSMessage.SendSMSMessage SendSMSMessage.SendSMS
SMSOverridable.SendSMSMessage SendSMSMessageOverridable.SendSMS

Metadata object names:

Previous name Current name
Constant.TestFilesExtensionsList Constant.TextFilesExtensionsList
Constant.UseEmailInMessagesTemplates Constant.UseEmailInMessageTemplates
Constant.UseSMSMessagesSendingInMessagesTemplates Constant.UseSMSMessagesSendingInMessageTemplates

System enumeration name:

Previous name Current name
Enum.SMSStatus Enum.SMSMessagesState

System enumeration value name:

Previous name Current name
Enum.ContactInformationTypes.EmailAddress Enum.ContactInformationTypes.Email

Migration to corrective releases 3.1.5

Corrective library releases differ only in the fourth digit in the full version number, for example, 3.1.5.1, 3.1.5.20, 3.1.5.300, and so on. To migrate to the corrective releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will help save your time on regular updates (for example, every week).

Start the data processor in the infobase with the application that contains the previous library release, specify the CF distribution file for the new library version, and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

As an alternative, you can also click Generate a settings file to generate a comparison/merging settings file. You can later load it in Designer for manual comparison/merging.

From version 3.1.5.262 and earlier

Infobase version update

From version 3.1.5.208 and earlier

Core

From version 3.1.5.192 and earlier

File management

From version 3.1.5.180 and earlier

File management

From version 3.1.5.163 and earlier

File management

From version 3.1.5.146 and earlier

Core

From version 3.1.5.132 and earlier

Infobase version update

Version 3.1.4

Use version 3.1.4 to develop on 1C:Enterprise platform in the mode of compatibility with versions 8.3.14, 8.3.15, or 8.3.16, that means:

Migration from version 3.1.3 to version 3.1.4

Required migration actions

In this section, you can find additional migration instructions for each subsystem. Follow the instructions in Designer after the comparison/merge is complete (see Chapter 2 Library integration instructions).

To update the following overridable common modules, move the new export procedures from the library distribution package, remove the missing ones, and make sure that the comments, number, and names of the procedure parameters are the same as in the library distribution package:

See New features for developers above for recommendations on how to take advantage of the new features of the overridable common modules.

If you use the API, there is less need to revise the application code on update to new library versions. In exceptional (rare) cases, when such compatibility is not ensured, and it is required to adapt the application to the new API of the library, this section contains the necessary instructions. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Business processes and tasks
Access management

Optional migration actions

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Period-end closing dates
Translator
Email Management

File management

Digital signature

How to migrate from earlier versions to version 3.1.4

When updating earlier library versions (to 3.1.3):

Migration to corrective releases 3.1.4

Corrective library releases differ only by the fourth digit in the full version number, for example, 3.1.4.1, 3.1.4.20, 3.1.4.300, etc. To upgrade to corrective releases, use external data processor UpdateToCorrectiveVersionSSL.EPF from the distribution package. It will help save your time when regularly updating the application (for example, weekly).

Start the data processor in the infobase with the application that contains the previous library release, specify the CF distribution file for the new library version, and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

As an alternative, you can also click Generate a settings file to generate a comparison/merging settings file. You can later load it in Designer for manual comparison/merging.

From version 3.1.4.232 and earlier

Core

Version 3.1.3

Use version 3.1.3 to develop on 1C:Enterprise platform in the mode of compatibility with versions 8.3.14, 8.3.15, or 8.3.16, that means:

Migration from version 3.1.2 to version 3.1.3

Required migration actions

In this section, you can find additional migration instructions for each subsystem. Follow the instructions in Designer after the comparison/merge is complete (see Chapter 2 Library integration instructions).

If you use the API, there is less need to revise the application code on update to new library versions. In exceptional (rare) cases, when such compatibility is not ensured, and it is required to adapt the application to the new API of the library, this section contains the necessary instructions. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Calendar schedules
Infobase version update
Marked objects deletion

Optional migration actions

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Report options
Infobase version update
Conversations
    If CommonClient.SubsystemExists("StandardSubsystems.Conversations") Then

        ModuleConversationsInternalClient = CommonClient.CommonModule("ConversationsServiceClient");
        ModuleConversationsInternalClient.OnGetCollaborationSystemUsersChoiceForm(ChoiceAssignment, Form, ConversationID, Parameters,
          SelectedForm, StandardDataProcessor);

    EndIf;
File management
Hierarchy

How to migrate from earlier versions to version 3.1.3

When migrating from earlier library versions (up to 3.1.2):

Migration to corrective releases 3.1.3

Corrective library releases differ only in the fourth digit in the full version number, for example, 3.1.3.1, 3.1.3.20, 3.1.3.300, and so on. To migrate to the corrective releases, use the UpdateToCorrectiveVersionSSL.epf external data processor from the distribution package. It will help save your time on regular updates (for example, every week).

Start the data processor in the infobase with the application that contains the previous library release, specify the CF distribution file for the new library version, and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

As an alternative, you can also click Generate a settings file to generate a comparison/merging settings file. You can later load it in Designer for manual comparison/merging.

From version 3.1.3.303 and earlier

Core

From version 3.1.3.250 and earlier

Core

From version 3.1.3.215 and earlier

Core

From version 3.1.3.187 and earlier

Core

Version 3.1.2

Use version 3.1.2 to develop on 1C:Enterprise platform in the mode of compatibility with versions 8.3.14, 8.3.15, or 8.3.16, that means:

Migration from version 3.1.1 to version 3.1.2

Required migration actions

In this section, you can find additional instructions on migrating for each subsystem. Follow these instructions after comparison or merging.

If you use the API, there is less need to revise the application code on update to new library versions.

There are additional instructions for each subsystem for the exceptional cases when such compatibility is not supported and it is required to adapt the application to a new library API. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Core
Object versioning
&AtServer
Procedure OnCreateAtServer(Cancel, StandardProcessing)
    // StandardSubsystems.ObjectsVersioning
    ObjectsVersioning.OnCreateAtServer(ThisObject);
    // End StandardSubsystems.ObjectsVersioning
EndProcedure
Work schedules
Calendar schedules
Data integrity
File management
Access management
Digital signature

Optional migration actions

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Core
Business processes and tasks
Object versioning
Contact information
Data integrity
AccountingAudit.AfterWriteAtServer(CurrentObject);
Item order setup
Application settings
Attachable commands
Email Management
File management

Migration to corrective releases 3.1.2

Corrective library releases differ only by the fourth digit in the full version number, for example, 3.1.2.1, 3.1.2.20, 3.1.2.300, etc. To upgrade to the corrective releases, use external data processor UpdateToCorrectiveVersionSSL.EPF from the distribution package. It will help save your time when regularly updating the application (for example, every week).

Start the data processor in the infobase with the application that contains the previous library release. Specify the CF delivery file for the new library version and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

Besides, as an alternative, you can click Generate a settings file and generate a comparison or merging setting file that can be imported to the application for manual comparison or merging.

From version 3.1.2.430 and earlier

Core

From version 3.1.2.352 and earlier

Calendar schedules

From version 3.1.2.306 and earlier

Access management

From version 3.1.2.166 and earlier

Contact information

From version 3.1.2.196 and earlier

Infobase version update

From version 3.1.2.202 and earlier

From version 3.1.2.229 and earlier

Core

How to migrate from earlier versions to version 3.1.2

When migrating from earlier library versions (up to 3.1.1):

Version 3.1.1

Version 3.1.1 is the new revision of 1C:Standard Subsystems Library. Use version 3.1.1 to develop on 1C:Enterprise platform versions 8.3.14 and later with disabled mode of compatibility with version 8.3.14. Полный перечень нововведений см. ниже в разделе Новые возможности и изменения в версии 3.1.1.

Migration from version 3.0.3 to version 3.1.1

Use version 3.1.1 to develop on 1C:Enterprise platform versions 8.3.14 and later with disabled mode of compatibility with version 8.3.14. You should preliminarily adapt the application according to the list of modifications and update of technological platform of versions 8.3.13 and 8.3.14. The minimum adaptation requirements are described in Methodology of application migration to 1C:Enterprise 8.3 platform.

In this version, deleted the metadata objects that were marked as obsolete more than two years ago (in version 2.3.3 and earlier) and the API that had been marked as obsolete before version 2.4.2.

If earlier the migration from an obsolete to a relevant API was not regular in the application, find and replace all the calls specified below in the Required migration actions section before the update. Make replacements according to the instructions in the documentation comments to obsolete procedures and functions. Use 1C:Automated Configuration Check tool (https://v8.1c.ru/acc/) to quickly identify deprecated calls of the obsolete API.

If you use 1C:Standard Subsystems Library (SSL) together with 1C:Cloud Technology Library (CTL), the migration procedure is as follows: to migrate to version 3.1.1, get SSL version 1.2 and perform 5 steps in Designer.

  1. Run the Configuration — Support — Update configuration command. Specify a path to the SSL delivery file in the Select update file option. In the application comparison/merging window that opens, go to the parameters by clicking Actions — Parameters, clear the Allow main configuration object deletion check box, and click OK. In the application comparison/merging window, clear all the check boxes and select the objects to migrate by clicking Actions — Select by new vendor configuration subsystems. Select from the Standard subsystems group:
  1. Click Configuration — Support — Update configuration. Specify a path to the CTL delivery file in the Select update file option. In the application comparison/merging window that opens, go to the parameters by clicking Actions — Parameters, clear the Allow main configuration object deletion check box, and click OK. In the application comparison/merging window, clear all the check boxes by clicking Actions — Select by new vendor configuration subsystems and select all the ‘SaaSTechnology’ subsystem objects. Next, click Set.

  2. Click Configuration — Support — Support options. On the Support options form that opens, select the StandardSubsystemsLibrary value in the Vendor configuration drop-down list and click Compare and merge. In the configuration comparison/merging window that opens, go to the parameters by clicking Actions — Parameters, select Allow main configuration object deletion, and click OK. In the configuration comparison/merging window, clear all the check boxes and select all the subsystems integrated in the application and related to the StandardSubsystems subsystem. Next, click Execute.

  3. Click Configuration — Support — Support options. On the Support setting form that opens, select the SaaSTechnologyLibrary value in the Vendor configuration drop-down list and click Compare and merge. In the configuration comparison/merging window that opens, go to the parameters by clicking Actions — Parameters, select Allow main configuration object deletion, and click OK. In the configuration comparison/merging window, clear all the check boxes and select the SaaSTechnology subsystem. Next, click Execute.

Required migration actions

In this section, you can find additional instructions on migrating for each subsystem. Follow these instructions after comparison or merging.

If you use the API, there is less need to revise the application code on update to new library versions.

There are additional instructions for each subsystem for the exceptional cases when such compatibility is not supported and it is required to adapt the application to a new library API. Changes in internal library procedures and functions (even if they are export ones) that are not related to the API are not documented. When calling them directly from the application, note that they can be changed, moved, or deleted in the next library version since they are its internal implementation.

Address classifier
Core
Business processes and tasks
Currencies
Report options
Business interactions
Additional reports and data processors
Personal data protection
Contact information
Calendar schedules
User reminders
Data exchange SaaS
Infobase version update
Attachable commands

As 1C:Enterprise platform updated to version 8.3.13 changed its behavior, add the Export keyword to the previously placed Attachable_ExecuteCommandAtServer procedures in the form modules:

Users
Object prefixes
Security profiles
File management
Object presentation declension
Individuals
Access management

Optional migration actions

The actions below are optional for the migration, but we recommend that you schedule them in the future.

Core
Currencies
Contact information
Application settings
Object presentation declension
Access management

Migration to corrective releases 3.1.1

Corrective library releases differ only by the fourth digit in the full version number, for example, 3.1.1.1, 3.1.1.20, 3.1.1.300, etc. To upgrade to the corrective releases, use external data processor UpdateToCorrectiveVersionSSL.EPF from the distribution package. It will help save your time when regularly updating the application (for example, every week).

Start the data processor in the infobase with the application that contains the previous library release. Specify the CF delivery file for the new library version and click Update to corrective version. The library version is automatically compared/merged with the new library version according to the documentation settings. All built-in library objects will be transferred, and those overridden during integration will be merged with the priority of the vendor configuration (for example, flexible type collections) or skipped (such as overridable modules). After the comparison/merging, the database configuration will not be updated automatically, which allows you to compare with the database configuration and edit the changed objects: overridable modules, various local patches, and revisions.

Besides, as an alternative, you can click Generate a settings file and generate a comparison or merging setting file that can be imported to the application for manual comparison or merging.

From version 3.1.1.99 and earlier

Access management

From version 3.1.1.120 and earlier

Access management
// StandardSubsystems.AccessManagement  
AccessManagement.AfterWriteAtServer(ThisObject, CurrentObject, WriteParameters);  
// End StandardSubsystems.AccessManagement 

From version 3.1.1.136 and earlier

Access management

From version 3.1.1.151 and earlier

Access management

How to migrate from earlier versions to version 3.1.1

Limited update for the versions earlier than 2.3.3

You can migrate to version 3.1.1 from version 2.3.3 and later. If an older library version is embedded in the application, a developer must restrict direct migration to the new application version (on the basis of library 3.1.1 version). The migration must be made via an intermediate version with a required startup to execute update handlers (including deferred ones).

For example, in the application version 1.1.1 and later, 2.3.3 SSL version is used. 3.1.1 SSL version is embedded to new 1.2.1 version:

  1. If you publish application releases on 1C:Application update portal (https://releases.1c.ru), then on publishing new version 1.2.1, specify in the Minimum version to startup handlers property the version where 2.3.3 SSL is used (here, it is 1.1.1). Then the required startup will occur automatically on updating the application in 1С:Enterprise mode.
  2. If you run update via Designer and want to avoid unexpected situations, consider displaying a warning in the OnDetermineUpdateAvailability procedure of the InfobaseUpdateClientOverridable common module:
Procedure OnDetermineUpdateAvailability(Val DataVersion) Export

    AvailableVersion = "1.1.1";

    DataVersionWithoutBuildNumber = CommonClientServer.ConfigurationVersionWithoutBuildNumber(DataVersion);
    Result = CommonClientServer.CompareVersionsWithoutBuildNumber(DataVersionWithoutBuildNumber, AvailableVersion);
    If DataVersion <> "0.0.0.0" And Result < 0 Then
        Message = NStr("en = 'Update from version %2 was attempted. 
            |You can update only from version %1 or later.
            |Restore the infobase from a backup
            |and try to update again as described in file 1cv8upd.htm'");
        Message = StringFunctionsClientServer.SubstituteParametersToString(Message, AvailableVersion, DataVersion);
        RaiseException Message;
    EndIf;

EndProcedure

How to update from versions 2.3.3 – 3.0.1

When migrating from earlier library versions (up to 3.0.1):

For example, if you are migrating from version 3.0.1.1 directly to version 3.1.1.123, sequentially follow the instructions of all the sections: