1C:Enterprise 8.3. Practical Developer’s Guide. Lesson 17 (1:00). Charts of calculation types and calculation registers. Understanding calculation registers

Understanding calculation registers

The Calculation register configuration object is intended to describe the structure of accumulated data resulting from calculations. Based on the Calculation register configuration object, the platform creates database tables that store accumulated data generated by various database objects.

Calculation registers are not designed to be edited directly by users. A developer can allow users to edit a calculation register, if required. However, normally calculation registers are modified by algorithms of other database objects, rather than through a direct user intervention.

Just like any other register, a calculation register has resources where it stores numerical data, it has dimensions used for getting register resource values by those dimensions, and it has attributes, which describe each calculation register record.

What makes calculation registers different is their periodicity, the ability to use the algorithms of displacement by action period and dependency by base period, and the connection with a chart of calculation types. We will discuss each of these features in the following sections.

Periodicity

The periodicity of a calculation register can have one of the following values:

  • Day
  • Month
  • Quarter
  • Year

The calculation register periodicity defines the time period where each register record belongs.

If the periodicity is set to Day, each record in the register belongs to some day; if periodicity is set to Month, each register record belongs to some month, and so on.

To reflect the fact that a record belongs to a certain period, the register has the RegistrationPeriod system attribute of the Date type. When writing data to the register, the platform always sets the value of that attribute to the beginning of the period where the data belongs.

For example, if data is written to a calculation register with periodicity set to Month, and the RegistrationPeriod for that data is 4/8/2014, the register stores the data with the RegistrationPeriod value set to 4/1/2014 (fig. 17.6).

Lesson 17 (1:00). Charts of calculation types and calculation registers / Understanding calculation registers / Periodicity 
Fig. 17.6. Recording document data to a calculation register

If you set the register periodicity to Year in this scenario, the stored registration period value changes to 1/1/2014 (fig. 17.7).
Lesson 17 (1:00). Charts of calculation types and calculation registers / Understanding calculation registers / Periodicity
Fig. 17.7. Recording document data to a calculation register

Displacement by action period

Another important feature of a calculation register is the ability to displace certain records with other records by action period.

In doing so, each calculation register record generates an actual action period which, in general, represents the sum total of several periods contained within a single action period (fig. 17.8).

Lesson 17 (1:00). Charts of calculation types and calculation registers / Understanding calculation registers / Displacement by action period
Fig. 17.8. Absence calculation record displaces a Salary calculation record by action period

After adding a salary accrual record, the structure of calculation register table records looks as shown in tables 17.1 and 17.2.

Table 17.1. Calculation register table

... Beginning of action period End of action period Calculation type ...
... ... ... ... ...
... 04/01/2014 00:00:00 04/30/2014 23:59:59 Salary ...
... ... ... ... ...

Table 17.2. Actual action period table

... Beginning of action period End of action period Calculation type ...
... ... ... ... ...
... 04/01/2014 00:00:00 04/30/2014 23:59:59 Salary ...
... ... ... ... ...

After adding records from the Absence calculation type, which displaces Salary calculations by action period, the records related to salary calculation look as shown in tables 17.3 and 17.4.

Table 17.3. Calculation register table

... Beginning of action period End of action period Calculation type ...
... ... ... ... ...
... 04/01/2014 00:00:00 04/30/2014 23:59:59 Salary ...
... 04/04/2014 00:00:00 04/10/2014 23:59:59 Absence ...
... ... ... ... ...

Table 17.4. Actual action period table

... Beginning of action period End of action period Calculation type ...
... ... ... ... ...
... 04/01/2014 00:00:00 04/03/2014 23:59:59 Salary ...
... 04/11/2014 00:00:00 04/31/2014 23:59:59 Salary ...
... ... ... ... ...

Dependency by base period

Another calculation register feature is support of register record dependency by base period. This feature is intended for calculating dependent (secondary) register records based on the result of primary record calculation.

A calculation register can support two types of dependency by base period: dependency by action period and dependency by registration period.

Dependency by action period

Dependency by action period means that when the platform analyzes base records, it selects the records where the actual action period and the specified base period overlap.

For example, at the beginning of April, March payroll is calculated. Bonuses for March are calculated based on March salaries. In this scenario, as a rule, developers use dependency by action period (fig. 17.9).

Lesson 17 (1:00). Charts of calculation types and calculation registers / Understanding calculation registers / Dependency by base period / Dependency by action period 
Fig. 17.9. Dependency by action period

There are two comments to be made regarding the figure above.

The Beginning of base period and End of base period fields are applicable only for the records with calculation types that have dependencies by base period specified (in this case, for calculation of bonuses).

The base value received from a specific record that influences a calculation generally is not equal to the result stored within that record. The base value is calculated based on the ratio between the part of the actual period of the influencing record that overlaps the base period and the full actual period of the influencing record, and also on the schedule data linked to record.

Dependency by registration period

Dependency by registration period means that when the platform analyzes base records, it selects the records whose Registration period field value falls within the specified base period.

Let us consider an example of penalty calculation for March salary accruals. Absence records registered in March serve as a base for calculating the penalty amounts (these can include March absence records as well as February absence records. In this scenario, as a rule, developers use dependency by registration period (fig. 17.10).

Lesson 17 (1:00). Charts of calculation types and calculation registers / Understanding calculation registers / Dependency by base period / Dependency by registration period 
Fig. 17.10. Dependency by registration period

The final important feature of a calculation register is its connection with the chart of calculation types. This connection enables displacement by action period and dependency by base period, since a chart of calculation types describes the interrelationship between calculation types.

A calculation register can have subordinate Recalculation objects. They are used to register the fact of adding register records that affect the calculation results of existing register records. A Recalculation configuration object can have multiple dimensions, each specifying a connection between the dimensions of this calculation register and the dimensions of calculation registers that influence it. In some scenarios it can be the same register.

The platform stores the list of register records that are subject to recalculations in database tables based on Recalculation configuration objects. Recalculation tables are populated automatically based on calculation register records that are affected by leading calculation types, as well as on calculation register records that have their actual periods changed. Based on this data, a developer can decide whether the register records require recalculation.

The last observation that we need to make regarding calculation registers concerns the ability to link a calculation register to a schedule. The schedule should be represented by an information register (nonperiodic, with a mandatory dimension of Date type, and a resource of Number type), which contains time-based source data used in the calculations. The dimensions of that schedule can be, for example, a work schedule (a reference to a catalog) and a date, and its resource can store the number of working hours for that date. In this scenario you can link a calculation register record to a specific work schedule (by specifying a reference to a work schedule catalog as a record attribute) and then use 1C:Enterprise script tools to get the number of working hours in the action period, actual period, or registration period for each record.

Learn more! For details on the structure of 1C:Enterprise script objects intended for calculation register operations, see section Quick developer reference. Calculation registers.

Leave a Reply

Your email address will not be published.

 

1C:Enterprise Developer's Community