Scenario 54 - Mid Market Order to Cash Procure to Pay

54.0 Overview

Scenario #54 describes the integration for a customer party application to integrate with a supplier party application and then with yet another supplier party (Small Manufacturer) application in order to obtain products or services.

This scenario also involves the use of Schematron to specify the minimum subset of elements that must be present in the messages (BODs) used within the scenario.

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.

54.1 Scenario

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.

54.2 Assumptions

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

It also presumes that this scenario can be applied as a B2B interaction between enterprises, as an internal A2A exchange within an enterprise or as an B2M exchange from a business to a mobile device following the same canonical business messaging model.

It also presumes that the users will use a package like Schematron to assure that the minimum agreed to elements are populated to assure a higher level of automation for the participants

54.3 Participant Definitions

This scenario contains three participants or roles: Customer party Supplier party Supplier party (Small manufacturer)

54.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.

This scenario contains the following events in the workflow sequence:

  1. A request to purchase from the supplier
  2. A request to purchase some or all of the customer’s needs from another supplier or manufacturer
  3. Acceptance’s or rejection of the request to the sub-supplier or manufacturer
  4. Acceptance or rejection of the request to the supplier
  5. Notification of shipments - either or both from the first level or second supplier
  6. Delivery communications
  7. Request to pay via invoices
  8. Notification of invoice acceptance and payment methods

54.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.