Information Exchange is a key feature of EDI Services, but there are other components needed to manage the flow of transactions. If you're doing EDI, you need a product to translate your transactions from the format your applications understand into the standard EDI format. Your trading partners then need to translate these transactions into the format understood by their applications. You also need to communicate your translated transactions to your trading partners' electronic mailboxes.

1. In this scenario, trading partner A has a purchase order application that generates a purchase order to be sent to trading partner B, one of its suppliers. Both trading partners use Information Exchange, the mailbox feature of EDI Services.
    
2. The purchase order application places the purchase order in a file. The purchase order is not in an EDI standard format. It's in the format understood by the purchase order application.
    
3. Trading partner A has GXS's WebSphere Data Interchange for Multiplatform, another feature of EDI Services, installed as its translation software, and is using WebSphere Data Interchange Client as a graphical interface. Note that another translation product running on a different platform could have been used. In this case, WebSphere Data Interchange for Multiplatform takes the file and converts it to the standard EDI format for purchase orders.
    
4. WebSphere Data Interchange for Multiplatform places the converted purchase order into another file.
    
5.  Trading partner A has GXS's Expedite Base/MVS (another feature of EDI Services) installed as its vehicle for communicating with Information Exchange. Note that there are other Expedite products that could be used, or if you use TCP/IP FTP, you could use the Information Exchange TCP/IP FTP gateway for your communications with Information Exchange. If you happen to be connected to the European Information Exchange system, you could use ODETTE File Transfer Protocol/Information Exchange. In the scenario depicted here, Expedite Base/MVS takes the converted file and sends it to trading partner B's mailbox on Information Exchange.
    
6. At a later time, trading partner B checks its mailbox on Information Exchange and discovers there is a purchase order waiting to be processed. (A variation on this step might be that trading partner B is running Expedite Notification Manager software, which works together with Information Exchange Notification Services to notify trading partner B whenever there is a purchase order in the mailbox to be processed.)
    
7. Trading partner B also has Expedite Base/MVS installed, but as described in Step 5, there are other possibilities. In this scenario, Expedite Base/MVS takes the purchase order and places it in a file. Remember that the purchase order at this point is in the standard EDI format.
    
8. Trading partner B has a translation product installed that determines whether the purchase order needs to be converted to another format. The translation product takes the purchase order and converts it to the format understood by trading partner B's order entry application.
    
9. The translation product places the converted purchase order into another file.
    
10. The purchase order becomes an order entry in trading partner B's order entry application, and this phase of the trading cycle is complete. We could take this example further by showing that trading partner B generates an invoice that is then translated to the standard EDI format for invoices. Expedite Base/MVS sends the formatted invoice to trading partner A's mailbox, where trading partner A retrieves it using Expedite Base/MVS, and translates it to a format understood by its accounts payable application using WebSphere Data Interchange for Multiplatform.