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 4a - Integrated B2B via 3rd Party
(Modern VAN or ISP), "Standards Agnostic" (Generic B2B)

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

Introduction

In this example, both buyer and seller support the same B2B business content standard, and the same messaging standards, including security and transport protocols.  Both parties have the B2B process integrated with their back-end.

Companies using new B2B standards such as OAGIS and RosettaNet are rediscovering the pain of managing many point-to-point connections with trading partners, and are turning to the modern VAN to handle communications.   In this example, the buyer is using a VAN, and connects to the VAN via secure dial-up.  The buyer and seller support use different B2B business content standards; the buyer sends a single format to the VAN, and the VAN transforms the data if the seller uses a different standard.  The VAN and the seller connect with an internet connection.

In practice, most B2B exchanges use the same content standard, so there's no need for the VAN to transform the data.  If the seller is also using a modern VAN, the processing is exactly the same as for Technology Option 1, except that modern VANs now support many of the newer B2B content standards, and not just the legacy EDI standards.

Many standards can be traded via the internet.  Some have specific requirements for transport and routing, and others are "transport-neutral", meaning that the standard addresses only payloads which can be sent using any transport protocol.  The business content standards that can be traded via the internet include:

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


Narrative (see also Graphic):

Step Description
In this example, both buyer and seller a third-party service provider for managing electronic transmissions - the modern VAN- and both parties have their business processes integrated with their back-end. 
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 eBusiness 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.
3. The EDI gateway application maps (translates) the file from internal format to a Purchase Order in a standard format, such as ASC X12, EDIFACT, RosettaNet, or OAGIS. 

In this technology option, the sender sends everything to the VAN using a single standard format, regardless of what the trading partner needs to receive (see Step 7.)

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" or "message wrappers".  The segments or wrappers used depend on the transport and routing standard used.

In this technology option, the sender establishes a single transport and routing protocol for communications with their VAN, and so  end all messages to the VAN using the same message wrapper, regardless of what the trading partner needs to receive (see Step 8).

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 translates the purchase order into the standard used by the seller.
8. The document (the payload) is packaged for transmission to the seller (a/k/a Wrapping, Enveloping).   See Technology Option 4a, step 4.
9. EIDX recommends that a sender (in this case, the VAN) validate their own outbound documents for compliance with the standards before sending the documents to a trading partner.  More.
10. The business document is authenticated electronically through the attachment of a digital signature, and is encrypted in preparation for secure transporting.
11. Purchase orders are sent to the buyer's trading partner.   The seller may pull documents from the VAN or the VAN may push documents to the seller's B2B gateway.
B. Start state B indicates that the seller's gateway is checking the server for deposited files independently from the purchase order process.  Typically, the seller's B2B gateway polls trading partner directories every n seconds to n minutes to see if any files have been received.
12. When files have been received, the B2B gateway routes the files to a another directory.  The presence of files in this other directory invokes the appropriate processing.
13. The data is decrypted.
14. 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.
15. The seller checks the incoming document for compliance against the standard.
16. 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.
  • RosettaNet requires the use of a Receipt Acknowledgment.
17. If necessary, the B2B gateway application maps (translates) the file into the format expected by the back-end application.
18. The seller processes the purchase order to load it into their back-end application.  Click here for description of typical processing steps.
19. 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.

20. Application software extracts the PO Response into a data file for transmission to the B2B gateway.  Assumption for this example: Back-end interface generates proprietary format or application-specific format such as SAP IDOC, Oracle data file, Baan EDI file, and so on.
21. The seller translates, envelopes and validates the PO Response before sending it.
22. PO Responses are encrypted and signed.
23. The documents are transferred to the VAN.
C. Start state C is the VAN's counterpart to the seller's start state B.
24. PO Responses are sent to the VAN.   The seller may push the documents to the VAN or the VAN may pull documents from the seller's B2B gateway.
25. The VAN decrypts, unwraps, validates and translates the data.
D. Start state D is the buyer's counterpart to the seller's start state B.
26. The buyer retrieves documents from their mailbox on the VAN.
27. 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!
28. The status of the purchase order transmission is updated in the gateway to indicate that the transmission was received by the seller.
29. The buyer unwraps, validates and translates the data file.
30. 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.
31. 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. 
32. The buyer validates the outbound Receipt Acknowledgment and then sends it to the VAN.
33. The VAN translates, wraps, validates, encrypts, signs and transports the Receipt Acknowledgment.
34. When files have been received, the B2B gateway routes the files to a another directory.  The presence of files in this other directory invokes the appropriate processing.
35. If it is used, the seller decrypts, unwraps (opens) and validates the Receipt Acknowledgment.
36. The seller reads the Receipt Acknowledgment.
37. The status of the PO Response transmission is updated in the gateway to indicate that the transmission was received by the buyer.
E. At end state E, 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.
F. End state F is the seller's counterpart to the buyer's end state E.

Last updated 01 February 2003