XML Standards > Message - Condition Document Message - Monetary Document
 
Implementation Considerations
Go To: www.gs1.org
 

CONDITION DOCUMENTS AND MONETARY DOCUMENTS v. 2.0.2
Relationship Dependent Data For Price Synchronisation

This section has been included to record implementation considerations and concerns that have been noted during the development of the RDD conceptual business model and the subsequent development of the business requirements.  The RDD Team is using this section to assist readers with understanding how the business requirements might be implemented and to offer input to the next step of the process where a new task group comprised of RDD and GDSN participants will be formed to develop the implementation requirements within the GDSN.



1.Status Of This Standards Document

  • The RDD Team  recognizes these overall facts regarding this BRD.
  • Business requirements have been captured to the best of our knowledge. With ample input from North America, Western Europe and Asia, the RDD Team feels that it has fully completed its task of capturing what the industry requires in order to meet the stated objective of accurate price data synchronisation.
  • The model design (the various messages and their content) and the proposed communication processes (sequence of actions required to move data from seller to buyer) have been checked to ensure that the proper attributes and necessary dependencies are in place. The standards have been tested against both simple and complex business scenarios.
  • The RDD Team anticipates that the work contained in this document will be further refined and improved by subsequent groups including the GDSN task group and groups formed to respond to change requests submitted by early implementers.
  • The RDD Team recognized during its work that there were some business requirements that should be deferred in the first phase of implementation. These requirements have been captured in this document for implementation in a later phase.
  • The RDD Team believes the model can be implemented by trading partners who use either a transaction price structure or a component-based pricing structure.



2. Scope Of Standards

  • On invoice only – The RDD Team focused on building a model that would handle any pricing component that would be reflected on the invoice sent to a buyer from a seller. Out of scope is any surcharge or discount which is put into place by the trading partners in a transaction that is not connected to the invoice. (Example – a check written after a promotional period ends for an addition discount that   covers one or more invoices).
  • Flexibility - The model is designed to be flexible enough to handle the two basic global models for “go to market” pricing strategies used by manufacturers. The first is Transactional Pricing and the second is Context Driven Component Based Pricing.
  • Transactional Pricing – Transactional Pricing, which is also known as Simple Net Pricing, is a pricing structure where the trading partners negotiate a single price in advance of trading. This price may or may not include considerations by both parties regarding discounts or surcharges. The partners agree, however, that the only price data that should be communicated is the final agreed to price. In most cases, this final price will not fluctuate between orders due to different circumstances (e.g. same price for ½ truckload or full truckload).
  • Context Driven Component Based Pricing - This pricing strategy involves a starting price and may or may not include a variety of other pricing considerations, some discounts and other surcharges, which will vary for the same trade item (GTIN) within the same trading partner relationship based on a variations in condition. (e.g. logistical discounts based on weight of the order. Orders that have different weight totals may generate a different price for the same product). This pricing structure is sometimes referred to as “complex.”
  • Choice of communication – the RDD Team has developed standards that can be used in a variety of communication choices. Both data synchronisation via the GDSN network and one to one communication without use of data pools are supported.
Note:  Because the model is intended to handle both simple and component-based pricing methods, it may appear at first to be complicated. Please note that a number of the attributes are optional, and as such, do not need to be used for simpler pricing structures. Included in the implementation notes are examples of both pricing structures and how they would be handled with these standards.
3. Basic Assumptions
  • Assumption 1. – As a prerequisite to price synchronisation, trading partners have already agreed to do business and have completed all negotiations around price. It is emphasized that this standard is not intended for use as a negotiation tool.
  • Assumption 2. - For trading partners using the GDSN network, it is assumed that the parties are already engaged in item data synchronisation, as this is a prerequisite for price data synchronisation.
4. Commentary
4.1 Overall Price Synchronisation Model’s Structure
  • In addition to listing all business requirements involving price data synchronisation, the RDD Team developed a logical model for how data is to be organized and communicated, in a manner which the RDD Team believes the business requirements will be met. This logical model arranges the attributes required to deliver business requirements into three “documents” or “message sets” which work together to deliver a full and complete set of pricing data from seller to buyer.  These are the:
  • Trading Partner Profile (TPP)
  • Conditions Document
  • Monetary Document
  • The RDD Team has designed the model using three separate components in response to their analysis of the industry’s various marketing strategies, to provide the flexibility needed to meet the business requirements. It is important to note that the overall model will only work if all three components are used.
4.2 Overall Comment – How This Model Will Be Applied Into Backroom Systems Of Both Trading Partners
While all trading partner approaches will be unique, it should be explained that the overall model is not designed to fully automate the communication process from end to end.
As envisioned, what will occur is that:
  • The seller will build a process to deliver all pricing components to their data pool of choice (internal or external to their firewall). This process may eventually be automated.
  • The data pool will use the information contained within the TPP to perform their publication function.
  • Buyers will still have to “open and read” the messages sent, during the initial data load, to understand which of the messages they wish to manually load into their existing accounts payable and order creation systems. An example would be the manual review of performance requirements for discounts.
  • It is expected that, as best practices develop, the trading partners will learn how to maximize the TPP’s ability to filter the messages sent to the buyers.
  • Once an initial data load is done, there will be a mix of automated and manual handling of updates to data that has been entered into the buyers’ internal systems.
  • It is expected that as these standards are refined, more automation will be built into the process.
4.3 Trading Partner Profile (TPP)
The TPP is designed to capture agreements between two specific trading partners. Since this document captures an entire seller buyer relationship, it is not trade item or “GTIN” specific. These agreements include how pricing will be handled. Specifically: Depiction on invoice, whether or not a simple net price or component-based price will be communicated; Pricing components (conditions) that will be applied; and, Sequence of pricing components as used for the calculation of a final price. Other relationship dependent attributes, both those related to price as well as those which may pertain to other aspects of supply chain transactions (ordering lead time) can be included in the TPP. It is anticipated that the TPP will be relatively static. While it would be used by each party and (within GDSN) data pools in the course of regular communications, it would  itself be “synched” and then stored within the network for use by all parties.
4.4 Condition Document
A condition document is a message set containing attributes which are designed to provide information around requirements set by a seller, or mutually developed by the seller and buyer, which govern how components of price will be reflected on an invoice. Examples: A condition message set that relates to a merchandising promotional discount offer may list a start and stop date for this offer, a description of the offer, and other relevant data. Conditions can be set by sellers to cover a wide range of their products. Offers for an additional discount if the buyer can pick up the order from the seller’s location for example, are often the same for all of the seller’s goods. Because of this common business practice, a trade item or “GTIN” is not included in a condition. By the combination of the condition document and the monetary document, which can include a trade item or “GTIN”, the buyer can gain a full understanding of a particular price component. Effective dates of a condition may be different than the monetary values to which they are related. Additionally, changes in conditions often occur independently of monetary values (example – seller lowers quantity of trade item needed for volume discount from 1000 units to 500 units. Actual discount gained e.g. 50 cents, does not change. Conversely, monetary values can change without conditions changing. The condition identifier attribute is the field used to link the condition message set with the monetary message set. The relationship between condition and monetary message set is one to many.  It is expected that the list of attributes within the condition message set will increase as the industry attempts to move toward a fully automated reconciliation of invoices.
4.5 Monetary Document
A monetary document is a message set which contains attributes which list details of the actual monetary values of pricing components. Monetary documents can apply either to a single GTIN or to all GTINS associated with a trading partner relationship as outlined in a TPP. As an example, a monetary document associated with the list price of $10.00 for Potato Chip A may include a GTIN which represents a case of this trade item. This communicates to the recipient that the monetary document and the numerical value associated with this document only applies to this single trade item, and that the price is offered at the case level. In an example of a monetary document where there is no GTIN, the same seller of Potato Chip A offers a “damaged goods allowance” of 1% for ALL of the products associated with its relationship with Trading Partner B. In this instance, Trading Partner B understands that they can expect a 1% discount to be reflected on their invoices for all trade items sold by Seller S such as: pickles, pretzels, beverages and potato chips.  It has been determined that there are technical and business reasons why multiple GTINs cannot be inserted into a single monetary document. See 5.4.12.11 below.
4.6 Date Context
The date context contained by the condition document to which the monetary document is associated also governs the context for the application of values contained in the monetary document. 
4.7 Addition Or Subtraction of Condition
 Whether the monetary value contained in the document is added or subtracted from the overall price of a trade item is determined by the value for the field “condition type” contained in the related condition document. (Example – “promotion” value equals a subtraction of the numerical value from the overall price).
4.8 Document Keys
 Each of the three pricing documents has a set of keys, when used in combination, guarantee their uniqueness. The keys for the TPP are: Data Source (GLN of price information provider), GLN of buyer, Target Market and Trade Channel.  The keys the Condition Document the keys are: Data Source and Condition Document ID#; and the keys for the Monetary Document are: Data Source and Monetary Document ID#.
4.9 Relationship Among The Documents
 Each of the three documents, which together enable price synchronisation, are related and linked. A TPP can contain any number of conditions, with a minimum of one.  A condition can be associated with any number of monetary documents. A monetary document can only be associated back to a single condition document.
4.10 Versioning, Modification and Archiving
It is clear that future business requirements will evolve to include making multiple versions of price information available to a buyer, to modify current documents, and to archive documents. Configuration management of the documents was not addressed at this time.  It is anticipated that the GDSN task force and subsequent RDD task groups will work on this functionality when requested based upon the experience of the early implementers.
4.11 Trading Partner Profile Residence
When used within the GDSN, in order to facilitate exchange of price and other relationship dependent data (anticipated future functionality of the TPP), it has been determined that the keys of the TPP should reside in the GS1 registry. The TPP is developed together by seller and buyer. Within GDSN, it could reside in the designated data pool, which uses the TPP for publication purposes. It is the responsibility of the seller to keep the TPP up to date. Both trading partners may choose to store a copy of the TPP in their internal systems.
When used outside of GDSN, the TPP should reside within the seller and buyer’s internal systems.
4.12 Getting Started
The following provides a general outline of activities trading partners must perform to implement price synchronisation.  Also see above use case scenarios for graphical presentation.
4.12.1 Agree To Do Business
The two trading partners must agree to conduct business and to utilize these standards to communicate pricing information
4.12.2 Create Condition Documents
The first step in building the required message sets for price synchronisation is the creation by the seller of their condition message sets. This is the first step because the next message set, the Trading Partner Profile, refers to these conditions.
4.12.3 Managing How Many Condition Documents Are Needed
Sellers should review their pricing strategy to determine how many unique conditions they offer. In most cases, conditions apply to a number of trade items, many times across an entire product line, even across categories. Some are specific to a trade item or to a buyer. Sellers with a simple go to market strategy or with limited products may not need to create many condition documents.
4.12.4 Send Condition Documents
Within the GDSN the next step for a seller is to send their condition documents to data pools in preparation for synchronisation.  Outside the GDSN the seller sends the condition documents to their trading partner.
4.12.5 Create Trading Partner Profile(s)
The second step in the price data synchronisation process is the creation of a trading partner profile. The seller and buyer create this mutually.
4.12.6 Managing How Many TPPs Are Created
As explained in other sections of this document, there are several considerations as to how many TPPs two trading partners will need to create to best capture all of their agreements. Trading partners can choose to have a single TPP, or segment their relationship into multiple TPPs. This may be due to considerations such as “trade channel” (e.g. seller has two different pricing strategies such as: retail and food service) or even category strategies (e.g. seller has a separate TPP for each category sold, which could significantly reduce the number of monetary documents needed to communicate price if the seller’s pricing go to market strategy includes offers that apply to all products within a category) or possibly delivery mode used by trading partners (e.g. delivery vs. direct store delivery).
4.12.7 Sequencing
Sequencing describes the point in the calculation of a final price that a component of price should be applied. Each condition listed within a TPP must have a sequence number.
For all calculations, there must be a “starting price”. The starting price is given a sequence number of “1” (one). A condition with a value of 2 means “take any monetary value associated with this condition, and add/subtract this value from the starting price”. In the above example, a value of 3 indicates taking the monetary condition associated with the condition, and adding/subtracting this value from the subtotal reached once the previous condition’s values are acted upon. 
More than one condition can share the same sequence. Conditions with the same sequence number can be applied in any order without affecting the result of the calculation.
4.12.8  Send Trading Partner Profile(s)
Within the GDSN the TPP for a seller is sent to their data pool in preparation for synchronisation.  Outside the GDSN the seller sends the TPP to their trading partner.
4.12.9 Transmit TPP and Condition Documents (GDSN Only)
The next step is for the data pool to use the instructions contained in the TPP (which condition documents apply to a buyer, etc.) to publish both the TPP and condition documents to buyer.
 
Part of the proposed communication process is that the data pool will use existing item subscription records to filter the price data messages which will be delivered to a buyer. The assumption is not that all items published to a buyer should have price message sent, but that the buyer should not receive price information for a trade item for which they do not have item information.
4.12.10 Create Monetary Document(s)
The last step is the process is the creation of monetary documents, which is the part of the message that actually contains the numerical values which are used to communicate a final negotiated transaction price or to communicate components of a derived price.
4.12.11 Managing The Number Of Monetary Documents
Testing by the RDD Team has shown that, until there is further refinement to the model, there are two options for applicability of a monetary document: GTIN specific, or applied to all trade items covered by the TPP. Several technical and business reasons determine that a single monetary document cannot cover multiple GTINs.
  1. Technical – If multiple GTINs are allowed within a monetary document and publication by a data pool to a data recipient is dependent on that recipient’s response to previous item data transmission (they have provided and “accept or pend” response to a synchronisation message), then having multiple GTINs within a monetary document would make the publication process much more complicated for the data pool.  For example, the data pool would have to receive the monetary document, open the document, extract the list of GTINs, compare the list of GTINs to the “data recipient’s” list of accepted items, send data recipient multiple messages for each GTIN that was accepted, and “drop” the rest of the GTINs.  With a single GTIN, the match between the items a data recipient has accepted and the monetary documents that must be sent to the data recipient is easier.
  2. Technical – there are technical issues around having XML do “and/or” statements, which would be needed in the processing of monetary docs with multiple GTINs.
  3. Business –In lieu of a clear technical process to only provide retailers with pricing information for items they have agreed to trade on, the manufacturers were not keen on adding an option to the BRD that could potentially "SPAM" the retailers with pricing data for products they did not carry.
 A component based price structure will naturally require more monetary documents.
Using this understanding, a seller can manage the number of monetary documents needed to fully communicate all of their price data.
4.12.12 Monetary Documents Without GTINs
Initial testing of the model has shown that users must take care when exercising the option of not including a GTIN in a monetary document.
If a seller is communicating price at more than one level, there is a danger that a price component quoted in a monetary document without a GTIN may be mis-applied. (example $1 off. Is it one dollar per dispatch unit or consumer unit). In this situation, only percentages can be applied without causing errors.
  Another example where a monetary document without GTIN will still be valid if more than one level of information is shared is with “rate components” where the amount of the component does not depend on the number of units (example – rate of $1 per hundredweight discount)
4.12.13 Send Monetary Documents
Within the GDSN, the Seller sends all monetary documents to their data pool. The data pool routes the monetary documents to the data recipient using the combination of TPP directions (e.g. TPP and condition documents that are applicable to the buyer) and the record of what relevant GTINs have been synched with buyer. The data pool sends monetary documents where both the condition documents and the GTIN applies to the buyer.  Outside the GDSN, the Seller would send all monetary documents to their trading partner.
4.12.14 Message Choreography – (Within GDSN)
Communication starts with the seller sending their condition documents to their data pool (this assumes the data will reside in the data pool). The TPP message will be sent from seller’s data pool to buyer once a TPP has been finalized between the buyer and seller. The publication of an initial load when a new TPP is established will be triggered by the data pool receiving the TPP and acting upon the instructions contained within the TPP.  Publication of subsequent monetary document(s) will be triggered by an “accept” or “pend” message of the item message for that trade item or list of trade items. In a one to one model, acceptance of a product’s information will also trigger a price message.  After initial load, TPPs and condition documents will be published as modified or added. Monetary documents will be published after receipt of a “accept” or “pend” message for the related trade item or items.
Condition documents need to be produced first for both business and technical reasons. In most common business practices, sellers develop their go to market strategy before finalizing trading relationships with buyers. Technically, a condition document needs to exist in the data pool before the TPP can be communicated, because the TPP document refers back to the condition document. If buyers were to receive a TPP without having a condition document, the TPP could not validated.   
4.12.15 Target Market Definition
Use of target market within these standards:
  • The purpose of the target market is to allow users to organize the data being communicated into specific geographies. This has been identified as a clear business requirement.
  • For the purpose of this model, target market indicates how a seller manages their price on a trade item for trading partners located within this geography. 
  • Within this model, a target market is not used to control distribution of the trade item to other markets by the buyer, or to indicate where a seller intends that the trade item should be made available to consumers.
  • Eventually, “grouping” or aggregations or sub-divisions of country codes will evolve to represent common definitions of geographies (i.e. U.S less Alaska and Hawaii, Benelux).
  • In this standard, ISO country codes are used.
  • Please note – within the GDSN network, it has been established that the combination of three separate attributes, GTIN, GLN of information provider and Target Market act to identify a unique trade item. There are two “target markets” included in the monetary document, one that is part of the trade item ID key and the other to indicate the geography for which a particular monetary document’s value is applicable. The target market key associated with the monetary value may only take the value equal to or within a subdivision of the Target Market for which the data owner makes the item available. For example, if the item is available in the United States only, the target market for the monetary document must be the United States or a state within the United States.
4.12.16 Target Market Subdivision Code
  • A subdivision code level can be used to address/comply with a “law making” requirement associated with a country.
  • The number of subdivision codes may 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 subdivision codes.
  • A subdivision code must be associated with a Target Market Country Code.  It cannot stand-alone.
  • This standard employs the ISO standard for subdivision codes
4.12.17 Degree Of Location Granularity
The RDD Team recognizes that many direct store delivery (DSD) industries will require granularity below the subdivision code. It is understood that price can be specific to one buyer location (store) or greater. The GLN may be used to identify the level of specificity.
4.12.18 Use Of  Data Pool
The RDD Team recognizes that the role of a data pool (third party service provider) is important to the success of price data synchronisation. The following scenarios are expected:
4.12.18.1 No Data Pool
Trading partner(s) can elect to use the standards described in this document without employing the services of a data pool. To do so, one or both of the trading partners will need to develop internal capabilities in order to comply with the current GDSN certification standards, to validate all data to ensure compliance with approved standards and to handle the full publication and subscription requirements.  These relationship dependent data standards incorporate the optional fields (alternate trade item and party IDs) needed if the partners choose to communicate outside of the GDSN network.
4.12.18.2 Data Pool Resident Model
In this example, trading partners employ a data pool, and the seller agrees to allow their pricing data to persist, (remain stored) in the data pool. This is required by the model, as the overall message structure requires that the data pool understand and deploy the links between the three messages. (see “Relationship To Other Processes”). This option also allows for the full use of a data pools’ publication and subscription functionality and offers the option of using the data pool as agent of record. 
4.12.18.3 Data Pool Pass Through Model
In this example, trading partners employ a data pool, but the price data messages are only routed by the data pool, and not opened, validated or stored. Through testing within the RDD Team it has been determined that this choice will require incremental efforts by trading partners. Because data pools are only passing data, one or both of the trading partners will need to develop internal capabilities in order to comply with GDSN certification standards and to handle the full publication and subscription requirements.
4.12.19 Security
4.12.19.1 The Security (Confidentiality) Of  Price Data
While security of price data has been affirmed as an extremely important business requirement, this was beyond the capabilities and scope of the RDD Team.  Encryption is seen as one possible solution; and the RDD Team anticipates that third party service providers, including data pools, will provide users with other options to fulfil this requirement. It is expected that the GDSN task group will also enhance the work done by the RDD Team on security. A companion business requirement is that only the proper recipient of a pricing message will receive and be able to read messages intended for them. It is not expected that all price messages will be confidential, as some sellers may choose to manage their pricing structure at a country level, offering all potential trading partners the same price. This model allows for management of data either by buyer or by geography.
4.12.19.2 Implementation Of Security Within The Model
The standard for security within the GDSN network is being developed by the GDSN task group. It is out of the scope of the RDD Team to dictate or develop a methodology for implementing these security standards.
4.12.20  Relationship To Other Processes
The process of price data synchronisation has specific relationships to both party and item data synchronisation.
4.12.20.1 Item Data Sync
The “accept” message sent from a buyer to a seller in response to an item publication message, directly or through a designated data pool, is a prerequisite to price synchronisation. The business requirement is that a price should not be sent to a buyer unless they have confirmed that they intend to buy the trade item. Additionally, it is assumed that once a buyer “accepts” a trade item, they will require full price data to be shared by the seller.
4.12.20.2 Party Data Sync
The price data synchronisation model includes several references to GLN. It is assumed that at some point in the future, full party data synchronisation will be deployed, and that the party data included in this model will be shared between seller and buyer with party data synchronisation.
4.12.20.3 GDSN Network
While these standards can be applied in a one to one relationship that does not utilize the global data synchronisation network, it is anticipated that a large number of users will use this network.
4.12.21 Glossary Of Terms
A full glossary of terms is included in this document. It is important to note that it is especially important to clearly define terms used within these standards due to the existence of numerous terms today to describe the same fact.
4.12.22 Application Miscellaneous Notes
This section contains a variety of notes designed to help implementers build their price data model. Many of these notes are in response to comments and questions sent to the RDD Team by participants in the GSMP process.
4.12.22.1 Changes in Pricing Documents
It is recognized that there is a business requirement that changes (delete, update, withdrawal, modification) be made to pricing documents (TPP, condition and monetary documents).
4.12.22.2  Audit Trail
There is a clear business requirement that there be an audit trail of all three price documents. The RDD Team recognizes that this need may require the addition of new attributes to one or more of the price documents. The expectation is that the GDSN task group will offer specific options on how to achieve this business requirement
4.12.22.3 At What Logistical Hierarchy Level To Apply Price
These standards are not intended to change current pricing practices. Therefore, the price information communicated using these standards should be communicated at whatever level (item, case, pallet, etc.) the trading partners used before using these standards. The RDD Team has explored the possibility of including business rules which instruct or guide users to use one or another principle for choosing what logistical level to apply pricing to. Their finding is that this would cause significant issues, including rounding problems. It was also established that there was not an overriding commonality in business practices that could be used as a business rule.
It is important to note that sellers must carefully organize how they will manage the level at which they will offer price. Often, the same consumer item may be priced differently depending the logistical hierarchy in which it is contained (normal case pack vs. contained in a merchandising display).
4.12.22.4 Effective Dates
The Monetary Document, Trading Partner Profile and Condition Document all contain effective start and end dates.  The Condition Document also requires a context for these dates. Examples of context are order dates, ship dates (departure of the trade item from the seller) and arrival dates.
 
A review of business practices shows that conditions, monetary values and trading partner profiles can have different effective dates. These dates are not related to and may be different from “publication dates” when information is shared with the buyer.
 
An example of the usage of effective dates is as follows:
  • trading partners decide to create a trading partner profile that documents a list of agreements. The effective date is Jan 1, 2000. In the course of the relationship, a condition is created. This condition explains how the best price for a product can be achieved through purchase of 10,000 kilos of product. This condition becomes effective with orders on July 1 2001. A monetary value for a specific trade item changes due to commodity costs, and the effective dates for the item changes on August 1, September 15 and January 20.
4.12.22.5 Variable Weight Trade Items
The model can handle communication of price for a variable weight item with the exception of one issue, which is being addressed by the item task group. The process developed within these standards would require a GTIN to identify the trade item, and there are currently no standards for how to identify a variable weight trade item with a GTIN within the GDSN.
4.12.22.6 Trade Channel Updating
The enumeration list for Trade Channel if dynamic to satisfy all business needs and will require frequent updating
4.12.22.7 Parent GTIN
There is a clear requirement for the monetary document to provide both the GTIN of the item the price is for and the GTIN of the item’s parent.  This supports the business scenario where a consumer unit is offered in more than one logistical configuration, example - merchandising display vs. regular case. A common business practice is to offer different prices for the same consumer unit GTIN depending on its logistical hierarchy.
 
The optional field called “Parent GTIN” is used by the seller whenever a product is available in more than one configuration.  This additional information allows the buyer to differentiate between various versions of a single consumer unit price based on different logistical configurations.
Glossary of Terms
Code Lists
Back to Message Description
 
Date of Publication: March 2007
Copyright © GS1 Global Office 2007. All rights reserved