CompTIA EIDX - Order Model 1A-option 4

sitemap

EIDX Home

About EIDX

Benefits of Membership

Business Process

	Current Projects
	Clickable Business Models
	Business Model Navigational Help
	Business Model Development Methodology
	Business Model Legends

Education

Guidelines & Standards

LOGIN

PASSWORD

remember my login

forgot my password

EIDX Order Model IA, Technology Option 4:
Integrated B2B via 3rd Party
(Modern VAN or ISP), "Standards Agnostic" (Generic B2B)
In this example, both buyer and seller support the same B2B business content standard and 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 finding it difficult to manage 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 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.

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:

ASC X12 (legacy EDI standard)
UN EDIFACT (legacy EDI standard)
RosettaNet XML
OAGIS XML

Order Model IA, Technology Option 4 Activity Diagram

Click here to view a larger image.

Order Model IA, Technology Option 4 Activity Narration

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 (PO). 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) PO 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.
2.	Application software extracts the PO 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, etc.
3.	The EDI gateway application maps (translates) the file from internal format to a PO 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 (a/k/a wrapping, enveloping) for transmission to the VAN. 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 upon the transport and routing standard used. In this technology option, the sender establishes a single transport and routing protocol for communications with their VAN, ending 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.
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.
7.	The VAN translates the PO into the standard used by the seller.
8.	The document (the payload) is packaged for transmission to the seller.
9.	EIDX recommends that a sender validate their own outbound documents for compliance with the standards before sending the documents to a trading partner.
10.	The business document is authenticated electronically through the attachment of a digital signature and is encrypted in preparation for secure transporting.
11.	POs 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 PO 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 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 to translate the data.
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 PO document at their gateway, and whether or not it passed the compliance check. Just like the PO document, the receipt acknowledgment needs to be packaged and validated before being sent. RosettaNet requires the use of a receipt acknowledgment.
17.	If necessary, the B2B gateway application maps the file into the format expected by the back-end application.
18.	The seller processes the PO to load it into their back-end application.
19.	The TPA documents the buyer's expectation turnaround time on response documents. Typically, a buyer expects a PO response be sent in 24 to 72 hours. The seller should send a response within this time limit and indicate 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. While the receipt acknowledgment (step 11) indicates that the PO 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, etc.
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 PO, 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 PO 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 PO.
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.	The seller decrypts, unwraps 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.