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 2 - Client (PC/Mac) EDI Application with VAN/ISP

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

Introduction

In this example, the buyer has enhanced version of client application that has import/export capabilities for interfacing with back-end systems, and seller has basic version of client with no back-end integration.

In practice, a company with a client EDI application can exchange data with other companies that have a client EDI application (with or without back-end integration), or with a partner that uses a "traditional" EDI solution.


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, the buyer has enhanced version of client application that has import/export capabilities for interfacing with back-end systems, and seller has basic version of client with no back-end integration.

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 import into the client EDI application.   In this example, the back-end interface generates a proprietary internal format.
3. Some client EDI applications have some gateway functionality built in so that some gateway activities may be performed while the application is not connected to the VAN.  In this example, mapping and other gateway functions are being performed in the client application while not connected to the VAN (compare with step 8 below).

a.  The Purchase Order data file is imported into the client EDI application.  The user has the option to display and modify the purchase order before releasing for transmission.  The client application usually has options for releasing orders one-by-one, in groups, or all new orders at once.

b.  The Purchase Order is released, and the client EDI gateway application extracts the order from the client application's data base and generates an ASC X12 or UN/EDIFACT Purchase Order.

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. The user may choose to connect and send the newly created purchase order immediately, or save it and send it later, or the client application may be configured to connect with the VAN per a schedule, and any purchase orders that are marked as ready for send are sent.  The client application deposits data into the buyer's 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. Some client EDI applications require that the user be connected to the VAN in order to perform most gateway functions.   In this example, mapping and other gateway functions are being performed at the VAN, so the client application must be connected to the VAN (compare with step 3 above).

The seller receives the data file by connecting to the VAN.

9. When the data file is received into the client EDI application, the application unwraps (opens) the data file.  If the sender has sent data in one large file, the VAN will have parsed it into separate files for each group or document.
10. The incoming document is checked for compliance against the standard, accessing the VAN's data bases and/or standards dictionaries.
11. If required by the buyer, the client EDI application triggers the VAN to create 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 VAN converts the data from an ASC X12 or UN/EDIFACT Purchase Order and posts it to the client application's data base.  This will allow the user to view the purchase order as needed later, while not connected to the VAN.
13. In this example, the seller does not have any back-end integration capability, so most of the processing of the purchase order occurs manually.  The user may print the purchase order, and may use the printout or display to manually load the order into a back-end application.  Even though there is no back-end integration, the seller still performs mot of the 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.

Some large customers work with the providers of client EDI applications to create templates that the seller can use for creating response documents.  So, for a purchase order, a template may be available that creates the PO response by "flipping" the PO and pre-populating the PO Response from the purchase order.  If the seller can commit to all the buyer's requested prices, quantities, and delivery dates, the PO Response may be released without modification; alternatively, the user can modify the PO Response as needed before sending it.

If no customer-specific template is available for creating a PO response from a PO, the client EDI application still allows for a PO Response to be created from scratch.  The client EDI application retrieves the standard message definition from the VAN's data base and generates a form for the seller to fill out.  The one problem with creating a PO response from scratch is that the seller could end up not populating a field that is optional in the standard but required by the buyer, or could end up populating a field that the buyer's translator ignores, but contains important information from the seller.

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. The PO Response is released, and the VAN extracts it from the client application's data base and generates an ASC X12 or UN/EDIFACT Purchase Order.
16. The VAN envelopes and validates the PO Response before sending it. 
17. The user is connected to the VAN, so as soon as the user tells the application to send the PO response, the VAN exports the PO Response to the buyer's mailbox.
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 client EDI application 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.  Click here for description of typical processing steps.
24. If required by the seller, the client EDI application 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 client EDI application 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 client EDI unwraps (opens) and validates the Receipt Acknowledgment.
29. The status of the PO Response transmission is updated in the client EDI application 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