Virtual tables of the calculation register 1s. Complex periodic calculations

  • 10.09.2023

In this article we will look at theoretical foundations work with calculation registers, and also perform calculations wages employee in proportion to the number of hours worked.

Theory

Calculation register (RR)- a configuration metadata object used to implement periodic calculations in the 1C system. The obvious areas of application of calculation registers include the following: payroll calculation, rent calculation, rent calculation.

In their structure, calculation registers are similar to accumulation registers or information registers. They, just like accumulation registers, have measurements, resources, details, but the principle of operation of calculation registers is completely different.

At their core, measurements in the accumulation register serve as “ filter» in the context of which we receive data from the accumulation register. As an example, when we take “remains” according to the accumulation register “Remaining goods” in the context of a certain item or a “cut of the latest” according to the information register “Employee salaries” in the context of a certain employee. In contrast to the accumulation register, measurements in the periodic calculation register serve to implement ““(this is when time-extended calculation types compete with each other over the interval of the record’s validity period, i.e., as an example, the business trip calculation type displaces the salary calculation type for the validity period) and ““(this is when the type of bonus calculation depends on the type of salary calculation for previous periods).

repression mechanism by period of action«:

Here we see that the “Business Trip” calculation type has a duration in time and is valid from April 10 to April 20, “Business Trip” is indicated as a displacing calculation type for the “Salary” calculation type. The “salary” also extends over time and is valid from April 1 to April 30. Since “Business trip” is indicated as a displacing type of calculation for the calculation type “Salary” (has a higher priority than salary) and is valid for the period of validity of the salary, then the salary is displaced by a business trip and the “Actual period of validity of the salary” is formed.” Actual period of validity of the salary “This is the period of validity of the salary after displacement by a business trip; in our case, it consists of 2 periods - from April 1 to April 9 and from April 21 to April 30 and in total is 19 days. The period-based displacement mechanism only works for long-term calculations.

The figure above graphically shows the principle of " dependence mechanism by base period«:

Let’s say that at the end of April 2017 we want to give an employee a bonus in the amount of 10% of the salary. Salary is indicated as the basic type of calculation for bonuses.

But as a “base” for calculating the premium, we will not take the entire month of April, but only the interval from April 10 to April 20 (11 days). Let's calculate the base for the bonus, the employee's salary is 60,000 rubles, there are 30 days in a month, daily salary = 60,000/30 = 2,000 rubles. Next 2000*11 = 22000 rub. The basis for calculating the premium is 22,000 rubles.

Let's calculate the premium: (22000/100)*10 = 2200 rubles. A bonus of 10% of the salary is 2,200 rubles.

The application metadata object “Plan of calculation types” is closely associated with the calculation register.

Plan of calculation types (PVR)- a configuration metadata object that stores information about the types of calculation types and determines the influence of different calculations on each other.

One calculation type plan can be used in several calculation registers, but one calculation register cannot use several calculation type plans at the same time.

The calculation register is a table in which calculated data is stored, and in terms of calculation types, algorithms for calculating this data are stored. The calculation register must have at least one document registrar that makes movements in the calculation register (for example, Payroll).

The calculation mechanisms in the 1C Enterprise system are designed in such a way that you first need to make entries in the calculation register and only then perform the calculation based on this data. For example, it is impossible to calculate a bonus based on a salary until this same salary is recorded in the calculation register.

Practice

Let's take a closer look at the calculation registers in practice:

Step 1 Let's start with a plan of calculation types. You must create a calculation type plan before creating a calculation register. We create a plan for calculation types before the calculation register because before creating a table for storing calculated data (i.e., a calculation register), it is necessary to specify algorithms for calculating this data (i.e., a plan for calculation types).

Let’s create a plan for the types of calculation “Basic charges”. Let’s immediately go to the “Calculation” tab. Here we immediately see the flag " Uses validity period", when this flag is set, all types of calculations included in this plan will have length in time(for example, Salary, Business trip), and also for this plan of calculation types, “ repression mechanism by period of action". If the flag “Uses the validity period” is not set, then the types of calculation will not have an extension in time (for example, Bonus, Fine) and the “displacement mechanism by validity period” will not operate. Also on this tab there are sections “Dependency on the base” and “Basic plans for calculation types” - they serve to implement “ dependence mechanism by base period“, but we’ll talk about it later. For now, let’s leave “Dependency on the base” in the “Independent” mode.

Let’s create a predefined calculation type “Salary”. On the “Basic” tab, everything is simple. Set the name and code of the calculation type.

Thanks to the fact that we set the flag " Uses validity period"We now have a tab" Displacing" and turned on " period-based repression mechanism«.

On this tab we indicate the types of calculations that will displace the salary by validity period (for example, Business trip).

Note: in “Displacing” you can add calculation types that belong only to this plan of calculation types.

There is also a tab " Presenters»—it indicates the types of calculations that, when changed, must recalculate the current type of calculation. Here you can also specify calculation types from other calculation type plans. For example, the “Salary” calculation type is the leading one for the “Bonus” calculation type, i.e. When the salary changes, we must also recalculate the bonus because The bonus is calculated depending on the salary. IN in this case the calculation type “Salary” belongs to the PVR “Basic accruals” using the validity period, and the calculation type “Bonus” belongs to the PVR “ Additional charges» not using a validity period.

Step 2.Let's create a directory “Graphs” with the default structure. In the “Schedules” directory we will store the working hours of employees (five-day, six-day, etc.).

Step 3.We also need an object in which we will store the Production calendar (working days and weekends). For these purposes, we use a non-periodic independent register of information.

Let’s create a non-periodic independent information register “Work Schedules” with 2 dimensions “Date” and “Schedule” and the resource “Number of Hours”.

Thanks to the “Work Schedules” information register, we will be able to calculate wages from the salary in proportion to the number of days worked.

Step 4.Create a “Payroll” document with the details structure shown below:

Details:

Operational execution is set to “Prohibit” because it does not make sense for the mechanism of periodic settlements in 1C - we never calculate bonuses, salaries, or fines in real time.

Let's create a document form with default settings.

Step 5. Finally, we got to the point of creating calculation registers.

The calculation register metadata object is located in the “Calculation registers” branch of the configurator.

Let’s create a calculation register “Basic charges”. Let's look at the calculation register settings below:

1. In the “Plan of calculation types” field, indicate the PVR “Basic charges” created in step 1.

2. Set the “Validity period” flag to “True” because The PVR specified in step 1 has extension in time.

After setting this flag, the standard details “Action Period”, “Action PeriodStart”, “ActionPeriodEnd” immediately become available to us, which means that the types of calculations registered in this calculation register also have length in time and we have access to " repression mechanism by period of action«.


P.S. If you specify a PVR that has length in time for a RR with the “Validity Period” flag set to “False”, then this PVR will work as a PVR that does not have extension in time.

3.After setting the “Validity period” flag to “True”, the fields “Chart”, “Chart value”, “Chart date” become available to us.

In the “Schedule” field we indicate the “Work Schedules” information register created in step 3.

In the “Schedule Value” field we indicate the “Number of Hours” resource in the “Work Schedules” information register.

In the “Schedule Date” field we indicate the “Date” dimension of the “Work Schedules” information register.

4.In the “Frequency” field we indicate the value “Month”, this means that the data will be entered into the register on a monthly basis.

Below is the registry metadata structure:

The “Basic” flag for a dimension only affects performance; you don’t have to set it, but if you do, the “Employee” field will be indexed.

The "Employee" dimension - it is used in " repression mechanism based on the period of action" And " mechanism of dependence on the base period«.

Resource “Amount” - the calculated salary will be recorded there.

The “Chart” attribute is indicated as an attribute, and not a register dimension, because neither it nor it displaces anything - essentially a reference field. Important!!! Don't forget to fill out the "Schedule Link" field at the “Schedule” attribute, the “Schedule” dimension of the “Work Schedules” information register must be indicated there, otherwise the salary amount will not be calculated.

The “Parameter” attribute will store the salary value.

Now that we have indicated the connection with the “Work Schedules” MS, we will calculate the employee’s salary in proportion to the number of days worked.

We indicate the document as the registrar " Payroll" created in step 4.

Step 6. We make movements according to the calculation register “Basic charges”.

Let's return to the “Payroll” document created in step 4.

Let us describe the processing of posting in the document object module:

Fragment of document processing processing code

1C (Code)

Procedure ProcessingProcessing(Failure, ProcessingMode) // register BasicAccrualsMotion.BasicAccruals.Write = True; Movements.MainAccruals.Clear(); Registration Period = Start of Month (Date); For Each TechLine MainAccruals From MainAccruals Cycle Movement = Movements.MainAccruals.Add(); Move.Reversal = False; Movement.CalculationType = TechLineMainAccruals.CalculationType; Movement.ActionPeriodStart = TechLineMainAccruals.StartDate; Movement.ActionPeriodEnd = EndDay(TexLineMainAccruals.EndDate); Movement.Registration Period = Registration Period; Movement.Employee = TechLineMainAccruals.Employee; Movement.Chart = TechStringMainAccruals.Chart; Movement.Parameter = TechStringMainAccruals.Size; EndCycle; End of Procedure

ProcessingProcedure(Failure, Mode)

// Main Accruals register

Movements. BasicAccruals. write = true;

Movements. BasicAccruals. Clear() ;

Registration Period = Beginning of Month (Date) ;

For each TechLine BasicAccrualsFrom BasicAccrualsCycle

Movement = Movement. BasicAccruals. Add() ;

Movement. Storno= False;

Movement. Calculation Type=TexLineMainAccruals. Calculation Type;

Movement. PeriodActionStart = TechLineMainAccruals. Start date;

Movement. ActionPeriodEnd=EndDay(TexLineMainAccruals.EndDate) ;

Movement. Registration Period = Registration Period;

Movement. Employee = TechLineMainAccruals. Employee;

Movement. Chart = TechLineMainAccruals. Schedule;

Movement. Parameter = TechStringMainAccruals. Size;

EndCycle;

End of Procedure

Let's create a test document and run it:

Let’s go to “Document Movements”:

We see that the registration period is set to the beginning of the month because The periodicity of the RR is indicated as “Month”. We also see that all fields except the amount have been filled in (the salary has not yet been calculated).

Step 7.Let's write the payroll calculation code.

Let's create a general module "Calculation" with the following flags:

The calculation itself will take place in this general module.

Let’s write the export function “Calculate charges” in the “Calculation” module:

Since we filled out the fields “Schedule”, “Schedule value”, “Schedule date” in the settings of the RR “Basic charges”, a virtual table of the calculation register became available to us DataGraphics, in a query to a virtual table we are interested in the following fields:

“Number of Hours Actual Action Period” — contains the number of hours actually worked calculated based on the schedule data

"Number of HoursAction Period" - contains the number of working hours calculated based on the schedule data in the calculation period

Payroll calculation procedure

1C (Code)

Procedure CalculateAccruals(Registrar, Set of Records) Export //Salary Request=New Request; Query.Text="SELECT | ISNULL(BasicAccrualsGraphicsData.NumberofHoursActualActionPeriod, 0) AS HoursFact, |BasicAccrualsGraphicsData.Parameter, | ISNULL(BasicAccrualsGraphicsData.NumberofHoursActionPeriod, 0) AS HoursPlan, |BasicAccrualsDataGr afika.Line Number |FROM |Calculation Register.Basic Accruals.Graphics Data(| Registrar = &Registrar | AND Calculation Type = &Calculation TypeSalary) AS Basic AccrualsDataGraphics"; Request.SetParameter("Registrator", Recorder); // pass the document to the registrar so that the search is performed only on the current document Request.SetParameter("Calculation TypeSalary", Plans of Calculation Types. Basic Accruals. Salary); //set the type of calculation salary because calculate the salary Selection=Request.Run().Select(); SearchStructure=NewStructure; SearchStructure.Insert("RowNumber",0); //create a structure for searching data for calculation by line number For Each Record From RecordSet Cycle //cycle through the set of records of the current documentSearch Structure.LineNumber=Record.LineNumber; //fill in the line number for search If Selection.FindNext(Search Structure) Then //we look in the sample for data for calculation using the current line number Record.Sum =?(Selection.HoursPlan=0.0, Sampling.HoursFact/Sample.HoursPlan * Sampling .Parameter); //calculate salary in proportion to days worked, in Parameter - current salary EndIf; Selection.Reset(); //reset the selection, we need the next record of the recordset to search through the selection first EndCycle; Recordset.Write(, True); //write the calculated records to the database, pass the parameter Replace = True EndProcedure

//Salary

Request=New Request;

Request. Text="SELECT

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActualActionPeriod, 0) AS HoursFact,

| BasicAccrualsDataGraphics.Parameter,

| ISNULL(BasicAccrualsDataGraphics.NumberofHoursActionPeriod, 0) AS HoursPlan,

| BasicAccrualsDataGraphics.NumberLines

|FROM

| Calculation Register. Basic Accruals. Graphics Data (

| Recorder = &Recorder

Calculation registers- these are application configuration objects. They are used in the mechanism of complex periodic calculations and serve to store records about certain types of calculations that need to be performed, as well as to store intermediate data and the results of the calculations themselves.

Structure

Information in the calculation register is stored in the form of records, each of which contains measurement values ​​and corresponding resource values.

Measurements registers describe the sections in which information is stored, and resources registers directly contain the stored information. For example, for a calculation register Basic accruals for employees of organizations, which has the following structure:

The records stored in the database will look like this:

Relationship to calculation types plan

The calculation register is associated with one of the calculation type plans that exist in the application solution. This relationship causes each register entry to have a field Type of calculation, thanks to which register mechanisms can track the mutual influence of calculation records on each other.

Periodicity

The calculation register stores data not only in the context of created measurements, but also in the context of time. This is the reason for each calculation register entry to have one more required field - Validity period. When creating a calculation register, the developer can specify the minimum frequency with which entries will be entered into the register:

Subordination to the registrar

A change in the state of the calculation register usually occurs when a document is posted. Therefore, each register entry is associated with a specific document - a registrar and the line number of this document. Adding entries to the register, changing them and deleting them is only possible simultaneously for all entries related to one document.

Relationship to Timeline

The calculation register can be linked to a time schedule. A timeline is a register of information that contains a time diagram of the source data involved in the calculations. The dimensions of this schedule can be, for example, the work schedule and date, and the resource can be the number of working hours on this date. Then it will be possible to associate a calculation register entry with a specific work schedule and in the future, using the built-in language, obtain information about the number of working hours necessary to perform calculations.

For example, a timeline with the following structure:

Recalculations

The calculation register may include special objects - Recalculations:

In these objects, the system will store information about which entries in the calculation register have lost their relevance and are subject to recalculation as a result of the operation of the dependency mechanisms for the base period and eviction for the validity period.

Uniqueness of records

The system provides control over the uniqueness of records stored in the calculation register. Therefore, the calculation register cannot contain two entries relating to the same line of the same document.

Mechanisms implemented by the calculation register

The validity period preemption mechanism allows you to calculate the actual validity period of a settlement register entry based on an analysis of other entries contained in the register.

IN general case, the settlement register entry contains two dates that define the period to which the entry is valid. This period is called the entry validity period. However, if the calculation type to which a given entry relates can be superseded by another calculation type, then the validity period of the given entry is only a “requested” period, that is, “we want the entry to be valid in this period.” In reality, the actual period of validity of this record can only be determined after analyzing all records of calculation types that displace this type calculation by validity period. The actual validity period will be a set of periods that are a subset of the original validity period of the entry. If no record is found that displaces the given one in terms of validity period, then the actual validity period of this record will be equal to its validity period. Another extreme case of lifetime eviction is when a given record is completely ousted by other records. In this case, there will be no actual validity period for the entry.

Each settlement register entry contains the settlement type to which it relates. To determine which entries should supersede a given entry by validity period, the payroll register uses a link to the payroll types plan, which describes the mutual influence of payroll types on each other. Using this relationship allows the payroll register to determine the actual validity period of each entry.

The base period dependence mechanism allows you to obtain the base value for a calculation register entry based on the analysis of other entries contained in the register.

The base is the numeric value that must be used to calculate the result of a given record. The base is calculated by analyzing the calculation results of other entries on which this entry depends for the base period. Thus, in the general case, a calculation register record contains two dates that determine the period in which it is necessary to analyze records of calculation types on which this type of calculation depends on the base - the base period. Using the link to the calculation type plan allows the calculation register to determine the calculation types on which a given calculation type depends for the base period.

The calculation register supports two types of dependence on the base period:

  • dependence on the period of validity;
  • dependence on the registration period.

In the case of a dependence on the validity period, to obtain the base, those records will be selected for which the intersection of their actual validity period with the base period of this record is found. The value of the base that will be obtained from a particular influencing record is generally not equal to the result that this record contains. The base will be calculated in proportion to the portion of the actual period of the influencing record that overlaps with the specified base period. This will use the chart data associated with this record.

In case of dependence on the registration period, to obtain the base, the results of calculation of those records that fall into the base period of this record by the value of their “Registration period” field will be selected.

The most complex version of the dependence on the base period is the case when the “Validity period is the base period” property is set for the calculation type of this record. This property means that the base period of this record will be used not the base period, which is specified in the corresponding fields of the record, but the actual validity period of the record, obtained as a result of the operation of the eviction mechanism for the validity period and which, in the general case, is a set of some periods.

The mechanism for generating recalculation records monitors the fact that records appear in the register that affect the calculation result of existing records. The possibility of new records influencing existing ones is determined as a result of an analysis of the mutual influence of calculation types and based on the operation of the displacement mechanisms for the validity period and the dependence for the base period.

The result of the mechanism for generating recalculation records is a set of recalculation records containing information about which register entries should be recalculated (recalculated).

Calculation register forms

In order for the user to view the data contained in the calculation register, the system supports a form for presenting the calculation register - a list form. It allows you to sort and select the displayed information according to several criteria:

The system can automatically generate this form. Along with this, the developer has the opportunity to create his own forms that the system will use instead of the default form, including a record set form that allows you to add, change and delete calculation register entries.

Calculation register functionality

Main functionality that the calculation register provides to the developer are:

  • selecting records in a given interval according to specified criteria;
  • selection of records by registrar;
  • obtaining the base value for register entries that satisfy the specified selection;
  • obtaining schedule data for register entries that satisfy a given selection;
  • obtaining data on records subject to recalculation;
  • reading, modifying, and writing a set of records to a register.

The Recalculation object is used to store information about for which calculation register records the calculation results (resources) need to be recalculated. It is a configuration object subordinate to the calculation register. The need to recalculate resources may arise due to an incorrect sequence of document input by the user (document input " retroactively"), which leads to the need to recalculate the calculation results of those records that depend on the calculation results of other records entered into the system later.

Recalculation object settings

Information about records requiring recalculation can be stored in varying detail.

Allocation records contain predefined fields:

  • Recalculation object – a link to the registrar whose calculation results need to be revised;
  • Calculation type – a link to the calculation type from the plan of calculation types that is assigned to the register that owns the Recalculation object.
Thus, at a minimum, information about recalculations is stored accurate to the registrar (document) and type of calculation.

To more accurately identify outdated settlement register entries, you can enter allocation measurements. This will allow you to narrow down the list of records that require recalculation.

Let's look at an example.

If the calculation register stores data on the accrued basic salary of the organization's employees and, thus, the calculation register has the "Employee" dimension, then the recalculation can also have the "Employee" dimension. This will lead to the fact that recalculation records will mean the need to recalculate those register entries that belong to a specific registrar, have a certain type of calculation and contain a link to a specific employee.

The conversion table can be filled in automatically by the system based on the settings made during configuration. Automatic tracking of records for which a revision of the result is required is the main purpose of the recalculation object.

Allocation dimensions are one of the tools that allow you to configure this automatic allocation filling.

This is done using the properties of the allocation dimension:

  • Register dimension – a link to the dimension of the “parent” calculation register to which the recalculation is subordinated.
  • Leading register data – links to measurements and details of leading calculation registers.
In order to describe the peculiarities of setting up recalculation measurements, we will agree on the following terms:
  • The main register is the calculation register to which recalculation is subordinated and which it “monitors” the relevance of the results.
  • Leading registers are calculation registers whose entries affect the result of the calculation of the main register entries.
If the system already has main register records, then any change in the composition of the leading register records should lead to the appearance of recalculation records. These recalculation entries will signal the need to recalculate one or another set of main register entries.

In order to describe exactly what changes in leading register entries will lead to the appearance of recalculations, recalculation measurements are used. To specify the need to recalculate records for the same employee for whom leading register records were entered (changed), do the following. A link to the "Employee" dimension of the main register is entered into the "Register Dimension" property, and links to the "Employee" dimension of all leading registers are entered into the "Leading Register Data" property. With this setup, in the event of any change in the composition of the leading register records (i.e. when writing the corresponding set of records), the following will happen:

  • A set of leading register records has been analyzed (let’s say the set of records contains records for employee Ivanov that have a certain validity period (for example, March)
  • The main register will be automatically requested
  • If it already contains records, according to Ivanov, and their result potentially depends on the records of the leading register (what “potentially depends…” means will be discussed below), then lines with the following data will be entered into the recalculation:

In this case, rows will be entered only if such rows are not already in the conversion table.

It should be noted that the appearance of recalculation entries does not mean any changes directly in the main register. Recalculation records are nothing more than a signal that the system gives. And how exactly to react to this signal about the need to recalculate register entries depends on the developer of a particular solution. We will discuss examples of processing recalculation records in other publications.

Calculation type plan settings related to allocations

The dependence of some register entries on others is built through the settings of plans for calculation types. The following concepts are used for this:

  • Variant of dependence on the base – property of the plan of calculation types;
  • Basic plans of calculation types – property of the plan of calculation types;
  • Leading types of calculation - property of the type of calculation;
  • Base period – details of the calculation register entry;
  • Validity period – details of the calculation register entry;
  • Registration period – details of the calculation register entry.
Let’s say that the main calculation register is assigned the “Main” calculation type plan, and the leading register is assigned the “Auxiliary” calculation type plan. Then the main plan of calculation types needs to set the following properties of the "Calculation" property group:
Dependence on the base – “by validity period” or “by registration period”;
Basic plans for calculation types – plan for calculation types “Auxiliary”.

This will mean that the main calculation register, which behaves according to the “Main” calculation type plan, depends on those registers to which the “Auxiliary” calculation type plan is assigned (i.e. in our case, the leading calculation register) and at the same time the entries The main register depends on the master records by validity period or by registration period.

When setting up the “Main” calculation type plan, its calculation types (for example, the “Additional payment” type of calculation) must be set to the “Auxiliary” plan calculation types in the list of leading calculation types (for example, the “Personal surcharge” and “Monthly surcharge” calculation types). This will mean that the results of calculating the main register entries with the calculation type "Additional allowance" depend on the results of the leading register entries with the calculation types "Personal surcharge" and "Monthly surcharge" and must be recalculated in the event of any change (appearance or deletion).

At the same time, in order to find out which records need to be recalculated, the system will compare the records of the leading and main calculation registers:

  • by type of calculation,
  • when the validity period (or registration period) of the leading register records falls within the base period of the main register records
  • and by the Employee dimension, which was described above.
This material will allow you to make settings that will lead to automatic filling of conversion tables. For some tasks, automatic completion may not be enough. In such cases, you should generate allocation records using the built-in language of the system. This is discussed in detail in the section "Entering allocations using the built-in language".

In the 1C:Enterprise system, calculation register objects are designed to record the results of calculations carried out with a certain periodicity, closely related to each other according to certain rules and mutually influencing each other within a certain period.

Calculation register properties

Along with the general properties inherent in all metadata objects, calculation registers have a number of specific properties.

Editing the calculation register is performed in the editing window.

When editing a calculation register, a plan for calculation types is determined, support for the validity period and base period, periodicity, the structure of the register is developed: sets of dimensions, resources and register details are created, if necessary, screen and printed forms for viewing register movements are created.

Plan of calculation types- the main characteristic of the register. Select one of the objects of the type "Plan of calculation types".

Validity period- if the property is established, then the competing nature of the mutual influence of movements of a given register is established. Examples of competing movements include payroll and sick leave - you cannot be sick and work at the same time, i.e. receive both salary and money sick leave. Such calculations are mutually exclusive in time, and the system must ensure that entering one of them will eliminate the other.

Schedule Validity period. The property represents a link to the information register, which describes the temporal scheme of the source data involved in the calculation. The schedule should be indicated for those calculations that depend on initial data distributed within the validity period according to a certain rule. For example, this could be a schedule for recording the organization’s working hours broken down by day, recording lecture hours broken down by hour, etc.

Graph meaning- the property is available if the property is set Validity period. In the property, the resource of the information register defined in the property is selected Schedule.

Schedule date- the property is available if the property is set Validity period. In the property, select the dimension of the information register defined in the property Schedule and having the type Date. The value of this property is used to bind to the values ​​of the information register resource specified in the Chart Value property.

Base period- if the property is established, then the related nature of the mutual influence of the movements of a given register is established. Examples related movements may serve as a connection between calculating the accrual amounts based on the average of the accrual amounts in the base period.

Periodicity- defines the period with which movements are recorded and within which movements can influence each other (for registers that support an action period).

Recalculations- subordinate register objects that allow you to set rules for the mutual influence of register movements. In the object properties palette, in the Relationship in Property group Measurement register specifies the main dimension of the current register, which should be recalculated when changing the data of the leading registers specified in the property Data leading registers. For example, recalculation of the deduction amount for an individual will be formed when accruals (wages, bonuses) change.

If the property is set Base period, then the generation of recalculation data will be performed automatically. If the property is not set, then the generation of recalculation data must be done manually by the user (during design, a special form for entering recalculations and a mechanism for their execution should be developed).

On the "Other" tab, you set the object blocking mode (automatic or controlled) and set the full-text search feature for objects of this type.

Calculation registers

Calculation registers are designed to store calculation records (intermediate and final results). Register forms allow you to view settlement records. For example, the figure below shows the form of the Main Accruals register.

As you can see, in this register for each individual the results of calculating basic accruals (salary, vacation), etc. are stored. Double-clicking on an entry opens the recorder document that entered this entry into the calculation register.

Each settlement register is based on a specific plan of settlement types. When editing the calculation register, its other characteristics are also indicated, for example, the frequency of calculations, support for the mechanism for obtaining the base, support for the validity period (for the preemption mechanism), schedules by which the validity periods will be controlled, etc.

The structure of the calculation register determines what information and in what sections will be stored in the register. The developer specifies dimensions, resources and register details:

Dimensions are sections of stored information. For example, the Main Accruals register will have the dimensions Individual, Organization, Division, Position, while the Taxes register will have only two dimensions: Individual and Organization.

Resources - calculation results, for example, the resource Accrued for the Main Accruals register, the resource Withheld for the Taxes register, etc. Resources can only be of numeric type.

Details are an additional characteristic of the calculation record. Details can be of almost any type stored in the database. For example, the details Days and Hours for the Main Accruals register, the DocumentBase detail for the Withholding register. The figure below shows the structure of the Employee Accruals calculation register.

Charts

If the register has the “Validity period” checkbox selected, then you can fill in the “Schedule”, “Schedule value” and “Schedule date” properties. In fact, the graph is a non-periodic register of information that describes the time distribution of the initial data for the calculation. For example, this could be the organization’s work schedule broken down by working days and hours, the duration of work shifts, the schedule of lecture hours, etc.

Below is an example of an information register that serves as a work schedule.

Recalculations

The system allows you to automatically track records that require recalculation. This situation may arise when their results are somehow related to other types of calculations, and those have been changed (deleted or new records added).

For example, when an employee’s accruals change, taxes need to be recalculated. Then, for the “NDFL” calculation type, accruals will be the leading calculation types, which is configured in terms of calculation types on the “Leading” tab.

Let's say we have calculation registers for Basic Accruals, Bonuses and Deductions. Taxes are calculated after all accruals and bonuses, as their results are used.

To automatically track the relevance of tax records for each employee, you need to create a recalculation with the Individual dimension in the Withholding register. The Individual dimension from the Basic Accruals register and the Bonuses register is assigned as the base register data.

The example below shows how recalculation works:

Changed entries are highlighted in each register. Consequently, the associated entries in the Withholding register have become irrelevant, i.e. require recalculation, which is reflected in the conversion table.

Thus, recalculation is a table that stores the values ​​of the dimensions for which recalculation is required. In addition to measurements, this table stores types of calculations and links to record documents. Using the recalculation table, you can determine which records have become irrelevant and require recalculation (or at least closer attention).

Queries to calculation registers

Queries on the calculation register data allow you to retrieve information about the calculations performed. You can access the following source tables in queries:

  • main table of calculation register entries,
  • table of actual validity period,
  • conversion table.

Using the query mechanism, you can group the calculation results in the required sections, calculate the totals, and select only the necessary calculation records. This allows you to generate the entire range of necessary reports, for example, Paysheets, Personal Accounts, Salary Payment Statements, etc. The query mechanism was described in detail in the “Queries” chapter. The list of fields in the calculation register source tables is given in the documentation.

All changes made to the database are stored in the corresponding tables. For 1C, these are tables of documents, document journals, directories and registers. The types of 1C registers, features and subtleties of their use will be discussed in our article.

Formation of entries in registers

One of the first questions about registers is: what for?

Why do you need to create separate tables, often duplicating existing records?

The answer here is quite simple. Of course, it is possible to isolate complex and time-consuming queries to tables of source documents by listing selection conditions, checking them for deletion marks and completion, but it is much simpler and less labor-intensive to create a specific slice of a set of records directly when saving the document and store it in a separate table, accessing to him as needed.

Thus, we found out that one of the ways to create a register entry is to write using a registrar (document). This option is present in all register types.

The process of generating register records based on a document is usually called document posting. An unposted document document has no movements in the registers; it is, in fact, a draft or blank.

The second option for generating a record is directly, without creating a registration document. You can create records in this way only in information registers; in the register properties, the “Record mode” attribute must have the appropriate value (Fig. 1).

Common to all registers

The internal structure of any register can be demonstrated in Fig.2

Fig.2

Let's look at it in more detail:

  • Dimensions – record properties that determine in which sections important information is stored;
  • Resources – they contain information that needs to be systematized;
  • Details – record fields that contain additional information;
  • Forms – a property that contains graphical information about the appearance of a list, element, etc. and their internal modules;
  • Layouts – printed forms of registers.

Information registers

Since we talked about information registers above, let’s talk about them.

This is probably the simplest and most understandable type of registers. A regular table containing columns and columns in which information is stored.

The list of important properties of the information register is small (Fig. 3), let's talk about the main ones:

Fig.3

  1. Periodicity, it indicates the extent to which the uniqueness of the record is controlled (within a minute, hour, day, year, in accordance with the selected value, two records with the same measurements cannot exist), it can also take the value “By recorder”, but for this you must select the appropriate recording mode;
  2. Recording mode is actually a choice of two values: “Independent” and “Submission to the recorder”.
    1. It is important to understand that choosing an independent mode does not mean that a record cannot be generated by a document; only selection by a registrar and control of the uniqueness of a record by it will be impossible;
  3. Allow totals for a slice of the first and Allow totals for a slice of the last: (we will combine two points into one) – when the appropriate checkboxes are checked, a request to the information register can be made using additional tables (Slice of the first and Slice of the last), which contain the corresponding data sets, as one of The parameters of these tables are the date on which it is necessary to make a selection of data.

Accumulation registers

We saw the structure of one of them in Fig. 2. The main property that greatly influences appearance register, as well as on its internal structure is “Register type” (Fig. 4)

Depending on the requirements for the stored information, it can take the following values:

  • Leftovers;
  • Revolutions.

In the first case, the database will contain information not only about the movements of resources in terms of dimensions, but also about the type of operation (receipt or expense). In addition, when creating a query, an additional table containing totals will be available.

One of the main problems that novice developers face when using the Balances and Balances and Turnover tables in queries is that when a query receives balances for a specific date, the data in these tables may differ. And there is one nuance here: when specifying a certain value as the end date of a period, the platform takes data from the Remaining table without including this value in the selection period.

If you require data that includes the end of the period, you can:

  • Use the table Balances and Turnovers;
  • Make a sample for a date 1 second greater than the specified one (i.e. not 12/31/16 23:59:59, but 01/01/17 00:00:00);
  • Use the Boundary method, which helps configure the option of including a point in time in the period under consideration (use case: Boundary(EndDate,Including).

Accounting registers

Quite specialized registers, in their design, resemble accumulation registers. The main difference from other types of registers of the 1C platform is the presence of the “Chart of Accounts” parameter in the property structure (Fig. 5).

Fig.5

The chart of accounts is a separate metadata object that requires a separate discussion. Depending on the chart of accounts, modern standard 1C configurations contain 4 main accounting registers:

  1. Budgeting;
  2. International;
  3. Tax;
  4. Self-supporting.

The second parameter, characteristic of accounting registers- “Correspondence”.

Checking this box allows you to create double records containing the credit account AccountKt and the debit account AccountDt and the analytics (subconto) corresponding to these accounts. If the checkbox is not checked, only one account will be entered in the register entries.

Calculation registers

These are probably the most difficult registers to understand. Meanwhile, in their essence they are very much reminiscent of accumulation registers of the “Turnover” type.

The defining difference between the calculation register and other registers is the presence in its properties of the “Calculation type plan” parameter. In addition, the calculation register, as well as the information register, is periodic.

In each calculation register, the ability to link a record with a time schedule specified in the corresponding information register can be enabled. This allows you to obtain working time data using a code.

In addition to the dimensions, resources and forms available in other types of register, calculation registers can be assigned a “Recalculation” object, where information about records that are irrelevant and require revision will be stored.

Their main use in standard 1C configurations is registration and facilitation of work with accruals for employees of the organization.