Scenario 47 - Full Cycle Purchasing

47.0 Overview

Scenario #47 describes the integration of full cycle purchasing of inventory goods through the interface points between buyer and supplier systems.

The purpose of this scenario is to enable the visualization of the participants in the process and the dialogs between them for this specific integration. This scenario is not meant to be the only model for integrating general ledger applications to a budget applications. This is simply one model that may be used to guide one’s own integration efforts.

The scenario diagram below shows an integration that involves a buyer with a purchasing system, receiving system, and an accounts payable system interacting with the supplier side which consists of an order management system, a shipping system, and a billing system. Typically the buyer places an order through their purchasing system which then interacts with the seller’s order management system wherein the order is acknowledged. The inventory system fulfills the order internal to the seller and the shipping system notifies the buyer that the shipment has been made by the buyer’s system. The receiving system receives the shipment and the seller’s billing system issues an invoice to the buyer’s system.

47.1 Scenario Diagram

The scenario below contains the participants involved in the interaction, the dialog flows or conversation between them, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.

This is a model to be used as a design recommendation, not a required approach.

47.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach with transaction management required but not explicitly defined.

The environment for this integration may be within a single enterprise, or across enterprises.

This scenarios describes a model for production execution. The environment for this first part of this integration is typically within an enterprise and within a division. The environment for the second part of this integration is typically between two enterprises.

This scenario also assume that one application will maintain the master data for integration.

47.3 Participant Definitions

This scenario contains two participants or overall roles:

  • Buyer - the party who is purchasing
  • Seller - the party who is providing the requested good or service.

Participant applications typically consists of:

  1. The buyer’s purchasing system, receiving system and accounts payable system
  2. The seller’s order management system, shipping system and billing system

Note that the buyer’s systems (purchasing, receiving, and accounts payable systems) could be part of a single or possibly within different ERP systems within the buying enterprise. Likewise the seller’s systems (order management, shipping, and billing systems) could be part of a single or possibly separate ERP systems in the seller’s enterprise.

The definitions and details of these applications are left to the designer but are assumed to contain the functionality as defined by what is commonly sold in the commercial market place today. This definition is broadly accepted by the scenario designers and is a direct result of the decision not to define how the processing takes place within any individual application.

Each application must be able to perform the services defined by the message BOD (business object document), but the internals of the application are not required or desired to be exposed at this level of standardized abstraction.

The most important factors in defining these participants is to ensure that an integration designer can communicate the requirements precisely enough to detail the interfaces needed and their interrelationships.

47.4 Business Workflow (Sequence)

The business workflow is graphically represented by starting at the Scenario top and reading from top down and from left to right.

The scenario contains the following events in the workflow sequence.

  • Something within the Buyer organization identifies the need to purchase something and a supplier is found. These steps are not addressed in this scenario, but are addressed in other OAGIS scenarios.

The actual sequence consists of:

  1. A purchase order is issued to the supplier and received by the suppliers order management system.
  2. The order management system chooses to accept, reject, or suggest modifications to the purchase order which triggers acknowledgment of the purchase order being sent back to the buyer’s purchasing system. From that point there can be a series of exchanges to address terms, conditions and availability. This dialog can occur using ChangePurchaseOrder BOD not shown in this workflow. This Workflow assumes that the order is accepted and confirmed with the Acknowledge PurchaseOrder.
  3. Next step is for the order management system to communicate the order to the inventory system such that the order can be picked and sent to shipping. Since this communication is internal to the seller it is not shown here.
  4. Next step is for the seller’s shipping system to pack the order and send via a carrier.
  5. Once the order is packed and advanced shipping notice (ASN) is sent to the buyer’s system via the ShowDelivery BOD.
  6. Next step is for the buyer’s receiving system to receive the ASN and prepare for the shipment followed by the actual physical shipment. Typically, the shipment then would be stored in inventory at the buyer’s receiving location. It may also be sent to inspection depending upon the situation.
  7. Next step is for the seller’s billing system to issue an invoice for the goods sent according to the terms agreed to in the purchase order.
  8. Finally, the Buyer’s accounts payable system acknowledges receipt and payment of the Invoice.

47.5 Exception Handling

Exception handling is highly localized as the result of an implementation’s infrastructure, management and business rules. As such, this section of the Scenario documentation is planned to be used as a guide to help understand the additional intent of these Scenarios. If no exceptions are noted here, then it can be assumed that the Scenario designers agreed that the Scenario is straight forward and has no additional needs:

  • Note that the Confirm BOD is not shown in the scenario and that it is the most obvious method for providing an application level exception and feedback mechanism between business software components. Full Confirm BOD use is described in other OAGIS documentation in detail, but it should be noted that the specific use of the Confirm BOD may vary significantly from scenario to scenario and from integration to integration.

  • The Confirm BOD is typically intended to be used by the original receiving application to communicate to the sending application that the information it sent in the message BOD (business object document) was received and understood and can be processed.

  • If the information was not received or nor understood, or contained errors of any type, it is accepted practice for the OAGIS users to presume that the data was not acted on and in the absence of a Confirm BOD within a partnership previously agreed to time limit to resend the original message again.

  • As errors and assumptions are the bane of any implementation, it is strongly recommended that the Confirm BOD be used to prevent any potential problem although it is not a requirement by OAGIS use.


OAGi and its members welcome your feedback.