Scenario 1 - General Ledger to Sub Ledgers

1.0 Overview

Scenario #1 describes the integration for general ledger software integrating with a sub-ledger software or multiple sub-ledger applications.

The purpose of this scenario is to enable the visualization of the participants and the dialogs between them for this type of integration. This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations.

Many applications create data that cause changes to account balances of a general ledger application. Some of those sub-applications have activity which will be reflected in a general ledger application. They can include:

  • Benefits
  • Costing
  • Human Resources
  • Inventory Control
  • Manufacturing
  • Payroll
  • Production
  • Treasury

Although not a complete list, this is meant to be a representative sample of activities that generates a journal entry scenario and would use these messages for interaction.

1.1 Scenario

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

This example is to be used as a design recommendation.

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

It describes a model for one or more sub ledger applications integrating with a common general ledger application. The environment for this integration may be within a single enterprise, across several divisions or across partnerships. There may be instances where the amount of information sent to the general ledger is sufficient to accomplish a goal, and there may be times when the sub ledgers applications need to send the detailed transaction data to a cost accounting application.

This scenario does not cover posting to a cost accounting component. Please refer to other Scenarios for posting.

This scenario also assumes that the details of the financial transactions will be owned by or kept in the sub ledgers and because of that, the drill back mechanism from the general ledger application is also described in a later Scenarios.

1.3 Participant Definitions

This Scenario contains two major participants: the general ledger application and the sub-ledger application(s).

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 are to ensure that an integration designer can communicate the requirements and design precisely enough to define the interfaces needed and their interrelationships.

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

For Scenario #1 the sequence includes:

  • The first business event in the sequence should be the synchronization of the financial chart of accounts to ensure full, traceable continuity. This scenario assumes that the general ledger owns the chart of accounts definition and the instances of data within it. This means that sub ledger applications have several choices for validation of account numbers and other fields in the complete chart of accounts structure with one of these choices being to synchronize the chart of accounts structure and data from the general ledger application.
  • ConfirmBOD is next used to assure that the sync has been received and is acceptable to the sub ledger.
  • PostJournalEntry is next used to inform the general ledger of the known or desired changes.
  • AcknowledgeJournalEntry is then used to affirm what the post requested and was accomplished. It is assumed that the Post and Acknowledge BODs reflect the same details and if not the sub ledger will then be forced into some form of reconciliation such as a re-sync and attempt the post a second time.

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