Skip Headers

Oracle Financial Services Accounting Hub Implementation Guide
Release 12.1
Part Number E13420-04
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Seeding Event Information Using Accounting Methods Builder

Seeding Event Information Using Accounting Methods Builder (AMB) Overview

This chapter describes:

Event Setup Steps

Along with the definition of sources, the accounting events setup establishes the framework within which users create and modify their application accounting definitions. The following steps, also shown in the Event Setup Overview diagram below, must be taken to seed event information using the AMB:

These components are fully described in Revise Source Definitions and Assign Accounting Attributes Introduction.

Event Setup Overview

the picture is described in the document text

After registering the application, setting up event entities, event classes, and event types are prerequisites. Sources must also be defined for the application. Once these are set up, sources are assigned to event classes. Lastly, Process Categories are defined for applications and event class options are defined for event classes.

Introduction to Event Entities, Event Classes, and Event Types

Accounting events are the basis for creating subledger journal entries. Within the events model, accounting events are categorized by event type, event class, and event entity.

See: Overview of the Financial Services Accounting Hub

At the lowest level, accounting events are categorized by event type. Accounting events with significantly different fiscal or operational implications are classified into different accounting event types, such as Invoice Approval, Invoice Adjustment, and Invoice Cancellation. The accounting program uses event types, along with accounting setups and application accounting definitions, to determine which subledger journal entries will be created.

The Financial Services Accounting Hub recognizes that while there are many kinds of accounting event types, there are also common requirements which they share. It is important to balance the need to create unique accounting definitions for each event type with the goal of an efficient implementation. To achieve this balance, the Financial Services Accounting Hub provides event entities and event classes.

An event class groups similar event types together for the purpose of sharing sources and accounting definitions. This reduces the setup time as it eliminates the need for separate accounting definitions for each event type. Event entities group related event classes. Event classes within an event entity usually share the same entity table in the transaction data model. For example, in Payables, invoices and prepayments can be grouped under the same event entity as both of them are stored in the table AP_INVOICES_ALL.

Event entities, classes, and types are specific to an application. Implementers are responsible for identifying and seeding all accounting event types, classes, and entities for their applications in the AMB.

For each accounting event, the Load Transaction Objects program provides the accounting program with source values which, in conjunction with the application accounting definitions, are used to create subledger journal entries.

As this chapter is restricted to the seeding of event information in the AMB, the following steps are a subset of the procedures shown in the Event Setup Overview diagram. Each of these steps corresponds to a particular window in the AMB and is described in detail in a subsequent section of this chapter.

the picture is described in the document text

The above diagram illustrates the component definitions in the following order:

  1. Step 1: Event Entities

  2. Step 2: Event Classes

  3. Step 3: Event Types

  4. Step 4: Process Categories

  5. Step 5: Event Class Options

Example of Entities, Classes, and Types

The diagram below provides an example of the relationship between event entities, event classes, and event types.

the picture is described in the document text

As shown in the above diagram, a single event entity can be associated with multiple event classes. The event entity Invoices is associated with the Invoices and Prepayments event classes.

Each of these event classes in turn, can be related to several event types. The Invoices event class is associated with the following event types:

The Prepayment event class is associated with the following event types:

Events Data Model

The entity relationship diagram below describes the entities related to the setup of accounting events and is described in the subsequent sections.

Events Data Model

the picture is described in the document text

Registering Subledger Applications

To use the AMB, register your application with the Financial Services Accounting Hub. Specify options related to event security, General Ledger, and subledger accounting options along with the names of event processing procedures.

To Register Subledger Applications

the picture is described in the document text

Selected Fields in the Subledger Applications Window
Field Description
Application Name List of values includes all existing Oracle E-Business suite applications. To display external applications, register them using the application's developer responsibility.
If an application is registered, query the application.
Drilldown Procedure Stored procedure that the Financial Services Accounting Hub uses to drill down from a journal entry to the corresponding subledger transaction
See: Drill-down API Details
Use Security If not selected, then there is no event security for this application and a session has access to all events in the application regardless of the transaction's security.
Policy Function If Use Security is selected, enter a stored function that establishes security access for a session.
Because this field has no validation, ensure that the value entered corresponds to a valid database function.
See: Financial Services Accounting Hub Security Introduction
Journal Source Identifies the origin of the subledger journal entries
Subject to Valuation Method Select if the application supports multiple valuations for a single transaction.
See: Valuation Methods and the Financial Services Accounting Hub
Calculate Reporting Currency Amounts Select to calculate accounted amount for any reporting currency.
If selected, the Create Accounting program calculates accounted amounts and creates journals for all enabled subledger level reporting currencies associated with the primary ledgers.
If not selected, the Create Accounting program does not calculate accounted amount for any reporting currencies, but it does create journals for the subledger level reporting currencies if reporting currency information is provided in the transaction objects.
If the Create Accounting program fails to create journal entries for any of the subledger level reporting currencies, no journal entries are created for the primary and secondary ledgers and for other subledger level reporting currencies.
This option does not apply to secondary ledgers. The Financial Services Accounting Hub calculates accounted amount for secondary ledgers regardless of the value of the Calculate Reporting Currency Amounts option.

Note: Select this check box for products that support Multi-reporting Currencies in release 11.5 except for Oracle Assets and Oracle Projects.

Note: This option does not correlate to the Calculate Accounted Amounts option in the Accounting Event Class Options window. The Calculate Accounted Amounts option applies to currency conversions from transaction currency to the functional currency of the ledger that the event is associated with. The Calculate Reporting Currency Amounts option applies to currency conversions to subledger level reporting currency.

Third Party Type Select Supplier, Customer, Any, or None.

Drilldown API Details

See: Drill-down API Details

Event Entities

Use accounting event entities to treat events for a single transaction model in a similar manner. Event classes within an event entity usually share the same entity table in the transaction data model and can be uniquely identified by the same primary or surrogate key.

Purpose

Use event entities to tie subledger transaction entities with their accounting representation. The Financial Services Accounting Hub uses event entities to maintain the system transaction identifiers that uniquely identify the subledger transactions associated with the accounting events.

Example: Oracle Payables invoices and prepayments are stored in the same entity table in the data model and are identified by the same primary key. Therefore, they can be grouped under the same event entity.

Characteristics

Event entities have the following characteristics:

Consider the following issues:

Defining Accounting Event Entities

Use the Entities window to set up event entities and system transaction identifiers for the application. This window is only available to implementers. Users cannot create or update event entities.

To Define Accounting Event Entities

the picture is described in the document text

Selected Fields and Buttons in the Entities Window
Field or Button Description
Entity Code Implementer's key used by programs and routines to refer to the entity. Codes are used because event entity names are translated.
Description If the event entity represents a specific transaction, then include the transaction name. Otherwise, include a description of the types of transactions represented by the event entity.
Gapless Event Processing Enables gapless event processing. If selected, all the events associated with the entity are flagged as On Hold if there is a gap in the event numbers.
Enabled If selected, makes this definition available for use
Identifiers Opens the System Transaction Identifiers window
Event Classes Opens the Event Classes and Types window

System Transaction Identifiers Window

You can assign up to five attributes to uniquely identify instances of an event entity. These attributes constitute the primary or surrogate key for the entity tables in the transaction data model where the subledger transaction associated with the event entity are stored. These identifiers link accounting events with their underlying transactions in the transaction data model. Define the link by mapping columns from the entity table to system transaction identifiers for the event entity in the System Transaction Identifiers window.

Note: The System Transaction Identifiers window provides only the definition of the link and not the actual link. The latter is stored in the XLA_TRANSACTION_ENTITIES table.

As part of registering event entities in the AMB, system transaction identifiers are assigned to entity table columns in the transaction data model.

See: System Transaction Identifiers

In the System Transaction Identifiers window, enter the columns that constitute the transaction header table's primary or surrogate key and assign them to system transaction identifiers.

To Define a Link Between an Accounting Event and Its Associated Transaction

the picture is described in the document text

Selected Fields in the System Transaction Identifiers Window
Field Descriptions
Entity Table Column Stores the column names that constitute the primary or surrogate key of an accounting event's underlying subledger transaction
Identifier Column Corresponding identifier column name; stores the column names from the transaction entities table that the Entity Table column is mapped to
List of values for this field includes 15 identifiers; five of these columns are numeric, five are alphanumeric, and five are dates.
When events are captured, the event identifiers must be passed to the event capture APIs in the corresponding parameters. For example, if TRANSACTION_ID is mapped to SOURCE_ID_INT_1 on this window, then the value of TRANSACTION_ID must be passed to the accounting event APIs in the SOURCE ID_INT_1 parameter.
See: Introduction to Capturing Events

Event Classes

Accounting event classes group accounting event types into distinct, user-oriented groups. They typically represent the actions possible on a particular transaction or transaction type.

For example, the Payables Invoice transaction model stores two different types of user transactions: invoices and prepayments. Receivables stores invoices, deposits, guarantees, and bill receivables in the same transaction table, but to the user, they are distinct types of transactions. Each of these transaction types lends itself to being an event class. Typically, there are different event classes for each category of real world transaction or transaction type.

Examples of real world transactions that normally correspond to accounting event classes are invoices, payments, purchase orders, receipts, and lease contracts. Each of these are associated with different kinds of transactions and account for business events with different operational and fiscal significance.

Examples of different types of transactions that result in distinct event classes are asset additions, depreciation, and retirements. While these operations are based on the same object (the underlying asset), they correspond to separate transactions that require different accounting treatment. Each of these operations results in an association with different event classes.

Accounting event classes are visible to users.

Purpose and Characteristics

Accounting definitions usually differ by accounting event class. Use event classes to group similar event types for sharing accounting definitions. In other words, assign accounting definitions to be used by all accounting event types in the class at the event class level.

In addition, assign sources and journal line types assigned to event classes. These sources and line types are available for creating accounting definitions for any event type in the event class. Also, default assignments for accounting attributes are made at the event class level.

Event classes enable users to maintain accounting and reporting sequences at the subledger journal entry level.

See:

Not all sources are relevant to all subledger journal entries. You can limit which event classes can use a given source to create subledger journal entries.

The following example explains why sources are restricted. Consider a source such as Receipt Date. An implementer may want to make this source available to the Receivables implementers for creating subledger journal entries. However, this source is irrelevant to users trying to create a subledger journal entry for the completion of Payables invoices. Restricting the Receipt Date to where it can be used avoids confusion.

Consider the following issues when defining event classes:

Defining Event Classes

Use the Event Class and Types window to define event classes for the application after creating event entities. This window is accessed from the Entities window. All event classes created relate to the same associated event entity. Users cannot create or update event classes.

Define an event class for:

See: To Define Event Classes and Types

Update Subledger Accounting Options Setup Concurrent Program

This program performs the default Financial Services Accounting Hub options setup on demand. It needs to be executed in the following circumstances:

Event Types

Accounting event types represent the business operations that can be performed on the event class. For example, the Payables event class Invoices is subject to three types of business operations, which are also event types: Invoice Validated, Invoice Adjusted, and Invoice Canceled.

An accounting event always has an associated event type. For products that are based on transactions, event types correspond to the different operations that can be performed on the transactions. For products that are nontransaction based, an event type corresponds to a particular kind of transaction.

Event types that pertain to the same kind of transaction and are subject to a similar accounting treatment should be associated with the same event class.

Define a separate event type for each kind of accounting event that is likely to require a different subledger accounting treatment.

Purpose

Accounting event types, used to categorize accounting events, provide the most granular level of detail for creating accounting definitions. Accounting events with significantly different fiscal or operational implications should be classified into different event types. Event types do not necessarily correspond to system operations. A business perspective yields the best definition for an accounting event type.

Characteristics

By virtue of providing the most granular level of detail, accounting event types have the following characteristics:

Consider the following when defining accounting event types:

To Define Event Classes and Types

the picture is described in the document text

Selected Fields and Buttons in the Event Classes and Types Window
Field or Button Description
Event Class Code Developer key used by programs and routines to refer to this event class. Codes are used because event class names are translated.
Event Class Name Create user-oriented names because they appear in several AMB windows.
Enabled If selected, makes this definition available for use
Event Type Code Developer key used by programs and routines to refer to this event type. Codes are used because event class names are translated.
Event Type Name Application accounting definitions are based on event types. It is critical that all event type names have a user orientation and are consistent with the user's experience in the subledger applications.
As an example of the kind of naming to be employed, event types for invoices should not be called Invoice Inserted, Invoice Updated, and Invoice Deleted. Use names like Invoices Created, Invoice Adjusted, and Invoice Canceled.
Define an event type in the system before events can be captured for that event type. Define event type names and descriptions in the past tense because the event is captured only if the transaction has completed successfully.
Accounting Indicates whether the event type is used by the Financial Services Accounting Hub
Tax Indicates whether the event type is used for tax and sequencing
Enabled If selected, makes definition available for use
Predecessors Opens the Event Class Predecessors window

Event Class Predecessors

Event class predecessors ensure that if there is an accounting event that is dependent upon the accounting of a prior event, the accounting of the dependent event is not delayed if the prior event is not yet accounted. For example, without event class predecessors, an AR Receipt that is dependent on an AR Invoice cannot be accounted if the invoice is not accounted. With event class predecessors, the Create Accounting program processes the AR Invoice before processing the AR Receipt thereby minimizing delays in accounting due to the dependencies inherent in business flow processing.

Predecessors can exist across entities and are defined at the application level. They must be in the same application because the Create Accounting program runs for only one application at a time. If an event is dependent on the accounting of another event that is in a different application, accounting must still be run separately for that application before the dependent event can be accounted.

Defining Event Class Predecessors

The Event Class Predecessors window establishes an order in which the Create Accounting program processes events selected for accounting. This order of events ensures that the accounting of a dependent event is not delayed because it depends on an unaccounted prior event. This window is accessed from the Event Classes and Types window.

To Define Event Class Predecessors

the picture is described in the document text

Selected Fields in the Event Class Predecessors Window
Field Description
Event Class Name
Entity Name
Default from the Event Class and Types window
Event Class Name Event class that the Create Accounting program must process before accounting the event class that is displayed in the header region of this window
List of values has the following attributes:
  • Displays the event classes for the same application of the selected event class indicated in the header region

  • Filters out the currently selected event class to prevent selecting an event class as a predecessor of itself

  • Filters out event classes that are not enabled

  • Displays the event class name, event class code, application, and entity


The Event Class Code, Description, and Entity fields are automatically populated with related information.

Process Categories

Process categories are collections of one or more logically related event classes. They restrict the events selected for accounting when users submit the Accounting Program. Events can be restricted from separate processing because of possible dependencies between transactions of different event classes. Such dependencies mean that accounting events of one class should not be accounted independently from accounting events of another class.

By grouping event classes so that they can be processed in a single submission of the Accounting Program, process categories enable users to create and transfer accounting for all the accounting events in a business flow.

For example, in many situations, accounting events for the Payment Issue event class should not be accounted independently from accounting events for the Payment Clear event class. These should be processed by a single submission of the Accounting Program. To accomplish this, group these two event classes into a single process category.

Seed a process category for each set of event classes that composes a business flow and that you want to create accounting for in a single run of the Accounting Program.

When submitting the Accounting Program, users can choose the process category that they want to create accounting for. If no process category is specified, the selection of accounting events to be processed is not restricted by event class.

Note: Assign event classes to process categories in the Accounting Event Class Options window.

See: Accounting Event Class Options

Selecting a process category indicates that all associated event classes and their assigned event types are selected for processing.

Process Categories Example

Consider the example of a cash manager who wants to reconcile General Ledger cash account balances to bank statements received.

To undertake this reconciliation, the first step is to process all transactions pertaining to cash to obtain an accurate report of the organization's cash account balances. The manager must ensure that all entries affecting the cash balance in General Ledger are selected for processing. This includes entries related to payments, their clearing, and unclearing.

A sample process category setup is shown in the figure below and is described in the Process Category: Payments table.

the picture is described in the document text

Process Category: Payments
Event Class: Payments Issued Event Class: Payment Reconciliation
Event Type: Payment Issued Event Type: Payment Cleared
Event Type: Payment Adjusted Event Type: Payment Uncleared

In this example, the cash manager can select the process category Payments when the Accounting Program is submitted. As a result, all events associated with these event types are selected for processing by the Accounting Program.

To Define Accounting Process Categories

the picture is described in the document text

The table below describes selected fields from the Process Categories window.

Process Categories
Field Description
Process Category Code Developer's key used by programs and routines to refer to this category
Process Category Name Selected by users when submitting the Accounting Program