product hierarchy common values

GDSN Trade Item Implementation Guide - Relevant Product Hierarchy Levels & Common Values

Dec-2010 All contents copyright © GS1 of 5

1. Relevant Product Hierarchy Levels & Common Values This section provides advice on which levels of a typical product hierarchy are appropriate for each attribute, and whether the same value should be sent for every level in the product hierarchy.

Note: This information was published in incomplete form as an Appendix to the BMS in early versions of the Trade Item standard. The GS1 GDSN Business Requirements Group (BRG) formally confirmed that this information is advisory, not normative, and ensured the information was completed for all attributes. Because it is classified as advisory, it is made available via this Implementation Guide, not as a formal part of the BMS.

1.1. Why Would I Use This? Many optional attributes make business sense to be used only at some levels of the product hierarchy.

For example:

■ For an electrical product, it makes sense to provide maximumEnergyUsage at the Each level only. It does not need to be repeated for a Case.

■ For any product, it makes sense to allow the Data Source to publish firstOrderDate at any level of the product hierarchy and the values might be different at each level. The published hierarchy might include an existing Each (already published in another hierarchy) contained in a new configuration of Case not made available before, where the Case has a different firstOrderDate from the Each.

1.2. Pre-Requisites ■ The Data Source has analysed what data is to be published and has identified the attributes

to be used. Its master data environment is capable of storing and making available for publication the relevant attributes at the appropriate levels of the product hierarchy.

■ The Data Recipient has the capability to store different data at different levels of the product hierarchy. Its master data environment is capable of receiving, storing and using in its internal processes of the relevant attributes at the appropriate levels of the product hierarchy.

1.3. When Would I Use This? When the Data Source has identified the information to be published, he should prepare a mapping from his internal database(s) to send the data to the Source Data Pool. When preparing the mapping, one key question is which attributes are relevant for each level of the product hierarchy.

The Common Values Relevant Levels Spreadsheet shows the detail, by attribute, of the advice based on many implementations in many countries:

■ which levels of the product hierarchy may typically be relevant for the attribute

■ whether the data value for the attribute should be the same at all levels of the product hierarchy

■ comments e.g. to explain why some levels are relevant

http://www.gs1.org/sites/default/files/docs/gsmp/gdsn/GDSN_Common_Values_Relevant_Levels_i1.xls�



Note: The information is advisory. It is the responsibility and privilege of the Data Source to determine which data attributes will be published at which product hierarchy level. The XML Schema is capable of holding all attributes at all levels of the product hierarchy. Provided no formal GDSN Validation Rules (located on in the GS1 Knowledge Centre) are broken, the message should not be rejected on the basis of attributes being populated at a particular level.

1.4. Explanation of the Report Contents Column Column Name Description

(1) Extension Name /Fast Track

The list contains all available Trade Item attributes, including Core Trade Item, Fast Track, and Extension attributes. The list is sequenced by Class, within Extension. Note: The list is updated during the GDSN Maintenance Release process Fast Track attributes are included under Extension Name “Fast Track” and Class is left blank. Note: Fast Track attributes are communicated using the AVP Extension which is located on the GS1 Knowledge Centre.

(2) Class Name

(3) Attribute Name

(4) Product Hierarchy Level

The ‘product hierarchy level’ column advises which Trade Item Unit Descriptors are most commonly used for sending the attribute. ‘All’ means that the attribute could be sent for any or all hierarchy levels. ‘Lowest level’ means that the attribute is advised to be sent for the lowest

hierarchy level only. Most commonly this is the “Base Unit or Each” level, but some hierarchies may use a different Trade Item Unit Descriptor at this level, such as “Case” for some FoodService trade items.

‘Non-lowest level’ means that the attribute can be sent for any or all hierarchy levels except the lowest one. Typically it will not be sent for the lowest level.

‘Highest level’ means that the attribute is advised to be sent for the highest hierarchy level only. Most commonly this is the “Pallet” level, but where no GTIN has been allocated to identify the logistics unit (e.g. pallet) as an item of trade, the product hierarchy will use a different Trade Item Unit Descriptor at this level, typically “Case”.

‘Non-pallet level’ means that the attribute typically will not be sent for the “Pallet” level, but it can be sent for any or all other hierarchy levels. If no “Pallet” level is sent, then the attribute can be sent for any or all levels.

The comment ‘Typically applicable to a consumer unit’ has been added for some attributes which might normally be expected to be sent for the lowest hierarchy level only. In a simple product hierarchy such as “Pallet – Case – Each” where only the Each is intended for sale at a Retail Point of Sale, these attributes would typically be sent only at the lowest level. However some other products are designed and intended to be sold to consumers at more than one level. For example, a drinks manufacturer may make a product available as a single bottle, a 6-pack of the bottles and a case of four 6-packs, all designed for sale at the Retail Point of Sale. In the product hierarchy the attribute isTradeItemAConsumerUnit is set to TRUE for the Each, the Pack, and the Case. In this example, the attributes marked ‘Typically applicable to a consumer unit’ may be expected to be sent for the Each, the Pack and the Case. Note: For more information on Product Hierarchy Reference Levels, refer to section 4, Trade Item Unit Descriptors (Building Trade Item Hierarchy) for the complete list..

http://www.gs1.org/gsmp/kc/gdsn�

http://www.gs1.org/gsmp/kc/ecom/xml/gdsn_grid�



Column Column Name Description

(5) Common Value Indicator

The ‘common attribute value’ condition indicates whether the value for the attribute is advised to be the same value in all levels of a given hierarchy. This feature is optional to support for the data pools and trading partners but helps them to achieve consistent data handling in the hierarchy. Common Value Indicator = NO: Meaning: The attribute value is not common to all levels of the trade item

hierarchy Example: grossWeight is not common to all levels of the trade item hierarchy,

so the value can be different on the different hierarchy levels e.g.

grossWeight of Each = 10 lbs / 4,5 kg

grossWeight of Pallet = 100 lbs / 45 kg). Common Value Indicator = YES: Meaning: The attribute value is common to all levels of trade item hierarchy Example: shipFromLocationIdentification is common to all levels of the trade

item hierarchy, so this value should be the same for each hierarchy level e.g.

shipFromLocationIdentification = '1234567890128' for all levels published in the trade item hierarchy

Note: The comment ‘To allow for assortments’ has been added for some attributes which might normally be expected to have the same value at all levels. Some assortment items might require different values for each hierarchy level.

For example: a manufacturer offers a Trade Item which is a Case of jam, with different flavours available at the Each level: - 4 x Strawberry - 4 x Raspberry - 4 x Blackcurrant If the manufacturer is using the Variant attribute to hold the flavour, the Each trade items will have the respective flavour in Variant, and the Case trade item may have a Variant of “Mixed” or “Strawberry,Raspberry,Blackcurrant”.

(6) Comments Additional information helpful for implementation. For example an additional comment may explain why the attribute might apply to more than one level of a trade item hierarchy, or to give examples.

1.5. Implementation Considerations Supporting the functionality:

■ This rule could be an additional validation for the GDSN data pools.

■ Data pools MAY validate the master data of their data sources against this rule but CAN NOT enforce this validation on the data sources of other data pools (incoming CINs).

■ Special rule for mixed hierarchies: the validation of ‘common' condition CAN be ignored in case of parents with mixed children (and above that level) as they are implicitly not common at all levels of that hierarchy.



1.6. Standards Maintenance Considerations The GDSN Maintenance Release process will take into account these considerations before assigning the appropriate ‘Product Hierarchy Level’ and 'Common Value Indicator' condition to a new attribute:

■ Can the attribute be used in more than one hierarchy level?

■ Will the supplier (manufacturer) provide the same value for every levels of the trade item hierarchy?

■ Will a distributor or importer provide the same value for every levels of the trade item hierarchy (example different trade items from different suppliers in the same case)?

■ If the answer is 'true' for every question above then the attribute can have its Common Value Indicator set to 'Yes'.

For each successive GDSN Release, the GS1 development team provides a list of suggested values for any new attributes in the release to the GDSN Trade Item Implementation Guide team – who will review the suggested values, amend where necessary, and when satisfied the revised values will be submitted for Public Review. Once any comments arising from Public Review are resolved, a new issue of the advice will be published.

product hierarchy common values

Documents