XML Standards > Message   
 

Definitions of Conditions

Go To: www.gs1.org
 

PEER-TO-PEER TRADE ITEM v. 2.0.2
To help with the implementation of this data model, several key definitions are listed below.
Trade Item
A Trade Item is any item (product or service) upon which there is a need to retrieve pre-defined information and that may be priced, ordered or invoiced at any point in any supply chain.  
The term “trade item” is not to be confused with the legacy term “traded item” (now referred to within the General EAN.UCC Specifications as ‘standard trade item group’ which can mean a specific product containment level, which is also called case. “Trade item” can represent any level of product containment, and also can represent a service. 
In addition, the supply chain is any point from the inception of the product through the final consumption and disposal/reuse/recycling/return of that trade item. Reference General EAN.UCC Specifications for definitions of the term ‘trade item’, ‘retail consumer trade item’, and ‘standard trade item grouping’.
 
Party
A Party (or) Location is any legal, functional or physical entity involved at any point in any supply chain and upon which there is a need to retrieve pre-defined information.
Master Data/Transactional Data
  • Master data is considered to be that set of data that describes the specifications and structure of each item and party involved in the supply chain processes. The uniqueness of the data associated with a trade item is given only by the GTIN or an alternate item identification. This data is static, not dependent on a transaction.
  • Transactional data is that set of data that can only be determined during a business transaction, i.e., plan, sell, buy, and deliver cycle. (E.g. actual amount of cases delivered).
  NOTE – this data model only includes master data
Master Data Alignment
  • Master Data Alignment is the process of timely distribution of accurate Master Data from one partner to others and the correct use of this data. Such synchronization and use of Master Data leads to more accurate business transactions and therefore reinforces the efficiency of the supply chain operations.
  • Successful Master Data Alignment is achieved via the use of EAN.UCC coding specifications throughout the supply chain, communication of all changes and new information between trading partners and use of the information exchanged in subsequent transactions.
  • Master Data Alignment relies on EAN.UCC specifications concerning the Unique Identification of Items, GTIN or alternate item identification and Parties GLN or alternate party identification type as shown in the Party BRD, section 3.2
Peer-to-peer Trade Item (P2P):
For the publication release of the 2.0 standard, the Peer-to-Peer Trade Item has diverged from the trade item in the BRD for Trade Item For Data Alignment. The trade item detailed in the BRD for Trade Item For Data Alignment is specifically for implementation within the Global Data Synchronisation Network (GDSN). The Peer-to-Peer Trade Item contains the base/core item information requirements needed for a simple (Peer-to-Peer) electronic commerce data exchange.  Classes and attributes that are peer-to-peer only will be marked in the model with the stereotype of <<P2P>>.
Core attributes
An attribute whose definition is common across all Industries
Core attributes are common across all geographies.  I.e. ALL Target Markets
Core attributes CANNOT be relationship dependant. They are trading partner neutral only
Extension attributes
  • An extension is an attribute that is relevant to one or more industries (not all EAN.UCC Industries)
  • The definition of an extension attribute is common to all Industries who use the attribute
  • Each Industry is responsible for determining the extension attributes that are relevant to their Industry
  • New extension attributes may be submitted/requested for a specific Industry as necessary
  • The conditions of extension attributes can vary by each industry.  E.g. Mandatory/Optional, Global/Local, Trading Partner Neutral/Relationship Dependent, and Common to all Hierarchy levels
  • Industry user groups should be developed in concert with the EAN.UCC GSMP Process, to determine their relevant extension attributes and the conditions associated with those attributes
  • Process user groups such as CPFR and local (target market) extensions
Trading Partner Neutral/Trading Partner Dependent
Values for an attribute can vary depending on the relationship with the party receiving the data. The Trading Partner Neutral/Trading Partner Dependent status indicates this rule.
  • The condition Trading Partner Neutral is applied to any attribute whose value is independent of a buyer and seller relationship. An attribute, which has the condition Trading Partner Neutral, can have only one set of values.
  • The condition Trading Partner Dependent is applied to any attribute whose value is dependent on a buyer and seller relationship. An attribute, which has the condition Trading Partner Dependent, can have only one set of values per GLN of Party Receiving Data. These are attributes whose value is dependent on a specific point-to-point agreement between a buyer and a seller.
  • An attribute which has the condition Trading Partner Neutral & Trading Partner Dependent, can have only one set of values for the Trading Partner Neutral value AND one set of values per GLN of Party Receiving Data
Multiple Values allowed
This condition is used to indicate that multiple values can be submitted for a trade item.
E.g. multiple types of packaging on a trade item e.g. plastic, cardboard etc.
Where there is a need to express multiple measures, these are handled through indicating the attribute type as ‘Measurement’.  Both the value and UOM can be repeated, and must be used together. See section 4.6 on Unit of Measure in the implementation consideration and concerns.
Where there is a need to express multiple language versions, these are handled through indicating the attribute type as ‘Text Description’. See section 4.4 on Language in the implementation consideration and concerns and Appendix C – Attribute Variations.
Market Group
A Market Group is used to identify a proprietary group of data recipients. The information provider normally determines it although it can also be created by buyers and third parties. This group is used and developed by the information provider to control the publication of data to a specific group of customers. This should not be confused with Target Market.
Target Market Country Code
  • The purpose of the target market country code is to organize master data to meet the requirements of specific geographies
  • The purpose of this field is to explain where a manufacturer is intending to sell its product(s) to a buyer. It does not control where the buyer can resell the product (s) to the end consumer.
  • It is the country, (the geopolitical area) where the product is to be sold and available for publication in an Item Catalog.
  • Target Market Country Code in relationship to Master Data, can be Trading Partner Neutral only. A Target Market Country Code is not used to control Distribution or Consumer Market Area geographies. E.g. product available for shipment from a single Distribution Center
Target Market Sub-Country Code
  • A sub-country code level used to address/comply with a “law making” requirement associated with a country.
  • The number of sub-country codes will vary by each country. These will match with the legislation requirements of each country. (Local bottle deposit tax laws, State and country taxes)
  • Not all countries will have sub-country codes.
  • A sub-country code must be associated with a Target Market Country Code.  It cannot stand-alone
Global/Global-Local/Local
  • All attributes are impacted by their geo-political relevance. This condition can be used by information providers as they build data models. With this information, they can limit the attributes communicated to those relevant for that geography.
  • A global attribute indicates that the attribute is relevant for business cases around the world, and can only have a single value throughout the world. (E.g. GTIN)
  • A global/local attribute indicates that the field is relevant for business cases around the world, that its definition is the same around the world, but may have a different value depending on the geography. (E.g. VAT tax values, 1.00 in France, 1.05 in Belgium)
  • A local attribute is only relevant in certain geographical areas, and the values may change based on where the product is offered for sale. (E.g. green dot – only relevant in certain European countries)
See: Attribute Variations
How does the Global/Global-Local/Local condition, and Target Market value interact to affect attribute values?
  • An attribute, which has the condition ‘Global’, can have only one global value (except where there are multiple values allowed).
  • An attribute which has the condition Global / Local can have one value per Target Market specified (except where there are multiple values allowed). A Global/Local attribute indicates that the field is relevant for business cases around the world, that its definition is the same around the world, but may have a different value depending on the geography. (E.g. the attribute - VAT tax values are relevant globally, but the actual value, 1.00 in France, 1.05 in Belgium varies by country)
  • As long as the attribute values apply consistently to the GTIN, GLN, TM combination the values are repeatable
Example
GTINa + GLNa + TMa + b, = Ohio, Indiana.  Start availability date = January 1, 2003 
Target Market can be repeated where the values for the attribute are the same e.g. start availability date is the same for the GTIN + GLN + TM combination data set.
 
GTINa + GLNa + TMc = Kentucky.  Start availability date = January 15, 2003
 
Note: If GTIN and GLN are not used, alternate item identification and alternate party identification should be used.
  • An attribute, which has the condition Local, can have only one value for the Target Market that is valid for (except where there are multiple values allowed).
Attribute Variations
Back to Message Description
Back to Implementation Considerations
 
Date of Publication: May 2006
Copyright © GS1 Global Office 2006. All rights reserved