|
CONDITION DOCUMENTS AND MONETARY DOCUMENTS
v. 2.0.2 |
|
|
Relationship Dependent Data For Price Synchronisation
|
|
|
Important Note |
|
|
Price synchronisation of relationship dependent data
requires three (3) business message standards to be used together. They are Trading Partner Profile (TPP),
Condition documents and Monetary Documents. The Trading Partner Profile is
detailed in the Relationship Dependent Data for Price Synchronisation – Trading
Partner Profile Business Requirements Document. |
|
|
Problem
Statement |
|
|
Currently there is no ability to
electronically communicate accurate, up to date pricing information between
trading partners. In addition, there is no ability to synchronise supply and
demand side price information. This leads to discrepancies between supply and demand
side price lists and leads to increased errors and costs when reconciling
invoices to purchase orders.
The aim is to contribute towards automating
the exchange of pricing information to facilitate an invoice amount equal to
the expected payment amount equal to the actual payment.
Price synchronisation can be accomplished
inside or outside of the global data synchronisation network
(GDSN). Both scenarios, “within GDSN” and
“outside
GDSN” are included in the business requirements documents for
price
synchronisation of relationship dependent data.
The price synchronisation model developed
by the Relationship Dependent Data Team (RDD Team) has been designed to
accommodate many different pricing business practices including simple pricing,
transactional pricing, and component pricing.
The business model (model) for price
synchronisation contains three parts:
condition documents, trading partner profiles and monetary
documents. The process starts with the
trading partners establishing their trading partner agreements including the
price conditions that are normal to their pricing business practices. Following the exchange of the price
conditions using condition documents the trading partner profiles are exchanged
or published for synchronisation. Then
values, rates and/or percentages are assigned to the condition documents using
the monetary document. The result will
be that trading partners will be able to create equivalent price lists within
their internal systems.
Condition documents and trading partner
profiles are expected to be static and not subject to short-term changes. The monetary document is the dynamic
component of the model because it is used to assign or change values, rates and
percentages.
Section Implementation
Considerations and Concerns has been included for
additional guidance in understanding the implementation the model. This is an informative section that has been
prepared by the RDD Team to communicate implementation considerations and
concerns in response to feedback from presentations of the price synchronisation
concept, comments from pilot test teams and comments from public reviews. Section 5.0 is also intended to provide input
to the next phase of development where the model and business requirements are
incorporated into the GDSN.
|
|
|
Objective |
|
|
Develop standards to enable the
description, communication and synchronisation of Condition Documents and
Monetary Documents which, along with the Trading Partner Profile, will enable
the electronic representation of the trading partner agreements for the inclusion,
depiction and application sequence of price components on an invoice.
Condition Documents are components that
when properly sequenced can enable the calculation of an end price from a given
starting price. Condition Documents contain information about a debit or
credit, which can affect the final price. Condition Documents can also be used
to represent a final price, for example transaction price.
Monetary Documents contain a value, rate or
percent relating to a specific price condition.
Monetary Documents can be GTIN specific or not GTIN specific (for
example backhauls).
Trading Partner Profiles enable the
electronic representation of the trading partners’ agreement for the inclusion,
depiction, and application sequence for price components on an invoice.
|
|
|
Audience |
|
|
The audience would be any participant in
the global supply chain. This would include retailers, manufacturers, service
providers, and other third parties.
|
|
|
Business
Transaction View
|
|
|
|
|
|
Business
Transaction Use Case
Diagram |
|
|
Note |
|
|
The detailed Use Cases for Trading Partner Profile
are in the Relationship Dependent Data for Price Synchronisation - Trading
Partner Profile (TPP) BRD.
|
|
|
|
|
|
Use Case Diagram -
Add Price Condition |
|
|
|
|
|
Use Case
Description - Add Price Condition
|
|
|
| Use
Case Name: |
Add Price Condition
(THIS IS THE FIRST STEP IN THE OVERALL PROCESS)
|
| Use
Case Description: |
A seller or third party creates and synchronises a
price condition with a buyer organization. |
| Actors
(Goal): |
Buyer
Seller
Data
Pool |
| Preconditions:
|
- Seller and Buyer agree to use the GS1 price
synchronisation standards.
-
Condition Documents to be exchanged have been agreed
upon between trading partners.
-
Initial load or addition of Condition Documents is
planned.
-
TPP
has been synchronised otherwise data pool would not know which conditions to
synch.
|
| Postconditions: |
- Buyer
has received Condition Documents required to utilize price synchronisation.
-
Monetary
Documents can be generated by the seller or third party.
|
| Scenario: |
Begins when the seller creates and sends the Condition Documents
to the data pool.
Continues with...
- Seller sending
completed TPP to data pool.
- Data pool using
the instructions contained in the TPP as a guide for how to communicate
Condition Documents to the buyer.
- Buyer receiving
price condition data.
- Buyer acknowledging
receipt of price condition data.
Ends
when seller receives acknowledgement of the buyer’s receipt
of price condition data.
|
Alternative
Scenario
(outside GDSN):
|
Begins when the seller seller sends Condition Documents to buyer
Continues with...
Buyer acknowledging receipt
of Condition Documents.
Ends
when seller or third party receives acknowledgement of the buyer’s
receipt of Condition Documents
|
Related
Requirements:
|
N/A
|
Related
Rules:
|
N/A
|
|
|
|
|
|
|
Business
Transaction Sequence Diagram Add Price Condition |
|
|
|
|
|
Use Case Diagram -
Add Price Condition
|
|
|
|
|
|
Use Case
Description - Add Monetary Document |
|
|
| Use
Case Name: |
Add Price Condition
(THIS IS THE THIRD STEP IN THE OVERALL PROCESS)
|
| Use
Case Description: |
A buyer or third party synchronises a monetary
condition with a seller organization. |
| Actors
(Goal): |
Buyer
Seller
Data
Pool |
| Preconditions:
|
- Trading
Partner Agreements have been created and shared among all actors.
- Item
and Party synchronisation has occurred.
- Condition
Documents have been added to the Data Pool and synchronized between trading
partners.
- Trading
Partner Profiles have been synchronized between trading partners.
- Applicable
Condition Documents have been synchronized between trading partners. Note: this
step is not necessary for non-GTIN specific Condition Documents.
-
Appropriate
GLN(s) to receive Monetary Documents have been identified.
|
| Postconditions: |
A price list can be constructed using Monetary
Documents, Condition Documents and the Trading Partner Profile. |
| Scenario: |
Begins when the seller or third party sends the Monetary Document
to data pool.
Continues with...
- Data pool using
the information contained in the TPP publishes monetary document data to the buyer.
- Buyer acknowledging
receipt of monetary document data.
Ends
when seller or third party receives acknowledgement of the buyer’s
receipt of monetary document data.
|
Alternative
Scenario
(outside GDSN):
|
Begins when the seller or third party sends monetary document to the buyer
Continues with...
Buyer receiving monetary document.
Ends
when seller or third party receives acknowledgement of the buyer’s
receipt of monetary document.
|
Related
Requirements:
|
N/A
|
Related
Rules:
|
N/A
|
|
|
|
Business
Transaction Sequence Diagram Add Monetary Document |
|
|
|
|
|
Implementation Considerations |
|
|
Glossary of Terms
|
|
|
Code Lists |
|
|
|
|
|
TOP
|
|
|
|
|
