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 3a - Integrated B2B, no VAN, "Standards Agnostic" (Generic B2B)

Special Notes:                   
Introduction
Activity Diagram
Narrative
 
In Technology Option 3 (Generic) Section:
General Information About This Technology (not created yet)
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.  The buyer is using a solution where the Enterprise Integration Application pulls data from the buyer's back-end system to the B2B gateway, and the seller is using a solution that pushes data from the back-end application to the B2B gateway.

In practice, a company with either type of B2B gateway process (push vs. pull) can exchange data with companies that have either type of B2B gateway process.

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 support the same B2B business content standard, and the same messaging standards, including security and transport protocols. 
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 in both B2B gateways.
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. The EAI software or other B2B gateway application extracts the purchase order data.   The data may be extracted into a proprietary or application-specific format such as SAP IDOC, Oracle data file, Baan EDI file, and so on, or it may be extracted into a standard XML format.
3. If needed, the B2B gateway application maps (translates) the data into the standard format used by the recipient.  The target format may be any one of several B2B business content standards, including ASC X12, UN/EDIFACT, OAGIS XML, RosettaNet XML, or another XML business content standard.
4. The document (the payload) is packaged for transmission to the seller (a/k/a Wrapping, Enveloping). 
  • Just about all XML standards organizations agree on converging to the ebXML standard for transport and routing (TR).  The ebMXL TR is payload-neutral - payload for any standard can be contained in an ebMXL package.
  • OAGIS XML is transport-neutral.   OAGI has published white papers describing how to send and receive OAGIS payloads using ebXML's Transport and Routing, the BizTalkā„¢ Framework, or the RosettaNet Implementation Framework version 2.0.
  • RosettaNet Implementation Framework (RNIF) version 1.1 requires RosettaNet-specific packaging that results in the creation of a package called a "RosettaNet Object" (RNO); only a RosettaNet payload can be contained in the package.
  • RosettaNet Implementation Framework (RNIF) version 2.0 is a step towards converging on the ebXML TR.  It uses a more standard enveloping (S/MIME), and allows the inclusion of attachments containing non-RosettaNet payloads.
  • The legacy EDI standards, X12 and EDIFACT, are transport neutral, and like OAGIS XML, can be exchanged using any standardized protocol.
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 business document is authenticated electronically through the attachment of a digital signature, and is encrypted in preparation for secure transporting.
7. Purchase orders are sent to the trading partner.  Typically, the buyer's B2B gateway is given a secure login to a directory on the seller's gateway server, where the buyer deposits documents intended for the seller.  Buyers can access only their own directories, and no buyer can access another buyer's directory.
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.
8. 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.
9. The data is decrypted.
10. 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.
11. The seller checks the incoming document for compliance against the standard.
12. 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.
13. If necessary, the B2B gateway application maps (translates) the file into the format expected by the back-end application.
14. The seller processes the purchase order to load it into their back-end application.  Click here for description of typical processing steps.
15. 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.

16. 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.
17. 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.
18. PO Responses are encrypted and signed as in the buyer's step 6 above.
19. The documents are transferred as in the buyer's step 7 above.
C. Start state C is the buyer's counterpart to the seller's start state B.
20. 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.
21. If it is used, the buyer decrypts and 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!
22. The status of the purchase order transmission is updated in the gateway to indicate that the transmission was received by the seller.
23. The buyer decrypts, unwraps, validates and (if needed) translates the data file just as in the seller's steps 9, 10, 11, and 13 above.
24. 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.
25. If required by the seller, the buyer creates and wraps 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. 
26. The buyer validates, encrypts and signs the outbound Receipt Acknowledgment and then transports it to the seller.
27. 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.
28. If it is used, the seller decrypts, 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