Complex periodic calculations. Basic measurement property of the calculation register Calculation register 1c lectures

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 (retroactive entry of documents), 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 out-of-date 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 the 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 a plan for calculation types “Main”, its calculation types (for example, the calculation type “Additional allowance”) must be set in the list of leading calculation types for the “Auxiliary” plan calculation types (for example, the calculation types “Personal surcharge” and “Monthly surcharge”). 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".

One of the tasks solved using calculation registers is obtaining register revolutions using queries to a virtual table of basic data or the GetBase() method. Register turnovers are obtained based on a large number of different source data, including settings and contents of the plan of calculation types, settings of the calculation register, parameters of the virtual table of basic data, etc. But one of the significant roles in obtaining basic data is played by the calculation register measurements.

The role of dimensions in parameterizing a virtual table of basic data

One of the important parameters of the virtual table of the basic data is the list of dimensions by which register entries are compared when summing the data. To solve different problems, you may have to sum register resources over different sets of dimensions. Let's look at the example of a register intended for calculating salaries and having three dimensions:

Organization,
Individual,
Subdivision.

Let's imagine that it is necessary to solve the following problems:

Obtaining for certain records of the register of turnover of the register for all records with the same division as the original record. This could be, for example, the calculation of an allowance, depending on the accruals of the entire department.
Obtaining turnover from records with the same Individual and Division. Those. receiving the amount of employee accruals that were accrued to him in the same department (accruals for the same employee that he received in other departments are excluded).
Receiving turnover from records with the same Individual and the same Organization (all accruals to the Individual within the same organization).

All of the above tasks are solved using queries to a virtual table of basic data. In this case, the parameters “Main register measurements” and “Base register measurements” will be different for all three tasks. In the first case, there is one dimension - “Division”; in the second - “Individual” and “Unit”; in the third - “Organization” and “Individual”.

Optimizing baseline data acquisition

For the cases listed above, when generating a query to a virtual table of the base data, the system will, in terms of the query language, perform a “left join” of the calculation register table with the same table. In this case, one of the connection conditions is the equality of the values in the fields specified as dimensions of the main and base register. Of course, in addition to this condition, there is a comparison of the validity period or registration period with the beginning and end of the base period, comparison of calculation types, etc., but the most “strict” limitation, as a rule, is the limitation on measurement values.

Thus, for the resulting query to work effectively, it is important to have an index on the calculation register table that contains the fields of the compared dimensions as the first fields.

The ability to index the dimensions of the calculation register allows us to solve such a problem, but only for the case when one dimension is compared (in our example, the task of obtaining data for a department). In the case where there are two or more comparable dimensions, it is necessary to build an index for several dimensions at once.

This is exactly the problem that the Basic dimension property of the calculation register allows you to solve. By setting this property to multiple dimensions, the configuration designer thereby creates an index on all dimensions marked as “base” (for more details, see the section “Database Table Indexes”).

From the above, it is clear that only one such index can be created for a calculation register to optimize the acquisition of basic data by selecting certain dimensions. Thus, during development, it is important to correctly assess which virtual tables will be used most often, and whose performance optimization is most important.

Let's return to our example. Let's imagine that accruals that require obtaining data on an individual and a department will be less common during configuration operation than accruals that require obtaining data on an individual and an organization. Then the “Organization” and “Individual” dimensions should be noted as the basic dimensions. At the same time, we will have to put up with the fact that obtaining basic data on an individual and a department will be relatively slow.

When choosing base measurements, one should also evaluate their “selectivity”, i.e. imagine how many values there will be in a particular dimension when operating the configuration. Let’s imagine that in our example, one individual may have very few (one or two) organizations and relatively many divisions. Those. An individual is almost always paid a salary for one organization, and at the same time, salaries are often calculated for different departments. Under such circumstances, it makes more sense to select the “Individual” and “Division” dimensions as the base ones.

But it is important to remember the order of measurement of the calculation register...

About the order of measurements in the calculation register

The fact is that when creating an index that will facilitate obtaining basic data, the system includes dimensions in it in the sequence in which they are located in the configuration tree. This means that simply by “switching” the “Individual” and “Division” dimensions, we will change the order of the fields in the index.

In our example, if the dimensions “Individual” and “Divisions” are selected as the base ones, then by rearranging them, we will not change the speed of obtaining basic data for an individual and a division, but we will radically worsen the situation with obtaining data for an individual and organization. When comparing values in the “Organization” and “Individual” fields, the system will not be able to use the Division+Individual index, since the “Individual” field is not the first in it, and the condition is not imposed on the division. And in the case of the Individual+Division index, both the receipt of basic data for the division and the individual, and the receipt of basic data for the organization and the individual will benefit, since the “Individual” field will be the first in the index, the system will be able to use it “partially” (one field at a time) . At the same time, the “Individual” field has much greater “selectivity” than the “Organization” field and it will not take much time to work out the conditions for the organization.

If the base dimension is one

Let’s not forget about the task in our example, which involves obtaining basic data only for a department. It would seem that creating an index Individual+Division to solve the other two problems excludes the effective operation of a virtual table of basic data for one dimension “Division”. But here we need to remember about the possibility of indexing register dimensions (Indexing property). The ability to index a dimension allows you to effectively solve the problem of obtaining a database based on one basic dimension.

Thus, in the example we considered, it is necessary to set the Basic property to the “Individual” and “Division” dimensions, the Indexing property to the “Division” dimension, and also make sure that the “Individual” dimension is “higher” than the “Division” dimension (the order of the “Organization” dimension " is not important).

Learning to work with registers (1C: Accounting 8.3, edition 3.0)

2016-12-08T13:50:45+00:00

Dear readers, in this lesson I want to touch on an extremely important topic when working in 1C: Accounting 8.3 - Registers.

I’ll immediately show you with a small example why this is so important.

Let us have a payroll for January:

At the beginning of February, we create a payroll slip from the cash register and click the “Fill” button:

And we get the following:

But for January:

Accrual of 50,000 rubles
Personal income tax 6,500 rubles
Total payable 43,500 rubles

Where did the error creep in? Something went wrong? Is it really possible to always enter the amount to be paid manually now?

An experienced accountant will immediately make a balance sheet for account 70:

And he will be even more bewildered, because according to the report, the same 43,500 are still due for payment! And where did the extra 5,000 rubles come from?

Moreover, such a situation (with any calculations) can happen both in the “troika” and in the “two”.

Today I will try to lift the veil of secrecy - why sometimes the program behaves so strangely. I will tell you how to find and fix the error in such cases. Towards the end of the article we will figure out where these 5,000 rubles came from.

So, let's go!

Learning to see registers

When posting documents, 1C:Accounting 8 makes entries to accounting accounts (the DtKt button for any document):

It is on the basis of these transactions that all accounting reports are built: Account analysis, Account card, Balance sheet...

But there is a huge layer of data that is written by the program in parallel with the postings and is used for everything else: filling out KUDIR, a book of purchases and sales, regulated reporting... wages payable, finally

As you probably already guessed, this layer is called registers, here he is:

Now I will not go into details of the description of the registers themselves, so as not to confuse you even more.

I will only say that it is simply vital for us to gradually learn to “see” movements in these registers in order to better understand and, when necessary, correct the behavior of the program.

Let's take a closer look at the "Salaries payable" register - it is this that makes sense for solving our problem with the extra 5,000:

We see two entries in this register made in the arrival, that is, in plus. If we scroll to the right of the screen, we will see in the first line the amount to be paid “-6,500”, and in the second “50,000”.

The balance in this register -6,500 + 50,000 is equal to 43,500, which should be included in the document “Statement for payment from the cash register” when we click on the “Fill” button.

I repeat once again - the payment statement determines our wage arrears to the employee not according to account 70, but according to the “Salaries payable” register.

It turns out that we know that the salary to be paid is filled out based on this register, but even seeing the register entries we cannot understand what is wrong.

Most likely, we do not see the whole picture (maybe there are other records for this register) and some tool for analyzing the register, similar to accounting reports, suggests itself.

Learning to analyze registers

And there is such a tool, it's called " Universal report".

Go to the "Reports" section and select "Universal report":

Select the register type “Accumulation Register”, the “Salary Payable” register and click the “Generate” button:

It turned out not very informative:

This is because preliminary setup of the report is required, click the “Show settings” button and on the “Grouping” tab add the “Employee” field:

On the “Selections” tab we make a selection for our organization:

Click the "Generate" button:

Now this is more interesting. We see the balance to be paid to our employee is the same 48,500 rubles!

Go to the report settings again and add a new field “Recorder” to the “Indicators” tab:

We generate the report again:

Now we can clearly see that 5,000 appeared as a result of the operation (apparently entering balances) on December 31, 2014.

And we need to either change this operation or manually adjust the “Salaries payable” register and close these 5,000 rubles, for example, on December 31, 2015.

Let's go the second way. So, our task is to make sure that at the beginning of 2016 there is no debt to the employee in the “Salaries Payable” register.

This is done by manual operation.

Learning to adjust registers

Go to the "Operations" section and select "Operations entered manually":

We create a new operation at the end of 2015:

From the "More" menu, select "Select registers...":

Specify the "Salary to be paid" register and click OK:

Go to the register tab that appears and make an expense of 5,000 rubles:

By doing this, we are subtracting 5,000 rubles from the register per employee in order to reach zero by the beginning of 2016.

We carry out the operation and regenerate the universal report:

Everything worked out! We see that our manual operation dated December 31, 2015 brought the balance to zero and the salary payable after accrual is equal to the expected 43,500.

Amazing. And now we will check this in the payment statement.

But first I want to draw your attention to another important point:

Please note that the balances at the beginning and at the end for the “Employee” group show nonsense. This is not a mistake, it is a nuance that needs to be taken into account related to the architectural features of 1c.

Remember. In the event that a universal report is displayed with detail down to the document (registrar), the balances by grouping will show nonsense.

If we require balances by employee grouping, we must first remove the “Registrar” indicator we added from the settings.

The mechanism of complex periodic calculations allows you to implement various payroll models. The operation of the mechanism is based on two components.

On the one hand, the mechanism for complex periodic calculations contains tools for describing various types of calculations that will be used in the application solution. For example, this could be such types of calculation as salary, alimony, fine, etc. In addition to the actual description of these types of calculations, it is possible to set rules according to which some types of calculations will influence other types of calculations.

On the other hand, this mechanism provides the ability to store intermediate data that is used to perform calculations and the final results of calculations.

The operation of the mechanism for complex periodic calculations is ensured by two objects of the application solution:

Plan of calculation types and Calculation register.

The plan of calculation types is used to describe the calculation types and their mutual influence on each other. In an application solution, there can be an arbitrary number of plans for calculation types, depending on the implemented accounting model:

The calculation register is used 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. An application solution may contain several calculation registers designed to reflect data from a specific accounting section:

Plan of calculation types

Structure of the calculation types plan
The plan of calculation types is a list of calculation types. Each type of calculation has a code, name and a set of details containing additional information about this type of calculation:

For example, a plan for calculation types Basic Accruals of Organizations may look like this:

The creation and editing of calculation types can be performed both by the developer (predefined calculation types) and by the user while working with the application solution. However, the user cannot delete calculation types created by the developer.

Calculation types created in a calculation type plan can influence each other. The system supports two types of such influence: dependence by the base period and displacement by the validity period.

For each type of calculation, you can specify a list of calculation types on which it will depend for the base period, and which will supersede it for the validity period.

For example, the type of alimony calculation may depend on the base period on the following types of calculation:

And the calculation type Salary can be replaced by the calculation type Absenteeism:

In addition to these dependencies, so-called leading types of calculation can be specified for a type of calculation - those on which it does not directly depend, but which can influence it through other types of calculations.
Calculation types plan forms
In order for the user to view and change the data contained in the plan of calculation types, the system supports several forms of its presentation. The system can automatically generate all the necessary forms; Along with this, the developer has the opportunity to create his own forms, which the system will use instead of the default forms:

To view calculation types, use the list form. It allows you to navigate through the list, add, mark for deletion, and delete calculation types. The list form allows you to sort and select the displayed information according to several criteria:

To view and change data for individual calculation types, use the calculation type form. As a rule, it presents data in a form that is easy to understand and edit:

In addition to these two forms for calculation types, a form for selecting specific calculation types from the list is supported. It usually contains the minimum set of information necessary to select one or another type of calculation.

Calculation register

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

Register dimensions describe the sections in which information is stored, and register resources directly contain the stored information. For example, for the calculation register Basic Accruals of 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 connection causes each register record to have a Calculation Type field, 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 terms of created measurements, but also in terms of time. This is the reason for the existence of another required field for each calculation register entry - 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

Preemption by validity period
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, a settlement register entry contains two dates that define the period over 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 be determined only after analyzing all records of calculation types that supersede this type of 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.

Dependency by base period
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.

Generating recalculation records
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 of presentation of 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
The main functionality that the calculation register provides to the developer is:

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.

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 associated with 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 the tables of source documents by listing the 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

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;
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;
Allow totals for a slice of the first and Allow totals for a slice of the last: (let's 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 the appearance of the register, as well as 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:

Budgeting;
International;
Tax;
Self-supporting.

The second parameter characteristic of accounting registers is “Correspondence”.

Checking this box allows you to create double entries 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.