Oracle® Fusion
Accounting Hub Implementation Guide 11g Release 1 (11.1.3) Part Number E20374-03 |
Contents |
Previous |
Next |
This chapter contains the following:
Accounting Transformation Configuration: Overview
Implement Accounting Event Interfaces
Secure Accounting Transformations
Create and Process Subledger Journal Entries
Oracle Fusion Accounting Hub creates detailed, auditable journal entries for source system transactions. The subledger journal entries are transferred to the Oracle Fusion General Ledger. These general ledger journals are posted and update the general ledger balances. Then the balances are used by the Financial Reporting Center for reporting and analysis. The following figure depicts this process.
Accounting transformations refer to the process of converting transactions or activities, referred to as accounting events, from source systems into journal entries. Source systems may be diverse applications that have been purchased from non-Oracle software providers or created internally. Often, source systems are industry specific solutions. Examples of source systems are core banking applications, insurance policy administration systems, telecommunications billing systems, and point of sales systems.
When using the accounting transformation implementation process:
Start with an analysis of your current system.
Determine which source systems have transactions or activities that need to be accounted and reported via the Oracle Fusion Accounting Hub.
Register the source system transactions and activities which have financial impact in the Accounting Hub to make them eligible for accounting.
Create accounting rules that indicate how each of the accounting events is accounted.
Group these rules together and assign them to ledgers to create a complete definition of the accounting treatment for the transactions and activities from the source system.
The following figure summarizes the accounting transformation process.
Complete the steps described in the following table in the order listed to account for accounting events of each of your source systems.
Implementation Phase |
Step Number |
Description |
---|---|---|
Analysis |
1 |
Analyze source system transactions or activities to determine what accounting events to capture. |
|
2 |
Analyze transaction objects requirements.
|
|
3 |
Analyze and map the source system's current accounting. |
Definition and Build |
4 |
Register source systems and define event model, including: process categories, event classes, and event types. |
|
5 |
Code calls to event capture routines. |
|
6 |
Build programs to extract the information from the source systems and populate it in the Accounting Hub transaction objects. |
|
7 |
Run the Create and Assign Sources program and revise source definitions and map accounting attributes. |
Integration |
8 |
Create programs that capture accounting events and their related information and send it to the Accounting Hub. |
Implement and Test |
9 |
Create accounting rules. |
|
10 |
Perform comprehensive testing to ensure that all accounting is correctly generated. |
The analysis phase of accounting transformation implementation includes three steps.
The steps are:
Analyze Accounting Events
Analyze Source Data Requirements
Analyze Accounting Requirements for Events
Some business events have financial accounting significance and require the recording of financial information. These business events are known as accounting events and provide the data used in accounting transformations.
Examples of business events from a revenue recognition or billing system include:
Complete an invoice
Record a payment
Record late charges
Examples of business events from a point of sale system include:
Record an order
Accept a payment
Receive a return
Examples of business events from a loan (core banking) system include:
Originate a loan
Fund a loan
Record late charges for a loan
An accounting event and its associated transaction data typically relate to a single document or transaction. However, the nature of source systems may prevent them from extracting this discrete information and sending it to Oracle Fusion Accounting Hub for processing. In some cases, summarized event information, such as overall customer activity for the day, is sent for accounting transformation.
The first task is to carry out a complete analysis to determine which accounting events are captured. This analysis incorporates both the functional requirements for accounting for the source system events, as well as a review of how the events can be captured. There may be limitations on the source system, as well as volume considerations that make it desirable to capture summarized event information such as total customer activity for a day.
Complete the following analysis to identify accounting events:
Identify the life cycle of documents or business objects and the transactions that affect their status.
Identify events in the life cycle that may have financial implications to ensure that they are captured and accounted.
Identify all business events for which contextual data and transaction amounts are available.
This is not a mandatory requirement, but it provides maximum flexibility for defining accounting transformation rules.
Verify that all the required sources, such as accounting amount and date, that can potentially be used to create subledger journal entries are included in the accounting transaction objects. Sources are the appropriate contextual and reference data of transactions. They provide the information that is used to create subledger journal entries. For example, the following items could be used:
Transaction amount as the debit amount
Transaction date as the accounting date
Customer account ID as part of the description
Complete the analysis to determine what source data is necessary to successfully create subledger journal entries from transactions.
Flexibility in creating accounting rules is dependent on the number of sources available. There is a balance between providing all the information that can be extracted versus how much is practical to send based on your processing resources. The following list provides examples of source data:
Amounts including entered, accounted, and conversion data
Dates
Descriptions
Accounts
Customer information
Transaction type information
Study the transaction objects data model used by the Oracle Fusion Accounting Hub. The data model provides detailed information about the different types of transaction objects. Transaction objects are the views and tables that store transaction data in the standardized form required by the Create Accounting process.
When specifying optional header and line objects, use single table views. If you specify optional objects as multi-table views, it can result in poor performance.
Data stored in transaction objects must also satisfy accounting transaction objects validation rules. These rules verify both completion and validity of the data.
Some source systems may already produce accounting entries, while others may produce raw transactions with no associated accounting. As part of the analysis, determine how much transformation is required to produce subledger journal entries. Once this is done, examine the subcomponents of the journal entry rule set to determine how to complete rules to produce the required subledger journal entries. This exercise helps determine which subledger journal entry rule set subcomponents must be defined for the source systems data to be properly transformed into subledger journal entries.
Journal entry rule set subcomponents include the description rule, account rules, journal line rules, and supporting references.
Such an analysis should, at a minimum, answer the following questions:
Under what conditions is each of the lines in the subledger journal entry created?
What is the line type, debit or credit, of each subledger journal entry line?
What description is used for the subledger journal entry?
How are the accounts derived for the entry?
What information may be useful for reconciling the subledger journal entry to the source system?
Note
This list is not comprehensive.
This section describes the steps for the accounting transformation definition and build phase of the Oracle Fusion Accounting Hub implementation.
After registering the source system, set up the accounting event model. The accounting events from the source system are registered in the Oracle Fusion Accounting Hub.
Define Process Categories
Process categories group event classes, and can be used to restrict the events selected for accounting when users submit the Create Accounting process. Selecting a process category when submitting the Create Accounting process indicates that all associated event classes and their assigned event types are selected for processing. This may be useful for segmenting events due to processing volumes.
Define Event Classes
Event classes represent transaction types and are used to group event types. For example, when accounting for transactions from a banking system, group the event types Loan Origination, Loan Scheduled Payment, and Loan Late Payments into an accounting event class for Loans.
For each event class, register the transaction objects that will hold source data for the event types in that class.
Define Event Types
For each transaction type specify each business event that can have an accounting impact.
Using application programming interfaces (APIs), create programs to capture the accounting events. The Create Accounting process combines the event information with the transaction object information and the accounting rules to create subledger journal entries. The Create Accounting process reads the event type for each event. Based upon the event type and the primary ledger, it determines which set of accounting rules should be applied to create the subledger journal entry. Once it determines which rules to use, it gets the information from the event and the transaction object rows related to the event to create the journal entry.
The following APIs for creating and updating accounting events are provided:
Get Event Information APIs to get event information related to a document or a specific event
Create Event APIs to create accounting events, individually or in bulk
Update Event APIs to update events and keep them consistent with related transaction data
Delete Event APIs to delete events
Transaction objects are tables or views defined for each event class, capturing source transaction data for accounting events. The Create Accounting process gets the source transaction data from the transaction objects to generate journal entries.
To build transaction objects, perform following tasks:
Create and register transaction objects
under ORACLE FUSION
schema that are
used to store the source transaction data.
Write programs that populate the transaction objects with source values for each accounting event.
There are different types of transaction objects, indicating whether they are used at the header or line level, and whether they hold translated values:
Transaction object headers for header level sources that are not translated
Transaction object headers Multi Language Support (MLS) for translated header level sources
Transaction object lines for line level source values that are not translated
Transaction object lines MLS for translated line level sources
Header sources have the same value for all transaction lines or distributions associated with an accounting event. These sources are typically associated with a transaction header or with transaction reference data. An example of a header standard source for a mortgage loan is the loan number. A mortgage loan can have only one loan number. This number would be on the header transaction object and would not vary by line number.
Line sources have values that can vary by the transaction lines or distributions associated with an accounting event. They must be stored in the transaction objects at the line level.
Transaction objects can be mandatory or optional. At least one header transaction object is mandatory.
When creating optional transaction objects, specify them as single table views. Specifying optional objects as multi-table views may result in poor performance.
It is also possible for accounting event classes to share transaction objects. For example, when accounting for a core banking system, use the same transaction objects line table or view for both of the event classes: Fixed Rate Mortgages and Variable Rate Mortgages.
Transaction objects need to be populated before the accounting for the events occurs; otherwise, the source transaction information will not be available to generate the journal entries for the events.
Transaction objects can be populated in advance of
running the Create Accounting process or they can be populated as
part of the Create Accounting process by customizing xla_acct_hooks_pkg
to automate this coordination.
Transaction objects should be created under the FUSION
schema. Then, select, insert, update
and delete access should be granted to FUSION_RUNTIME
for all the transaction view and objects.
A sample grant command is: Grant SELECT, INSERT, UPDATE, DELETE ON FUSION.XXFAH_TRX_HEADERS_V TO FUSION_RUNTIME
; if XXFAH_TRX_HEADERS_V
is created
as a transaction object.
After the transaction objects are registered, sources and source assignments to event classes are created based on these objects. Assigning sources to event classes makes them available for creating accounting rules for those classes. The transaction objects column names are used to generate sources. Each column in each transaction object is registered as a separate source. These sources are used in the definition of accounting rules used in creating journal entries.
Create and Assign Sources process also validates the transaction objects by verifying that.
All transaction objects, defined for the event class, exist in the database.
All transaction objects, based on the transaction object type, contain the appropriate primary key columns of the correct data type.
The syntax of all join conditions between the transaction and reference objects is correct.
A reference object is not registered multiple times for an event class.
A reference object is not assigned to another reference object.
Existing sources or source assignments created from previous run of this process continue to be consistent with the transaction objects.
Any existing accounting attributes mapping previously done continue to be consistent with the transaction objects and accounting attribute definitions.
Once sources have been created, revise the source definitions before they can be used. These revisions are:
Source names are the same as the transaction object column names. These can be revised to be more business user friendly so they are easily understood when configuring accounting rules.
Sources that correspond to accounting flexfield identifiers are marked as accounting flexfield.
Whenever appropriate, sources can have lookup types or value sets assigned. Assigning a value set or lookup type allows you to predefine valid values for the source that is used to create accounting rules.
After the sources are created, they need to be mapped to the accounting attributes for each event class. An accounting attribute is a piece of the journal entry; the mapping of sources to accounting attributes specifies how the Create Accounting process gets the value for each piece of the journal entry. For example, an attribute of entered currency is used to map source values to the entered currency field for subledger journal entry lines.
This section describes the accounting transformation implementation steps for the integration of source system programs with the Create Accounting process in the Oracle Fusion Accounting Hub.
For Oracle Fusion Subledger Application, integrate source system programs to create accounting events using application programming interfaces (APIs).
For Oracle Fusion Accounting Hub, you need to customize
the xla_acct_hooks_pkg
.
This section describes the steps in the accounting transformations implement and test phase of the Oracle Fusion Accounting Hub implementation.
Accounting methods group subledger journal entry rule sets together to define a consistent accounting treatment for each of the accounting event classes and accounting event types for all source systems.
The following steps must be completed:
Define accounting methods
Perform testing
Define accounting methods to group subledger journal entry rule sets to determine how the source system transactions are accounted for a given ledger. Your goals in defining accounting methods are to:
Ensure regulatory compliance
Facilitate corporate financial reporting
Enable audits
Facilitate reconciliation to source systems
Assign journal entry rule sets to event class and event type combinations in an accounting method to determine how the subledger journal entries for that class or type are created.
The following are the subcomponents of a journal entry rule set:
Journal Line Rules: Determine basic information about a subledger journal entry line. Such information includes whether the line is a debit or credit, the accounting class, and if matching lines are merged.
Description Rules: Determine the descriptions that are included on subledger journal entry headers and lines. Include constant and source values in descriptions.
Account Rules: Determine which account should be used for a subledger journal entry line.
Supporting References: Optionally used to store additional source information about a subledger journal entry and are useful for reconciliation of accounting to source systems.
You can attach conditions to journal line rules, description rules, and account rules components. A condition combines constants, source values, and operands to indicate when a particular journal line rule, description, or account rule is used. For example, for mortgage loans, you can elect to use a specific loan receivable account based on the loan type.
Once the setup is complete, testing should be comprehensive to ensure that all accounting is correctly generated. To complete testing, use accounting events and information from the source system, that is populate the transaction objects. This should, at a minimum, include testing that:
Accounting events are successfully created.
Sources are available for creating subledger journal entries.
Subledger journal entries accurately reflect the accounting rules. Test that:
Subledger journal entries contain the appropriate dates, amounts, descriptions, and accounts.
Conditions used to determine journal line rules, account rules, or descriptions are valid.
Entries are successfully summarized when transferred to the general ledger.
Subledger journal entries are successfully transferred and posted to general ledger.
Note
The above list is not intended to be comprehensive.
Accounting events have financial accounting significance and are used as a basis for recording financial information.
The diagram below describes the process to create subledger journal entries from accounting events using a custom Loans application as an example and is explained in the succeeding text.
As illustrated in the above diagram, after transactions occur, accounting events are captured to record their accounting impact. Accounting events can be captured as transactions are generated in the source system, or they can be captured in bulk as part of a standard daily close or batch process. When accounting events are captured is based upon the flexibility of the source system and the frequency with which accounting should be created. For each eligible event, the transaction object contains contextual information about the event, such as source values.
The setups associated with a ledger use the source data for the event to create the appropriate subledger journal entry. Each accounting event can be used to create one or more subledger journal entries. Subsequently, the accounting event links transactions to their corresponding subledger journal entries.
All business events that can have an accounting impact should be captured as accounting events.
The following procedures can assist in the analysis and identification of accounting events:
Identify transactions that may have a financial impact on your organization.
Identify the life cycles of these transactions and the business events that change the state of the transactions throughout their life cycles.
Business events vary by industry and organization. Examples of business events include the contract, order and delivery of goods and services, and receipts and payments to third parties.
Some business events have financial significance. Their impact must be accounted.
The following examples have a financial accounting impact and therefore are accounting events:
Originating a loan
Funding a loan
Applying payment to a loan
Not all events are accounted. As an example, consider a loan application. The loan origination event results in accounting if the accounting method is Accrual, but may not result in accounting if the accounting method is Cash Basis.
When an accounting event is captured, different event attributes are passed to the Oracle Fusion Accounting Hub.
The following table lists some of the attributes that are stored for an accounting event along with their corresponding descriptions.
Attribute |
Description |
---|---|
Event ID |
Accounting event internal identifier; provided by Create Accounting. |
Event Number |
Unique event sequence number within a document. Create Accounting processes events in the order of their event number. |
Event Type |
Represents the business operation that can be performed on the end user transaction type event class and has accounting significance. |
Transaction Identifiers |
Identifies the document or transaction in the subledger tables and constitute the primary key of the transaction. |
Event Status |
Available statuses are:
|
Event Date |
Date of the accounting event that originated the journal entry. |
Transaction Context Values |
|
Application Specific Attributes |
Additional columns are provided for implementers to store data drawn from the transaction model (state) at the time the event is captured. These can be useful in cases where the transaction data changes and information is needed on the original event. |
Security Context Values |
Provide the event's security context. Examples include organization identifier and asset book. |
On Hold Flag |
Indicates whether there is a gap ahead of an accounting event. If there is a gap, the event is put on hold. The Oracle Fusion Accounting Hub does not process accounting events on hold due to a gap. |
The Oracle Fusion Accounting Hub event tables store the event data for these attributes. The presence of this data enables the creation of individual subledger journal entries for each accounting event. It also provides an audit trail between the subledger journal entry and the transaction data of the accounting event.
Event capture routines populate these tables when the events are created.
The event status is an indicator of what actions have been completed on the transaction and what operations are yet to be done.
The Create Accounting process makes updates to this status as the accounting process progresses. Once Create Accounting successfully processes the accounting event, the status of the event will be updated to Processed.
The table below lists the event statuses along with their corresponding details. At any point of time, an event can have only one of these statuses.
Status |
Details |
---|---|
Incomplete |
The accounting event data is in the process of being created. Some of the accounting event data cannot be created at this point. There can be validations that have not yet been performed. No subledger journal entry exists for the accounting event. If Create Accounting is run, it does not process accounting events with a status of Incomplete. The subledger application updates this event status. |
Unprocessed |
All of the transaction data for this accounting event has been created and all validations have been performed. At this point of time, the subledger journal entry can be created. When Create Accounting is run, it processes accounting events with a status of unprocessed. |
No action |
This status is set when creating or updating events using APIs. No subledger journal entry is needed for this accounting event. |
Processed |
All of the transaction data for this accounting event is created, all validations are performed and, if appropriate, the final subledger journal entry is created. The transaction data associated with the accounting event should not be changed. For those transactions where multiple accounting events are allowed, any changes to the transaction data at this point of time results in a new accounting event. The changed transaction data is tracked under the new accounting event. After successfully creating subledger journal entries, Create Accounting updates the event status. However, you can enter new lines provided the subledger functionality allows such a change. New lines entered are recorded with new accounting events. |
Every event has a life cycle. The event status indicates what actions have been completed on a event. An accounting event does not necessarily go through each of the statuses.
Possible event statuses are displayed below.
The above diagram illustrates all the possible status changes for accounting events. An accounting event will not necessarily go through each of the statuses.
The diagram has three blocks. The left block, From Event Status, shows the possible initial statuses of an event. These statuses are Incomplete, Unprocessed, No Action, and Processed.
The center block, Action, represents actions that you complete in subledger applications. These actions result in events being created, processed, or deleted.
The right block, To Event Status, shows the possible final status based on the action in the central block. The status values include Incomplete, Unprocessed, No Action, and Processed Program.
All of the possible status changes are displayed in the diagram. Not all accounting event types can support all of these status changes. For example, some accounting events, once they have a status of Unprocessed, cannot be updated to an Incomplete status. Implementers are responsible for determining the supported status changes for an event.
There may also be conditions that determine whether the accounting event can move from one status to another. These conditions can vary by accounting event.
For example, a loan that has not been processed for accounting may be cancelled and will be set to a No Action event status. However, if unprocessed loan interest accrual events cannot be cancelled, the event status cannot be set to a No Action status.
Each accounting event must have one and only one event date. If there are multiple dates for a particular event type, then one accounting event must be created for each accounting date.
For example assume a loan is originated and accounted. The next day the loan interest is adjusted. Later, a loan payment is scheduled.
This creates three accounting events:
If the transaction has the potential to create multiple events, then both the event date and status of the previous event determines whether a new accounting event is created. Consider the following examples:
A user cancels the loan before accounting for the loan origination event.
If the event date for the cancellation is the same as that of the accounting event created for the loan, then the status of the loan origination accounting event is updated to No Action. No accounting event is created for the cancellation.
An loan origination is canceled after it has been accounted.
The accounting event created for the loan origination is not affected by the cancellation. A new event for the cancellation is created and requires processing to create a subledger journal entry.
Subledger applications can support third party control account type and calculate reporting currency amounts.
If the subledger application is configured to calculate reporting currency amount, there is no need to provide reporting currency information in the transaction objects.
The following are additional considerations when creating a subledger application:
Determine the subledgers requirement. For example, how many subledgers are to be created? This may depend on what security your company wants to have over its accounting rules.
Using the same subledger allows you to share subledger accounting rules, and lets you report across all data easily.
Using separate subledgers provides more security across applications and less data in each process run providing better performance. Specific benefits are:
If you run two Create Accounting requests at the same time for different applications, they are much less likely to contend for database resources. The requests will perform better, as the indexes are tuned for running with different applications instead of running for different process categories within the same application.
It allows you to efficiently process different sets of data (different applications) at different times during the day instead of running it as one process.
Determine the transaction objects requirements. These requirements determine what source data is required to successfully create subledger journal entries from transactions that are captured in transaction objects and shared in reference objects.
Analyze accounting events to determine what events to capture for the subledger application.
Create programs to capture accounting events using APIs (application programming interfaces) that are provided as follows:
Get Event Information APIs to get event information related to a document or a specific event.
Create Event APIs to create accounting events, individually or in bulk.
Update Event APIs to update events and keep them consistent with related transaction data.
Delete Event APIs to delete events.
Determine how often to capture accounting events, populate transaction objects, and run the Create Accounting process. This may depend on the immediacy and volumes of accounting requirements in your company.
Accounting events represent transactions that may have financial significance, for example, issuing a loan and disposing of an asset. Financial accounting information can be recorded for these events and accounted by the Create Accounting process. When you define accounting events, determine from a business perspective which activities or transactions that occur in your source system may create a financial impact.
Events with significantly different fiscal or operational implications are classified into different accounting event types. Event types are categorized into accounting event classes. Accounting definitions in the Oracle Fusion Accounting Hub are based on event types. An event type must be unique within an application, process category, and event class.
Events are captured when transactions are committed in the subledgers, or they may be captured during end-of-day or period-end processing. For example, a loan is originated, possibly adjusted, interest is accrued, and then the loan is paid or canceled. The accounting events representing these activities can create one or more subledger journal entries, and subsequently link the originating transaction to its corresponding journal entries.
The following is an example of an accounting event model for a loan application:
A process category consists of specific event classes and the event types within those classes. To restrict the events selected for accounting, users can select a process category when they submit the Create Accounting process.
You can assign a transaction view, system transaction identifiers, and optionally user transaction identifiers and processing predecessors for an event class in the Edit Event Class section. The transaction view should include all columns that have been mapped to system transaction identifiers for the accounting event class as well as the user transaction identifiers.
System Transaction Identifiers
System transaction identifiers provide a link between an accounting event and its associated transaction or document. An identifier is the primary key of the underlying subledger transaction, usually the name of the surrogate key column on the transaction (header) associated with the accounting event. At least one system transaction identifier must be defined for the accounting event class.
When an accounting event is captured, system transaction identifiers, along with other required event data, are validated for completeness.
User Transaction Identifiers
User transaction identifiers constitute the user-oriented key of the underlying subledger transaction, and are typically drawn from one or more database tables. These identifiers are primarily used in accounting events inquiry and on accounting event reports, to uniquely identify transactions. You can specify up to ten columns from the transaction views that are available for inquiry and reports.
The transaction data that identifies the transaction varies by accounting event class. Accounting event reports and inquiries display the transaction identifiers and their labels appropriate for the corresponding event class. The user transaction identifiers can be displayed for an event regardless of its status. This includes the case where the accounting event has not been used to create subledger journal entries due to an error or the cases where it has not been processed. The user transaction identifier values are displayed at the time that the accounting event reports and inquiries are run. If a transaction identifier value has changed after the accounting event was captured, the accounting event reports and inquiries reflect the change.
Processing Predecessors
The processing predecessor establishes an order in which the Create Accounting process processes events selected for accounting.
For accounting event types, specify whether their accounting events have accounting or tax impact. When the Create Accounting process is submitted, it only accounts business events that are enabled for accounting.
You may assign transaction and reference objects for each accounting event class in the subledger application. Sources are generated based on the transaction objects and are assigned to the corresponding accounting event classes.
Sources are used to create accounting rules. Subledgers pass information to the application by populating transaction object tables. The columns in these tables are named after the source codes. Transaction and reference objects hold transaction information that is useful when creating journal entry rules for accounting. The transaction and reference objects are defined for an accounting event class so that source assignments to accounting event class can be generated using these objects.
Transaction objects refer to the tables or views from which the Create Accounting process takes the source values to create subledger journal entries. Source values, along with accounting event identifiers, are stored in the transaction objects. The Create Accounting process uses this information to create subledger journal entries.
You have several options. You can:
Create new tables as the transaction objects and create a program to populate them.
Use views of your transaction data as the transaction objects.
Use your transaction data tables as the transaction objects.
The transaction objects and or views must be accessible to the Create Accounting process. Typically, an ETL (extract, transformation, and load) program is used to take values from the source system and load them into the database used by the Create Accounting process. The ETL process is done outside of the Create Accounting process.
The following are transaction object types:
Header transaction objects
Implementers need to provide at least one header transaction object for each accounting event class. Header transaction objects store one row with untranslated header source values for each accounting event. The primary key of a header transaction object is the event identifier.
Transaction details that are not translated, and whose values do not vary by transaction line or distribution, should normally be stored in header transaction objects. Examples of sources normally stored in header transaction objects include the Loan Number for a loan or the Contract Number for a contract.
Line transaction objects
Line transaction objects are relevant when there are details for the accounting event that vary based upon transaction attributes. For example, a mortgage transaction for loan origination may have multiple amounts, each related to different components of the loan. There may be a loan origination amount, closing cost amounts, and escrow amounts. Each of these amounts could be captured as separate lines, along with an indication of the amount type
Line transaction objects store untranslated line level source values. There should be one row per distribution, identified by a unique line number. The primary key of a line transaction object is the event identifier and transaction object line number. Transaction details that are not translated and whose values vary by transaction line or distribution are normally stored in line transaction objects columns. Examples include the Loan Number for a loan payment.
Multi-Language Support (MLS) transaction objects
MLS transaction objects are relevant to applications that support the MLS feature. MLS transaction objects store translated source values. There should be one row per accounting event and language. The primary key of a header MLS transaction object is the event identifier and language. The primary key of a line MLS transaction object is the event identifier, transaction object line number, and language.
Transaction details that are translated, and whose values do not vary by transaction line or distribution, are normally stored in header MLS transaction object columns. Examples include Loan Terms for a commercial loan. Implementers can avoid having to store source values in header MLS transaction objects by using value sets and lookup types.
Transaction details that are translated, and whose values vary by transaction line or distribution, should normally be stored in the transaction object in columns defined in a line MLS transaction object.
Reference objects are useful for storing information that is used for creating subledger journal entries. This information may not be directly from the source system or may be used for many entries, thus making it redundant. Use reference objects to share sources information across applications.
For example, store customer attributes, such as the customer class or credit rating in a reference object, and then, use it to account for different journal entries in a loan cycle, such as loan origination or interest accrual. Store information, such as bond ratings and terms, and use it to account for entries across the life of bonds, such as interest accruals or bond retirement.
Reference objects can either have a direct relationship to transaction objects (primary reference object), or be related to other reference objects (secondary).
Sources are a key component for setting up accounting rules. Sources represent transaction and reference information from source systems. Contextual and reference data of transactions that are set up as sources can be used in accounting rules definitions.
When determining what sources should be available, it is helpful to begin the analysis by considering which information from your systems is accounting in nature. Examples of sources that are accounting in nature include general ledger accounts that are entered on transactions, the currency of a transaction, and transaction amounts. Sources that are not always required for accounting rules include items that are related to the transaction for other purposes than accounting. Examples of information that may not be specifically for accounting, but which may be useful for creating subledger journal entries, are transaction identification number (loan number, customer number, or billing account number), counter party information, and transaction dates.
Provide a rich library of sources from your source systems for maximum flexibility when creating definitions for subledger journal entries.
Sources are assigned to accounting event classes by submitting the Create and Assign Sources process.
There is a distinct difference between sources and source values. Sources represent the transaction attributes used to create accounting rules. Source values are used by the Create Accounting process to create subledger journal entries based upon source assignments to accounting rules.
Sources must be created prior to creating accounting rules. This is a predefined step which must be undertaken before the application can be used to create subledger journal entries.
To set up appropriate subledger journal entry rule sets, users and those implementing need to understand the origins, meaning, and context of sources. Use business oriented names for sources to allow accountants and analysts to effectively create accounting rules.
Enables users to easily identify a source.
Ensures consistency in nomenclature.
Source values are stored in transaction objects. They are the actual transaction attribute values from the source system and are used in creation of the journal entries.
The Create Accounting process uses the values of sources assigned to accounting attributes plus accounting rules to create subledger journal entries. Almost all accounting attributes have sources assigned at the accounting event class level. Depending on the accounting attribute, the accounting attribute assignment defaulted from the accounting event class can be overridden on journal line rules or subledger journal entry rule sets.
Once sources are assigned to accounting event classes, they are eligible for assignment to accounting attributes for the same accounting event classes.
The Create Accounting process uses these assignments to copy values from transaction objects to subledger journal entries. For example, you may map the invoice entered currency to the subledger journal entry entered currency.
Each accounting attribute is associated with a level:
Header: To be used when creating subledger journal entry headers.
Line: To be used when creating subledger journal entry lines.
The types of accounting attributes values are as follows:
You may have values that are subject to special processing or values that are stored in named columns in journal entry headers and lines.
Examples of accounting attributes are Entered Currency Code and Entered Amount.
You may have values that control the behavior of the Create Accounting process when processing a specific accounting event or transaction object line.
An example of accounting attributes of this type is Accounting Reversal Indicator.
In order to create a valid journal entry you must, at a minimum, set up the following accounting attribute assignments.
Accounting Date
Distribution Type
Entered Amount
Entered Currency Code
First Distribution Identifier
The details and descriptions of these attributes are included in the Accounting Attributes section.
Accounting attribute groups are represented in the tables below:
Accounted Amount Overwrite
The accounted amount overwrite accounting attribute indicates whether the accounted amount calculated by the Create Accounting process should be overwritten by the value of the accounted amount accounting attribute. If the source value mapped to Accounted Amount Overwrite is 'Y', then an accounted amount must be provided.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Accounted Amount Overwrite Indicator |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
Y - Overwrite accounted amount N - Not overwrite accounted amount |
Accounting Date
The accounting date attribute is relevant to all applications. The Create Accounting process uses it to derive the accounting date of journal entries. Typically, the event date system source is assigned to the accounting date attribute.
The Accrual Reversal GL Date accounting attribute is relevant to applications using the accrual reversal feature. Users can assign system and standard date sources to the Accrual Reversal GL Date in the Accounting Attribute Assignments page. When the Accrual Reversal GL Date accounting attribute returns a value, the Create Accounting process generates an entry that reverses the accrual entry.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Accounting Date |
Date |
Header |
Event Class and Journal Entry Rule Set |
Yes |
Should be in open general ledger period |
Accrual Reversal GL Date |
Date |
Header |
Event Class and Journal Entry Rule Set |
No |
Should be later than the accounting date |
Accounting Reversal
Accounting reversal accounting attributes are relevant to applications that wish to take advantage of the accounting reversal feature. The Create Accounting process uses them to identify transaction (distributions) whose accounting impact should be reversed. For the Create Accounting process to successfully create a line accounting reversal, the accounting reversal indicator, distribution type, and first distribution identifier should always be assigned to sources. The definition of the accounting reversal distribution type and distribution identifiers mirrors the definition of the distribution identifiers.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Accounting Reversal Distribution Type |
Alphanumeric |
Line |
Event Class |
Yes, if another accounting reversal accounting attribute is assigned. |
|
Accounting Reversal First Distribution Identifier |
Alphanumeric |
Line |
Event Class |
Yes, if another accounting reversal accounting attribute is assigned. |
|
Accounting Reversal Second Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Accounting Reversal Third Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Accounting Reversal Fourth Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Accounting Reversal Fifth Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Accounting Reversal Indicator |
Alphanumeric |
Line |
Event Class |
Yes, if another accounting reversal accounting attribute is assigned. |
Y - Reverse without creating a replacement line B - Reverse and create a new line as replacement N or Null - Not a reversal |
Transaction Accounting Reversal Indicator |
Alphanumeric |
Header |
Event Class |
No |
Y - Reversal transaction object header N or null - Standard transaction object header |
Business Flow
The business flow accounting attributes are referred to as 'applied to' accounting attributes. If a transaction is applied to a prior transaction in the business flow, the transaction object must populate sources assigned to 'applied to' accounting attributes with sufficient information to allow the Create Accounting process to uniquely identify a transaction object line for a prior event in the business flow. When deriving accounting data from a previous event in the business flow, the Create Accounting process searches for a journal entry line for the prior event using a combination of the 'applied to' accounting attributes and the business flow class of both journal entries.
The Applied to Amount accounting attribute is used to calculate the accounted amount and gain or loss in cross-currency applications when business flows are implemented. This attribute value is used to calculate the accounted amount when a source is mapped to the Applied to Amount attribute on a journal line type and the entered currency is different than the original currency entered.
Note
When enabling business flow to link journal lines in the Journal Line Rule page, certain accounting attribute values are unavailable for source assignment in the Accounting Attributes Assignments window of the same page because they will be copied from the related prior journal entry.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Applied to Amount |
Number |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to First System Transaction Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
|
Applied to Second System Transaction Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Third System Transaction Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Fourth System Transaction Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Distribution Type |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
|
Applied to First Distribution Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
|
Applied to Second Distribution Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Third Distribution Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Fourth Distribution Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Fifth Distribution Identifier |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
|
Applied to Application ID |
Number |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
Must be a valid application ID |
Applied to Entity Code |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
Must be a valid Entity for the application selected in Applied to Application ID |
Distribution Identifier
Distribution identifiers accounting attributes are relevant to all applications. The distribution identifier information links subledger transaction distributions to their corresponding journal entry lines. In addition, many of the Oracle Fusion Subledger Accounting features, including accounting reversals, rely on the correct definition and storing of distribution identifiers in the line transaction objects. The distribution type and first distribution identifiers are always assigned to sources. If a transaction distribution is identified by a composite primary key, additional distribution identifiers are assigned to standard sources, as appropriate. Values for the distribution type and distribution identifiers are always stored in accounting transaction objects. The combinations of the values of the system transaction identifiers with the values of the distribution identifiers uniquely identify a subledger transaction distribution line.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Distribution Type |
Alphanumeric |
Line |
Event Class |
Yes |
|
First Distribution Identifier |
Alphanumeric |
Line |
Event Class |
Yes |
|
Second Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Third Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Fourth Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Fifth Distribution Identifier |
Alphanumeric |
Line |
Event Class |
No |
|
Document Sequence
The document sequence accounting attributes are relevant to applications that use the document sequencing feature to assign sequence numbers to subledger transactions. The Create Accounting process uses them to provide a user link between subledger transactions and their corresponding subledger journal entries. Assign all document sequence accounting attributes to sources or do not assign any. In addition, the Document Sequence Category Code is made available as an Accounting Sequence Numbering control attribute.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Subledger Document Sequence Category |
Alphanumeric |
Header |
Event Class |
Yes, if another accounting attribute in the same group has assignment. |
|
Subledger Document Sequence Identifier |
Number |
Header |
Event Class |
Yes, if another accounting attribute in the same group has assignment. |
|
Subledger Document Sequence Value |
Number |
Header |
Event Class |
Yes, if another accounting attribute in the same group has assignment. |
|
Entered Currency
Entered currency accounting attributes are relevant to all applications. The Create Accounting process uses them to populate the journal entry line entered currency code and amounts. The entered currency accounting attributes must always be assigned to sources. The sources assigned to the entered currency accounting attributes must always contain a value. For event classes that support cross currency transactions and therefore, more than one entered currency and entered currency amount, multiple event class accounting attribute assignments are created.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Entered Currency Code |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
Yes |
A valid currency code |
Entered Amount |
Number |
Line |
Event Class and Journal Line Rule |
Yes |
|
Ledger Currency
Ledger currency accounting attributes are relevant to all applications that use the Create Accounting process. The Create Accounting process uses them to populate journal entry accounted amounts. If a transaction's entered currency is different from the ledger currency, the Create Accounting process copies the conversion date, conversion rate, and conversion rate type to the corresponding journal entry lines. If the entered currency is the same as the ledger currency, the Create Accounting process ignores the conversion type and conversion rate. For event classes that support foreign currency transactions and therefore more than one exchange rate and reporting currency amount, multiple event class accounting attribute assignments are created.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Accounted Amount |
Number |
Line |
Event Class and Journal Line Rule |
No |
|
Conversion Date |
Date |
Line |
Event Class and Journal Line Rule |
No |
|
Conversion Rate |
Number |
Line |
Event Class and Journal Line Rule |
No |
|
Conversion Rate Type |
Alphanumeric |
Line |
Event Class and Journal Line Rule |
No |
A valid general ledger conversion rate type or User |
Tax
The tax accounting attributes are relevant to applications that uptake the tax initiative. The tax team uses the tax accounting attributes to link subledger transaction tax distributions to their corresponding journal entry lines. Oracle Fusion Tax specifies which tax reference values are mandatory in transaction objects and are assigned to standard sources.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Detail Tax Distribution Reference |
Number |
Line |
Event Class |
No |
|
Detail Tax Line Reference |
Number |
Line |
Event Class |
No |
|
Summary Tax Line Reference |
Number |
Line |
Event Class |
No |
|
Third Party
Third party accounting attributes are relevant to subledger applications that use third party control accounts. The third party accounting attributes link suppliers and customers to their corresponding subledger journal entry lines in the supplier and customer subledgers. For all subledger transactions that represent financial transactions with third parties, all third party accounting attributes have sources assigned. If a transaction line is associated with a customer or supplier, the transaction objects need to include values for all sources mapped to third party accounting attributes for the event class.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Party Identifier |
Number |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
If party type C - Should be a valid customer account If party type is S - Should be a valid supplier identifier |
Party Site Identifier |
Number |
Line |
Event Class and Journal Line Rule |
Yes, if another accounting attribute in the same group has assignment. |
If party type C - Should be a valid customer account If party type is S - Should be a valid supplier identifier |
Party Type |
Alphanumeric |
Line |
Event Class |
Yes, if another accounting attribute in the same group has assignment. |
C for Customer S for Supplier |
Exchange Gain Account, Exchange Loss Account
The Create Accounting process determines whether there is an exchange gain or loss and derives the account combination based on whether the journal line rule is defined. If the gain or loss journal line rule is defined, the account rule assigned to the journal line rule is used to determine the gain or loss account to use. If the gain or loss journal line rule is not defined, the gain or loss account assigned to the Exchange Gain Account and Exchange Loss Account accounting attributes is used.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Exchange Gain Account |
Number |
Header |
Event Class |
No |
|
Exchange Loss Account |
Number |
Header |
Event Class |
No |
|
Gain or Loss Reference
The Gain or Loss Reference accounting attribute groups entry lines together when calculating exchange gain or loss. The accounted debit and accounted credit amounts for lines with the same gain or loss reference are combined. The total of accounted debit and total of accounted credit are compared to calculate the exchange gain or loss.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Gain or Loss Reference |
Alphanumeric |
Line |
Event Class |
No |
|
Transfer to GL Indicator
The Transfer to GL accounting attribute is relevant to applications which create subledger journal entries that will never be transferred to the general ledger. The Transfer to GL process uses this accounting attribute to determine whether to transfer subledger journal entries to the general ledger.
If the Transfer to GL accounting attribute is not assigned to a source, the Transfer to GL process transfers journal entries for the event class to the General Ledger.
If the Transfer to GL accounting attribute is assigned to a source and the source is not populated, the Transfer to GL process transfers journal entries for the event class to the General Ledger.
Accounting Attributes |
Data Type |
Journal Entry Level |
Assignment to Rules |
Assignment Required? |
Validation Rules |
---|---|---|---|---|---|
Transfer to GL Indicator |
Alphanumeric |
Header |
Event Class |
No |
Should be Y or N |
The Oracle Fusion Accounting Hub provides a set of common APIs to capture accounting events. All event operations must be performed through these APIs. By ensuring that event operations are executed through generic APIs, the architecture meets the needs of implementers:
Insulates implementers from changes in the implementation of an API
The presence of the API reduces dependencies between the Accounting Hub and your source systems.
Implementers do not have to know the underlying Accounting Hub data model to capture accounting events. In addition, any implementation changes made by the Accounting Hub have minimum or no impact on implementers.
The Accounting Hub relies on accounting events to indicate that there are activities from source systems that require accounting.
The Create Accounting process selects accounting events based on criteria specified by users. The Create Accounting process does not check for any functional dependencies between transactions or event types.
Note
For each eligible event, the Create Accounting process retrieves source values from the transaction objects. Subledger journal entries are created using both event and source information.
Implementers must undertake the following steps to create event capture routines:
Perform accounting event setups
Write product specific wrapper routines
Integrate event APIs with source systems
As a prerequisite, you must register the application.
An additional prerequisite step is to define and register event process categories, accounting event classes, and event types before events can be captured. The event APIs use event information to perform the necessary validations when creating events.
In order to reduce dependencies and facilitate maintenance, it is recommended that you write a wrapper routine on top of the Oracle Fusion Accounting Hub APIs. Wrapper routines can encapsulate source system specific logic to perform necessary validations before creating new events. Map source system specific parameters to the API parameters
For example, if you were implementing the Accounting Hub to capture information for a loans application, you could use a package called LOAN_XLA_EVENTS_PKG, which contains all the APIs to implement accounting events in Loans. The code for this package is shown below.
Assume that this example loans application has two event classes Create Loan and Create Payment. To handle accounting events for loan transactions, you could create a procedure create_loan_event() with p_loan_id as an input parameter, instead of using a generic parameters like source_id_int_1. The procedure create_loan_event() calls the appropriate Accounting Hub API to create an event.
Similarly, create create_payment_event() to handle accounting events for the event class Create Payment.
LOAN_XLA_EVENTS_PKG
-- Procedure to create events for creating a loan
PROCEDURE create_loan_event
(p_loan_id
,p_event_type
,p_event_date
,p_event_status) IS
l_loan_source_info XLA_EVENTS_PUB_PKG.t_event_source_info;
l_security_context XLA_EVENTS_PUB_PKG.t_security; BEGIN
BEGIN
-- Perform product specific checks
...
-- Map generic event API parameter to the product specific columns
l_load_source_info.application_id = loan_application_id;
l_loan_source_info.legal_entity_id = l_legal_entity_id;
l_loan_source_info.source_id_int_1 = p_loan_id;
-- Call XLA API
XLA_EVENTS_PUB_PKG.create_event
(p_event_source_info => l_loan_source_info
,p_event_type_code => p_event_type
,p_event_date => p_event_date
,p_event_status_code => p_event_status
,p_event_number => NULL
,p_reference_info => NULL
,p_valuation_method => NULL
,p_security_context => l_security_context);
...
...
EXCEPTIONS
....
END;
It is suggested that implementers create an Enterprise Scheduler Service (ESS) process for the event capture wrapper routines. Using an ESS process instead of directly running the routines in the database will provide for the following:
Enable implementation of security where some users can be given access to create events for specific source systems but not all.
Go through the proper channels of executing code on Fusion schema. The ESS job will not require the user to have write access to Fusion schema.
You may need to perform certain checks with respect to events. For example, before creating a new accounting event, it is necessary to check whether there is an existing unprocessed event for the same transaction with the same accounting event type and event date.
You may also want to know the status of a particular event or query events already created for the transaction.
To perform these checks, obtain event information for a transaction by doing the following:
Determine the system transaction identifiers and accounting event class for the transaction.
Note
System transaction identifiers identify the transaction on which events are based. The Oracle Fusion Accounting Hub uses these identifiers to search the events table and identify all the events that are related to a transaction.
Call the function Get_Array_Event_Info()
with the appropriate transaction
parameters. The function returns an array of all events for a transaction.
To obtain all the events created for a particular event type within a transaction, do the following:
Determine the system transaction identifiers, event class, and event type of the transaction.
Call the function Get_Array_Event_Info()
with the appropriate transaction
and event type input parameters. The function returns an array of
all accounting events for that transaction and event type. Optionally
pass the event class, event date, and event status to further restrict
the rows returned.
To get information about a specific event, do the following:
Determine the event_id
.
Call the function Get_Event_Info()
with the event_id parameter. This function
returns a PL/SQL record containing all information pertaining to that
particular event.
This section describes the following guidelines on creating events using the create event APIs:
Creating a single event
Creating events in bulk
To create a new event:
Determine the accounting event type, event date, and event status for the new event.
Call the Oracle Fusion Accounting
Hub function Create_Event()
with the
appropriate input parameters.
The Create_Event()
API
creates a single event at a time. The function returns the event_id
of the created event.
Create events in bulk using the API Create_Bulk_Events()
.
Note
Do not use this API for existing transactions that already have events associated with them. For performance reasons, bulk event APIs do not perform checks as to whether events for the transaction already exist. Therefore, use this API only to create events for new transactions that do not have any prior events created.
Update the event to keep the transaction data and related events synchronized.
You can update an event as long as it is not processed. Once an event is accounted in Final status, you cannot update the event or the data associated with it.
Use the following APIs to update your events:
Update Event
This is an overloaded API used to update the status, type, date, number, and reference information of a single event.
Update Event Status
This API updates multiple events to a given status.
To delete all Unprocessed events associated with a transaction:
Determine the transaction source information.
Call the Oracle Fusion Accounting
Hub function Delete_Events()
with the
transaction source information.
Optionally, specify the accounting event type, event status, or event date, to restrict the events deleted.
If a transaction is deleted, the Delete_Entity()
API must be called to delete the row in the XLA_TRANSACTIONS_ENTITY
table.
In the case where the transaction number of the transaction has been changed, this API updates the transaction number on the events in the XLA_TRANSACTION_ENTITIES table so that they are consistent with the transaction number on the transaction.
The API checks the source information for a valid application, legal entity, event process category, and source identifiers. However, no validation is performed on the transaction number.
This section describes the event APIs accessible by implementers to perform event operations. The APIs described are generic and available to all applications.
Event APIs have the following characteristics:
Event APIs do not issue any commits.
If an API fails, any changes made are rolled back and a standard exception is raised.
All parameters are read only (IN parameters); there are no OUT parameters.
The event date is always truncated.
The Oracle Fusion Accounting Hub does not store the timestamp for an event date.
All functions return a single value or record.
The exceptions to this rule are the
functions prefixed with a Get_Array
string.
For example, the function Get_Array_Event_Info()
returns an array.
Input parameters must be passed in a nonpositional notation, named notation.
All the APIs called in query mode locks the event record in NOWAIT mode.
Event APIs have the following types of input parameters:
System transaction identifiers
These parameters capture information such as loan_id. This information is stored with each event to later identify the source transaction for the event. You need to pass the source identifiers when creating an event.
Transaction security identifiers
Accounting events are subject to the security of the corresponding transaction. Every accounting event is stamped with its related transaction's security context.
Transaction security parameters capture application-specific transaction security information, such as business unit or ledger.
Transaction reference information
The reference parameters enable you to capture any miscellaneous reference or contextual information for an event. This information is optional and no validations are performed against any reference parameters.
The XLA_EVENT_PUB_PKG package contains the following items:
PL/SQL record and table structures for common parameters
CONSTANTS for event statuses
Use these constants and structures when passing and reading values to and from the APIs.
This section provides details on the APIs that obtain event information.
This API returns information for a particular event. The event is identified by specifying the transaction and event identifier. The API locks the specified event before returning any event information.
The API checks all source information for valid application, legal entity, event entity, and source identifiers (IDs). It ensures that the required parameters are not passed as null and that the event ID belongs to the same transaction, as the other transaction information being passed.
The API returns a PL/SQL record containing event information.
FUNCTION XLA_EVENTS_PUB_PKG.get_event_info
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN xla_events_pub_pkg.t_event_info;
This routine returns information for one or more events within a transaction. The calling program specifies the transaction and event selection criteria. Return information contains data on all events that belong to the specified transaction and fall under the given criteria. The API locks the specified events before returning the event information.
The API checks all source information for valid application, legal entity, event process category, and source IDs. It ensures that the required parameters are not passed as null and also validates the accounting event class, event type, and event status. Note that the API truncates the event date.
The API returns an array of event information.
FUNCTION XLA_EVENTS_PUB_PKG.get_array_event_info
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_class_code IN VARCHAR2 DEFAULT NULL
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2 DEFAULT NULL
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN xla_events_pub_pkg.t_array_event_info;
This API returns the event status for a specified event. The calling program needs to specify the transaction and event identifier. The API locks the specified event record before returning the status.
The API checks all source information for valid application, legal entity, event process category, and source IDs. It ensures that the required parameters are not null and the event belongs to the same transaction as the other transaction information being passed.
This API returns an event status. The Oracle Fusion Accounting Hub has defined all event statuses as Constants.
FUNCTION XLA_EVENTS_PUB_PKG.get_event_status
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN VARCHAR2;
This API checks whether an event exists for the specified criteria. It returns True if it finds at least one event matching the criteria; otherwise, it returns False. The API locks the event rows before returning a value.
The API checks all source information for valid application, legal entity, event process category, and source IDs. It ensures that the required parameters are not null and also validates the event class, event type, and event status. The API truncates the event date.
The API returns True if an event is found for the specified criteria; otherwise, it returns False.
FUNCTION XLA_EVENTS_PUB_PKG.event_exists
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_class_code IN VARCHAR2 DEFAULT NULL
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2 DEFAULT NULL
,p_event_number IN NUMBER DEFAULT NULL
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN BOOLEAN;
This section provides details on the API that create events.
This API creates a new event.
The API checks all source information for valid application, legal entity, event process category, and source IDs. It ensures that the required parameters are not null and also validates the accounting event type and event status.
No validations are performed against the reference columns and event number. However, if no event number is passed, the routine populates the next highest event number for that transaction. The event date is truncated.
If an event is created successfully, then the function returns its event ID.
FUNCTION XLA_EVENTS_PUB_PKG.create_event
(p_source_event_info IN xla_events_pub_pkg.t_event_source_info
,p_event_type_code IN VARCHAR2
,p_event_date IN DATE
,p_event_status_code IN VARCHAR2
,p_event_number IN NUMBER DEFAULT NULL
,p_reference_info IN xla_events_pub_pkg.t_event_reference_info
DEFAULT NULL
,p_valuation_method IN VARCHAR2
,p_transaction_date IN DATE DEFAULT NULL
,p_security_context IN xla_events_pub_pkg.t_security
,p_budgetary_control_flag IN VARCHAR2)
RETURN NUMBER;
FUNCTION XLA_EVENTS_PUB_PKG.create_event
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_type_code IN VARCHAR2
,p_event_date IN DATE
,p_event_status_code IN VARCHAR2
,p_event_number IN NUMBER DEFAULT NULL
,p_transaction_date IN DATE DEFAULT NULL
,p_reference_info IN xla_events_pub_pkg.t_event_reference_info
DEFAULT NULL
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN NUMBER;
This API creates multiple events for multiple transactions.
Note
Do not use this API for existing transactions that already have events associated with them. For performance reasons, bulk event APIs do not perform checks as to whether events for the transaction already exist. Therefore, use this API only to create events for new transactions that do not have any prior events created.
Information required for each event is inserted into the XLA_EVENTS_INT_GT table as described below, before the API is called.
The API checks all source information for valid application, legal entity, event entity, event number, and source IDs. It ensures that the required parameters are not null and also validates the event type and event status.
No validations are performed against the reference columns and event number.
Column Name |
Data Type |
Size |
Required |
---|---|---|---|
ENTITY_CODE |
VARCHAR2 |
30 |
Yes |
APPLICATION_ID |
NUMBER |
15 |
Yes |
LEDGER_ID |
NUMBER |
15 |
Yes |
EVENT_STATUS_CODE |
VARCHAR2 |
30 |
Yes |
EVENT_TYPE_CODE |
VARCHAR2 |
30 |
Yes |
EVENT_DATE |
DATE |
- |
Yes |
TRANSACTION_DATE |
DATE |
- |
No |
VALUATION_METHOD |
VARCHAR2 |
30 |
No |
TRANSACTION_ NUMBER |
VARCHAR2 |
240 |
No |
BUDGETARY_ CONTROL_FLAG |
VARCHAR2 |
1 |
No |
SOURCE_ID_INT_1 |
NUMBER |
15 |
No |
SOURCE_ID_INT_2 |
NUMBER |
15 |
No |
SOURCE_ID_INT_3 |
NUMBER |
15 |
No |
SOURCE_ID_INT_4 |
NUMBER |
15 |
No |
SOURCE_ID_CHAR_1 |
VARCHAR2 |
30 |
No |
SOURCE_ID_CHAR_2 |
VARCHAR2 |
30 |
No |
SOURCE_ID_CHAR_3 |
VARCHAR2 |
30 |
No |
SOURCE_ID_CHAR_4 |
VARCHAR2 |
30 |
No |
SECURITY_ID_INT_1 |
NUMBER |
15 |
No |
SECURITY_ID_INT_2 |
NUMBER |
15 |
No |
SECURITY_ID_INT_3 |
NUMBER |
15 |
No |
SECURITY_ID_CHAR_1 |
VARCHAR2 |
30 |
No |
SECURITY_ID_CHAR_2 |
VARCHAR2 |
30 |
No |
SECURITY_ID_CHAR_3 |
VARCHAR2 |
30 |
No |
REFERENCE_NUM_1/REFERENCE_NUM _4 |
NUMBER |
15 |
No |
REFERENCE_CHAR_1/REFERENCE_CHAR_4 |
VARCHAR2 |
30 |
No |
REFERENCE_DATE_1/REFERENCE_DATE_4 |
DATE |
- |
No |
Procedure XLA_EVENTS_PUB_PKG.create_bulk_events
(p_source_application_id IN NUMBER DEFAULT NULL
,p_application_id IN NUMBER
,p_legal_entity_id IN NUMBER DEFAULT NULL
,p_ledger_id IN NUMBER
,p_entity_type_code IN VARCHAR2);
The Update_Event_Status()
API updates the event
statuses of more than one event of a transaction. There is a set of
overloaded APIs that can be used to update more than one attribute
for an event. These APIs update accounting event type,
event date, event status, event number, and reference information
for an event. All of these API's use the Update_Event()
API.
Note
Though these update event APIs retain the same name Update_Event()
, they use the PL/SQL feature of overloading to create
unique procedures. In overloading, the input parameter names and types
are distinct, resulting in unique procedures. Different columns are
updated in the tables, depending on which procedure is called.
An event can be updated as long as it is not processed. Once an event is processed, you cannot update the event or the data associated with it.
This topic provides examples of the APIs that update events.
In this example, the API updates the event status of one or more events within a transaction matching the specified criteria.
This API checks all source information for valid application, legal entity, event process category, and source IDs. It ensures that the required parameters are not null. The API also validates event status and if passed, event class and event type. The event date is truncated.
PROCEDURE XLA_EVENTS_PUB_PKG.update_event_status
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_class_code IN VARCHAR2 DEFAULT NULL
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security);
In this example the API updates multiple attributes of a single event. Using this API, the calling program can update event type, event date, and event status. An error code is returned if the update fails.
This API checks all source information for valid application, legal entity, event entity, and source IDs. The API ensures that the event ID is not null, that it belongs to the same transaction as the other transaction information being passed, and that the event has not already been accounted.
The parameters event type, event date, and event status are also validated if passed Not Null.
PROCEDURE XLA_EVENTS_PUB_PKG.update_event
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2 DEFAULT NULL
,p_event_number IN NUMBER
,p_reference_info IN
xla_events_pub_pkg.t_event_reference_info
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security);
,p_transaction_date IN DATE DEFAULT NULL)
In this example the API updates multiple attributes of a single event. Using this API, the calling program can update event type, event date, event status, and event number. An error code is returned if the update fails.
This API checks all source information for valid application, legal entity, event entity, and source IDs. No validations are performed against the event number but if no event number is passed, the routine populates the next highest event number for that transaction. The event date is truncated.
The API ensures that the event ID is not null, that it belongs to the same transaction as the other transaction information being passed, and that the event has not already been accounted. The parameters event type, event date, and event status are also validated if passed Not Null.
PROCEDURE XLA_EVENTS_PUB_PKG.UPDATE_EVENT
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2 DEFAULT NULL
,p_event_number IN NUMBER
,p_valuation_method IN VARCHAR2
,p_transaction_date IN DATE DEFAULT NULL
,p_security_context IN xla_events_pub_pkg.t_security);
In this example the API updates multiple attributes of a single event. Using this API, the calling program can update event type, event date, event status, and the event's reference information. An error code is returned if the update fails.
This API checks all source information for valid application, legal entity, event entity, and source IDs. No validations are performed on the reference information.
The API ensures that the event ID is not null, that it belongs to the same transaction as the other transaction information being passed, and that the event has not already been accounted. The parameters event type, event date, and event status are also validated if passed Not Null.
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2 DEFAULT NULL
,p_reference_info IN xla_events_pub_pkg.t_event_reference_info
,p_valuation_method IN VARCHAR2
,p_transaction_date IN DATE DEFAULT NULL
,p_security_context IN xla_events_pub_pkg.t_security);
In this example the API updates multiple attributes of a single event. Using this API, the calling program can update event type, event date, event status, event number, and the event's reference information. An error code is returned if the update fails.
Note
This API updates both the event's event number and reference information.
This API checks all source information for valid application, legal entity, event entity, and source IDs. The API ensures that the event ID is not null, that it belongs to the same transaction as the other transaction information being passed, and that the event has not already been accounted.
The parameters event type, event date, and event status are also validated if passed Not Null. No validations are performed against the event number and reference information, but if no event number is passed, the routine populates the next highest event number for that transaction.
PROCEDURE XLA_EVENTS_PUB_PKG.update_event
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_event_status_code IN VARCHAR2 DEFAULT NULL
,p_valuation_method IN VARCHAR2
,p_transaction_date IN DATE DEFAULT NULL)
,p_security_context IN xla_events_pub_pkg.t_security);
This API updates the event status of multiple events. Before calling this API, users must populate the XLA_EVENTS_INT_GT table with the following:
application_id
entity_code
ledger_id
event_id
event_status_code
This API updates the events in the XLA_EVENTS table to the new status.
This API validates the application ID, event entity, event ID, and event status. The status of both the new and old status cannot be Processed. The new status must be a valid event status.
Procedure XLA_EVENTS_PUB_PKG.update_bulk_event_statuses
(p_application_id IN INTEGER);
This topic provides examples of the APIs that delete events.
This API deletes an unaccounted event based on its event identifier. The API returns an error code if the delete fails.
The API checks all source information for valid application, legal entity, event process category, and source IDs. The API also ensures that the mandatory parameters are not null, that the event ID belongs to the same transaction as the other transaction information being passed, and that the event has not been accounted.
PROCEDURE XLA_EVENTS_PUB_PKG.delete_event
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_id IN NUMBER
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security);
This API deletes all events for a transaction that meet the specified criteria. When called, events that belong to the given accounting event class, event type, and event date are deleted.
The API checks all source information for valid application, legal entity, event process category, and source IDs. It ensures that the required parameters are not null and if passed, validates the event type and event status.
The function returns the number of events deleted.
FUNCTION XLA_EVENTS_PUB_PKG.delete_events
(p_event_source_info IN xla_events_pub_pkg.t_event_source_info
,p_event_class_code IN VARCHAR2 DEFAULT NULL
,p_event_type_code IN VARCHAR2 DEFAULT NULL
,p_event_date IN DATE DEFAULT NULL
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN INTEGER;
This API deletes a row from the XLA_TRANSACTION_ENTITIES table. The routine checks if there are still events associated with the transaction. If yes, the routine does nothing and returns 1; otherwise, it deletes the transaction in the XLA_TRANSACTION_ENTITIES table and returns 0.
There are no validations for this API.
If a transaction is deleted, users must call the DELETE_ENTITY API to delete the row in the XLA_TRANSACTION_ENTITIES table.
Function XLA_EVENTS_PUB_PKG.delete_entity
(p_source_info IN xla_events_pub_pkg.t_event_source_info
,p_valuation_method IN VARCHAR2
,p_security_context IN xla_events_pub_pkg.t_security)
RETURN INTEGER;
This API deletes multiple events. Before calling this API, users must populate the XLA_EVENTS_INT_GT table with the following:
application_id
entity_code
ledger_id
event_id
event_status_code
The API deletes events from the XLA_EVENTS table.
This API validates the application ID, event process category, and event ID. The status of the event to be deleted cannot be processed.
Procedure XLA_EVENTS_PUB_PKG.delete_bulk_events
(p_application_id IN INTEGER);
This topic provides details on the parameters common to many event APIs.
This topic includes information on the following types of parameters:
Transaction identifiers
Contextual information
Transaction security identifiers
Transaction reference information
Event information
The table below describes transaction identifier attributes.
Parameter Name |
Type |
Description |
---|---|---|
p_transaction_number |
Varchar2(240) |
Transaction number of the event-based transaction. This is the user transaction identifier and serves as a reference for the transaction. |
p_event_source_info |
xla_events_pub_pkg.t_event_ source_info |
System transaction identifiers |
The table below describes contextual information details.
Parameter Name |
Type |
Description |
---|---|---|
p_source_application_id |
Integer |
Internal identifier of the application that generates the document or transaction. This may be different from the application that generates and/or owns the accounting for the corresponding event. If no value is provided, the default is p_application_id. Used for Oracle subledgers. This parameter is unlikely to be used for non-Oracle systems. |
p_application_id |
Number |
Application internal identifier. |
p_legal_entity_id |
Number |
Legal entity internal identifier. |
p_ledger_id |
Number |
Ledger internal identifier. |
p_valuation_method |
Varchar2(30) |
Valuation method used for securing a transaction. Some applications secure their transactions by valuation method. Used for Oracle subledgers. This parameter is unlikely to be used for non-Oracle systems. |
The table below describes transaction security identifier attributes.
Parameter Name |
Type |
Description |
---|---|---|
p_security_context |
xla_events_pub_pkg.t_Security |
Security context information for the transaction that has created the events. |
The table below describes transaction reference parameter attributes.
Parameter Name |
Type |
Description |
---|---|---|
p_array_reference_info |
xla_events_pub_pkg.t_array_ event_reference_info |
Array of optional reference information for multiple events. These are stored with the events. |
p_reference_info |
xla_events_pub_pkg.t_event_ reference_info |
Optional reference information for a particular event. |
The table below describes event information parameter attributes.
Parameter Name |
Type |
Description |
---|---|---|
p_entity_type_code |
Varchar2(30) |
Entity type internal code. |
p_event_class_code |
Varchar2(30) |
Event class internal code. |
p_event_type_code |
Varchar2(30) |
Event type internal code |
p_event_id |
Number |
Event internal identifier. |
p_event_date |
Date |
Event accounting date. |
p_event_status_code |
Varchar2(1) |
External status code for an event. |
p_event_number |
Number |
Event sequence number within a transaction. Events are ordered by this sequence number for accounting. |
p_array_entity_source_info |
xla_events_pub_pkg.t_array_ entity_source_info |
Array of transaction source ID information as stamped on the entity. |
p_array_event_type_code |
xla_events_pub_pkg.t_array_ event_type_code |
Array of internal codes for the event type as defined by applications. |
p_array_event_date |
xla_events_pub_pkg.t_array_ event_date |
Array of accounting dates for events. |
p_array_event_status_code |
xla_events_pub_pkg.t_array_ event_status_code |
Array of external status codes for events. |
p_array_event_number |
xla_events_pub_pkg.t_array_ event_number |
Array of event sequence numbers within a transaction. Events are ordered by these sequence numbers for accounting. |
p_array_entity_event_info |
xla_events_pub_pkg.t_array_ entity_event_info |
Array of combined entity and event attributes. |
The following are the predefined PL/SQL data structures available in the XLA_EVENTS_PUB_PKG package.
Transaction Source Information
TYPE t_event_source_info IS RECORD
(source_application_id NUMBER DEFAULT NULL
,application_id NUMBER
,legal_entity_id NUMBER
,ledger_id NUMBER
,entity_type_code VARCHAR2(30)
,transaction_number VARCHAR2(240)
,source_id_int_1 NUMBER
,source_id_int_2 NUMBER
,source_id_int_3 NUMBER
,source_id_int_4 NUMBER
,source_id_char_1 VARCHAR2(30)
,source_id_char_2 VARCHAR2(30)
,source_id_char_3 VARCHAR2(30)
,source_id_char_4 VARCHAR2(30));
The table below provides descriptions on select attributes listed above.
Attribute Table #1
Attribute |
Description |
---|---|
source_application_id |
Internal identifier of the application that generates the document or transaction. This may be different from the application that generates and or owns the accounting for the corresponding event. Source applications do not need to be registered as subledger applications. If no value is provided, the default is application_id. Used for Oracle subledgers. This parameter is unlikely to be used for non-Oracle systems. |
application_id |
Application transaction owner identifier. |
legal_entity_id |
Transaction legal entity identifier. |
ledger_id |
Transaction ledger identifier. |
entity_type_code |
Entity code as defined by applications during setup. |
transaction_number |
Transaction number of the transaction that has created the events. The transaction number serves as a reference for the transaction. |
source_id_xxx_n |
Generic columns that store the identifier for the transaction in the transaction table. |
TYPE t_event_reference_info IS RECORD
(reference_num_1 NUMBER
,reference_num_2 NUMBER
,reference_num_3 NUMBER
,reference_num_4 NUMBER
,reference_char_1 VARCHAR2(240)
,reference_char_2 VARCHAR2(240)
,reference_char_3 VARCHAR2(240)
,reference_char_4 VARCHAR2(240)
,reference_date_1 DATE
,reference_date_2 DATE
,reference_date_3 DATE
,reference_date_4 DATE);
Note
See Attribute Table #2 for descriptions on select attributes.
TYPE t_event_info IS RECORD
(event_id NUMBER
,event_number NUMBER
,event_type_code VARCHAR2(30)
,event_date DATE
,event_status_code VARCHAR2(1)
,process_status_code VARCHAR2(1)
,reference_num_1 NUMBER
,reference_num_2 NUMBER
,reference_num_3 NUMBER
,reference_num_4 NUMBER
,reference_char_1 VARCHAR2(240)
,reference_char_2 VARCHAR2(240)
,reference_char_3 VARCHAR2(240)
,reference_char_4 VARCHAR2(240)
,reference_date_1 DATE
,reference_date_2 DATE
,reference_date_3 DATE
,reference_date_4 DATE);
Note
See Attribute Table #2 for descriptions on select attributes.
The table below provides descriptions on select attributes listed above.
Attribute Table #2
Attribute |
Description |
---|---|
event_type_code |
Code for the event type of the event, as defined during setup. |
event_date |
Event accounting date. |
event_id |
Event internal identifier. |
event_number |
Event sequence number for the event within a transaction. Events are processed in the order of their event number. |
event_status_code |
Status code for the event. This is the event's external status and is used by implementers. |
transaction_number |
Transaction number of the transaction that has created the events. The transaction number serves as a reference for the transaction. |
source_id_xxx_n |
Generic columns that store the identifier for the transaction in the transaction table. |
reference_xxx_n |
Generic columns that store reference information for the event. |
valuation_method |
Valuation method code used as a security context for applications that support the valuation method. Used for Oracle subledgers. This parameter is unlikely to be used for non-Oracle systems. |
security_id_xxx_n |
Security contexts. |
Security context information is optional and restricts a user's access to several features in the Oracle Fusion Accounting Hub. In conjunction with the Fusion Security model, the security context information will determine:
Which events the Create Accounting process will process.
Which events and entries will be visible to the user on the screens and reports.
If used, the securing organization's IDs should be populated in the attributes. As an example, a securing organization can be a business unit or a ledger.
Use the following record structure to pass security context information through event APIs. This structure is defined in XLA_EVENTS_PUB_PKG package.
TYPE t_security IS RECORD
(security_id_int_1 NUMBER
,security_id_int_2 NUMBER
,security_id_int_3 NUMBER
,security_id_char_1 VARCHAR2(30)
,security_id_char_2 VARCHAR2(30)
,security_id_char_3 VARCHAR2(30));
The table below provides descriptions for the attributes listed above.
Attribute Table #3
Attribute |
Description |
---|---|
security_id_int_n |
Security context information in INTEGER type. |
security_id_char_n |
Security context information in VARCHAR type. |
Array of Information based on above Structures
TYPE t_array_event_reference_info IS TABLE OF t_event_reference_info
TYPE t_array_event_info IS TABLE OF t_event_info
TYPE t_array_event_source_info IS TABLE OF t_event_source_info
Other Array Structures
TYPE t_array_event_type IS TABLE OF VARCHAR2(30)
TYPE t_array_event_date IS TABLE OF DATE
TYPE t_array_event_status_code IS TABLE OF VARCHAR2(1)
TYPE t_array_entity_id IS TABLE OF NUMBER
TYPE t_array_event_id IS TABLE OF NUMBER
TYPE t_array_event_number IS TABLE OF NUMBER
The Oracle Fusion Accounting Hub uses predefined accounting event status Constants. These constants are defined in the XLA_EVENTS_PUB_PKG package.
The table below lists event statuses and the corresponding constants that must be used when employing event APIs.
Event Status |
Constant |
---|---|
Incomplete |
XLA_EVENTS_PUB_PKG.C_EVENT_ INCOMPLETE |
Unprocessed |
XLA_EVENTS_PUB_PKG.C_EVENT_ UNPROCESSED |
No Action |
XLA_EVENTS_PUB_PKG.C_EVENT_NOACTION |
Processed |
XLA_EVENTS_PUB_PKG.C_EVENT_PROCESSED |
The Oracle Fusion Accounting Hub enables customers to extend and customize the integration with the Create Accounting process by invoking API calls. The Accounting Hub code structure enables the integration of customized business logic at various stages during the accounting process.
Specifically, you will need to customize the xla_acct_hooks_pkg if you want to add custom logic.
Implementers of the Accounting Hub at the customer site can add logic to these APIs that they want the Create Accounting process to perform at the indicated step.
Preaccounting
Create Accounting extract
Postprocessing
Postaccounting
This section describes the life cycle of the Create Accounting process.
The figure below shows the life cycle of the Create Accounting process.
The preaccounting logic is called at the beginning of the Create Accounting process before selecting accounting events for processing.
Example: This can be used to evaluate a condition to identify transactions for processing.
The extract logic is called for all modes of accounting, final and draft, in batch as well as document mode. It is called after selecting the next set of events to be processed, but before any processing is done. Events selected for processing are made available to custom logic through the global temporary table XLA_EVENTS_GT. Implementers adding code to this API can use it to populate transaction objects based on information in the XLA_EVENTS_GT table.
Example: Use this to populate transaction objects.
The postprocessing logic is called after creating subledger journal entries for each processing unit (commit unit). Custom logic within this API can use the view XLA_POST_ACCTG_EVENTS_V to determine which accounting events were successfully accounted by the Create Accounting process.
Example: Use this to update posted flags on the transaction distributions to indicate whether the transaction was accounted successfully.
The postaccounting logic is called after subledger journal entries are successfully committed in the database.
Examples: Use this to send a notification to a system administrator that the accounting process has completed.
Or, use this to export the supporting reference balances to a third party reconciliation tool for comparison to source system totals to ensure accounting is complete.
The table below describes the view structure.
Column Name |
Null? |
Data Type |
Description |
---|---|---|---|
APPLICATION_ID |
Not Null |
NUMBER(18) |
Internal identifier for the application to which the event belongs |
ENTITY_CODE |
Not Null |
VARCHAR2(30) |
Event entity type code |
ENTITY_ID |
Not Null |
NUMBER(18) |
Internal identifier for the entity representing the actual document |
EVENT_CLASS_CODE |
Not Null |
VARCHAR2(30) |
Event class code |
EVENT_DATE |
Not Null |
DATE |
Event or accounting date for the event |
EVENT_ID |
Not Null |
NUMBER(18) |
Event internal identifier |
EVENT_NUMBER |
Not Null |
NUMBER(18) |
Event number assigned to the event within the document |
EVENT_STATUS_CODE |
Not Null |
VARCHAR2(1) |
Event status code |
EVENT_TYPE_CODE |
Null |
VARCHAR2(30) |
Code for the event type that classifies the event being created |
LEDGER_ID |
Not Null |
NUMBER(18) |
Ledger internal identifier to which event the belongs |
LEGAL_ENTITY_ID |
Null |
NUMBER(18) |
Internal identifier for the legal entity |
PROCESS_STATUS_ CODE |
Not Null |
VARCHAR2(1) |
Event process code |
REFERENCE_NUM_1 |
Null |
NUMBER |
Reference information |
REFERENCE_NUM_2 |
Null |
NUMBER |
Reference information |
REFERENCE_NUM_3 |
Null |
NUMBER |
Reference information |
REFERENCE_NUM_4 |
Null |
NUMBER |
Reference information |
REFERENCE_CHAR_1 |
Null |
VARCHAR2(240) |
Reference information |
REFERENCE_CHAR_2 |
Null |
VARCHAR2(240) |
Reference information |
REFERENCE_CHAR_3 |
Null |
VARCHAR2(240) |
Reference information |
REFERENCE_CHAR_4 |
Null |
VARCHAR2(240) |
Reference information |
REFERENCE_DATE_1 |
Null |
DATE |
Reference information |
REFERENCE_DATE_2 |
Null |
DATE |
Reference information |
REFERENCE_DATE_3 |
Null |
DATE |
Reference information |
REFERENCE_DATE_4 |
Null |
DATE |
Reference information |
SOURCE_ID_INT_1 |
Null |
NUMBER(18) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_INT_2 |
Null |
NUMBER(18) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_INT_3 |
Null |
NUMBER(18) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_INT_4 |
Null |
NUMBER(18) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_CHAR_1 |
Null |
VARCHAR2(30) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_CHAR_2 |
Null |
VARCHAR2(30) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_CHAR_3 |
Null |
VARCHAR2(30) |
Placeholder column that stores internal identifier of the document being represented by the entity |
SOURCE_ID_CHAR_4 |
Null |
VARCHAR2(30) |
Placeholder column that stores internal identifier of the document being represented by the entity |
TRANSACTION_ NUMBER |
Null |
VARCHAR2(240) |
Transaction number given to the document by the products owning the document |
This section describes parameters for the Create Accounting process integration points.
The table below describes the parameters for xla_acct_hooks_pkg.preaccounting().
Parameter Name |
Description |
---|---|
P_APPLICATION_ID |
Application identifier for which the Create Accounting process is submitted. The custom logic checks this parameter first to see if it is the desired application. |
P_LEDGER_ID |
Ledger identifier for which the Create Accounting process is submitted. |
P_PROCESS_CATEGORY |
Process category specified by you when launching the Create Accounting process. |
P_END_DATE |
End date specified by you. |
P_ACCOUNTING_MODE |
Indicates the mode in which the Create Accounting process is submitted. |
P_REPORT_REQUEST_ID |
Request ID of the Create Accounting process submitted. |
P_VALUATION_METHOD |
Valuation method specified by you. Relevant for internal Oracle applications. |
P_SECURITY_ID_INT_1 P_SECURITY_ID_INT_2 P_SECURITY_ID_INT_3 P_SECURITY_ID_CHAR_1 P_SECURITY_ID_CHAR_2 P_SECURITY_ID_CHAR_3 |
Security context values as passed in as a parameter for the Create Accounting process. |
The table below describes the parameters for xla_acct_hooks_pkg.extract().
Parameter Name |
Description |
---|---|
P_APPLICATION_ID |
Application identifier for which the Create Accounting process is submitted. The custom logic checks this parameter first to see if it is the desired application. |
P_ACCOUNTING_MODE |
Indicates the mode in which the Create Accounting process is submitted |
The table that describes the parameters for xla_acct_hooks_pkg.postprocessing() is the same as the table that defines the parameters for extract.
The table that describes the parameters for xla_acct_hooks_pkg.postaccounting() is the same as the table that defines the parameters for preaccounting.
To integrate non-Oracle applications or customizations
with the Oracle Fusion Accounting Hub, you can add logic to the preaccounting,
extract, postprocessing, or postaccounting APIs in the xla_acct_hook_pkg
.
In order to improve the performance, it is recommended that you check the Application ID as the first step in your logic and exit if it does not match.
If the API logic raises an exception, then that exception will abort the Create Accounting process.
If the logic that raises the exception is in preaccounting, then the Create Accounting process will immediately rollback and exit without doing any accounting.
If the logic that raises the exception is in extract or postprocessing, then any accounting done for the current set of transactions will be aborted and rolled back, and the worker will exit. However, other workers may continue processing.
If the logic that raises the exception is in postaccounting, then the Create Accounting process will rollback and exit. However, this will only rollback anything done by the postaccounting logic. It will not rollback any accounting done by the Create Accounting process.
In Oracle Fusion Accounting Hub you can add logic to the postaccounting API to notify you of the status of the Create Accounting process.
Accounting methods group subledger journal entry rule sets together to define a consistent accounting treatment for each of the accounting event classes and accounting event types for all subledger applications. The grouping allows a set of subledger journal entry rule sets to be assigned collectively to a ledger.
For example, a subledger accounting method entitled US GAAP can be defined to group subledger journal entry rule sets that adhere to and comply with US Generally Accepted Accounting Principles (GAAP) criteria.
By assigning a different subledger accounting method to each related ledger, you can create multiple accounting representations of transactions.
Accounting rules can be defined with either a top down, or a bottom up approach. When defining subledger accounting rules from the top down, you will initially define the accounting method followed by components of each rule, which will need to be assigned to it. When defining subledger accounting rules from the bottom up, you will initially define components for each rule and then assign them as required.
The Create Accounting process uses the accounting method definition with active journal entry rule set assignments to create subledger journal entries.
When an accounting method is initially defined, or after modifying a component of any accounting rule associated to the assigned journal entry rule set, its status changes to Incomplete.
The accounting method must be completed, by activating its journal entry rule set assignments, so that it can be used to create accounting.
The following definitions are utilized to define the journal entries, and are applied as updates to the accounting method:
Updates to the predefined accounting method
Assignment of journal entry rule sets for an accounting event class and/or accounting event type from the accounting methods page
Assignment of accounting methods to ledgers
Activation of subledger journal entry rule set assignments
You may update a predefined accounting method by end dating the existing assignment and creating a new assignment with an effective start date.
You create the assignment of a journal entry rule set for an accounting event class and accounting event type using the accounting method page.
The following should be considered for assigning rule sets:
If the accounting method has an assigned chart of accounts, you can select journal entry rule sets that use that same chart of accounts, or that are not associated with any chart of accounts.
Select an option to assign existing journal entry rule sets or define a new one.
If the accounting method has an assigned chart of accounts, it may only be used by ledgers that use the same chart of accounts.
If the accounting method does not have an assigned chart of accounts, the accounting method can be assigned to any ledger.
You can activate the subledger journal entry rule set assignments from the Accounting Method page. You can also submit the Activate Subledger Journal Entry Rule Set Assignments process to validate and activate your accounting setups.
The figure below shows the relationship of components making up an accounting method as described in the above text.
Subledger journal entry rule sets provide the definition for generating a complete journal entry for an accounting event.
Select the option to define the subledger journal entry rule set for a particular accounting event class or accounting event type.
If you are using multiple ledgers to meet divergent and mutually exclusive accounting requirements, you can vary journal entry rule sets by ledger. Each of the subledger journal entry rule sets can meet a specific type of accounting requirements.
For example, use US Generally Accepted Accounting Principles (GAAP) oriented subledger journal entry rule sets for a ledger dedicated to US GAAP reporting, and French statutory accounting conventions for a ledger dedicated to French statutory reporting. These two sets of definitions have differences based on the setup of the various components that make up their subledger journal entry rule sets.
Seeded subledger journal entry rule sets are provided for all Oracle subledgers. If specific requirements are not met by seeded subledger journal entry rule sets, users can create new ones of copy the seeded definitions and then rename and modify the new copied definitions and their assignments.
Subledger journal entry rule set assignments can be made at two levels, header and line. The following are the subcomponents of a subledger journal entry rule set:
Description rules
Journal line rules
Account rules
Supporting references
Header assignments define subledger journal header information and line assignments define journal line accounting treatment.
A header assignment includes the following:
Accounting date (required)
Accrual reversal accounting date (optional)
Description rule (optional)
Supporting references (optional)
You can define multiple subledger journal entry rule sets for an accounting event class or accounting event type. A single journal entry is generated per accounting event per ledger using the line assignments from the journal entry rule set assigned to the accounting event class or accounting event type.
The following can be assigned to a journal entry line:
Journal line description rule
Journal line rule
Account rule
Supporting references
If a description rule is defined with sources, the sources must also be assigned to the accounting event class that is assigned to the journal entry rule set. The description rule may be assigned at either the header or line level of the journal entry or to both levels.
When assigning the journal line rule, you must identify the line type: Gain, Loss, Gain or Loss, Credit, or Debit. The journal line rule must be assigned to the same accounting event class as the one assigned to the subledger journal entry rule set.
When assigning a journal line rule that is enabled for accounting for a business flow, the account combination and certain accounting attribute values are copied from its related journal line having the same business flow class as the current line. Optionally, copy the description rule into the current line instead of assigning a separate description rule.
When assigning a journal line rule that is enabled to copy from the corresponding line within the same journal entry, you have the option to copy the account combination, the segment value, or the line description from the corresponding line into the current line.
The account rule assignment will define which accounts will be used for the subledger journal line. If the account rule is setup with a chart of accounts, it must have the same chart of accounts as the one assigned to the journal entry rule set. When account rules are defined with sources, the sources must also be assigned to the accounting event class that is assigned the journal entry rule set.
There are two types of account rules:
Account Combination Rule: Assign an account combination rule to derive the account combination.
Segment Rule: Assign a segment rule to derive a specific segment of an account. For example, a cost center or a natural account segment.
Supporting references may be assigned at the header or line level of the journal entry to capture transaction values on the journal entry header or lines. If the supporting reference segments are assigned multiple sources, at least one source must also be assigned to the accounting event class that is assigned the journal entry rule set.
Journal line rules are defined within the context of accounting event classes. A journal line rule can be used in a subledger journal entry rule set that has the same event class. You may also assign conditions to the journal line rule.
Journal line rules are assigned to journal entry rule sets.
To create a journal line rule, select values for options such as:
Side (Debit, Credit, Gain or Loss)
For example, when an Oracle Fusion Payables invoice is generated, the liability account should normally be credited. The journal line rule must therefore specify the Side option as Credit. On the other hand, the payment of the Payables invoice must be accounted with a debit to the liability account. A separate journal line rule must be defined to create this debit line.
Merge Matching Lines: To summarize subledger journal entry lines within each subledger entry. Journal entry lines with matching criteria are merged.
Accounting Class
Select an accounting class to classify journal entry lines.
For example, when a validated Payables invoice is accounted, the Item Expense and Liability journal lines are created. In this case, the journal line rules used in the accounting rules are assigned Item Expense and Liability accounting classes respectively.
Conditions: To restrict the use of a journal line rule by controlling when a particular journal line rule is used by the Create Accounting process.
Accounting Attributes: When creating a journal line rule, accounting attribute assignments are automatically established based on the default accounting attribute assignments for that journal line rule's accounting event class. You can override this default mapping of standard sources to accounting attributes. The list of values for the source override includes all sources assigned to the accounting attribute for the event class associated with the journal line rule.
Advanced Options
The Subledger Gain or Less Option: Applies only to amount calculations for the primary ledger. Gain or loss amounts are not converted to reporting currency or non-valuation method secondary ledgers. If the option is selected, the journal line holds the gain or loss amounts calculated by the subledger.
The gain or loss amount is calculated as the difference in applied amounts due to fluctuations in exchange rates based upon conversion to the ledger currency. Foreign exchange gain or loss amounts occur when two related transactions, such as an invoice and its payment, are entered in a currency other than the ledger currency, and the conversion rate fluctuates between the times that the two are accounted.
The Rounding Class Option: Along with the transaction rounding reference group journal lines together and calculates transaction rounding. Subledger transaction rounding differences can occur when a transaction has multiple related applied-to transactions, such as when a Receivables invoice has multiple associated receipts.
The Link Journal Lines Option: Determines whether the journal line rule is set up to establish a link between the accounting of transactions that are related both within the same application, and across applications. The alternatives are described in this table:
Link Journal Lines Option |
Description |
---|---|
None |
No link is established. |
Copy from corresponding line |
Build account for a journal line using segments from the offsetting entry of the current journal line. For example, when the business process requires that a cost center incurring an expense must also bear the invoice liability and cash outlay. |
Business flow |
Link logically related business transactions. For example, when recording the closing of a loan, you can link to the account that was used to book the loan origination. Journal line rules that are linked must also be assigned the same business flow class. |
You may set conditions to specify whether the journal line rule will be used to create a subledger journal entry line. If the conditions are true, the line rule is used to create a subledger journal entry line. Use sources to create these conditions.
For example, you can set up a condition that will create a journal line to record tax, only if there is tax for an invoice. The line type and account class mentioned here are examples of sources.
The condition for a Payables invoice tax journal line rule could be:
Where Line Type = Tax
When this condition is true, there is tax for a payables invoice line. A journal entry line is created to record the accounting impact of the tax.
Similarly, the condition for a Oracle Fusion Receivables invoice tax journal line rule could be:
Where Account Class = Tax
In this case, if there is an account class of Tax, the journal line is used to record the accounting impact of the tax.
Another example is a condition that creates a journal line for freight when there are freight charges on an invoice.
Journal line rule conditions determine whether a journal line rule and its associated account rules and description rules, are used to create the subledger journal entry line.
Note
Constant values that are used in any Conditions region must not contain the following characters:
"
,
&
|
(
)
'
For example, in the condition "Project Type" = ABC (123), the constant value following the equal sign, ABC (123), contains restricted characters ( ) that enclose 123 and is invalid.
Account rules are used to determine the accounts for subledger journal entry lines. In addition, you can specify the conditions under which these rules apply. Using these capabilities, you can develop complex rules for defining accounts under different circumstances to meet your specific requirements. You can define account rules for an account, segment, or value set.
Define account rules by account to determine the entire account combination. For example, an account rule defined by account can be used to determine the complete supplier liability account in Oracle Fusion Payables.
Define segment rules to derive a specific segment of the general ledger account. For example, a particular segment like the company segment can be determined from the distribution account. Another segment can be determined with the use of a constant value. Creating the account one segment at a time offers greater flexibility, but also requires more setup.
Use both segment based and account based rules to derive a single account. Segment specific rules are used, where they are defined, and take the remaining values from an account based rule. For example, you can select an account rule which is for all segments and also separately select a rule which is for one particular segment. Segment specific rules take precedence over the all segments account based rule.
Combine account rules with segment rules. In this case, the segment value is derived from the segment rule to override the corresponding segment of the account. However, if the segment rule has conditions associated with the priorities and none of the conditions are met, no override occurs and therefore, the segment value is derived from the account rule.
Note
If the returned account is end dated with a date that is the same or before the subledger journal entry accounting date and a substitute account is defined in Oracle Fusion General Ledger, a substitute account is used. The original account is stored on the journal line for audit purposes. If the substitute account is invalid, and the Post Invalid Accounts to Suspense Account option is selected in the Create Accounting process, then a suspense account is used. An error message is displayed if a valid suspense account is not available.
In the absence of a chart of accounts, you may define account rules based upon value sets. This enables you to share the same rule between more than one chart of accounts if the segments in these charts of accounts share the same value set.
You may share account rules across applications in the following ways.
Assign an account rule from the same or a different application to a journal line rule in the subledger journal entry rule set. For example, to derive an expense account for journal line rule Expense, assign the Projects Cost Account rule owned by Oracle Fusion Projects to the Payables journal line rule Expense.
Create an account rule based on an account rule from another application and assign it to a journal line rule. For example, you may create a new account rule Invoice Expense Account referencing Project Cost Account assigned in the Priorities region. You may attach the Invoice Expense Account rule to the journal line rule Expense in the journal entry rule set.
Note
To share an account rule across applications, all sources used by the account rule must be available for the event class.
If the sources are available, an account rule is assigned to a journal line rule in the journal entry rule set, and verification occurs to confirm that all sources used by the account rule are available for the journal line rule accounting event class. Journal line rules are only available if the sources are shared; such as reference objects.
Mapping sets can be used to associate a specific output value for an account or segment. You can use mapping sets in account rules to build the account.
In the account rules you may specify conditions for each rule detail line. Priorities determine the order in which account rule conditions are examined. When the condition is met, the rule associated with that priority is used. Depending on which of the defined conditions is met, a different account rule detail is employed to create the account.
The Create Accounting process evaluates conditions based on the priority of the rule detail. When the condition is met, the rule detail is applied.
You can define an account rule using the following rule types:
Account combination
Segment
Value set
Set up account combination rules based upon the following value types:
Source Value Type: Derive the account combination by specifying a source. Sources that have been set up as accounts can be assigned to an account combination rule. Oracle Fusion Subledger Accounting then obtains the code combination identifier from the source.
Constant Value Type: Establish the account as a constant value.
For example, the constant could be a completed account combination from the chart of accounts specified. An example is the account combination, 01.000.2210.0000.000. This is the simplest way to derive an account.
Mapping Set Value Type: Derive the account combination by referencing a mapping set. Set up a mapping set to determine the complete account combination from the chart of accounts specified.
Account Rule Value Type: Derive the account by referencing another account rule.
The chart of accounts does not need to be specified when defining this type of rule. If the account rule has a chart of accounts assigned, then all the related account rules must use the same or no chart of accounts.
Note
A chart of accounts must be specified for rules using constants.
Set up segment rules as follows:
When a chart of accounts is specified, create a rule to derive the value for a specific segment from the chart of accounts.
If the chart of accounts is not specified, create a rule to derive the value for an account segment with a specific qualifier.
Set up segment rules using the same methods discussed in the preceding Account Combination Rules section. By specifying different value types, users can select the way in which the segment value is derived.
Note
A chart of accounts must be specified for rules using constants.
Value set based rules can be created when a chart of accounts is not specified. This enables you to share the same rule between more than one chart of accounts if the segments in these charts of accounts share the same value set.
Set up value set based rules using the same methods discussed in the preceding Account Combination Rules section.
Use descriptions rules to define the elements of a description that appears on the subledger journal entry at the header and/or the line. The definition determines both the content and sequence in which the elements of the description appear. You can assign a condition to a description rule to determine that the description is selected for display if the condition is satisfied.
A description rule can be defined with combinations of source and literal values. If sources are used in the rule, the accounting event class associated with the sources determines in which subledger journal entry rule set the description rule can be selected and used.
Build descriptions using the available sources for the application.
The following is the description details that have been entered, using a literal and a source:
Loan Origination Date = Origination Date
Literal = Loan Origination Date
Source = Origination Date
Assuming that the source value of the Origination Date is 11/01/11, then a journal entry that has the above description rule attached will have the description, Loan Origination Date 11/01/11.
The following illustrates an example of defining an account rule with a condition.
This is an example to define an account rule for assignment for a loan journal line. The account rule has two priorities, a mapping set and a constant.
The first priority will create an output for an account based on the mapping set rule definition.
A condition is created on the first priority rule. This rule will only be used if the condition below is met.
The condition is Credit Status must not be null.
The accounts derived from the mapping set rule will be used if the Credit Status has a valid value. Otherwise, the accounts derived from the entered constants value from the second priority will be used.
The following table describes the setup of the condition on the first priority:
( |
Source |
Operator |
Value |
) |
---|---|---|---|---|
( |
"Credit Status" |
is not null |
|
) |
The second priority will create an output from a constant value (0.9100030.50034206331.0.0.0). There is no condition associated with the second priority.
This is an example of a rule for a capital purchase. The rule is to be applied only if the distribution account cost center is the same as the liability account cost center and the asset tracking option is Yes. This condition can be expressed as:
Where Distribution Cost Center = Liability Cost Center and Asset Tracking option = Yes
The following tables describe the setup of the condition:
( |
Source |
De-limiter |
Segment |
Operator |
Value |
De-limiter |
Segment |
) |
And Or |
---|---|---|---|---|---|---|---|---|---|
( |
"Dis-tribution Account" |
. |
"Cost Center" |
= |
"Liability Account" |
. |
"Cost Center" |
) |
'AND' |
( |
"Asset Flag" |
|
= |
Yes |
|
) |
|
The following two rows of data are used in the accounting event, to which the account rule and condition applies.
Account Rule Condition Example: Accounting Event Data
Account |
Invoice 1 |
Invoice 2 |
Asset Flag |
---|---|---|---|
Distribution Account |
02-640-2210-1234 |
01-780-6120-0000 |
Yes |
Liability Account |
01-640-2210-0000 |
02-782-2210-0000 |
Yes |
In the Accounting Event Data table above, assume the cost center segment is the second segment. When the account rule with this condition is used to derive the account for the transaction, the account rule is applied to derive the account of Invoice 1 only. For Invoice 2, even though the assets tracking option is set to Yes, the cost center for the Distribution account and Liability account are not the same. Both conditions must be met in order for the rule to apply.
Note
When an account source is selected or entered, you must also select or enter a specific segment. If an entire account is required to be used in the condition instead of a specific segment, then select or enter All as the segment for the account.
The condition uses the account source, Distribution Account, and a segment must be provided. In this example, the Cost Center segment is provided.
Supporting references can be used to store additional source information about a subledger journal entry either at the header or line level.
Sources are assigned to supporting reference segments to indicate which transaction values should be captured on subledger journal entries. The segments are grouped into one supporting reference.
Supporting references that have the option for maintain balances set to Yes, establish subledger balances for a particular source and account.
You may want to use Supporting Reference balances for supporting:
Reconciliation back to the source systems
Profit and loss balances by dimensions not captured in the chart of accounts
If the information requirement is purely informational, and not needed for reconciliation or balances, you may consider using description rules to store the source values.
There are several key points to consider when assigning supporting references:
Define a maximum of five segments for a supporting reference. Assign different sources to each segment.
Assign only one source from the same accounting event class and application to a supporting reference segment.
Assign only supporting references with header level sources to the header level of a journal entry rule set.
Assign supporting references with header and line level sources to the line level of a journal entry rule set.
Select the balances option in the definition of the supporting reference, to have balances only maintained when the supporting reference is assigned at the line level. For supporting references for which balances are maintained, you can specify whether the balances at the end of a fiscal year are carried forward to the next fiscal year.
As an example:
A loan information supporting reference can be defined to track two segments:
Credit status
Loan contract number
Sources will be assigned to each of these segments and the source values for each of these segments will be used to create separate balances.
Use the export and import functionality in the Setup and Maintenance work area to perform migration of setup data. When migrating accounting rules, you must migrate task lists in entirety and fulfill some requirements.
This table shows the task lists to migrate in full, depending on the offering.
Offering |
Task List |
---|---|
Oracle Fusion Accounting Hub |
Define Accounting Transformation Configuration |
Oracle Fusion Financials |
Define Subledger Accounting Rules Define Transaction Account Rules |
There is no support for a partial task list migration.
You may migrate setup data for specific applications only. Note that supporting references, accounting options, and accounting class usages are migrated for all applications, regardless of the applications specified.
Prior to migration, journal entry rule sets and accounting methods must be successfully activated. Invalid journal entry rule sets or accounting methods will cause import failure
Ensure that your setup data migration includes all dependent business objects from other required setup modules, such as Define Ledgers. The import sequencing of these dependent business objects must be prior to accounting rules business objects.
Accounting transformations require both function and data security privileges.
Oracle Fusion Accounting Hub security for accounting transformations include:
Setup task security
Security to integrate your external systems with accounting transformations, indicating what types of transactions or activities require accounting from those systems.
Security to configure accounting rules to define accounting treatments for transactions.
Transactional task security
Security to create subledger journal entries (manual subledger journal entries or those generated by the Create Accounting process).
Security to review and generate reports of subledger journal entry headers and lines.
Use the Define Accounting Transformation Configuration task in the Setup and Maintenance work area to integrate your external systems with the Accounting Hub.
To register your external systems and configure accounting rules, the setup user needs to be provisioned with a role that includes the Accounting Hub Administration Duty role.
In the security reference implementation, the Financial Application Administrator job role hierarchy includes the Accounting Hub Administration Duty role, which provides the access to integrate your external systems with accounting transformations.
For more information on available setup job roles, duty roles and privileges, see the Oracle Fusion Accounting Hub Security Reference Manual.
To create and view subledger journal entries, you must have the access necessary to perform the tasks. These tasks can be accessed from the Oracle Fusion General Ledger, Journals work area, therefore you must have access to the work area, and the ledgers (primary, secondary and reporting currency) in which the journal entry is posted.
The following are defined in the security reference implementation:
The General Accounting Manager job role hierarchy includes duty roles that provide entitlement to manage your general accounting functions. This entitlement provides access to General Ledger Journals work area.
The General Accounting Manager data role hierarchy includes data security policies that provide entitlement to access ledger and subledger journal entries.
Ledger access is provided through Data Access Sets.
The following duty roles need to be assigned directly to the General Accounting Manager job role to provide access to create and view subledger journal entries:
Subledger Accounting Duty
Subledger Accounting Reporting Duty
Alternatively, you can assign the Subledger Accounting Duty and Subledger Accounting Reporting Duty roles to any of the following General Ledger job roles:
Chief Financial Officer
Controller
Financial Analyst
General Accountant
The Create Accounting process uses the transaction objects data to create subledger journal entries. For example, if a subledger journal entry rule set specifies that the customer name should appear in the description of a subledger journal entry line, then the customer name value is taken from the customer name source data provided by the transaction objects.
The following figure illustrates the process used to create subledger journal entries.
When transactions are committed in a subledger, accounting events are captured and stored in the subledger accounting events table.
The Create Accounting process identifies all accounting events eligible to be processed. For each of these events, the transaction objects provide the Create Accounting process with the transaction objects data (source information). This is the contextual data of the transaction, such as amounts and accounting dates.
When the Create Accounting process is run, subledger journal entry rule set definitions and transaction objects data are applied to the transaction object data to create subledger journal entries.
These entries are summarized and transferred to Oracle Fusion General Ledger.