Seeding Event Information Using Accounting Methods Builder
Seeding Event Information Using Accounting Methods Builder (AMB) Overview
-
How the Financial Services Accounting Hub creates subledger journal entries from accounting events using event entities, event classes, and event types
-
How to register the Financial Services Accounting Hub application, which is required before using the AMB
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:
-
Sources and accounting attributes
-
Run, create, and assign sources: modify sources.
-
Assign sources to accounting attributes.
See: Assigning Sources
-
-
Events
-
Register applications.
-
Define event entities.
-
Define event classes.
-
Define event types.
-
Define process categories.
-
Enter options for event classes.
-
These components are fully described in Revise Source Definitions and Assign Accounting Attributes Introduction.
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 above diagram illustrates the component definitions in the following order:
-
Step 1: Event Entities
-
Step 2: Event Classes
-
Step 3: Event Types
-
Step 4: Process Categories
-
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.
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:
-
Invoice Created
-
Invoice Validated
-
Invoice Adjusted
-
Invoice Canceled
The Prepayment event class is associated with the following event types:
-
Prepayment Created
-
Prepayment Approved
-
Prepayment Adjusted
-
Prepayment Applied
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.
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
| 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
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:
-
They usually correspond to a database object.
They can also logically correspond to a single transaction, which is used as a basis for several related accounting events. Examples of such transactions include Payables or Receivables invoices.
-
Event entities differ by application; implementers create their event entities for a particular application.
Consider the following issues:
-
Whether different types of transaction data are maintained in the same table
Such transactions should typically be part of the same event entity. For example, in Payables, invoices, prepayments, and credit memos are stored in the same table. Therefore, it is logical to have an event entity to cover these accounting event classes. The table below lists examples of event entities for Payables and their associated entity tables.
Event Entity Entity Table Name Invoices AP_INVOICES_ALL Payments AP_CHECKS_ALL -
Whether there is a requirement to provide separate sequences for the different kinds of subledger journal entries used to account for events
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
| 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
| 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:
-
Journal Line Types, Oracle Subledger Accounting Implementation Guide
-
To Assign Accounting Attributes in the Accounting Methods Builder
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:
-
What users regard as distinct, user-oriented transaction groups
-
Whether sources are shared
-
Items such as descriptions and accounts that can be common to related transactions or transactions
-
Whether all related event types belong to a common group
For example, credit memos can be considered a separate event class from transactions if there is an event type that is relevant only to credit memos.
If credit memos can be applied only to invoices, consider creating an event class for credit memos.
-
Whether there is a requirement to provide separate sequences for the different kinds of subledger journal entries used to account for events
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:
-
Each set of accounting events that pertain to the same kind of transaction
-
Sources to be shared
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:
-
When event classes are added or modified after ledger accounting setup has been completed, users must run this program to include the new event classes in the accounting setup.
-
In a running install where ledgers are implemented, implementers can decide to uptake the Financial Services Accounting Hub for a custom subledger application. Once the custom subledger application is set up in the AMB, users need to run this program to set the defaults for the custom subledger application and all the implemented ledgers.
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:
-
Enable accounting definitions based on the event type
This is useful when an environment has detailed and varying accounting requirements.
In addition, event types provide an accurate name and description of the business event which gave rise to the subledger journal entry.
For example, using event types enables users to distinguish between subledger journal entries that arise from accounting events invoice approvals, invoice adjustments, and invoice cancellations. As another example, users can create different descriptions for canceling and applying receipts. Creating separate event types for these two operations makes this possible.
-
Provide an audit trail of business events on a transaction
-
Visible to end users
Consider the following when defining accounting event types:
-
Whether a particular transaction or occurrence creates accounting events that require a distinct accounting treatment
-
Whether users need a separate accounting event type to be able to understand the relationship between the actions they perform in the subledger products and the accounting for the associated accounting event
For example, since there is a separate accounting event type called Invoice Adjusted, users understand that this event type is used to account for invoice adjustments.
To Define Event Classes and Types
| 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
| 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:
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.
| 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 table below describes selected fields from the Process Categories window.
| 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 |