Scenario 45 - Sub Ledgers to General Ledger - GL Actuals

44.0 Overview

Scenario #44 describes integration of order management and receiving systems with external supplier systems and warehouse management application.

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 order management system is shown as managing the interface with the external supplier partner. The order management system communicates to the warehouse management delivery system.

The warehouse management system informs the receiving system what to expect in a delivery. Once received, the receiving system updates the order management system on what was received and acknowledges the delivery to the external supplier partner.

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

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

44.3 Participant Definitions

The scenario contains four major application: the external supplier partner, material scheduling or order management, warehouse management systems, and the receiving system.

Note: The order management, warehouse management and receiving systems could be part of a single or possible within different ERP systems.

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

44.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 has the following major events in the workflow sequence.

  • PlanningSchedule
  • ShipmentSchedule, and
  • SequenceSchedule created and agreed to by the external supplier order system and the internal order management systems.

Once these are agreed to and the supplier has either acquired or manufactured the item(s) Additional steps not addressed in this scenario, but are described in earlier scenarios include:

  • Ship the goods - once the shipment has been loaded on the transportation mechanism a shipment detail is provided to the order management system.
  • The next step is for the order management system to communicate the delivery information to the warehouse management system so that shelf space or and available inventory can be noted.
  • The next step is for the warehouse management system to communicate to the receiving system what to expect on the delivery.
  • The next step is for the transport to arrive with the delivery which will be verified against what was expected. The receiving system updates the order management system on what was received. It also acknowledges the delivery to the external supplier.
  • Finally, the material received is stocked to the warehouse.

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