In practice, a company with a client EDI application
can exchange data with other companies that have a client EDI application
(with or without back-end integration), or with a partner that uses
a traditional EDI solution.
| Step |
Description |
|
In this example, the buyer has enhanced version of client
application that has import/export capabilities for interfacing
with back-end systems, and seller has basic version of client
with no back-end integration.
|
| 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 import into the client
EDI application. In this example, the back-end interface
generates a proprietary internal format. |
| 3. |
Some client EDI applications
have some gateway functionality built in so that some gateway
activities may be performed while the application is not connected
to the VAN. In this example, mapping and other gateway
functions are being performed in the client application while
not connected to the VAN (compare with step 8 below).
a. The PO data file is imported into the client EDI
application. The user has the option to display and
modify the PO before releasing for transmission. The
client application usually has options for releasing orders
one-by-one, in groups, or all new orders at once.
b. The PO is released, and the client EDI gateway
application extracts the order from the client application's
data base and generates an ASC X12 or UN/EDIFACT PO.
|
| 4. |
The document is packaged
for transmission to the VAN (a/k/a Wrapping, Enveloping).
The packaging consists of adding service segments - heading
and trailing data to the translated document.
- 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. |
The user may choose
to connect and send the newly created PO immediately, or save
it and send it later, or the client application may be configured
to connect with the VAN per a schedule, and any POs that are
marked as ready for send are sent. The client application
deposits data into the buyer's 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 at regular intervals 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. |
Some client EDI applications
require that the user be connected to the VAN in order to perform
most gateway functions. In this example, mapping
and other gateway functions are being performed at the VAN,
so the client application must be connected to the VAN (compare
with step 3 above).
The seller receives the data file by connecting to the VAN.
|
| 9. |
When the data file is
received into the client EDI application, the application unwraps
(opens) the data file. If the sender has sent data in
one large file, the VAN will have parsed it into separate files
for each group or document. |
| 10. |
The incoming document
is checked for compliance against the standard, accessing the
VAN's data bases and/or standards dictionaries. |
| 11. |
If required by the buyer, the client
EDI application triggers the VAN to create 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 VAN converts the
data from an ASC X12 or UN/EDIFACT PO and posts it to the client
application's data base. This will allow the user to view
the PO as needed later, while not connected to the VAN. |
| 13. |
In this example, the
seller does not have any back-end integration capability, so
most of the processing of the PO occurs manually. The
user may print the PO, and may use the printout or display to
manually load the order into a back-end application. Even
though there is no back-end integration, the seller still performs
mot of the typical processing steps. |
| 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.
Some large customers work with the providers of client EDI
applications to create templates that the seller can use for
creating response documents. So, for a PO, a template
may be available that creates the PO response by flipping
the PO and pre-populating the PO response from the PO.
If the seller can commit to all the buyer's requested prices,
quantities, and delivery dates, the PO response may be released
without modification; alternatively, the user can modify the
PO response as needed before sending it.
If no customer-specific template is available for creating
a PO response from a PO, the client EDI application still
allows for a PO response to be created from scratch.
The client EDI application retrieves the standard message
definition from the VAN's data base and generates a form for
the seller to fill out. The one problem with creating
a PO response from scratch is that the seller could end up
not populating a field that is optional in the standard but
required by the buyer, or could end up populating a field
that the buyer's translator ignores, but contains important
information from the seller.
While the receipt acknowledgment 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. |
The PO response is released,
and the VAN extracts it from the client application's data base
and generates an ASC X12 or UN/EDIFACT PO. |
| 16. |
The VAN envelopes and
validates the PO response before sending it. |
| 17. |
The user is connected
to the VAN, so as soon as the user tells the application to
send the PO response, the VAN exports the PO response to the
buyer's mailbox. |
| 18. |
The VAN transfers data
from buyer's mailbox to seller's mailbox as in step 7. |
| 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
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 client EDI application to indicate
that the transmission was received by the seller. |
| 22. |
The buyer unwraps, validates
and translates the data file just as in steps 9, 10, and 12. |
| 23. |
The buyer processes
the PO response to load it into their back-end application.
|
| 24. |
If required by the seller,
the client EDI application 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 client EDI application
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. |
If it is used, the client
EDI opens and validates the receipt acknowledgment. |
| 29. |
The status of the PO
response transmission is updated in the client EDI application
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 
