|
PRICE v. 2.0.2 |
|
|
|
|
|
Regarding the Price attribute |
|
|
This Price communication process has been
defined with the intent to support the effective communication of price
data
relating to specific goods or services between parties. The parties
could
include individual businesses representing a buyer and seller in a one
to one
relationship, or price information being communicated from one to many,
as in a
public catalog. The intent is that a single process definition supports
the
exchange of public and non-public Price information.
The Price communication process is intended to
communicate pre-agreed prices between entities. The Price
document does not include supporting information
attributes that may have been used to arrive at the final price, such
as
discounts, allowances and charges, payment terms, etc. If this
supporting
information is required, it may be communicated electronically and must
be
facilitated via the use of pre defined extensions. |
|
|
Regarding the notification of the acceptance
of the price communication |
|
|
A notification from the buyer (or third
party) is required back to the seller because of the critical nature of
the
price data and its financial impact. Once the buyer has accepted the
data and
no errors have been found, then, data alignment has been achieved. Both
parties
now have exactly the same required information. This process can be an
on going
process as the price changes or new prices are added. Refer to the
EAN/UCC work
on global data synchronization of relationship-dependent master data.
There are up to three levels of
acknowledgement or acceptance inherent in the messaging architecture.
These are
message receipts (Buyer (or third party) has received the message),
functional
acknowledgement (Buyer (or third party) can interpret/decode the
message) and
price acceptance (Buyer (or third party) agrees and accepts the price
communicated). The first two levels of acknowledgement do not
constitute price
acceptance. |
|
|
Regarding the Effective Start and End Date
attributes |
|
|
There
is a concern
that the effective start and optional end dates will not be processed
properly.
A prerequisite to the price message communication is that the trading
partners
agree to the effective start date of the price being communicated. This
start
date is mandatory. It is important to note that if price is sent to a
buyer (or
third party) without an end date, it implies that the price is
effective until
further notice. Also, it is implied that the price is effective until
further
notice, if an invalid end date is sent. Examples of invalid dates
include
99/99/9999, 00/00/0000, blank, etc. These invalid end dates should not
be communicated
intentionally. There are various valid types of dates that reflect
price start
date (Effective Start Date) and price end date (Effective End Date),
and can be
communicated with the Price Date Type List. |
|
|
Regarding the definition of the Target
Market |
|
|
The
Target Market
Information contains attributes that define a geographical region based
upon
geographical boundaries sanctioned by the United Nations. There is one
international
system to describe geographical regions, the ISO – 3166-code
system. |
|
|
The Target Market Country Code is the primary code of two
that may be used to define Target Market
and indicates the country level or higher geographical definition in
which the
information provider will make the GTIN available to buyers. This indication does not
in any way govern
where the buyer may re-sell the GTIN to consumers. These Target Market
Country
Codes can be repeated, as many times as needed to communicate where the
trade
item is available. The Target Market Country Code is represented by the
two-character ISO 3166-1 code. This code is an optional attribute. It
is
important to note that the lack of the Target Market Country Code
implies that
the product or service is available everywhere the seller offers the
trade
item, therefore representing a global price. |
|
|
The Target Market Subdivision Code is the secondary code of the
Target Market and must be a
subdivision of a Target Market Country Code. The Target Market
Subdivision Code
describes the "geo-political subdivision of a country" where the
trade item is available to buyers, as determined by the information
provider.
For example, "State" in the US, "Land" in Germany,
"Region" in France, or "Province" in Canada. Not all
countries have subdivisions. Target Market Subdivision Code cannot
stand-alone,
it must be associated with a Target Market Country Code. This code is
represented
by the three-character ISO 3166-2 code. This Target Market Subdivision
Code is
an optional attribute. It is important to note that the lack of the
Target
Market Country Code and Target Market Subdivision Code implies that the
GTIN or
Alternate Trade Item Identification is available everywhere the seller
offers
the trade item, therefore representing a global price. |
|
|
The Target Market Description consists of the common
library class Description containing Text and
Language Code used to describe the Target Market Information.
|
|
|
For
further clarification, review the
definition within the Item Business Message Standard. |
|
|
Regarding Market Group |
|
|
The Price Project
Team acknowledges the term Market Group is used to identify a
proprietary group
of customers that is normally determined by the seller, although it can
also be
created by buyers and third parties. The Market Group is a common term
and
should not be confused with the Target Market Information. Due to the
proprietary nature of this grouping, it was decided not to include
Market Group
within the Price document but to note its existence and differences
with Target
Market Information. |
|
|
Price and
additional reference document flow |
|
|
 |
|
|
TOP |
|
|
Back to Message Description |
|
