XML Standards > Message
  
 
Message Description
Go To: www.gs1.org
 

TRADING PARTNER PROFILE DOCUMENT v. 2.0.2

Important Note
Price synchronisation of relationship dependent data requires three (3) business messages to be used together.  They are Trading Partner Profile (TPP), Condition Documents and Monetary Documents. Condition Documents and Monetary Documents are detailed in the Relationship Dependent Data for Price Synchronisation – Condition Documents and Monetary Documents 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 Process View
Requirements
Business Requirements
General Model
Number Statement Rationale
1 The model shall enable the synchronisation of a transaction price. Transaction price is an item price or invoice amount of a product or service. Some geographic regions require the inclusion of a flat final item or invoice price on a price list.
2 The model shall provide a scalable solution, which will include components reflecting segmentation by geography, trade channel, trading partner relationships and industry sector. The intent is to encourage wide implementation by all sizes of trading partners, across industries.
3 The solution shall be workable both inside and outside of the Global Data Synchronisation Network (GDSN). To meet stated EAN.UCC system goal of providing standards which are not dependent on the technology being used.
4 The solution shall allow for the following scenarios in relation to the routing of Condition Documents, Monetary Documents and Trading Partner Profiles:
1.             Secure pass through leveraging the GDSN communication protocols/security.
2.             Secure point to point outside network complying with standards.
3.             Resident in both the supplier and retailer data pool leveraging secure pass though or secure point to point.
See Section 5 for implementation notes and commentary.
Privacy of data has been established as a clear business requirement for trading partners.

Trading Partner Profile (TPP)
Number Statement Rationale
1 Each TPP must have an effective start date. Effective Start Dates determine when the TPP is first available for use.
2 Each TPP may have an effective end date, or it may be open-ended. Effective End Dates enable the termination or expiration of a TPP.
3 Each TPP must be uniquely defined. (Within GDSN) A unique identifier is the combination of a Data Source GLN, Data Recipient GLN, target market, and channel of trade.
(Outside GDSN) The document identification role is used.
4 Each TPP may have a free text field for the seller to add a name or description to the trading partner profile.
Examples:
  • Retailer name and class of business
  • XXX Hospital Group for vending supplies
  • YYY Retail Stores in Northwest Region
Trading partners may choose to add a text description for ease of identification.
5 Each TPP may have a reference assigned by the buyer that would provide an internal party identification of the seller in the buyer’s internal information system. e.g. “vendor number”. This field is optional. This reference enables a linkage to the ERP systems:  examples: procurement, category management and accounting for buyer.
 
6 Each TPP may have a reference assigned by the seller that would provide an internal party identification of the buyer in the seller’s internal information system. “customer number”. This field is optional. This reference enables a linkage to the ERP systems:  examples:  sales, manufacturing, accounting systems.
7 Each TPP shall refer to the TPP Data Source through a party identifier. Within GDSN, this shall be by GLN. This field is mandatory. Buyers will want to identify the source of a TPP.
8 Each TPP shall refer to the Data Recipient through a party identifier. Within GDSN, this shall be by GLN. This field is mandatory. Sellers will want to identify the buyer for whom the TPP applies.
9 Each TPP shall include Target Market. Target Market is defined as a geographical region based upon geographical boundaries sanctioned by the United Nations. The ISO 3166_1 List  is used to populate this attribute. Target Market is mandatory. It is expected that some trading partner relationships span across multiple geographic markets, and that seller or buyer may wish to specify the geography for which the TPP is relevant.
 
10 Each TPP may include Rounding Factor.  This is the number of positions that trading partners agree to round to.  Rounding Factor is an integer. The precision of decimal places and the rules used for rounding should be mutually agreed between the trading partners. Rounding errors are often the cause of price mismatches between trading partners.
11 A TPP shall include trade channel. This is an enumerated list.
  • drug
  • food service
  • grocery
  • hard lines
  • home goods
  • industrial
  • institutional
  • mass
  • military
  • unspecified 
  • vend
Trade Channel is mandatory.
Many trading partners have different go to market strategies for different trade channels.  Unspecified, this field shall be created as a default.  Unspecified may also be used when proprietary trade channels would apply or “not applicable” would be desired.
12 Each TPP shall include the conditions agreed upon by the seller and buyer.
Each Condition will have a condition identifier. Each condition identifier will be used in combination with the attributes “application sequence”, “method of depiction”, and “lead time” to fully describe its application within a trading partnership.  This field is mandatory.
Trading partnerships will list what conditions the buyer and seller have agreed upon as being applicable to their relationship. Each condition listed in the TPP will need to have three other fields to fully describe its application within a pricing model. These four fields can loop as often as necessary.
13 An application sequence number shall be assigned to each condition to denote the order of succession in which the calculations shall be derived.  This field is mandatory for both component based and transaction price pricing approaches.
 
Sequencing of price components within a calculation is relationship dependent in some markets. The TPP captures the agreement between trading partners.  In instances where there is only a transaction price communicated (no components) the sequence will still be required and will equal 1.
14 Two or more conditions shall be permitted to have the same application sequence number but only if the price is derived. In certain business cases, the sequence with which multiple components are applied to a calculation can be the same.
15 Each condition on a TPP shall be assigned a method of depiction. Method of depiction shows how the condition group will be depicted on the invoice.
There are two methods of depiction:
  • Line item level
  • Invoice summary level
The method of depiction is mandatory.
Calculation of price will require information on how a value should be applied.
 
16 The method of depiction “line item level” shall refer to a single trade item. Within GDSN the item identifier will be a GTIN. The assumption is that the standard invoice lists a single trade item per line.
17 The method of depiction “invoice summary level” shall refer to the entire invoice, which may be depicted just once on the invoice (e.g. at bottom or at top). This reflects common business practices.
18 The TPP may include a price notification lead-time.  The price notification lead-time may be repeated for each condition contained in a TPP.
 Price notification lead-time is optional.
Price notification lead times specify the amount of time required between communication of a price or price component change to the seller and the effective date of this change.
19 TPPs must be processed in a manner that will provide a history of current and past agreements. An audit trail is necessary for all three parts of the price synchronisation model.
20 TPP may include a tax indicator that would enable the management of taxes that could be included on an invoice. 
  • Tax Indicator is an enumerated list and is optional. There can be multiple instances of Tax Indicator for a TPP. 
  • Values for Tax Indicator include:
  • Tax Included:  indicates that the tax is included in the price.
  • Tax Calculated – indicates that the tax is included in the calculation of the price.
  • Tax Shown – indicates that the tax amount(s) are shown clearly on the invoice.
  • Tax In Base – indicates that the tax is included in the calculation base for the end of year allowance and backhaul.
Used for tax management. 

Technical Requirements
Number Statement Rationale
1 Security must be established by the Global Data Synchronisation Network (GDSN) for price synchronisation messages sent through the GDSN network. The same level of security must be employed for sending price synchronisation  messages outside of the network. There is a clear need for privacy of all price data messages. 
2 The GDSN Group must develop the necessary protocol or tools to meet all security requirements for the exchange of price components. The RDD team delegates this work to the appointed group within GSMP.
3. A history of TPPs must be kept as an audit trail. There is a business requirement to track past agreements.
4. An overall prerequisite for price synchronisation is both Item and Party synchronisation. Monetary Documents relate to a trade item through trade item identification. It is assumed that this trade item is unique.
Party synchronisation is necessary for the publication of trading partner profiles to parties below the top level of the party hierarchy.
5. Validation rules are required regarding the effective dates of the three documents (TPP, Condition Document and Monetary Document). The effective dates of these documents must logically relate to each other to maintain the integrity between the documents. For example, a monetary document should not be accepted for a condition document with an end effective date that has already expired.
 
These validations will ensure the integrity of price information passed between trading partners.

Business Transaction View





Business Transaction Use Case Diagram
The synchronisation of Condition Documents, Monetary Documents and Trading Partner Profiles are connected processes enabling trading partners to independently create equivalent price lists.
 
The detailed Use Cases for Add Price Condition and Add Monetary Document are in the BRD for Relationship Dependent Data for Price Synchronisation -Condition Documents and Monetary Documents.

Use Case Diagram

Use Case Diagram - Add Trading Partner Profile
Use Case Diagram

Use Case Description - Add Trading Partner Profile

Use Case Name: Add Trading Partner Profile  (THIS IS THE SECOND 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
Data Pool
Seller
Preconditions:
  1. Trading partner relationship between the seller and buyer exists.
  2. Trading partners have reached agreement on channel management, bracket pricing implications and management of geographical issues.
  3. The locations that the TPP will apply to have been agreed upon between trading partners.
  4. Seller and buyer have determined reference numbers that will refer the TPP to the seller and buyer’s internal information systems (if necessary).
  5. Agreement has been reached on conditions that apply to the relationship.
  6. Application of sequence numbers to conditions have been assigned and agreed on by trading partners.
  7. Methods of depiction for the conditions have been agreed on by trading partners.
  8. Effective start and end dates (if appropriate) for the TPP have been selected and agreed on by trading partners.
  9.  
  10. Trading partners understand what they are capable of supporting (e.g. which condition (types) can be supported and at which part of invoice:  line item level or invoice total).
  11. The seller has sent all relevant condition documents to the participating data pool.
Postconditions: The TPP when used with the categories of pricing conditions along with pricing information calculated by the use of a monetary document will facilitate an invoice amount equal to the expected payment equal to the actual payment.
Scenario:
(within GDSN)
Begins when the seller or third party sends the data pool the trading partner profile data.
Continues with
 
  1. The data pool sending a copy of trading partner profile data to buyer for verification.
  2.  
  3. The buyer confirming trading partner profile data.
 
Ends when the seller receives the validation acknowledgement.
Alternative Scenario
(outside GDSN):

Begins when the seller or third party sends the buyer the trading partner profile data.
Continues with
 
1. The buyer confirming trading partner profile data.
 
Ends when the seller receives the validation acknowledgement.
Related Requirements:
N/A
Related Rules:
N/A


Business Transaction Activity Diagram Add Trading Partner Profile
Activity Diagram
Use Case Diagram - Terminate Trading Partner Profile
Use Case Diagram
Use Case Description - Terminate Trading Partner Profile

Use Case Name: Terminate Trading Partner Profile  (ONLY USED WHEN TRADING PARTNERS AGREE TO NO LONGER CONDUCT BUSINESS TOGETHER)
Use Case Description: This use case describes the process to flag a TPP as terminated. Once the TPP is terminated it is no longer valid for use.
Actors (Goal): Buyer
Data Pool
Seller
Preconditions:
  1. TPP has been synchronized.
  2. Trading Partners agree to terminate their agreement.
Postconditions: The TPP is no longer valid for use.
Scenario: Begins when the seller or third party sends to the data pool trading partner profile termination data.

Continues with
1.  The data pool receiving information on the TPP to be terminated.
 
2.  The data pool sending termination notice to buyer.
 
3. The buyer validating that the TPP should be terminated.
 
4. The buyer sending a termination validation acknowledgement to the data pool.
 
Ends when the seller receives the termination validation acknowledgement.
Alternative Scenario
(outside GDSN):

Begins when the seller or third party sends to the buyer trading partner profile termination data.
 
Ends when the seller receives the termination validation acknowledgement.
Related Requirements:
N/A
Related Rules:
N/A


Business Transaction Activity Diagram Terminate Trading Partner Profile
Activity Diagram
Implementation Considerations
Glossary of Terms
TOP
 
Date of Publication: March 2007
Copyright © GS1 Global Office 2007. All rights reserved