1C:Enterprise 8.3. Core Development Techniques Tutorial. Tools for scheduled reporting and accounting.

Tools for scheduled reporting and accounting

1C:Enterprise 8 provides a number of tools for creating a system of scheduled indicators that can be used for:

• scheduled reporting;

accounting in accordance with local and international standards;

• tax accounting;

• budgeting;

• etc;

You can implement the following:

adding new types of indicators in real time;

a system of connected indicators (i.e., changes in one indicator impact another indicator);

various methods to group indicators by different parameters to generate reports.

If we use the accumulation registers to handle these tasks, to add a new indicator we will need to create a new accumulation register with the structure customized in Designer, define the indicator dependence algorithm, and develop a new report.

This is why the best method for handling these tasks is to use the following group of configuration objects:

charts of accounts: the structure and types of indicators;

charts of characteristic types: storing conditions for indicator values and types of accounting objects;

accounting registers: storing general conditions and changes in the indicator values.

From a technical point of view, any chart of accounts can be viewed as a kind of catalog (with new capabilities and limitations) optimized to store the structure and types of indicators at the system level:


For instance, any chart of accounts is a hierarchical entity with a hierarchy of elements22 that does not have any system limitations for its hierarchical levels (without an option to change this rule by object customization, that is why the configuration object editing window does not contain a Hierarchy tab); however, you can see the Parent field in the list of standard attributes.

Or you can note that the code is now of string type only, with new types of attributes (Accounting flags and Extra dimension accounting flags), new standard attributes, and a standard tabular section having been added, as well as a new Extra Dimension tab and other properties and methods.

An applied solution may contain any number of charts of accounts.


A chart of accounts is a configuration object, so you can only create a new chart of accounts or delete an existing one in Designer mode.

Task 20

1. Create a chart of accounts to store additional management and scheduled indicators, and name it Types of indicators.


2. Specify the code length (= 150) and the description length (= 200).


3. Set the default presentation of the account to As description:


4. Set the system to check the uniqueness of account numbers within a group:


You can fill a chart of accounts (create new chart elements) both at the configuration stage (predefined accounts) and at run time (1C:Enterprise mode).

Task 21

1. Create Trade and Financial groups of indicators in Designer.


2. At run time, create CashAvailable and DebtToClients elements in the Financial group:


You cannot delete a predefined element of a chart of accounts in 1C:Enterprise mode:


You cannot mark the item for deletion either.


In 1C:Enterprise mode, you cannot change the values of some standard attributes of chart of accounts elements, as well as change or delete predefined strings of a standard tabular section. The following warning appears when you try to perform these actions, i.e., try to write a predefined account with the changes you made in 1C:Enterprise mode:


Any predefined account has a name by which it will be called in software modules:

TradeIndicators = ChartsOfAccounts.IndicatorTypes.SelectHierarchically(ChartsOfAccounts.IndicatorTypes.Trade);

You can use registers to register any changes of indicator values in the 1C:Enterprise 8 system (accumulation registers were reviewed previously). When working with accumulation registers, we used a separate accumulation register for each indicator. We will need to use configuration objects to implement a system of indicators:


An accounting register is a system that registers changes in indicator values. Records are entered into the accounting register (just as in the accumulation register) to change indicator values. A record may increase or decrease the value of an indicator.

To increase the value, use Debit (+), which is similar to the Receipt accumulation register.

To decrease the value, use Credit (–), which is similar to the Expense accumulation register.

An accounting register has to be connected with a specific chart of accounts: 


Information on the type of value change is stored in the standard attribute named RecordType:


The structure of an indicator value is defined through a set of resources of the accounting register. The resources (value components) may only be numerical. The CashAvailable and DebtToClients values are changed and analyzed in the totals view, so we need to create a Total resource of type NUMBER 10.2.


An accounting register may exist in the database configuration if it has at least one resource.

To change indicators, we will need a document that cannot be posted, but with record registration enabled in the SystemOfIndicators accounting register.


You will also need to enable interactive access to the DocumentForm register:


If you try to save a document that contains a record in the accounting register in 1C:Enterprise mode, the system will display the following warning:


This warning is displayed due to a property of the resource contained in the Balance accounting register, which is set to TRUE when a resource is created in the register structure:


This resource property is necessary to create a balanced system of indicators, i.e., a system in which a change in any one indicator value necessarily brings about changes in one or more other indicators in such a way that the total of all changes (all receipts and expenses) within a single document and for a single time period (a specific Document+Period moment) is equal to 0.


Creation of independent indicators may be enabled in two ways:

Option 1. A global rule for the system of indicators (in Designer mode, in the accounting register)

To enable registration of independent indicators, disable the balance feature for both resources. 

Afterwards, the system will record any correction made to indicators, even for a single record. You can verify this by opening a list of records in the IndicatorsList accounting register (for example, via the All functions menu).


Option 2. Individual settings for an indicator (in Designer and 1C:Enterprise modes, in the account settings).

You can disable the "balanced indicators" rule for an individual account by clearing the Off-balance check box.


Limitations to changing the check box value:

You can only select and clear the check box in 1C:Enterprise mode for a non-predefined account if there are no records for this account in the accounting registers.

You can select and clear check boxes for predefined elements only in the Designer mode. In this scenario, the system does not control the availability of records in the accounting registers. (CAUTION!)

Accounting registers (AR) allow you to define the scope of your indicators (I):


To define a list of available indicators for your scope, you need to specify the object from which the system will take different types of indicators. In our example, the Types of indicators chart of accounts functions as such object.


Therefore, the definition of an accounting register is closely connected with the chart of accounts. It does not make sense to use an accounting register without a chart of accounts, since the chart of accounts stores types of indicators to be changed through the accounting register.


To create the connection with a chart of accounts, you need to select a data type for the standard Account attribute.


The standard Account attribute may not be of composite type, that is why the accounting register may be connected with a single chart of accounts only. However, this does not prevent us from using a single chart of accounts in different accounting registers:


When you create a system of indicators, you can define three basic models for the scope of indicator values:

a system of independent indicators (similar to accumulation registers);

a system of connected indicators (a bundle of 2 indicators);

a system of balanced indicators (bundles of indicators groups).

Task 22

1. Create an accounting register named SystemOfIndependentIndicators and connect it to the Types of indicators chart of accounts. 

2. Create an accounting register named SystemOfBalancedIndicators and connect it to the Types of indicators chart of accounts.  

3. Create an accounting register named SystemOfConnectedIndicators and connect it to the Types of indicators chart of accounts.


Before we continue specifying register settings, review the specific features of your models in greater detail.

Model 1. A system of independent indicators: when one indicator changes its value, another indicator does not necessarily have to change its value immediately.


To implement this model, you need to do the following:

1)  Disable use of correspondence in the accounting register settings.

2)  Clear the Balance check box in the accounting register resource settings.

Model 2. Connected indicators: if we change the value of one indicator, it will immediately change another one, i.e., the indicators always function as a bundle. Integration of two indicators is defined by the Correspondence setting of the accounting register.

1C:Enterprise 8 provides tools for creating a combined model based on the correspondence model (model 2).

To enable the use of an unbundled (independent) indicator in this model, the standard attribute OffBalance of Boolean type is provided in the indicator (account) settings.

Using this attribute only makes sense in this indicator system model.  

You cannot change the value of the OffBalance attribute for predefined accounts in 1C:Enterprise mode.


Task 23

1. Set the correspondence rules for the accounting registers that you created.

2. In 1C:Enterprise mode, create the Stored Goods account in the Trade group to be able to use the account without correspondence with other accounts.

If you try to update the database configuration (F7) at this stage, you will receive the following warning:

and the following messages:

As you see, we need to define resources for the accounting register.

From the physical point of view, resources are used in accounting registers to define the measurement system for the values of your indicators:

For example:

The value of the CashAvailable indicator is measured with the total:


The value of the InventoryBalance indicator is measured with the total sum and the amount:

Therefore, you will need two resources for your system (for the simplest scenario): the total sum and the amount. Resources of the accounting registers can be of Number type only (similar to the accumulation register).

Task 24

Create TotalSum and Quantity resources in the accounting registers that you created.


Task 25

Create the CorrectingIndicators document with posting prohibited for manual editing of indicator values through accounting registers. Specify this document as the recorder for your accounting registers: SystemOfIndependentIndicators and SystemOfConnectedIndicators.


Then update the database configuration.

In 1C:Enterprise mode, we will only see two fields in the Correcting Indicators document: Number and Date.


To enable interactive access to your registers through the Correcting Indicators document, you need to create a document form in Designer mode.

Task 26

1. Start the Document Form Wizard for the document:


2. On the wizard page that is opened, click Finish.

If you look at the resource settings in the accounting register, you will see a new resource property — Balance.


Complex periodic calculation features

Periodic calculations are calculations performed with certain periodicity, closely connected with one another by certain rules, and mutually influencing each other within a certain period of time.

Periodic calculations are mostly used to calculate wages.

As a rule, employees’ wages consist of many components (salary, bonuses, sick leaves, penalties, etc.). Each of these is calculated using a certain algorithm. For example, bonus amounts may be calculated as a percentage of salary, while salary might be calculated based on a number of workdays in a month or a number of days actually spent at work. Each accrual may be matched with a certain calculation type. An algorithm for each calculation type is generally based on two parameter categories: a period for which we need to get final data and a set of certain source data used in your calculation.

In the real world, different calculation types generally do not exist by themselves, but rather exert certain influence on other calculations. Since a calculation type depends on two different kinds of parameters, this influence is also of a twofold nature.

First of all, source data used in the calculation may be affected. For instance, when a salary changes, the bonus amount should also be recalculated based on the new salary amount, i.e., the salary amount is the basis for calculating a new bonus. In addition, since the salary is calculated for a given period, when calculating bonuses we need to know not just the basic salary amount, but rather the total that is calculated for the period affecting the bonus calculation. We’ll refer to such a period as a base period, and the corresponding dependency between calculation types will be referred to as being dependent on a base period.

The second factor that may be influenced is not the source data, but the calculation period itself.

Imagine a rather common real-life situation: an employee schedules a leave for one of the months of the year. Leave allowance was accrued and paid before the beginning of the leave. Calculation of the leave allowance is registered for the one-month period (when the calculation was made) that precedes the month when the leave was taken. The month for which the leave allowance was accrued is called an action period. 

Assume that the leave allowance is calculated based on the employee’s average salary (taking into consideration the accruals for the 3 months that precede the leave). The period we use to calculate the accrual is called the base period.

Let us present the rules described above graphically on the time scale.

You can see that the actual action period of the salary has changed and requires recalculation. This is called displacement by action period.

Thus, based on the two kinds of mutual influence of calculations, we can say that there are generally three periods associated with each calculation type: the action period, the actual period, and the base period.

The action period is the "requested period", that is, by specifying the action period, we say, "We would like the result to be valid for that period."

The actual period is an action period modified in the analysis of all calculation action periods that displace your action period.

The base period is a period within which we analyze the results of other calculations that influence ours by base period.

Therefore, mutual influence between different types of calculations is differentiated and multilevel.

Obviously, these tasks call for some kind of universal feature that will allow you to define each of these calculation types (its algorithm, influence on other calculation types, and dependencies), to provide storage of data obtained as a result of these calculations, and to monitor the need to recalculate the results of dependent calculations in the event of changes to the results of "primary" calculations.

Configuration objects Charts of calculation types and Calculation registers provide such a feature in 1C:Enterprise 8.

The Chart of calculation types configuration object is an applied object designed to define structures for storing information on the available calculation types. Based on a Chart of calculation types configuration object, the platform will create an information structure in the database to store information about what calculation types exist, and what their interrelationships are.

An applied solution may contain any number of charts of calculation types depending on the accounting model implemented. Each chart can have a number of characteristics typical for the calculation types that it contains.

The Chart of calculation types object properties are edited in the editing window and in the properties palette.

On the Data tab, you can enter a set of attributes that contain additional information on the calculation type. A set of attributes can be seen in the configuration tree as well.

Let us review the content of the Calculation tab.

The Chart of calculation types configuration object has a property called Uses action period. This property defines whether an action period is used by the calculation types of a chart of calculation types. If at least one calculation type in the chart will have the action period property, the Uses action period property will be set to TRUE. You can also set a list of replacing calculation types for each calculation type.

Another important property of the Chart of calculation types configuration object is Dependence on base. It indicates whether this chart of calculation types contains calculation types that are dependent on a base period. If at least one calculation type has a calculation base, the property will be set. If that property is set, you will be able to indicate which chart of calculation types will contain the base calculation type, and likewise indicate how that dependence will be defined.

Calculation types may be created and edited by a developer (predefined calculation types) or a user working with the applied solution. However, the user may not delete the calculation types created by the developer.

Predefined calculation types are entered in the Predefined Calculation Types window that is opened by clicking the Predefined button on the Other tab.

You can see predefined tabular sections by adding a new calculation or editing an existing one in the Predefined Calculation Types window.

A chart of calculation types contains the following predefined tabular sections: base calculation types, displacing calculation types, and leading calculation types.

Base calculation types. The calculation types that define the structure of the calculation base of the current calculation type are specified in the Base calculation types tabular section. 

For instance, a predefined calculation type Salary may be the base for a predefined calculation type Leave.

Availability of the Base calculation types tabular section is defined with the Dependence on base property. If the Dependence on base property is not defined, the base calculation types concept makes no sense. You can specify calculation types from other charts that are defined as base charts of calculation types. 

Displacing calculation types. The calculation types that displace the current calculation type by action period are specified in the Displacing calculation types tabular section. Only the calculation types that belong to the same chart of calculation types may be displaced.

For instance, Salary is displaced by Absence and Leave.

Leading calculation types. The calculation types that require recalculation of the current type when they are entered or modified will be specified in the Leading calculation types tabular section. If several charts of calculation types are specified in the configuration, calculation types from other charts of calculation types may be specified as the leading ones.

For instance, Salary is the leading calculation type for Bonus.

The Action period as a base period property of predefined calculation types is set in Designer and may not be changed by users in 1C:Enterprise mode.

The calculation register is a configuration object that supports accounting of calculation results obtained in the course of calculations specified in the chart of calculation types. In other words, calculation registers are used to accumulate information on periodic calculations.

When you edit a calculation register, you need to specify the list of calculation types, action period and basic period support, and periodicity, and to develop its structure: sets of dimensions, resources and attributes, as well as screen forms and print forms for viewing register records.

Each calculation register is connected to one of the charts of calculation types that exist in the applied solution. Because of this connection, each register record has a Calculation type field. The register uses this field to monitor the mutual impact of different register records. You can specify only one chart of calculation types for the calculation register.

Information in the calculation register is stored as records, each of which contains dimension values and the corresponding resource values. Register dimensions describe the sections where information is stored, while register resources contain this stored information (numerical values only). 

The calculation register stores data by dimensions and by time. This is why each record of the calculation register contains another mandatory parameter — Action period. If the Action period check box is selected, the calculation register record will have the following properties available: ActionPeriod, BegOfActionPeriod, EndOfActionPeriod, and Schedule. At the calculation register development stage, the developer may set the minimum periodicity of adding records into the register. It should be noted that the ActionPeriod property is a date that takes discrete values depending on the periodicity of the calculation register. The value of the ActionPeriod property is cast to the beginning of the period (month) after the BegOfActionPeriod date and does not always match the BegOfActionPeriod date.

If the Base period check box is selected, the properties BegOfBasePeriod and EndOfBasePeriod of the calculation register record become available.

The state of the calculation register is usually changed when a document is posted. This is why each register record matches a certain document (the recorder) and some lines in the tabular section of this document. In the register, you only can simultaneously add, modify, or delete all of the records related to a single document.

The system checks the uniqueness of the records stored in the calculation register. Therefore, the calculation register cannot contain two records related to a single line of a single document.

You can specify a connection between a calculation register and a time scale. The Schedule property is available if the Action period property is set. A time scale is an information register that contains a time model of the source data used in calculations. The data used as a time scale cannot be periodic. Instead, it will have a dimension of Date type. The dimensions of that information register may, for example, be a work schedule and a date, while the resource may reflect the number of work hours on that date. Then we will be able to connect a calculation register record with some specific work schedule and later obtain information on the number of work hours that is required to perform the calculations with the help of a script.

A calculation register can include objects called recalculations.

In recalculations, the system will store information about which calculation register records are no longer up-to-date and should be recalculated due to the following features: dependence on the base period and displacement by action period. Several recalculations of different structures intended for handling different tasks may be supported for a single calculation register. A subordinate object of a Recalculation register can have several dimensions, each of which can set the connection between the dimensions of this calculation register and the leading calculation registers. In some cases it can be the same register.

Calculation registers implement the following features:

• Displacement by action period

• Dependence on base period

The displacement by action period feature helps define the actual action period of the calculation register record by analyzing other records that this register contains.

As a rule, a calculation register record contains two dates that define the period to which this record is applicable. This period is called a record action period. However, if a calculation type to which this record refers may be displaced by another calculation type, the action period of this record is only a "requested" period, i.e., "we would like the record to be valid for that period". In reality, the actual action period for this record may only be defined after all the records of calculation types that displace this calculation type by action period are analyzed. The actual action period is a set of periods that are a subset of the source action period of this record. If no record that displaces this one by action period is found, the actual action period of this record will be equal to its action period. Another extreme in this scenario, i.e., displacement by action period, is full displacement of this record by other records. In this case, a record will not have any actual action period.

Each calculation register record contains a calculation type to which it relates. In order to identify which records will displace this record by action period, the calculation register uses the connection to a chart of calculation types that describes the mutual influence of calculations upon one other. The calculation register uses this connection to define the actual action period for each record.

The dependence on the base period feature helps obtain the base value for the calculation register record by analyzing the other records that this register contains.

The base is a numerical value used to calculate the result of the record. The base is calculated by analyzing the calculation results of other records on which this record depends by base period. Therefore, as a rule, the calculation register records contains the base period, i.e., two dates defining the period within which calculation type records should be analyzed.  The connection to a chart of calculation types enables the calculation register to define the calculation types on which this calculation type depends by base period.

Calculation registers support two dependencies by base period:

• Dependence by action period 

• Dependence by registration period 

If dependence by action period is used, the records for which an intersection is found between their actual action period and the base period of the record will be selected for the base. The base value received from a specific record that impacts the calculation will generally not match the result contained within that record. The base will be calculated in proportion to the part of the impacting record’s actual period that intersects with the specified base period. The data of the schedule connected to this record will be used.

If dependence by registration period is used, the calculation results of those records whose Registration period field values match the base period of this record will be selected to form the base. If the record’s registration period (a registration period is a date that has discrete values depending on the periodicity of the calculation register, i.e., it matches the beginning of a month) matches the base period, the record will be accounted in full. Otherwise it will be excluded from processing in full.

The most complex scenario of dependency by base period is when the Base period as action period property is set for the calculation type of the record. This property means that an actual action period of the record obtained through the displacement by the action period feature and generally presented by a set of certain periods will be used as the base period of this record instead of the base period specified in the appropriate fields of this record.

The recalculation record generation feature monitors the appearance of new records in the register that impact the calculation result of existing records. To identify whether new records may impact existing ones, you need to analyze the mutual impact of different calculation types and consider how the displacement by action period and dependence by base period features function. 

The recalculation record generation feature outputs a set of recalculation records that contains the list of register records to be recalculated. 

A recalculation record contains information on RecalculationObject — a reference to the document that created records to be recalculated, the calculation type, and the recalculation dimension.

Recalculations are registered by the system automatically or with the help of a script.

In 1C:Enterprise 8 recalculations function on a "per-notification" basis, i.e., the developer may decide on their own whether the register records need to be recalculated.

Below is a list of major calculation register functionalities that developers can use:

selecting records in the specified interval by the specified criteria; 

• selecting records by recorder; 

obtaining the base value for the register records complying with the specified filter;

obtaining the schedule data for the register records complying with the specified filter;

obtaining data on the records to be recalculated; 

reading, modification, and writing of a set of records into the register. 

Working with calculation registers with script tools

You can retrieve data from a calculation register using queries or script methods. A selection of calculation register records can be created with the

Select and SelectByRecorder methods of the CalculationRegisterManager object. By using the

GetScheduleData(<Filter>,<PeriodType>) method, you can obtain the number of actual work days of an employee (specify the actual action period in the <PeriodType> parameter) and the days norm (specify the action period in the <PeriodType> parameter).

Use the GetAddition() method of a set of records of the calculation register to reverse records. This method gets additional data to reverse records related to previous registration periods when the current record set is entered. The data is obtained as a table with the following structure: all predefined calculation register record fields except the recorder and record number, all dimensions, resources and attributes, and additional fields such as reversing registration period, reversing start date, and reversing end date.

An addition is the data that the system provides to add to the current record set. This allows you to increase the actual action period of the current records by reversing records belonging to previous registration periods (if necessary). The additional reversing entries are generated based on the action periods of the calculation register records and action period displacement rules, which are set by the displacement calculation type lists in the register's chart of calculation types.

It is necessary to get an addition if you try to enter an accounting record with the action period that is "occupied" by another record, which has a registration period that is less than yours. In the resulting table of values the fields are filled with data from the reversing entries (already existing in the calculation register) and with other additional data: the reversing entry registration period (the registration period within which the system recommends registering a reversing entry) and reversing period start and end dates (the period that the system recommends to enter as a reversing entry action period).

Leave a Reply

Your email address will not be published. Required fields are marked *

1C:Enterprise Developer's Community