The specifications comparison allows any number of objects to be compared with each other. In particular, comparisons can be carried out within an object.
A comparison always uses two object types with the same name from two different nodes. Thus, a comparison is also possible between two different specification types/item types. It is generally possible to compare horizontal and vertical elements. Possible conditions and multiple valuations are taken into account.
The specifications comparison is also able to compare long texts for elements as well as node long texts. A profile with a customer-specific comparison object can be used to control which set of rules is used for the comparison. The comparison can also be used via an API without a GUI. This means that the specifications comparison can also be used for your own applications. The GUI shows the matches and differences between the individual values. The display can be refined using the various filters.
As a special function, nodes and object types that cannot be compared are visualized in the GUI.
Functionality
When objects or parts of objects are entered in the specifications comparison, pairs of base entries are first formed based on the currently valid profile and are then compared with each other. A pair is defined as a tuple of two base entries and an object type that occurs on both base entries. This means that only two object types with the same name are ever compared with each other.
Next, condition types and their condition fields are determined. Dynamic elements (vertical elements) are analyzed for this purpose. The condition fields are those fields from the column group of dynamic elements whose elements in the element group have the usage “condition”. Fields relating to unit and short texts are excluded. A condition type uniquely identifies a set of condition fields. The condition types are cross-element.
Secondly, group types and group fields are determined. To do this, the entries in the column group are analyzed. The group fields are those fields from the column group of elements and dynamic elements (horizontal and vertical elements) whose elements in the element group do not have the “condition” usage. Fields relating to unit and short texts are excluded. A group type uniquely identifies a set of group fields and always refers to a horizontal element.
The third step is to determine the values for the condition fields and group fields used.
The fourth step is to create groups. A group refers to a group type, row group (ROWGRP), sequence number (LFDNR) and a condition type with its condition values.
The fifth step is to form group combinations of two groups that have the same condition values and the same group type. The group combination therefore contains groups that are comparable in pairs.
The comparison takes place at group level. A result is generated for this purpose. A result refers to a condition type with its condition values, a group type and two groups. The actual comparison takes place on group fields with the same name in pairs of the two groups. A status of the comparison is created at the level of the group fields and results.
The possible statuses are “Not found” (both values are empty), “Equal” (the values are equal) and “Different” (the values are not equal).
The representation of the pairs found is visualized in a tree. The grid visualizes the objects and nodes involved as well as the values of the group fields and conditions used.