A BOM Compare is defined by two components:
• Compare descriptor
• BOM Compare mode Compare Descriptor
The compare descriptor is a list of attributes (referred to as compare elements to differentiate them from POM attributes) that are used as the basis of the compare.
Although most compare elements are simply be properties (and are handled automatically by the compare engine), you can compare based on nonproperty elements by defining methods. You can also use methods to customize the compare behavior for awkward properties (for example, quantity, which is described later in this section).
Compare elements can be generally divided into two distinct groups: primary elements and aggregate elements (there’s a third group: display elements, which is described later in this section). The key difference between these two groups is that primary elements define different entities, while aggregate elements are combined for multiple instances of the same entity. For example, the compare functionality before version 8 (when expressed in version 8 terms) defined "item id" as a primary element, and "quantity" as an aggregate element. This meant that BOM lines that had the same item id were bundled together for the purposes of compare and their quantities were added together. In other words, 1 BOMLine with qty 2 was equivalent to 2 BOMLines with qty 1.
In figure 8-3 below, the compare descriptor uses the bl_occurrence (occurrence thread tag) property, the bl_item property, the bl_quantity property, and the Torque (an occurrence note) property.
BOM Compare Mode
The BOM Compare mode is a uniquely named object that combines a compare descriptor and a BOM traversal order. The BOM traversal order defines which BOM lines are fed into the compare engine, and in what order. The BOM Compare supports three traversals: single level, multilevel, and lowest level. A single descriptor can be shared between multiple compare modes.
Figure 8-3 shows a single level compare which is best suited for an occurrence-based compare.
Chapter 8 Product Structure Management
int define_compare_mode() {
int ifail;
tag_t desc;
ifail = CMP_find_desc("example desc", &desc);
if (ifail != ITK_ok)
BOM_compare_singlelevel, /* from bom_tokens.h */
desc, /* from above */
false, /* not shown UI - irrelevant*/
false, /* no autopack - only multi-level needs this */
true /* virtual unpack - copes with packed bomlines */
/* All occurrence-based compares need this */
);
if (ifail != ITK_ok) {
/* If it was previously defined, return success */
if (ifail == BOM_duplicate_bom_compare_mode) {
EMH_clear_errors();
return ITK_ok;
}
/* otherwise report failure */
return ifail;
/* Insert error handling here */
CMP_create_desc("example desc", &new_desc);
IMANTYPE_find_type("BOMLine", NULL, &bomline_type);
/***** Primary Element : Occurrence Thread *****/
Figure 8-3. Single Level Compare (Continued)
Product Structure Management
CMP_create_prop_element(
new_desc,
CMP_primary_element,
CMP_cache_sync, /* Cache property values in native type */
NULL, /* Do not define element name - will default to prop name */
false, /* Show value of this property in output */
bomline_type, /* Type to which prop belongs */
"bl_occurrence", /* Name of property */
NULL, /* No display prop - use real prop instead */
&new_element);
/***** Aggregate Element : Item *****/
CMP_create_prop_element(new_desc,
/***** Aggregate Element : Quantity *****/
CMP_create_prop_element(new_desc,
/***** Aggregate Element : Torque Occ Note *****/
CMP_create_prop_element(new_desc,
Figure 8-3. Single Level Compare
For simple examples, defining a compare mode is relatively easy. You create your descriptor and create a number of property elements against it. Then define your mode, combining the descriptor with a traversal mode.
Chapter 8 Product Structure Management
There are a number of features that are described as follows:
• UI Suppression
In the call to the BOM_compare_define_mode function, the fourth argument is the mode UI display flag. This controls whether the UI should present this compare mode in the PSE BOM Compare dialog window. This is a legacy setting and is now irrelevant because even if this was set to true, the UI still would not show this mode in the dialog window. The UI dialog window is currently hard coded to our standard pre-version 8 compare modes.
• Auto Pack
In the call to the BOM_compare_define_mode function, the fifth argument defines whether multi-level compares should pack BOM lines as it goes along.
Auto pack is an attempt to allow the simplification of the presentation of the results of multi-level compares where the primary compare elements match the pack rule attributes. By default, the BOM line pack attributes are item ID and sequence number. These are the primary attributes for the standard multi-level compare as currently supported by the PSE compare dialog window.
If you set this argument, set it to false.
• Virtual Unpack
In the call to the BOM_compare_define_mode function, the sixth argument defines whether BOM lines should be temporarily unpacked during the compare.
If you are using bl_occurrence as one of your compare elements, set this flag to true because packed BOM lines represent multiple occurrences. To gain access to the individual occurrences, the compare must unpack the BOM line, pull out the required data, and then repack, which is transparent to the end user. Why is not this always switched on? The main limitation of virtual pack lies in the BOM line property compare output. Normally, BOM compare sets a BOM line property called Changes to display the actual changes that have happened to the BOM line (for example, Qty 2->3 or Rev A->B). If you are performing an occurrence-based compare, you might have two occurrences behind a packed BOM line. One occurrence might have a change (for example, Qty 2->3). The other occurrence might not have any change. In this situation, what should compare put in the Changes property of the BOMLine? Should it say Qty 2->3?
Should it be empty? In reality, it says PACKED CHANGES, and expects the user to manually unpack the BOM line to see to individual changes.
For non-UI compares, UGS recommends that the BOM windows being compared have packing switched off.
Product Structure Management
• Caching
In the calls to the CMP_create_prop_element function, the third argument tells BOM Compare whether and how to cache property values. The
CMP_cache_sync setting means that the type of the cache should be synchronized to the property value type. Setting this to CMP_cache_none would disable caching of that property. The CMP_cache_auto setting is similar to CMP_cache_sync, but allows BOM Compare to make the final decision on the cache type. This is important if you plan to use certain properties as aggregate elements. For example, multiple tag elements cannot be aggregated into a tag cache. Instead, they need a tag array cache type. The CMP_cache_auto setting makes that decision for you. You can also manually specify the type of the cache, but it is up to you to make sure that it is suitable for storing the property.
• Element Naming
In the calls to the CMP_create_prop_element function, the fourth argument allows a user to specify the (internationalized) name by which this element is known. If this is set to NULL, then the property name is used. Element naming is primarily used for non-property compare elements, but can still be useful for property elements where the property name is considered to be too verbose for display in compare output. For example, with the bl_quantity property you might want compare to output the more compact Qty rather than property display name Quantity.
• Element Display Suppression
In the calls to the CMP_create_prop_element function, the fifth argument allows for the possibility that certain elements are useful for comparing, but not good for displaying. For example, tag elements are great for comparing, but because they are simply unsigned integers they have no meaning to end users.
This ties into display elements.
• Element Display Aliasing
In the calls to the CMP_create_prop_element function, the eighth argument provides a simplified version of the display elements concept. It allows an unfriendly property to be replaced in the output stage with a more readable one.
In the example above, we used the bl_item property. This property is the tag of the item. When displaying item changes to the user, you do not want to show them item tags. Instead you would want to show them the item ID. To do this, we could define bl_item_item_id as a display alias property of the bl_item property element. Note that while you could use bl_item_item_id as your compare element, the use of bl_item is much more efficient for two reasons: it is an integer compare rather than a string compare, and bl_item is a directly defined BOM line property while bl_item_item_id is indirected through the item.
Chapter 8 Product Structure Management