Data storages

• Using attributes of String type
• Length of configuration object codes and numbers
• Name, synonym, and comment
• Delivering data in configuration packages
• Tooltips and fill checks
• Reflecting the nature of metadata objects using attributes
• Handling inactive objects
• Comment attribute of documents
• Deleting obsolete metadata objects from configurations
• Self-sufficiency of registers
• Generic data storage principles
• Using predefined items
• Using the Active property of register records
• Document posting requirements
• Limitations to usage of composite-type attributes

Using attributes of String type

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

1.1. For String attributes, specify Variable length type in the Allowed Length property, and specify the maximum string length. Avoid using Fixed length type unless absolutely necessary (fixed length can be maintained by adding spaces to the end of the string). 

1.2. If the maximum string length is predefined (in standards, regulatory documents, and so on), specify it in the Length property, or in the Description length property of the standard Description attribute. For example, the length of the SSN attribute of the Employees catalog must be 9 characters.

1.3. Calculate the length of a concatenated string by summing up lengths of all its segments. For example, calculate the length of address presentation by adding lengths of address lines.

1.4 If a string length is not regulated by any standards, set the length that is sufficient for storing data in most cases. For example, a full contractor name usually takes up to 250 characters, a file name in most file systems takes up to 260 characters, a full name of an individual takes up to 100 characters, and so on.

2. Using strings with undefined length is allowed in the following cases:

2.1. A string attribute is intended for storing user-defined text that might be of significant length. A common example is a form field that allows input of multiple text lines. For example, a manager can store the entire customer communication history in the Additional info field of a customer order; a user can store an arbitrary text that contains multiple lines in the Comment field, and so on.

2.2. A string attribute stores application-generated technical data, which is mostly not intended for viewing by users but intended for using in data processing algorithms. For example, XML documents or email message headers.

3. When using strings with undefined length, remember the following query language limitations:

3.1 When comparing, grouping, or selecting distinct values you must convert them to fixed length strings. Otherwise, the calculation result might be incorrect.

We recommend that you use the following query syntax:

CAST AS STRING(1000)

3.2. In data composition schema-based reports, specify the Value Type parameter for such fields (on the Data Sets tab).

Note that frequent conversion of undefined length to fixed length in queries and data composition schema-based reports might indicate that the application design is not optimal. If this is the case, redesigning in favor of fixed length is recommended.

3.3. In all other cases you can freely use strings with undefined length in queries.

4.1. If a string is displayed in a print form field, ensure that it is never cut, regardless of the declared string length. Cutting a string might lead to a loss of significant data, such as building and apartment numbers in a delivery address.

Length of configuration object codes and numbers

This article describes the standards that apply to object code or number length. All of the listed recommendations are mandatory unless noted otherwise.

Name, synonym, and comment

This article describes the standards that apply to object names, synonyms, and comments. All of the listed recommendations are mandatory unless noted otherwise.

1.1. An object Synonym must describe the object in a concise manner, which reflects the object purpose. A synonym is mandatory for each object.

This is required because synonyms are present in the user interface (in forms, reports, command interfaces, and so on), and therefore they must describe objects correctly, clearly, and consistently. Besides metadata objects, this requirement also applies to metadata object attributes, tabular sections, tabular section attributes, register dimensions, resources and any other configuration objects that have synonyms.

1.2. We recommend that you do not use abbreviations for synonyms. You can make an exception for abbreviations that are well known to the target audience (such as Sum, TIN, or SSN).

1.3. The meaning of all terms used in object synonyms must be clear to users, and the same is true for any messages displayed to users. Do not use slang, informal names of products or companies, English words written in foreign alphabet, foreign words written in English alphabet, and so on.

1.4. Specify synonyms for standard attributes of metadata objects based on their actual meaning in your application.

1.5. For standard attributes Parent and Owner, always change their default synonyms. For example, a configuration contains the Files catalog, which has a standard attribute Owner of CatalogRef.FileFolders type.
Incorrect:

• Leave the default synonym "Owner" of the standard attribute Owner.

Correct:

• Define the synonym that reflects the object meaning, such as "Folder" or "Directory".

For some catalogs it is okay to leave the default synonym "Description" of the standard Description attribute. For the Files catalog, you can choose the synonym "File name", and for the Individuals catalog you can choose the synonym "Full name".

1.6. If you have two or more similar metadata objects, ensure that their synonyms fully describe them.

Incorrect catalog synonyms:

• Bank accounts
• Counterparty bank accounts

Correct:

• Company bank accounts
• Counterparty bank accounts

The names must explicitly describe the objects. Otherwise, users will ask: "If the Counterparty bank accounts catalog stores bank accounts of counterparties, whose accounts are stored in the Bank accounts catalog?"

This requirement also applies to synonyms of subordinate metadata objects (attributes, tabular sections, dimensions, resources, and so on).
The following example describes synonyms for attributes of the Items tabular section of the InventoryCount document.
Incorrect:

• Count
• Count (from accounting)

Correct:

• Count (available)
• Count (from accounting)

The following example describes synonyms for the standard Description attribute and another attribute of the Items catalog.
Incorrect:

• Description
• Extended description

Correct:

• Description for viewing
• Description for printing

2.1. We recommend that you create object Name based on its synonym (by removing spaces and other characters that are not allowed in names and capitalizing the first letter of each word). Examples:

• the AdditionalDataAndAttributeSets catalog has synonym "Additional data and attribute sets".
• the AttachedFiles command has synonym "Attached files".

You can use shorter names where one or several words of the synonym are omitted. Examples:

• ServerResponseTimeout has synonym "Server response timeout (sec)"
• NumberOfUnits has synonym "Number of measurement units"
• AttributeName has synonym "Attribute name (property)"

When creating names from synonyms, omit articles. You can also omit prepositions and conjunctions. For example, the DiscountMarkupValue attribute has synonym "Discount or markup value".

On the other hand, you can use shorter synonyms where one or several "technical" parts of the name are omitted.

This requirement ensures that configuration objects and their presentations in the user interface are easily recognizable. It helps at the deployment stage because developers usually do not participate in this process, leaving it to deployment specialists.

See also: Metadata object names in configurations

2.2. Metadata objects with Delete prefix are an exception to this rule.

Also, do not rename metadata objects, their attributes, forms, and so on if the objects must comply with backward compatibility requirements. In particular, different library versions within a single revision must be compatible with each other.

2.3. Names of top-level metadata objects (catalogs, documents, and so on) must not exceed 128 characters.

2.4. We recommend that names of subordinate metadata objects (attributes, dimensions, resources, and so on) are not identical to parent object names. For example, the User dimension (that has CatalogRef.Users type) of the TaskExecutors information register has incorrect name; it should be named Executor to reflect its meaning.

2.5. We recommend that you do not use names identical to query language table names (Document, Catalog, InformationRegister, and so on). Such names can cause errors during query execution, cumber the use of query builder and decrease the clarity or query text. For example, this query returns an error:

SELECT
Information.Information
FROM
InformationRegister.Information AS Information

3.1. Specify the Comment only when you need to leave a note on the object for another developer. Example comments to a catalog attribute are "Indexing is implemented for optimization of reports filtered by counterparty" and "Used in foreign currency accounting".

3.2. Start your comment with a capital letter. Use periods only in abbreviations.

See also

• Tooltips and fill checks

• Comment attribute in documents

Delivering data in configuration packages

This article describes the standards that apply to data included in configuration delivery package. All of the listed recommendations are mandatory unless noted otherwise.

If you want to include some data in your configuration delivery package (for example, data for filling catalogs, report settings, data exchange rules, and so on), we recommended that you use formats designed for data transfer (such as XML), and you use the "Text document" template or the "Binary data" template.

Do not use the "Spreadsheet document" template for including data in a configuration delivery package.

Tooltips and fill checks

This article describes the standards that apply to writing tooltips and using the fill check option. All of the listed recommendations are mandatory unless noted otherwise.

1.1. Tooltip property. Each typed metadata object (object attribute, tabular section attribute, dimension, or register resource) must have a tooltip explaining the object purpose to end users.

Standard attributes Code, Description, Parent, Owner, and Period (for periodic information registers) also must have tooltips. The remaining standard attributes usually do not require tooltips.

Keep tooltips clean from "trash" messages such as copies of metadata object or attribute synonyms. Tooltips are not required in the following cases:

• The object or attribute synonym clearly explains its purpose. For example, the synonym of the FullName attribute of the Currencies catalog clearly explains that the attribute stores the full currency name.
• The attribute value will never be viewed or edited from the user interface (in particular, it is never available in form fields). Therefore, no one will see the tooltip.

2.1. Fill check property. For all typed metadata objects, standard attributes, and tabular sections that need to be filled according to the object logic, set their "Fill check" properties to "Display error".

In some cases posting a document with empty attributes or tabular sections does not make sense for accounting. For example, a Customer order document represents a customer's request for purchasing a certain number of items. An order with no customers or empty Items tabular section does not make sense, therefore the Customer field and the Items tabular section must have their "Fill check" properties set to "Display error".

2.2. When specifying "Fill check" value, remember that all limitations and checks must be described as completely as possible in configuration metadata. Therefore, if at least one scenario requires filling the attribute, set "Fill check" to "Display error". If other scenarios do not require filling the attribute, reflect this in the event handler of the FillCheckProcessing object module.

Do not use the reverse method when "Fill check" is set to "No check" and the FillCheckProcessing handler includes additional fill checks. This hinders the analysis of configuration logic.

2.3. If the fill check is conditional, we recommend that you use conditional form appearance to toggle the "AutoMarkIncomplete" property. Turn it off if the current object state does not require performing fill checks.

See also

• Name, synonym, and comment

Reflecting the nature of metadata objects using attributes

This article describes the principles of reflecting purposes and functions of business logic entities in metadata objects and their attributes. All of the listed recommendations are mandatory unless noted otherwise.

1. When designing application structure, use different object types for representing different entities. For example, use the Companies catalog for companies and the Departments catalog for departments.

2. To pinpoint object purpose you can add attributes to the object, so that its meaning and behavior change depending on the attribute values. For example, the Companies catalog can store both regular companies and subsidiaries, and the Employees catalog can store both current and former employees.

We recommend that in such cases you create dedicated attributes that uniquely identify the object kind or state. They can be Boolean attributes or enumerations that store object kinds. Do not determine object kind by indirect characteristics—in particular, by checking whether any of its attributes is filled.

Incorrect:

• The Companies catalog has a ParentCompany attribute, and the attribute value defines whether it is a regular company or a subsidiary.

Correct:

• In addition to the ParentCompany attribute, the Companies catalog has a Boolean attribute Subsidiary. The value of this attribute (True or False) explicitly defines the company type and whether filling the ParentCompany attribute is needed.

3. At the same time, if the Employees catalog has attributes HireDate and FireDate, adding a pair of Boolean attributes Hired and Fired is not reasonable. It is a good practice to create a single enumeration attribute for entities that can have multiple states. For example, an attribute can have states "works" and "fired", and you can add more states when needed.

Handling inactive objects

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

Procedure ChoiceDataGetProcessing(ChoiceData, Parameters, StandardProcessing)
 If Not Parameters.Filter.Property("Inactive") Then
  Parameters.Filter.Insert("Inactive", False);
 EndIf;
EndProcedure

Procedure FormGetProcessing(FormType, Parameters, SelectedForm,
                            AdditionalInformation, StandardProcessing)
 If FormType = "ChoiceForm" Then 
  ParameterChanged = False;  
  If Not Parameters.Property("Filter") Then
   Parameters.Insert("Filter", New Structure("Inactive", False));
   ParameterChanged = True;
  ElsIf Not Parameters.Filter.Property("Inactive") Then
   Parameters.Filter.Insert("Inactive", False);
   ParameterChanged = True;
  EndIf;
  
  // This code utilizes the changed parameter values
  If ParameterChanged Then  
   StandardProcessing = False;
   SelectedForm = "ChoiceForm"; // Passing the choice form name
  EndIf;
 EndIf;
EndProcedure

Comment attribute of documents

This article describes the standards that apply to the Comment attribute of documents. All of the listed recommendations are mandatory unless noted otherwise.

Deleting obsolete metadata objects from configurations

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

1. While changing configuration metadata structure, when you delete a metadata object (attribute, dimension, resource, and so on) related to infobase data, you have to decide whether you simply delete its data or migrate it to some other data structures. We recommend that you follow these recommendations when migrating object data:

1.1. Do not delete obsolete metadata objects and attributes permanently. Instead, mark them as obsolete by adding the Delete prefix to their names. Example: rename MainAgreement to DeleteMainAgreement. We recommend that you add the prefix (not used) to the object or attribute synonym, for example: (not used) Main agreement. If a standard attribute becomes obsolete, also add the (not used) prefix to its synonym.

1.2. Once you have changed the metadata structure, transfer the data from the obsolete attributes to the new metadata structure. If the metadata object that is subject for deletion is a document that generates register records and the related registers are not deleted together with the document, ensure that the register records are preserved. We recommend that you do the following to preserve the register records generated by obsolete document objects:

• Disable generation of register records for documents of this type.
• Disable removing deletion marks for documents of this type.
• For all of the register records generated by documents of this type, replace the recorder with one or several replacement recorder documents. These can be either existing universal documents or documents developed specifically for migration purposes, for example, DataTransfer or Operation.
• Mark all documents of this type for deletion.

1.3. Since using obsolete metadata objects and attributes after changing metadata structure is not a proper procedure, replace all occurrences of calling obsolete objects by calling new ones in the entire configuration.

1.4. Sort obsolete metadata objects and attributes in the metadata tree according to common configuration requirements.

Following these rules ensures that existing infobase records are no longer related to obsolete metadata objects and prevents generation of new infobase records related to these objects.

2. When a new configuration version is released, permanently delete obsolete metadata objects and attributes marked with the Delete prefix if at least one of the following conditions is met:

• Users always perform sequential configuration updates, with a mandatory update to the version where data transfer from the obsolete metadata objects and attributes is implemented.
  
  Example: in configuration version 1.1 the MainAgreement attribute is marked obsolete. Update from version 1.0 to version 2.0 is always sequential: fisrt, update to version 1.1, and then update to version 2.0. Updating directly from 1.0 to 2.0 is technically impossible (this option is not provided).
   
• Chances that anyone still uses the old configuration version are negligible.

Self-sufficiency of registers

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

While developing register structure, remember that the register must stay logically independent from the recorders. Any logic based on register data and any reports on the register must not access recorder fields; all required data must be located in the register itself.

Accessing register fields using . (dot) leads to implicit connections to additional tables. Moreover, a distributed database might not have a recorder if register records are transferred between nodes but recorders are not.

Generic data storage principles

This article provides guidelines for choosing optimal metadata object types for storing data in your configuration.  

1. At the solution design stage, proper selection of metadata object types that will store business data is very important. Incorrect choices might impact the applied solution efficiency and future development options, and hinder adaptation to possible changes of business tasks covered by the applied solution.

2. We recommend that you choose metadata object types based on the following diagram:

* The arrows represent data dependencies (cross-references).

The diagram contains the following blocks:

1. Conventionally static data. This includes data that  is normally entered once, rarely changed, and regularly accessed. Examples: classifiers, settings, lists, registers, and regulations.

2. Business process-related events, which have time stamps and can generate or modify data when registered. Examples: enterprise document flow, accounting, registering orders or calls.

3. Collected data and commercial indicators, which describe the current state of the application area and the current processes. Unlike data described in paragraphs 1 and 2, this data does not have object nature and it does not describe independent entities belonging to the application area. Examples: item sales history, warehouse balances, current account balances, currency exchange rate history. 

The last block represents data analysis, processing, and reporting tools. They utilize data from the other blocks but do not store data themselves.

2.1. Therefore, you have to assign each business area entity to one of these blocks based on the following algorithm:

• If you need to store data that is rarely changed and does not have time stamps, use the conventionally static data block (1).

• If you need to register documented events that have time stamps, use the busines process-related events block (2).

• Otherwise use the collected data and commercial indicators block (3).

Detailed block selection criteria:

2.2. Then select a specific metadata object type inside the selected block:

2.2.1. For conventionally static data:

1. To store a chart of accounts for double-entry bookkeeping, use the Chart of accounts metadata object.
2. To store a chart of calculation types for calculating accruals and retentions, use the Chart of calculation types  metadata object.
3. To store a single value that can be edited by users (usually by the administrator who performs the system setup) and does not require references from other data, use the Constant metadata object .
4. To define a fixed list of values that cannot be edited by users and does not have additional attributes, use the Enumeration metadata object.
5. To store the list of characteristics (properties) where both the characteristic types and their content are defined by users, use the Chart of characteristic types metadata object.
6. In most other cases, you can use the Catalog metadata object.

Detailed criteria for metadata object selection:

2.2.2. For business process-related events:

1. To register one-time events that have performers (users, employees, groups, or roles) and do not require posting once they are completed, use the Task metadata object.
2. To register the creation and progress of a repeated process that can be divided into a set of actions (events), use the Business process metadata object. To register actions (events) that form a process, use the Task metadata object.
3. In most other cases, you can use the Document metadata object.

Detailed criteria for metadata object selection:

2.2.3. For collected data and commercial indicators:

1. To store accounting data for double-entry bookkeeping, use the Accounting register metadata object.
2. To store calculated accruals and retentions, use the Calculation register metadata object.
3. To store the history of indicator changes (incomes and expenses, turnovers and balances for a specific period), use the Accumulation register metadata object.
4. In most other cases, you can use the Information register metadata object.

Detailed criteria for metadata object selection: 

3. Example of metadata object type selection:

A company provides survey services. Each questionnare includes a date and a set of questions, a filled questionnare also includes a set of answers. The "questionnare" entity has a time stamp and generates statistical data (the answers).

Let us use the algorithm described in this article:

• Filling a questionnare is an event that has a time stamp and generates parameter values. It belongs to the second block: business process-related events.
• According to the table describing this block, a questionnare that generates data (the answers) is represented by a Document object.

Using predefined items

These recommendations apply to 1C:Enterprise version 8.3.3 or later (except configurations where compatibility mode is set to Version 8.2 or earlier). They are mandatory unless noted otherwise.

1.1.  You have the option to create predefined items in catalogs, charts of accounts, and charts of calculation types, both automatically or using 1C:Enterprise script. 

1.2. In most scenarios we recommend that you have predefined items created automatically because they are needed at all times and because this simplifies calling them from 1C:Enterprise script. Examples of such scenarios are the predefined USA item in the Countries catalog and the predefined Administrator access group profile.

For the automatic creation, do the following:

• Set the value of the PredefinedDataUpdate catalog, chart of accounts, or chart of calculation types property to Auto (the default value) and ensure that you never call the SetPredefinedDataUpdate method for those objects (this method sets the property value).
• Ensure that users cannot delete predefined items by disabling the following rights for all users (these rights are disabled by default):  
  • Interactive deletion of predefined objects
  • Interactive deletion mark on predefined objects
  • Interactive removal of deletion mark from predefined objects 
  • Interactive deletion of marked predefined objects

1.3. Subordinate nodes of distributed infobases are exceptions to this rule. In such nodes predefined items must not be created or updated automatically. Instead, they must be replicated from the master node together with the configuration changes.

In this case ensure the following:

a) The configuration loads an exchange message to a subordinate node prior to execution of the script that accesses predefined items retrieved from the master node.

b) The applied logic of loading data from the master node (for example, the OnReceiveDataFromMaster handler and object reguistration rules) does not include accessing predefined items because you cannot be sure that they have already been loaded from the exchange message.

c) The infobase update handler script that processes predefined items is not executed in subordinate infobase nodes:

If ExchangePlans.MasterNode() = Undefined Then
    // fill predefined items
    // ...
EndIf;

1.4. We recommend that for tables with predefined items that are not included in the distributed infobase exchange plan (and are not referenced by other tables included in the exchange plan) you set the PredefinedDataUpdate property to AutoUpdate.

If you use the compatibility mode with version 8.3.3, on the first start of a subordinate node (right after its configuration update) set automatic data update using the following script:

Catalogs.<CatalogName>.SetPredefinedDataUpdate(PredefinedDataUpdate.AutoUpdate);

2. In some cases automatic creation of predefined items is not required. This includes cases when the availability of predefined items depends on some condition (functional option values, application mode, and so on).

For example, the availability of predefined items in the Accruals chart of calculation types can depend on the values of the following functional options: UseHourlyWorkTimeRecords, UsePieceworkWages, and so on.

If this is the case, do the following:

• Set the PredefinedDataUpdate property of a catalog, chart of accounts, or chart of characteristic types to Do not update automatically.
• Write the script that creates predefined items depending on the business logic (and marks them inactive), for example:

If GetFunctionalOption("UseHourlyWorkTimeRecords") Then
    AccrualObject = ChartsOfCalculationTypes.Accruals.CreateCalculationType();
    AccrualObject.PredefinedDataName = "HourlyPayment";
    // ...
    AccrualObject.Write();
EndIf;

• When writing script algorithms, take into account that the predefined items might be not available (accessing an unavailable item throws an exception):

  ... = ChartOfCalculationTypes.Accruals.HourlyPayment;
  ... = PredefinedValue("ChartOfCalculationTypes.Accruals.HourlyPayment");

Using the Active property of register records

This article describes the standards that apply to setting the Active property of register records. All of the listed recommendations are mandatory unless noted otherwise.

If your configuration includes functionality that changes the Active property of register records (for example, you might use this for manual record correction), we recommend the following:

1. All queries to register records and reports based on those records must take into account the value of the Active property. Use the following condition to filter out inactive records:

WHERE Active = TRUE

If your query selects records from virtual tables linked to registers, 1C:Enterprise always retrieves active records only (because virtual register tables only contain active records).

2. In particular, the Active property of register records must be taken into account in universal reports (and in the universal business logic in general) that utilize data from various configuration registers because those registers might store inactie records.

3. When a document that allows manual correction of register records is unposted, do not delete its records, make them inactive instead. Example of such document is General Ledger Entry (this document is intended for manual adding of general ledger entries).

See also:

• Document posting requirements
• Writing register records

Document posting requirements

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

1. Documents are intended for entering source data related to events that affect accounting records. For example, in business activity automation this includes business activity accounting records, while in manufacturing activity automation this includes manufacturing records.

2.1. Registering an event (adding its data to accounting records) is performed by posting a document. Most of the documents should be posted (their Posting property should be set to Enable).

From the logical point of view, an unposted document is a "draft" that does not affect accounting records. Such documents can be saved even if they are not fully filled or not filled at all, they are not subject to any checks or business logic restrictions (such as fill checks or date change restrictions). Their data is not included in reports.

And a posted document is an approved one, it is fully filled, processed, and included in the accounting records.

2.2. If a document lifecycle includes several processing stages, you can create additional document statuses to reflect these stages. For example, a Customer Order document can have the following statuses: "open", "backordered", and "closed". An Invoice document can have the following statuses: "open", "invoiced", and "paid".

In such scenarios the first posting creates an initial accounting record, while the document statuses affect the record details. 

If a document is posted, changing its status might require filling specific document data, and status-specific fill checks and business logic restrictions might apply. If a document is not yet posted, the system does not perform any status-specific checks and does not apply any restrictions.

Examples of status-specific document behavior:

• A posted Customer Order in the "open" status does not create additional register records.
• A posted Customer Order in the "backordered" status writes register records that store the quantity of goods yet to be delivered.
• A draft Invoice in the "open" status does not require filling the "Due date" field.
• A posted Invoice in the "invoiced" status requires filling the "Due date" field.

2.3. The following documents are exceptions to the "Most of the documents should be posted" rule:

• Documents that are not intended for generating accounting records. These are documents that record events with time stamps: incoming messages, calls, meetings, and so on. 
• Documents whose posting procedure is very different from the standard 1C:Enterprise posting procedure, but from the user perspective this should look like standard posting. Examples of such documents are General Ledger Entry (this document is intended for manual adding of general ledger entries) and Manual Adjustment (this document is intended for manual corrections of accounting records and is only available during applied solution testing).

Such documents are never posted.

2.4. When a user needs to record an event and generate the corresponding accounting records in a single operation, they have to create a document and save it in the posting mode.

Implementing this in a different way is not allowed. In particular, disabling the posting is not allowed.

3.1. To reflect an event in accounting records, you might need to generate "secondary" data that has complex relations with points in time, periods, or other system objects. Such data should be stored in registers. The register records should be generated during posting (automatically or manually).

If you select automatic generation of register records, users record the event data to the document and the register records are generated during the document posting. For example, bookkeeping transactions generate register records automatically.

If you select manual generation of register records, users can record data directly to registers using documents referred to as manual operations. They can use them for entering initial balances or for registering business activities that cannot be described by standard business activity documents available in the configuration.

3.2. In rare cases you can use a separate document for generating register records. This makes sense in scenarios where several document types require similar processing, bulk document processing is involved, or parts of complex business processes require different user rights. In such scenarios a series of events can be implemented as a document chain, one document based on another, rather than a single document that changes statuses. Some parts of the document chain might not require posting.

For example, a Customer Order is created in the Sales department and it cannot be changed during the posting. In this scenario the Customer Order is created by a salesperson and never posted, while a logistics specialist checks that the requested quantity of goods is available and creates the Shipment document, which is intended for generating register records and is based on the Customer Order document.

3.3. Unposted documents and documents marked for deletion must not have active records.

3.4. Even if a document does not generate register records, its posting should still be enabled. This is required to make a visual difference between draft and approved documents.

4. In most scenarios recording accounting data can be undone (use the undo posting feature provided by the platform).

See also:

• Metadata object names in configurations
• https://1ci.zendesk.com/hc/en-us/articles/360007971773Using the Active property of register records
• Self-sufficiency of registers

Limitations to usage of composite-type attributes

This article describes the standards that apply to the usage of composite-type attributes. All of the listed recommendations are mandatory unless noted otherwise.

2.1. Do not use AnyRef, CatalogRef, DocumentRef, and similar composite types for typed metadata objects stored in the infobase. Specify the types of typed objects explicitly.

Universal algorithms intended for processing reference objects of various types are an exception to this rule.

2.2. If a composite type is widely used in objects belonging to a specific subsystem or in the entire configuration, we recommend that you use defined types.