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 3b - EDIINT:  Legacy EDI Over the Internet - Point-to-Point

Special Notes:                   
Activity Diagram
In Technology Option 3 (Generic) Section:
General Information About This Technology (not created yet)
Business User View (not created yet)


In this example, both buyer and seller support "traditional" EDI - using either the ASC X12 or UN/EDIFACT business content standards - and are using the internet to send and receive data per EDIINT.  EDIINT is an internet specification from the IETF for reliably exchanging structured messages over the internet.  It is often used as an extension of Traditional EDI, using the existing back-end application and gateway processes.  The difference is that instead of sending data to a "traditional" VAN, the EDI data is formatted to be sent over the internet as a secure e-mail attachment, and the communications with trading partners are point-to-point

Both partners must be capable of supporting EDI over the internet.  EDIINT-compliant solutions do not all interoperate, so both parties may have to use the same solution, e.g. Templarâ„¢, ECXpertâ„¢, etc.

Activity Diagram (See also Narrative)

Smaller Print Version of Diagram
(Change to Landscape Orientation to Print)

Note: The "Receipt Acknowledgment" signal is shown as "optional" via the "Used" guard condition because in Europe, the EDIFACT message, CONTRL, is not always used; VAN audit reports are used instead.  The X12 message, 997 Functional Acknowledgment, is almost always used in the U.S.

Narrative (see also Graphic):

Step Description
In this example, both buyer and seller support "traditional" EDI - using either the ASC X12 or UN/EDIFACT business content standards - and are using the internet to send and receive data per EDIINT.
A. At Start Point 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. - 5. The existing EDI infrastructure is used; steps 1-5 are the same "Traditional EDI" steps 1-5.
6. Purchase orders that have passed validation are sent to the EDIINT server.
7. The EDIINT server receives EDI files.
8. The EDIINT software formats the EDI file as an S/MIME file, including converting EDI addresses into email addresses, signing, encrypting, and encoding.

The EDIINT application typically tracks and logs the entire round-trip process to provide a complete history of the transaction.

9. The message is sent to the internet mail server, and the order is sent as a secured e-mail attachment.
12. - 14. The Internet Service Providers route the message, and finally it is received on the seller's mail server.
15. - 16. The message is transferred to and received on the seller's EDIINT server.  The seller's EDIINT application (must be same EDIINT application the buyer is using) creates a notification message and sends it to the original sender to verify receipt of the original message.
17. The seller's EDIINT application decrypts the message and performs authentication and verifies that the data has not been changed (data integrity).  The EDI data is recreated by decoding and extracting S/MIME attachment, and converting e-mail addresses into EDI addresses.
18. - 19. The EDI data is transferred to the EDI gateway, to be processed just like any EDI file received from a VAN.
20.+ The PO file is opened, validated, translated, and so on. All other processing is just the same as for "Traditional EDI".
28.+ The process is going to continue on "in reverse" to transport the PO Response and the Receipt Acknowledgment back through the EDIINT server, the mail server, the ISP, and so on.
47.+ The process reverses once again to send a Receipt Acknowledgment to the seller's gateway telling the them that the PO Response was received, and whether or not it passed validation.

Last updated 04 January 2003