In the query builder, when it is called from the form of data source configuration, there is a tab “Characteristics” for the data composition schema the use of which is not distinctly described in the documentation. In this article I will try to explain how and for what the characteristics are used in the DCS.
In the typical configurations the mechanism of properties and properties values is actively used which is available almost for any objects. Primitively, in the catalogs, this mechanism was implemented already in the configurations of 1С 7.7. Now this mechanism is implemented using the chart of characteristics types and the information register, but an idea remained the same.
This mechanism is very convenient in the sense that it allows adding new attributes of the objects without the need to change configuration.
When I firstly encountered the need to use this mechanism in DCS, I suffered for a long time, organized the nested queries, joined to the main selection and bothered my head how to take into account the possibility of new properties appearance that do not exist at the moment of report generation. The entire properties mechanism, being a simple and logical in terms of user, could not be normally processed until I examined the tab “Characteristics”.
The table on the tab is very capricious, either you enter the entire string correctly or refuse the input of string at all, the system will not allow to leave incompleted string “for the future”.
Demo-base with example you can download using the link under publication.
So, let’s move to the specifics. The first column: “Type” - here we select the object type with which the characteristics will be associated, for example, “CatalogRef.Goods”.
This means that now for all the objects of specified type it will be possible to get the properties values.
In the next column “Source of types” we have to set the parameters of the source of properties types. The possible options are the table and the query, I will tell later what the option query is necessary for, for now, select the item Table.
In the column “Types of characteristics” we have to select the table of information base in which the required types of characteristics are stored, in our example it will be “ChartOfCharacteristicTypes.ExtendedProperties”.
Further, the values available for us to select in the columns “Field of option”, “Field of name” and “Field of value type”, depend directly on the fields of selected table. In “Field of option” we select “Ref”, in “Field of name” - “Presentation” (just this the user will see as the attribute name) and in “Field of value type” respectively “ValueType”.
Now move to the source of values. The source of values can be the information register “ValueProperties”, so we select:
In column “Source of values” — table.
In column Characteristic values — “InformationRegister.ValueProperties”.
In the columns “Object field”, “Field of type”, “Field of value” we select the corresponding register fields “Object”, “Property”, “Value”.
it would seem that is all. Go into the schema settings, add grouping, expand the list of grouping attributes for the field “Ref” and … do not see any properties there:
The fact is that we are in the Designer where there is no access to the data. How to make the required configuration? It is more convenient to open this report in the mode of «Enterprise» and open the windows of advanced settings.
As you can see, we have added new attributes, while externally they are not different from the typical attributes of catalog. However, we have now the property “Headquarters” which is associated with catalog “Vendors” and has no relation to the “Goods”. if not to use in the configuration “Headquarters”, then everything will work correctly, if to select it, as a result, it will be unfilled, because this property is not actually filled in any nomenclature item. But how to filter the extra properties in order that they “did not get under our feet”?
To do this, we need to change the configuration of the source of types, in the query builder, on the tab “Characteristics”. Do you remember that I promised at the beginning of the article to tell you why do we need such type of the source of types like query? Now there is such a case. Change the type of the source of types to the query. In the column Types of characteristics click the button “[…]” and a new window of query builder is opened.
Enter there the query:
SELECT ExtendedProperties.Ref, ExtendedProperties.Description + " (prop.)" AS Description, ExtendedProperties.ValueType FROM ChartOfCharacteristicTypes.ExtendedProperties AS ExtendedProperties WHERE ExtendedProperties.Purpose = VALUE(Enum.PurposeProperties.Goods)
In the columns “Field of option”, “Field of name” and “Field of value type” select the corresponding fields of selection: “Ref”, “”Description” и “ValueType”.
it will turn out like this:
Now, when we will move to the report configuration in the enterprise mode, the situation will change in the list of attributes Goods:
Now the goods have only those properties that are assigned to it, moreover, they are now noticeably different from the typical attributes thank to the postscript (prop.) which we have added to the name of property in the query.
That is really all, but many can confuse inability to configure in the Designer. In truth, there is no harm in doing that. it is enough to save the configuration (or the entire schema) in file and restore in the Designer.
The attributes incomprehensible for it the Designer will display with red crosses as unavailable:
But this is not terrible, because the report with these settings can be saved in the configuration and it will correctly work when opening by the user.
The initial catalog “Goods”. As we can see, there is no additional attributes:
Generated report with additional attributes: