1s skd output of documents in the period. We create a report with a given frequency on the warehouse

Good day, dear readers of the blog site! In the last article, we learned what these roles are for. And today, in the second of this series of articles, we will look at setting the role with the "Period" property, and also consider examples of filling these roles. The remainder is calculated for the field with the "Period" role. The same as for the field with the “Dimension” role, which we will talk about another time. So, let's begin!

Let's create a new report:

In the Configurator, select the menu item "File" - "New" - "External report".
Click on the "Open Data Composition Schema" button. In the dialog that opens, click the "Finish" button.
Now let's create , which refers to the virtual table "Registers of Accumulation".
Let's press right click Click on the node "Datasets" and select the line "Add dataset - Query".
Now click on the "Query Builder" button. Let's select the accumulation register "Goods in Warehouses Remains and Turnovers" (USP configuration).
Let's open the "Virtual Table Options" dialog and indicate that the frequency "Auto" will be used, that is, it will be possible to specify several periods.

Now let's set up the output fields. Let it be the following fields: "Registrar", "PeriodMonth", "Nomenclature", "Quality" and information on balances. Adding a field is carried out by double-clicking the left mouse button on the desired field or using the ">" button. After adding the fields, click the OK button.

Please note that for some fields the role with the "Period" property is automatically configured.

Let's consider what are role settings for the "Period" property. First, the serial number of the period is indicated. The numbering should be continuous, starting from one, from the younger periods to the older ones, that is, first it will go, for example, the line number, then the “Registrar”, then the second, day, week, month, quarter, year.

Thus, the fields that occur in our request should be numbered. Notice that we have two period fields - "Registrar" and "PeriodMonth". The junior field is "Registrar" it is assigned one, and the senior field is "PeriodMonth" it is assigned two. We'll take a closer look at the next article.

Let's set up our report:

Let's go to the "Resources" tab and define the resources of our report.
Click on the ">>" button to select all fields for resources.
Now let's go to the "Settings" tab and create a setting in the form of a list.
Click on the button "Constructor of data composition settings" (button in the form of a magic wand).
Report type: "List". Let's press the "Next" button.
Set up the output fields by clicking on the ">>" button. Let's arrange them like this: "PeriodMonth", "Nomenclature", "Quality", "Registrar".
Click the "Next" button and configure the grouping. Grouping will be configured in the following order: "PeriodMonth", "Nomenclature", "Quality". The "Registrar" grouping will be displayed as detailed records.
Let's press the "OK" button.

Let's open our report. If we execute this report, we will see some features when receiving balances. If you look closely at the result of the report, you can immediately notice several errors. In particular, for some reason, at the very beginning of the period of the company's activity, there is an initial balance.

And this error is connected with the peculiarity of receiving balances by registrar. In order for these balances to be displayed correctly, you need to add one more field to the output fields of the request - the "PeriodSecond" field. To add the "PeriodSecond" field, open the report in the Configurator, click on the "Open data composition scheme" button. Now click on the "Query Builder" button and add "PeriodSecond". In this case, the "Registrar" field will remain the first field of the period, "PeriodSecond" will be the second, and "PeriodMonth" will be the third.

What is a second for? The data composition system calculates the residuals by calculation, and in order to unambiguously determine the position of the recorder on the time axis, the reference to the recorder itself is not enough, a second is also needed, that is, the date of this recorder, and then the composition system will be able to calculate the correct residual. If we specify the correct order of the fields and generate the report again, we get:

Now there is no balance left for the beginning of activities in the Plinth nomenclature. Further, for the next period, it coincides with the final balance, that is, we see a really correct result. You can download an example report from the link below. Did you like the article? What can be changed, what can be added? Feel free to share it in the comments!

At the end of the article I want to advise you free from Anatoly Sotnikov. This is a course from an experienced programmer. He will show you on a separate basis how to build reports in the ACS. You just need to listen carefully and remember! You will receive answers to questions such as:
How to create a simple list report?

What are the Field, Path, and Title columns on the Fields tab for?

What are the restrictions on layout fields?

How to properly set up roles?

What are the roles for layout fields?

Where can I find the data layout tab in a query?

How to configure parameters in SKD?

Further more interesting...

Perhaps you should not try to surf the Internet yourself in search of the necessary information? Moreover, everything is ready for use. Just get started! All the details about what is in the free video tutorials

Here is one of the lessons about the data composition tab in a query:

When creating reports on ACS, it often becomes necessary to display a period selection on the report form, moreover, so that you do not need to fill in dates manually, but select from a list of standard periods, such as: "Year", "Month", "Week", etc. . For parameters of the Date type, you can only specify "Start of this year, month, etc.", but "End" is not provided.

The fact is, of the data types, only the “Standard start date” type is available, but I also want the “Standard end date” type.

There is a way to get around this.

Let's create a new Parameter, call it "Period"
Set this parameter to the type "Standard period"
In the "Expression" field of the "StartPeriod" and "EndPeriod" parameters that are used in the query, set the expressions " &Period.StartDate" and " &Period.EndDate" respectively.

But there is a slight subtlety. If we use virtual tables in the query, then most likely the report will stop working and an error message will be generated like "View processing error, type mismatch, parameter number ...".

To avoid this, you need to remove all the parameters of virtual tables.

And add them to the tables on the Data Composition tab.

In order for the parameters to be displayed in the quick report settings, enable the corresponding flag for the report parameters.

Now the period selection on the report form looks like this.

Some features of setting the period in the ACS.

Most of the reports that are developed using the Data Composition System (DCS) require the user to enter the period for which the report will be generated.

As a rule, in ACS, the period input is organized through parameters, using the following construction, see. This method of entering a period is considered "classic", it is described in an article on ITS and other literature devoted to development in 1C, so let's take it as a basis. Consider, as an example, a simple query that retrieves all the Goods/Services Sales documents for a given period (see Fig.

When using this report, the user sets the period through the parameters, see. Everything seems to be correct ... BUT there is a small problem:

The thing is that the vast majority of users “understand” the period differently than 1C “understands” it, examples:

From the user's point of view, the period is not set, that is, it is NOT LIMITED, that is, ALL documents without a date limit should be included in the report.

“From the point of view” of the 1C system, the parameter-period is set and ... both of its boundaries are equal to 01.01.

From the user's point of view, all documents starting from the date 01/28/2010 should be included in the report.

"From the point of view" 1C period 01/28/2010 - 01/01/0001 will cause an exception.

Of course, you can try to explain to the user why the report does not display the documents that he expects to see and how the period is presented from the "point of view" of 1C, but this is a thankless task, and wrong. Good program should be, first of all, convenient for the user, because the program exists for the user, and not vice versa, therefore, it will be necessary to “teach” 1C to understand the period as the user understands it, namely:

one). StartPeriod and EndPeriod are not set -> all documents.

2). Only StartPeriod is set -> all documents starting from StartPeriod

3). In addition, we will check that the End of Period >= Start of the Period, and if this is not true, then we will assume that the End of the Period is not set, i.e. 2).

Based on the above, the expression for the EndDate parameter is:

WHEN &Period.EndDate=DATETIME(1,1,1)

THEN DATETIME(3999,12,31)

WHEN &Period.EndDate<&Период.ДатаНачала

THEN DATETIME(3999,12,31) DATETIME(3999,12,31,23,59,59)

&Period.EndDate

The final view of our period selection design is shown in

Note: this parameter setting mechanism is intended for old 1C 8.1 and 8.2 platforms (and configurations running under their control), older versions of the 1C platform have built-in mechanisms for controlling unfilled parameters and there is no need to resort to the mechanism described in this article, in addition on some versions of the 1C platform, errors and incorrect work are possible.

So, let's begin.

For simplicity, understanding the example, we will build on one simple reverse accumulation register.

In my case, this is the accumulation register "Work in progress accounting".

For example, we will specify its parameters rigidly (not through soft imposition of parameters on the ACS):

Note that the frequency of the virtual table is "Record".

But, as noted above, we need the period in the context of periodicity, so I propose to calculate the "Period" field in the following way (not very beautiful, but I have not seen better options):

As you can see from the screenshot, a parameter is passed to the request, which the user specifies on the form: Value of the enumeration "Periodicity" - this enumeration is available in almost all standard solutions.

Its available types are indicated on the "Parameters" tab:

With this setting, we format our period so that everything is beautiful and pleasing to the eye)

Here are the actual formats:

Month: DF="MMMM yyyy "y.""

Day: DF = dd.MM.yyyy

Week: df = ""Week from" dd.MM.yyyy "

Quarter: DF = "to "quarter" yyyy "y."

Year: DF = "yyyy "y."

Decade: DF = ""Decade since" dd.MM.yyyy "

Half year: DF = "" Half year since" dd.MM.yyyy"

That's all. As a result, we have a wonderful picture:

This article discusses some of the features of setting the period when using the Data Composition System (ACS), problems that arise due to the difference in the concept of the period between the average user and the 1C system, and also suggests ways to solve them.
Most of the reports that are developed using the Data Composition System (DCS) require the user to enter the period for which the report will be generated. As a rule, in ACS, the period input is organized through parameters, using the following construction, see Fig. Fig.1 This method of entering a period is considered “classic”, it is described in an article on ITS and other literature devoted to development in 1C, so we will take it as a basis. Consider, as an example, a simple query that retrieves all the Goods/Services Sales documents for a given period (see Fig. Fig.2 When using this report, the user sets the period through the parameters see. Fig.3 Everything seems to be correct ... BUT there is a small problem:

The thing is that the vast majority of users “understand” the period differently than 1C “understands” it, examples:
one). Consider Fig.3
From the user's point of view, the period is not set, that is, it is NOT LIMITED, that is, ALL documents without a date limit should be included in the report.
“From the point of view” of the 1C system, the parameter-period is set and ... both of its boundaries are equal to 01.01.
2). Consider Fig.4
From the user's point of view, all documents starting from the date 01/28/2010 should be included in the report.
"From the point of view" 1C period 01/28/2010 - 01/01/0001 will cause an exception.

Of course, you can try to explain to the user why the report does not display the documents that he expects to see and how the period is presented from the “point of view” of 1C, but this is a thankless task, and wrong. A good program should be, first of all, convenient for the user, because the program exists for the user, and not vice versa, therefore, you will have to “teach” 1C to understand the period as the user understands it, namely:
one). StartPeriod and EndPeriod are not set -> all documents.
2). Only StartPeriod is set –> all documents starting from StartPeriod
3). In addition, we will check that the End of Period >= Start of the Period, and if this is not true, then we will assume that the End of the Period is not set, i.e. 2).
Based on the foregoing, the expression for the EndDate parameter will look like this:

SELECT WHEN &Period.EndDate=DATETIME(1,1,1) THEN DATETIME(3999,12,31,23,59,59) ELSE SELECT WHEN &Period.EndDate<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ

The final view of our period selection design is shown in Fig.5