3.1. OBI Workflow

Figure 2 below shows the general workflow from a requisitioner's point of view. For more detailed information and description, please refer to the OBI Model description in the OBI technical specification[2]. The scenario here is Paul, an IBMer, trying to buy a logo'ed T-shirt for a business event from a selection of corporate designated suppliers. Paul first went to the corporate purchasing homepage. From there he got a selection of goods and services. Paul chose a specific seller SmartLogo Inc. from a list of Logo'ed merchandises supplier list. Buy following the link in the Intranet homepage, Paul was redirected SmartLogo's selling server on the Internet. Paul was requested to present his digital certificate to the selling server to identify himself. Upon receiving Paul's certificate, SmartLogo realized that this Paul was actually an IBMer and sent him an IBM-specific catalog. Paul made his selection according to the catalog and submitted his order with the order button.

Paul was done with the purchasing at this point and was ready to receive the T-shirt he had ordered. Later on, SmartLogo picked up the submitted items from Paul's shopping cart, packaged them as an OBI POR and then sent it back to IBM for IBM's internal processing.

Upon receiving new PORs', the OBI/BUY server in IBM kicked off the purchasing approval request by notifying Paul's manager. When Paul's manager approves the request, the OBI/BUY server kicked off account processing for this request to assure the accounting information in the order request form. When both of these procedures OK'ed, the OBI/BUY server in IBM transformed the original POR into official PO and sent it back to SmartLogo. At this point, SmartLogo kicked off its own accounting processing to check on the payment instruction in the PO. If acceptable, it initiated the order fulfillment process, notified Paul his order was coming and exchange invoice/receipt with IBM for final payment settlement.