Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Order Models Index | Supporting Documentation | Downloads | FAQs |
Order Model 1 - Discrete Purchase Order, Established Customer, Established Product, Version 2.0 
Status:  Provisional Ratification by Committee April 2000. Created as part of recast of original order models, Pre-2000 Version C (Balloted and Ratified by Membership, November 1996), into Replenishment Scenarios.

Implementation Option 1 - "Traditional" EDI via a VAN

Special Notes:                   
Introduction
Activity Diagram
Narrative
 
In Technology Option 1 (Generic) Section:
General Information About This Technology
Business User View (Generic Technology Option)
 

Introduction

In this example, both buyer and seller support "traditional" EDI - using either the ASC X12 or UN/EDIFACT business content standards, and both parties have the EDI process integrated with their back-end.

Order Model 1a -  Create Purchase Order Sub-process is described here, but the other sub-processes can be derived from this model:

Activity Diagram (See also Narrative)

Smaller Print Version of Diagram

Note: The "Receipt Acknowledgment" signal is shown as "optional" via the "Used" guard condition because in Europe, the EDIFACT message, CONTRL, is not always used; VAN audit reports are used instead.  The X12 message, 997 Functional Acknowledgment, is almost always used in the U.S.


Narrative (see also Graphic):

Step Description
In this example, both buyer and seller support "traditional" EDI - using either the ASC X12 or UN/EDIFACT business content standards, and both parties have the EDI process integrated with their back-end. 
Buyer's Back-end Application
A. At start state A, preorder and planning processes have occurred and the buyer is ready to create a purchase order.  The trading partners have a relationship already established; all applications and parties involved in the exchange have the correct configurations established, including registration of the trading partnership and one or more VANs.
1. The buyer creates a discrete (standalone) purchase order in the back-end application.  The buyer may save it if it is not ready to send, or may mark it as ready to be transmitted and/or printed.   Click here for description of typical processing steps.
2. Application software extracts the purchase order into a data file for transmission to the EDI gateway.   Assumption: Back-end interface generates proprietary format or application-specific format such as SAP IDOC, Oracle data file, Baan EDI file, and so on.
A3.  
3. The EDI gateway application maps (translates) the file from internal format to ASC X12 or UN/EDIFACT Purchase Order.  Note: Some companies outsource the mapping to their VAN service provider, and send their proprietary format file to the VAN.
4. The document is packaged for transmission to the VAN (a/k/a Wrapping, Enveloping).  The packaging consists of adding some heading and trailing data segments to the translated document.  These are some times called "service segments."
  • In the ASC X12 standard, there are two envelopes - the inner envelope, which contains documents between the "GS" (Functional Group Header) and "GE" (Functional Group Trailer) segments, and the outer envelope, which contains Functional Groups between the "ISA" (Interchange Control Header) and "IEA" Functional Group Trailer.
  • In the EDIFACT standard, one envelope is used.  Documents are contained between the "UNB" Interchange Header and "UNZ" interchange trailer.
5. EIDX recommends that a sender validate their own outbound documents for compliance with the standards before sending the documents to a trading partner.  More.
6. Purchase orders that have passed validation are sent to the VAN.  The gateway application deposits data into the buyer's own mailbox on the VAN.  More.
7. The VAN transfers data from buyer's mailbox to seller's mailbox if both are using the same VAN.  If the seller is using another VAN, the buyer's VAN interconnects to the seller's VAN to transfer the data.
B. Start state B indicates that the connection to a VAN may be initiated independently from the purchase order process.  Typically, a trading partner agrees to check VAN periodically (hourly, daily, etc.) for new documents of any type (a pull process) and this is documented in the TPA.

In some cases, the partner may have an "always on" connection, and arranges to have the VAN automatically open a session and deliver new documents to the EDI application (a push process).

8. The seller receives the data file.
9. The seller unwraps (opens) the data file.  Often, data is received in one large file, and the recipient has to parse it into separate files for each group or document, so that the data can be translated.
10. The seller checks the incoming document for compliance against the standard.
11. If required by the buyer, the seller creates a Receipt Acknowledgment, which indicates that the seller received the Purchase Order document at their gateway, and whether or not it passed the compliance check.  Just like the purchase order document, the Receipt Acknowledgment needs to be packaged and validated before being sent.  Unlike the Purchase Order, which is a "document", the Receipt Acknowledgment is classified as a "service" transaction.
  • In general, users of the ASC X12 standard require the use of a Receipt Acknowledgment - the "997" (Functional Acknowledgment).
  • There is a counterpart to the X12 997 in EDIFACT, the CONTRL message, but it is rarely used.  In Europe, particularly, senders rely on reports from their VANs to determine whether or not a trading partner has received a transmission.
12. The EDI gateway application maps (translates) the file from an ASC X12 or UN/EDIFACT Purchase Order to an internal format.  Note: Some companies outsource the mapping to their VAN service provider, and receive their proprietary format file to the VAN.
13. The seller processes the purchase order to load it into their back-end application.  Click here for description of typical processing steps.
14. The TPA documents the buyer's expectation turnaround time on response documents.  Typically, a buyer expects a PO Response to be sent in 24 to 72 hours.  The seller should send a response within the required time limit, indicating that the order was either accepted or rejected.  If the seller cannot confirm their ability to meet the buyer's requirements for delivery, the seller should indicate in the response that the commitment to requested dates and quantities is pending, and then follow-up with another PO Response as soon as the commit information is available.  More.

While the Receipt Acknowledgment (step 11) indicates that the purchase order transmission made it to the seller's gateway, the PO Response tells the buyer that the order made it all the way to the seller's back-end application.

15. Application software extracts the PO Response into a data file for transmission to the EDI gateway.  Assumption: Back-end interface generates proprietary format or application-specific format such as SAP IDOC, Oracle data file, Baan EDI file, and so on.
16. The seller translates, envelopes and validates the PO Response before sending it.  These are the same activities the buyer performed for the PO in steps 3, 4 and 5.
17. PO Responses are sent to the VAN as in the buyer's step 6 above.
18. The VAN transfers data from buyer's mailbox to seller's mailbox as in the buyer's step 7 above.
C. Start state C is the buyer's counterpart to the seller's start state B.
19. The buyer retrieves documents from their mailbox on the VAN.
20. If it is used, the buyer unwraps (opens) and validates the Receipt Acknowledgment.  Unlike the Purchase Order, which is a "document", the Receipt Acknowledgment is classified as a "service" transaction.  A Receipt Acknowledgment is never created in response to an Receipt Acknowledgment!
21. The status of the purchase order transmission is updated in the gateway to indicate that the transmission was received by the seller.
22. The buyer unwraps, validates and translates the data file just as in the seller's steps 9, 10, and 12 above.
23. The buyer processes the PO Response to load it into their back-end application. It indicates that the seller either accepts or rejects the Purchase Order.  Click here for description of typical processing steps.
24. If required by the seller, the buyer creates a Receipt Acknowledgment, which indicates that the buyer received the PO Response document at their gateway, and whether or not it passed the compliance check. 
25. The buyer validates the outbound Receipt Acknowledgment and then sends it to the VAN.
26. The VAN transfers data from the buyer's mailbox to the seller's as in the buyer's step 7 above.
27. The seller retrieves documents from their mailbox on the VAN.
28. If it is used, the seller unwraps (opens) and validates the Receipt Acknowledgment.
29. The status of the PO Response transmission is updated in the gateway to indicate that the transmission was received by the buyer.
D. At end state D, the legal commitment to do business exists.  The order is in an "open" state until it has been entirely fulfilled.  Some orders are fulfilled immediately.  Orders that remain open for any length of time are subject to both buyer-initiated and seller-initiated changes, and changes to the status of delivery schedules per the main Order Model 1.
E. End state E is the seller's counterpart to the buyer's end state D.

Last updated 01 February 2003