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 5a1 - Seller Uses Buyer's Web Application, Buyer's Data is Mastered in Back-End Application

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

Introduction

In this example, the seller has no existing B2B infrastructure, but does have PCs or workstations and access to the internet.  The buyer has a fully integrated eBusiness solution, and is using it to generate purchase orders to suppliers.  The buyer's back-end application has functionality in place for extracting purchase orders and posting purchase order responses.  The buyer's gateway receives all purchase orders from the back-end application and determines which get translated into a standard format and transmitted to the seller via a VAN (connection to VAN could be via dial-up or internet) or directly to the seller's gateway via the internet, and which get translated and transmitted to a web application where suppliers can view documents and create response documents.  The web application may be the buyer's application or trading hub running in the buyer's Virtual Private Network, or may be a service provided by a 3rd party.


Activity Diagram (See also Narrative)

Smaller Print Version of Diagram

 


Narrative (see also Graphic):

Step Description
In this example, the seller has no existing B2B infrastructure, but does have PCs or workstations and access to the internet.  The buyer is has a fully integrated eBusiness solution, and is using it to generate purchase orders to suppliers.  The buyer's back-end application has functionality in place for extracting purchase orders and posting purchase order responses.  The buyer's gateway receives all purchase orders from the back-end application and determines which get translated into a standard format and transmitted to the seller via a VAN (connection to VAN could be via dial-up or internet) or directly to the seller's gateway via the internet, and which get translated and transmitted to a web application where suppliers can view documents and create response documents.  The web application may be the buyer's application running in the buyer's Virtual Private Network, or may be a service provided by a 3rd party.
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 client application.   Assumption: Back-end interface generates proprietary format or application-specific format such as SAP IDOC, Oracle data file, Baan EDI file, and so on.  An XSLT map may be used to transform the data from one XML standard to another (if needed).
3. If the web application is in the buyer's extranet/VPN, the buyer should still encrypt the data for transport across the intranet firewall.  If the web application is outsourced to a 3rd party, the document may be authenticated electronically through the attachment of a digital signature, and then encrypted in preparation for secure transporting.
4. The data is decrypted.
5. The purchase order is parsed and posted to the web application's data base.  An XSLT map may be used to transform the data for display in the web application.
May use XSLT map to transform the data for display in the web application.
6. If the order is successfully posted to the web application data base, a notification is created and sent to the seller, informing of the need to login in and read the order; if possible, the notification should include the login URL.  If the purchase order has a static URL, it may also be included in the notification.
7. A notification is created and sent to the buyer regardless of whether the order was successfully posted; the notification either alerts the buyer that the posting failed, or that it succeeded , that a notification was sent to the seller,  and what time the notification was sent.  This notification is an approximate equivalent to a Receipt Acknowledgment.
8. The buyer reads the buyer notification.
B. In end state B the buyer knows whether or not the order has been successfully posted to the web application.
9. The seller reads the seller notification.
10. The seller logs on and displays the purchase order.
11. The seller processes the purchase order, and may simply print it, or manually enter the order data into a back-end application.  The web application may provide downloadable files in standard formats.  A seller might manually download a file and load it into a back-end system as part of testing and transitioning to an integrated B2B solution.

The business processing is essentially the same as for an integrated process; it's just that most of it is performed manually.  Click here for description of typical processing steps.

12. 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.

As a recommended best practice, the web application should create 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 needs no modification; alternatively, the user can modify the PO Response as needed.

While the e-mail notification in step 7 indicates that the purchase order was posted to the web application,  the PO Response tells the buyer that the seller actually read it.

13. The seller uses a "save" function to post the PO Response to the web application data base.
14. If the PO Response is not ready to send to the buyer, the seller may save it without marking it for send, and then re-display and modify the PO Response data when ready.
15. The seller uses a "save" function to update the PO Response in the web application data base.
16. If the PO Response is ready to send to the buyer, the seller marks it for send.
17. Web application software extracts the PO Response into a data file for transmission to the buyer's gateway inside the firewall.
18. The gateway unwraps, validates and translates the data file into the format expected by the back-end application.
19. 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.

Last updated 28 December 2002