| Step |
Description |
| In this example, both
buyer and seller support traditional EDI - using either the
ASC X12 or UN/EDIFACT business content standards - and both
parties have the EDI process integrated with their back-end.
|
| Buyer's Back-end
Application |
| 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 EDI
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 ASC X12 or
UN/EDIFACT PO. Note: Some companies outsource the mapping
to their VAN service provider, and send their proprietary format
file to the VAN. |
| 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. |
| 6. |
POs 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 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 PO 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. |
The seller receives
the data file. |
| 9. |
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. |
| 10. |
The seller checks the
incoming document for compliance against the standard. |
| 11. |
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. Unlike the PO, 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 EDI gateway application
translates the file from an ASC X12 or UN/EDIFACT PO
to an internal format. Note: Some companies outsource
mapping to their VAN service provider. |
| 13. |
Seller processes
the PO to load into back-end application. |
| 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.
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.
|
| 15. |
Application software
extracts the PO Response into a data file for transmission to
the EDI 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. |
| 16. |
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. |
| 17. |
PO Responses are sent
to the VAN as in the buyer's step 6 above. |
| 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 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! |
| 21. |
The status of the PO
transmission is updated in the gateway to indicate that the
transmission was received by the seller. |
| 22. |
The buyer opens, 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. It
indicates that the seller either accepts or rejects the PO.
|
| 24. |
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. |
| 25. |
The buyer 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. |
Seller opens and validates
the receipt acknowledgment if it is used. |
| 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. |
contact
us 
