1s SKD standard period example. Standard parameter &Period and problems in use

So, let's begin.

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

In my case, this is the accumulation register "Work in Progress Accounting".

For example, we will indicate its parameters rigidly (not through soft imposition of parameters on the access control system):

Please note that the frequency of the virtual table is “Record”.

But, as noted above, we need the period in terms of periodicity, so I propose to calculate the “Period” field in the following way (not very nice, but I haven’t seen any better options):

As can be seen from the screenshot, a parameter is passed to the request, which the user specifies on the form: The value of the "Frequency" enumeration - this enumeration is found in almost all standard solutions.

We will indicate its available types on the “Parameters” tab:

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

Here are the formats themselves:

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 from "dd.MM.yyyy"

Half-year: DF = ""Half-year from" dd.MM.yyyy"

That's all. The output is a wonderful picture:

When creating reports on an access control system, there is often a need to display a period selection on the report form, so that you do not need to enter dates manually, but select from a list standard periods, such as: “Year”, “Month”, “Week”, etc. For parameters of the Date type, you can only specify “The beginning of this year, month, etc.”, but “End” is not provided.

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

There is a way to get around this.

1. Let's create new Parameter, let's call it “Period”
2. Set this parameter to the type “Standard period”
3. In the “Expression” field of the “Start of Period” and “End of Period” parameters, which are used in the request, set the expressions “ &Period.StartDate" and " &Period.End Date” 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 like “Error processing the view, type mismatch, parameter number...” will be displayed.

To avoid this, you need to remove all virtual table parameters.

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

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

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

Let's create a report with one set of query data:

Now let's go to the parameters tab and see that the system, in addition to our &MyDate parameter, has also created the &Period parameter.
In order to visually monitor the periods, we will create a main report form and place a table field with data on it: Settings Composer.Settings.DataParameters

Let's save the report and open it in the enterprise. In the table field with parameters, only the &Period parameter is displayed:

Accordingly, any change in this parameter will not give the desired result.

Why is the &MyDate parameter not available? Of course, because on the parameters tab he has a checkbox checked Availability limitation.

Uncheck the box. Now we see both in the available parameters. Only when generating the report will we see that the report responds to the &Period parameter, and not to &MyDate.

IN in this example The easiest way is to rename the parameter &MyDate to &Period in the request and achieve the desired result. But maybe you have a query in which the &Period parameter has already been used, or your religious views do not allow you to use this parameter, in any case, you can solve the problem like this:

UPD from the user Boo:

The main problem when using “standard” (system-added) parameters is that when using several virtual tables in a report, if this parameter is defined, its value will be used in all other cases instead of the “own” ones.

Let me give you an example:

In the second subquery, the value of the “standard” PERIOD parameter will be used as the slice date parameter, rather than the OtherDate value.

This “glitch” will be observed even if the second subquery is output to the second data set and linked using ACS. The option using in the second request an expression like “ADDATE(&Period, MONTH, -1)” will also not work, the month will not be subtracted. But renaming the “Period” parameter in the request to, for example, “FirstDate” solves this problem.

By the way, exactly the same problem occurs with virtual tables accumulation and accounting registers used to obtain, for example, turnover. There the system adds the parameters “Start of Period” and “End of Period”.
So in the case of requests of even slightly increased complexity, it makes sense to turn off availability and the use of “standard periods”.

Some features of setting the period in the access control system.

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

As a rule, in ACS, period entry is organized through parameters, using the following construction, see. This method of period entry is considered “classical”; it is described in an article on ITS and other literature devoted to development in 1C, so let’s take it as a basis. Let's consider as an example a simple request that receives all documents Sales of Goods and Services for a given period, see

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 specified, that is, UNLIMITED, that is, ALL documents without date restrictions 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.0001 and only documents with an empty date will be included in the report, which in practice means not a single document will be included.

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

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

You can, of course, 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 it is also wrong. Good program must, first of all, be convenient for the user, because the program exists for the user, and not vice versa, therefore it is necessary to “teach” 1C to understand the period as the user understands it, namely:

1). Start of Period and End of Period are not specified -> all documents.

2). Only the Beginning of the Period is specified -> all documents starting from the Beginning of the Period

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

Based on the above, the expression for the End Date parameter is:

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

THEN DATETIME(3999,12,31)

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

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

&Period.End Date

The final form of our period selection design is shown in

Note: this mechanism for setting parameters is intended for older platforms 1C 8.1 and 8.2 (and configurations running under their control); older versions of the 1C platform have built-in mechanisms for controlling empty 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 operation are possible.

This article discusses some of the features of setting up a period when using a Data Composition System (DCS), problems that arise due to differences in the concept of a period between an ordinary user and the 1C system, and also suggests ways to solve them.
Most reports that are developed using a Data Composition System (DCS) require the user to enter the period for which the report will be built. As a rule, in ACS, period entry is organized through parameters, using the following construction, see. Fig.1 This method of entering a period is considered “classical”; it is described in an article on ITS and other literature devoted to development in 1C, so let’s take it as a basis. Let's consider as an example a simple request that receives all documents Sales of Goods and Services for a given period, see 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:
1). Let's consider Fig.3
From the user's point of view, the period is not specified, that is, UNLIMITED, that is, ALL documents without date restrictions 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.0001 and only documents with an empty date will be included in the report, which in practice means not a single document will be included.
2). Let's consider Fig.4
From the user's point of view, the report should include all documents starting from the date 01/28/2010.
“From the point of view” of 1C, the period 01/28/2010 – 01/01/0001 will cause an exception.

You can, of course, 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 it is also wrong. A good program should, first of all, be user-friendly, 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:
1). Start of Period and End of Period are not specified -> all documents.
2). Only the Beginning of the Period is specified –> all documents starting from the Beginning of the Period
3). In addition, we will check that End of Period >= Beginning of Period, and if this is not true, then we will assume that End of Period is not specified, i.e. 2).
Based on the above, the expression for the End Date 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 form of our period selection design is shown in Fig.5