|
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 |
|