|
ALIGN
TRADE ITEM v. 2.0.2 |
|
|
|
|
|
To
help with the implementation of this data model, several key
definitions are
listed below. |
|
|
Trade
Item |
|
|
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 GS1 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 GS1 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
|
|
|
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 GS1 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 GS1
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)
|
|
|
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).
|
|
|
Trade Item
|
|
|
A Trade Item is
any 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 GS1 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 GS1 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. |
|
|
|
|
|
Product Hierarchy
Reference Level |
|
|
This condition is
used to indicate at what level of
the product hierarchy each attribute is relevant. For some attributes,
business
requirements are such that the attribute only needs to be provided at a
specific level.
Example – “netContent” this field is only
required at
the consumer unit level.
For most attributes, a value must be entered for all
attribute levels. |
|
|
Common Value to
all Product Hierarchy |
|
|
Common value
condition indicates when the value for
the attribute is equal for all levels of a hierarchy.
Example – “orderingLeadTime” is common
across all
levels of the product hierarchy; common value = Yes
Example – “grossWeight” is not common
from each to
case to pallet;
Common value = No |
|
|
Attribute Variations |
|
|
Back to Message
Description |
|
|
Back
to Implementation
Considerations |
|
