Analysis of Accounting Events
Creating Subledger Journal Entries from Accounting Events
Accounting events have financial accounting significance and are used as a basis for the recording of financial information.
It is up to you to decide when an accounting event should be created. Accounting events can be created along with the entry or storage of transactions or their creation can be independent of transaction entry. For example, an import process can import documents first and then create accounting events as a separate step.
Capturing an event indicates that the event has occurred. Once events are captured, users can determine if and how they should be accounted.
See: Overview of the Financial Services Accounting Hub
The diagram below describes how to create subledger journal entries from the accounting events process using Oracle Payables as an example and is explained in the succeeding text.
Creating Subledger Journal Entries from Accounting Events Using Oracle Payables
As illustrated in the above diagram, transactions, such as Payment Issued, Invoice Validated, and Payment Applied, results in the capture of accounting events. When users signal that a transaction is ready to be accounted, the event is eligible for processing. For each eligible event, the accounting transaction objects passes contextual information about the event (source values) to the accounting program.
Financial Services Accounting Hub 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.
The purpose of this chapter is to help identify the accounting events that must be captured. These events result in the creation of subledger journal entries.
Identifying Accounting Events
As a general rule, capture and record as accounting events all situations used to create General Ledger journal entries. The following procedures can assist in the analysis and identification of accounting events:
-
Identify transactions that can impact your financial reports.
Accounting events have financial significance for which financial information (accounting) can be recorded.
-
Identify the life cycle of the transaction and the business events that change the state of the transaction throughout its life cycle.
-
Identify distinct transaction objects data for each accounting event.
This is necessary to record its full accounting implications.
See: Introduction to Transaction Objects
For maximum flexibility, all business events that the transaction model can reliably provide transaction amounts and contextual data necessary to create accounting for should be captured as accounting events. Such an approach allows greater flexibility in the creation of subledger journal entries.
Note: There are special guidelines for handling changes in third party or third party site information for transactions that have already been accounted.
See: Third Party Merge
The following sections provide examples of these procedures for identifying accounting events:
Financial Significance of Accounting Events
Business events continually occur within applications. Most of them have operational significance. These events range from the procurement of material and the hiring of employees to the manufacture of goods and collection of revenues.
Some business events require the recording of financial accounting information and are known as accounting events. The following examples have a financial accounting impact and therefore are accounting events:
-
Applying a receipt to a Receivables line
-
Approving or validating an invoice
Placing a payment hold on a Payables invoice changes the state of an invoice but it does not have a financial accounting impact and therefore, it is not an accounting event.
Not all users account for these events. As an example, consider an invoice in Payables. The invoice-validated event results in accounting if the accounting method is Accrual, but may not result in accounting if the accounting method is Cash Basis.
The capture of an accounting event is therefore completely independent from any subsequent accounting representation. All business events that can have an accounting impact should be captured as accounting events, irrespective of whether the events are eventually accounted.
Identifying the Life Cycle
The state of a transaction can change several times. Consider the following examples:
-
A user selects the Complete option for a Receivables invoice. If the invoice is successfully completed, then its state is changed to completed.
-
A user selects the Retire option for a fixed asset. Once the retirement is complete, the asset state is changed to retired.
-
A user runs the Projects process to distribute the costs of an expenditure batch. After the process has successfully completed, the state of the batch is changed to distributed.
-
A user enters a Payables invoice. The user then approves the invoice, but it goes on hold. The problem is resolved and the invoice is successfully approved. The state of the invoice is changed for both the hold and the approval.
In each of the above cases the state of the transaction is changed by the business event. There is also a corresponding financial accounting impact. As a result, in all the above examples, a case can be made for capturing appropriate accounting events when the transaction is saved.
Ability to Record the Full Accounting Implications of Accounting Events
To enable the creation of subledger journal entries, the data for each accounting event must be identified distinctly from the data for other accounting events. This also preserves an audit trail between the subledger journal entry and the transaction data for the accounting event.
Consider the business event, Invoice Validated. All the relevant information associated with this validation, such as the event date, invoice amount, invoice number, and distribution accounts, is unique. Therefore, the event qualifies as an accounting event. Transaction objects can capture and pass applicable data to the accounting program.
See:
See: Transaction Objects Introduction.
Some transactions can have several accounting events. This is always true if the actions on a document have different event dates. Additionally, each accounting event can be a different accounting event type.
See: Event Type
As an example, consider a user working with a Payables invoice as described in the diagram below.
As the above diagram illustrates, the invoice is validated on 01-Jan-00. On the next day, an event date of 02-Jan-00, the invoice is adjusted. Two days later, 04-Jan-00, the invoice is canceled.
In this scenario, three accounting events, each with a different type, are used to track these actions. For each of these events, it is possible to derive the unique transaction data required to create accounting for the event.
Requirements for Valid Accounting Events
For an accounting event to be valid, ensure that it meets the following requirements:
-
Must have a possible financial impact
-
Must be related to a document or transaction
-
Must contain links to its associated document or transaction
-
Must have a valid status
Accounting Event Attributes
When an accounting event is captured, different event attributes are passed to the Financial Services Accounting Hub.
The table below 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 the accounting program |
| Event Number | Unique event sequence number within a document. The accounting program processes events in the order of their event number. |
| Event Type | For applications or transactions that are based on documents, event types typically correspond to the different operations that can be performed on the documents. For applications or transactions that are nondocument based, an event type corresponds to a particular kind of transaction. |
| Transaction Identifiers | Identifies the document or transaction in the subledger tables and constitute the primary key of the transaction |
| Event Status | Available statuses are Incomplete, Unprocessed, No Action, Processed. |
| Event Date | Date selected for processing. Each accounting event can have only one event date. |
| Transaction Context Values | Legal Entity, Ledger, and Asset Book |
| 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 Financial Services Accounting Hub does not process accounting events on hold due to a gap. |
The Financial Services 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.
See: Seeding Calls to Subledger Event Capture Routines Introduction
The following sections describe selected accounting event parameters in more detail:
Event Type
Event types categorize accounting events. Events with significantly different fiscal or operational implications are classified into different accounting event types. Accounting definitions in the Financial Services Accounting Hub are based on event types. An event type must be unique within an application, entity, and event class.
Transaction Identifiers
Transaction identifiers identify a subledger transaction associated with an accounting event. There are two types of transaction identifiers:
System Transaction Identifiers
System transaction identifiers provide a link between an accounting event and its associated transaction or document. For example, in Oracle Payables, CHECK_ID can link a Payment Issue event to the corresponding check (payment document). Support and technical personnel use these identifiers to trace and resolve errors.
System transaction identifiers constitute the primary key of the underlying subledger transaction. Typically, the identifier is the name of the surrogate key column on the transaction (header) associated with the accounting event. For example, the system transaction identifier for Payables invoices is the INVOICE_ID.
Whenever an accounting event is captured, the values of the system transaction identifiers are stored on the accounting event record along with other event data. Whenever system transaction identifiers are defined for the accounting event's event entity, the event capture mechanism validates that the system transaction identifiers are populated.
See: System Transaction Identifiers Window
User Transaction Identifiers
User transaction identifiers constitute the user-oriented key of the underlying subledger transaction. They are typically drawn from one or more database tables.
These identifiers are primarily used in accounting events inquiry and on accounting reports. Users use these identifiers to uniquely identify underlying transactions.
Example (Oracle Payables): User transaction identifiers for a Payables invoice include its invoice number, invoice date, supplier name, and supplier number.
Example (Oracle Receivables): User transaction identifiers for a Receivables invoice include its transaction type, transaction number, transaction date, customer name, and customer number.
The Financial Services Accounting Hub displays user transaction identifiers on accounting event reports and inquiries by dynamically generating SQL statements based on the definitions of both system and user transaction identifiers.
The following user transaction identifier characteristics are described in this section:
Independent from the Transaction Model
User transaction identifiers enable users to uniquely identify any subledger transaction. The transaction data that identifies a subledger transaction varies by event class. Accounting event reports and inquiries display the transaction identifiers and their labels appropriate for the corresponding event class.
For example, the tables below list the transaction identifiers and their descriptions for an invoice and its corresponding payment. They are in two different event classes.
| User Transaction Identifier | Description |
|---|---|
| Supplier Name | ABC Supplies |
| Supplier Number | 1234 |
| Invoice Number | Z-181723 |
| Invoice Date | 10-Jan-2005 |
| Transaction Identifier | Description |
|---|---|
| Bank Name | <Your Bank> --- Replace <Your Bank> with the name of your bank. |
| Account Number | 4567 |
| Payment Method | Check |
| Payment Number | 45641 |
| Payment Date | 20-Jan-2005 |
Independent from Accounting Event Status
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.
Up to Date
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.
Event Status
The event status is an indicator of what actions have been completed on the transaction and what operations are yet to be done. It is a snapshot of where the transaction is in its accounting event life cycle.
See: Event Status and the Accounting Event Life Cycle
Each event has an event status. The accounting program can make updates to this status. As an example, consider an accounting event that has a status of Unprocessed. Once the accounting program successfully processes the accounting event in final mode, the status of the event is updated to Processed.
See: Draft and Final Accounting
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 the accounting program is run, it does not process accounting events with a status of Incomplete. The subledger application updates this event status. Example: A user enters a Payables invoice, but does not validate it. If an event is captured, it has a status of Incomplete. |
| 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 the accounting program is run, it processes accounting events with a status of unprocessed. This event status is updated by the subledger application based on the transaction status. Example: A user successfully validates a Payables invoice. An accounting event is captured and has a status of Unprocessed. |
| No action | No subledger journal entry is needed for this accounting event. The subledger application updates this event status. Example: Assume an Invoice accounting event is created with the status Unprocessed. If the invoice is canceled on the same GL date, the Invoice accounting event should not be accounted. The event status is set to a status of No Action, since the invoice has no financial accounting impact. |
| 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 cannot 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, the accounting program updates the event status. Example: Consider an Invoice accounting event which has a status Processed. Users cannot change the invoice currency at this point because it affects data potentially associated with an event that has already been accounted. However, you can enter new lines provided the subledger functionality allows such a change. New lines entered are recorded with new accounting events. See: Transactions with Multiple Events |
| Related Event in Error | If an event ends in status Invalid or Error, other events for the same document which are processed and accounted successfully in the same run of the Create Accounting program must be set to status Related Event in Error. |
Event Status and the Accounting Event Life Cycle
Every event has a life cycle. The event status indicates what actions have been completed on a transaction and where the event is in its life cycle. The life cycle is shown in the diagram below.
The above diagram illustrates all the status changes for an accounting event. 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 users complete in subledger application, such as Oracle Projects, Oracle Assets, or Oracle Receivables. 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.
Note that these are all the possible status changes. 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.
Accounting Event Life Cycle Example
The following example of the event life cycle has two parts, both related to the same invoice. However, the events are different in each section. This is due to the following reasons:
-
The invoice is regarded as completed in part one; accounting is created.
-
The adjustment in part two relates to a different event date.
Note that each accounting event can have only one event date.
Note that two accounting events are used if either one of these conditions are true; either the adjustment was for a different date or the invoice was already accounted.
Part 1. Creating and Modifying an Invoice
Accounting Event: Invoice Validated Date: 15-Jun-2005
Step 1. A user enters a purchase invoice. The table below lists the details of this invoice.
| Line # | Amount | Account | Event Date | Accounted |
|---|---|---|---|---|
| 1 | $100 | 01-cc1-expacct1 | 15-Jun-2005 | No |
| 2 | $100 | 01-cc2-expacct1 | 15-Jun-2005 | No |
An event is created upon creation of the invoice header. The distribution lines have the accounting status No. They remain in this status until the invoice is accounted in final mode. The event status is Incomplete.
Step 2. The user validates the invoice. As a result, the event status is updated to Unprocessed.
Step 3. The user adds a new distribution line. The event status is now Incomplete and the invoice must be revalidated.
Step 4. The user revalidates the invoice. As a result, the accounting event status is updated to Unprocessed.
Step 5. The user creates accounting for the accounting event in Final mode. As a result, the accounting and document status are both updated to Processed. The table below lists the details of the invoice. The lines now show a status of Yes for accounted.
| Line # | Amount | Account | Event Date | Accounted |
|---|---|---|---|---|
| 1 | $100 | 01-cc1-expacct1 | 15-Jun-2005 | Yes |
| 2 | $100 | 01-cc3-expacct1 | 15-Jun-2005 | Yes |
| 3 | $200 | 01-cc3-expacct1 | 15-Jun-2005 | Yes |
Part 2: Modifying an Invoice which is Accounted
Accounting Event: Invoice Adjusted Date: 16-Jun-2005
In Part 2, the invoice from Part 1 is modified. Because the invoice has already been accounted and the adjustment is for a different event date, a new accounting event is created to record the adjustment.
Step 1. The user adds a line to the invoice. This addition appears as line 4 in the table below, which lists the details of the invoice.
| Line # | Amount | Account | Event Date | Accounted |
|---|---|---|---|---|
| 1 | $100 | 01-cc1-expacct1 | 15-Jun-2005 | Yes |
| 2 | $100 | 01-cc2-expacct1 | 15-Jun-2005 | Yes |
| 3 | $200 | 01-cc3-expacct1 | 15-Jun-2005 | Yes |
| 4 | $50 | 01-cc4-expacct1 | 16-Jun-2005 | No |
An event is created to account for this adjustment. The event status is Incomplete.
Step 2. The user approves the invoice. As a result, the event status is updated to Unprocessed.
Step 3. The user creates accounting for the invoice. The new line 4 now has a status of Yes for accounted and the event status is updated to Processed. The table below lists the details of the invoice.
| Line # | Amount | Account | GL Date | Accounted |
|---|---|---|---|---|
| 1 | $100 | 01-cc1-expacct1 | 15-Jun-2005 | Yes |
| 2 | $100 | 01-cc2-expacct1 | 15-Jun-2005 | Yes |
| 3 | $200 | 01-cc3-expacct1 | 15-Jun-2005 | Yes |
| 4 | $50 | 01-cc4-expacct1 | 16-Jun-2005 |
Event Date
Each accounting event must have one and only one event date. If multiple GL dates are entered for a document, then one accounting event must be created for each GL date. For example, assume a user enters an invoice with two distributions, each with a different event date. In this case, two accounting events must be created, one for each event date.
As another example, assume a Payables invoice is approved and accounted. On the next event date, it is canceled. This creates two 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 Payables user cancels an invoice before accounting for the Invoice event.
If the event date for the cancellation is the same as that of the accounting event created for the invoice, then the status of the Invoice accounting event is updated to No Action. No accounting event is created for the cancellation.
-
A new accounting event with the same event date as the original invoice now reverses the allocations.
The status of the original Invoice accounting event is set to No Action and no accounting event is created for the reversal.
-
An invoice is canceled after it has been accounted.
The accounting event created for the invoice is not affected by the cancellation. A new event for the cancellation is created and requires processing to create a subledger journal entry.
Transaction Context Values
For the accurate creation of subledger journal entries, an accounting event's transaction context must be passed to the Financial Services Accounting Hub. This context includes the following:
Ledger (mandatory)
A ledger represents a set of accounting information for a legal or management entity. Each ledger is associated with a chart of accounts, calendar, and currency for which accounting information is recorded.
Valuation Method (optional)
In some cases, the rules for how accounting events should be accounted require that they be subject to differing monetary valuations (valuation methods) for different ledgers. The Financial Services Accounting Hub assumes that each subledger transaction and accounting event is for a single valuation method.
See: Valuation Methods and Financial Services Accounting Hub
Legal Entity (optional)
Accounting events inherit the legal entity from the transaction it is associated with. Each transaction entity is stamped with a single legal entity. A single business transaction that crosses a legal entity boundary, such as a cross legal entity payment, results in one accounting event for each legal entity involved in the transaction.
Security Context Values
Security can be enforced if the application implements a security policy. In this case, only accounting events for transactions to which the user has access based on the security policy can be processed by the accounting program. When users submit the accounting program, only accounting events with operating units to which users have access are eligible to be accounted.
For example, if an operating unit secures a subledger's transactions, implementers can implement security so that accounting events inherit the operating unit of the transactions.
Accounting Event Analysis - Additional Notes
This section includes the following:
Accounting Event Order
All events have an associated event type. As noted earlier in this chapter, for transactions that are document-based, event types correspond to the different operations that can be performed on a document. For transactions that are nondocument-based, an event type corresponds to a particular kind of transaction.
See: Event Types
If there is an implied order in the accounting events related to the different event types of a particular document, then implementers are responsible for enforcing that order. For example, an Invoice Validated event should have a lower event number and the same or an earlier event date than Invoice Adjusted events for the same invoice. The Financial Services Accounting Hub is neither aware of, nor does it enforce any implied order.
The accounting program processes accounting events according to criteria specified by users. All events whose dates are equal to or less than the end date specified when the accounting program is submitted are selected for processing.
Example: Implied Order in Oracle Payables
Assume the following three accounting event types for an invoice: Invoice Validated, Invoice Adjusted, and Invoice Canceled.
It should not be possible to generate a subledger journal entry to account for an invoice adjustment before the invoice validated event is processed. Similarly, it should not be possible to adjust the invoice after it has been canceled. Therefore there is an implied order to these event types.
Correctly Enforcing Implied Order
Assume that Payables has four accounting events for a single invoice as described in the table below.
| Event Number | Event Type | Event Date |
|---|---|---|
| 1 | Invoice Validated | August 1, 2005 |
| 2 | Invoice Adjusted | August 15, 2005 |
| 3 | Invoice Adjusted | August 16, 2005 |
| 4 | Invoice Canceled | August 28, 2005 |
In this case, Payables has correctly ordered the accounting events. For example, since event processing is by event number, the Financial Services Accounting Hub does not attempt to account for the adjustment or cancellation of the invoice before the invoice approved accounting event has been processed.
The Invoice Canceled event, must receive an event number greater than the event number of the last Invoice Adjusted event type. Similarly, the Invoice Adjusted events receive event numbers greater than the Invoice Validated event but less than the Invoice Canceled event.
No Implied Order Between Events of the Same Type
In the following example, assume that event number 3 has an earlier date than event number 2 as described in the table below. Note that event number 2 and event number 3 have the same type of Invoice Adjusted.
| Event Number | Event Type | Event Date |
|---|---|---|
| 1 | Invoice Validated | August 1, 2005 |
| 2 | Invoice Adjusted | August 16, 2005 |
| 3 | Invoice Adjusted | August 7, 2005 |
| 4 | Invoice Canceled | August 28, 2005 |
If the user submitted the accounting program with an end date of August 10th, event 1 and then event 3 are processed. Events 2 and 4 remain unprocessed. The latter two events are selected during a later submission of the accounting program with an End date greater than August 28th. Since there is no implied order between the two Invoice Adjusted accounting events, this is acceptable ordering.
If the user submitted the accounting program with a To Date of the August 31st, all events are processed in event number order, with the August 7th adjustment being processed after the August 16th adjustment. Therefore, the order that the events are processed is affected by the To Date when submitting the accounting program.
Not Enforcing the Implied Order, Incorrect Dating of Events
The table below describes this example.
| Event Number | Event Type | Event Date |
|---|---|---|
| 1 | Invoice Validated | August 1, 2005 |
| 2 | Invoice Adjusted | August 15, 2005 |
| 3 | Invoice Adjusted | August 16, 2005 |
| 4 | Invoice Canceled | July 20, 2005 |
In this example, the events are appropriately numbered. If the user specified an end date equal to or later than August 16th, the events would still be processed in the correct order.
However, the events are not appropriately dated. If the user specified an end date less than August 16th, the accounting program would be unaware of the Invoice Adjusted event number 3, and the invoice canceled event on July 20th would be processed before the adjusted event.
In this example, Payables has incorrectly ordered the accounting events using the event dates. It is possible to account for the cancellation of an invoice before the invoice validated accounting event has been processed.
Third Party Merge
Third party merge is a business event that results in the need to update third party information on journal entries or impact third party control account balances. Situations that may require third party updates are described as follows:
-
A company acquires another company
-
Clerical input error
-
A duplicate or erroneous third party is entered into the system
The third party merge event differs from other accounting events in the following ways:
-
It involves many different transactions whereas other accounting events are related to a single transaction entity.
-
It can affect many applications because it is not limited to one subledger.
For example, when two companies merge, all related subledgers are affected, such as Receivables, Payables, and Purchasing. The Financial Services Accounting Hub performs the accounting for all the subledgers involved.
-
The accounting impact of third party merge results in one of the following:
-
Updating third party information on the existing journal entries
-
Transferring the third party control account balance and reversing the journal entries followed by a rebooking of the existing journal entries
-
-
The accounting generated by third party merge is based on existing journal entries and not on transaction data.
Third Party Merge Process
The following components make up the third party merge process flow:
-
Third Party Merge Accounting option
For every ledger and subledger application, users define this accounting option in the Update Accounting Options window in the Accounting Setup Manager.
See: Financial Services Accounting Hub Options Setup Overview, Oracle Subledger Accounting Implementation Guide
-
Creation of the third party merge event
When users record a third party merge operation, the corresponding subledger application calls the Third Party Merge program to create the event. The event is created with the following characteristics:
-
The event is attached to a seeded transaction entity.
-
The event is assigned a hard-coded event type.
-
The old third party and the new third party information is populated in reference columns.
-
-
Creation of journal entries
The journal entries are created in one of the following ways:
-
Synchronously
The third party merge is executed as soon as the event is created if this feature is implemented in the subledger application.
-
Asynchronously
Users submit the Create Accounting for the Third Party Merge program to process the third party merge event.
-
The Create Accounting for the Third Party Merge program performs the following tasks for third parties:
-
Identifies the existing journal entries that are impacted by the third party merge operation
-
Depending on the third party merge accounting option selected, performs one of the following:
-
Updates the third party information in the existing journal entries
-
Transfers the third party control account balance as of the merge date and reverses and rebooks the journal entries after the merge date with the new third party information
For the new journal entries just created, populates the description of the journal entry header and lines with the old and new third party information.
-
-
Maintains a link between the original journal entry and the reversed journal entry
-
Maintains a link between the new journal entries and their corresponding distributions
Audit Trail and Business Event Restrictions
Accounting event parameters enable an audit trail between the subledger journal entry and the transaction data for the accounting event.
Some business events have the potential to invalidate the accounting created by a previous accounting event. These business events should not be supported. Each event and its accounting should be auditable and reportable at a later point in time. As an example, it should not be possible to delete an invoice after the Invoice Validated accounting event is processed in final mode.
Users can change the transaction data if its associated event is unprocessed, but no changes should be allowed after the event is processed. As a general guideline, transactions should not support business events that call for a delete or update of accounting created by other accounting events. The business events should be changed to achieve the same results by reversing accounting created by the previous accounting events.
Draft and Final Accounting
Subledger journal entries can be created in draft or final mode. Both kinds of entries are created using the same accounting definitions, with the difference that it is possible to modify or delete transaction information associated with draft entries. Any changes to the transaction data after accounting in draft mode invalidates the draft journal entries.
In both draft and final mode, if errors are raised in processing of events for a transaction, the accounting program does not endeavor to fully account that transaction. Instead those events are flagged and the program proceeds to the next transaction.
Draft journal entries are purged once the final accounting is created. Also, if there is any change in event status, event date, or event type of an event, then draft journal entries associated with this event are deleted. Draft entries are not transferred to General Ledger.
If you have already created accounting in Final Mode but have not transferred them to GL, and then you run the Create Accounting program again with Transfer to GL option set to Yes, then the application does not pick up events already created in the Final mode. In this case, run the Transfer Journal Entries to General Ledger program.
The table below summarizes the modes of accounting for events.
| Accounting Issue | Draft Mode | Final Mode |
|---|---|---|
| Are journal entries created for the events? | Yes | Yes |
| Are subsequent changes to transaction data permitted? | Yes | No (enforced by the application implementers and not by the Financial Services Accounting Hub) |
Transactions with Multiple Events
Guidelines for creating accounting events for transactions and documents with multiple events are as follows:
-
If a previous event with the same GL date has a status of Unprocessed, merge accounting events within the same document.
There should be at most one accounting event for the same document and same GL date that does not have the status Processed. One accounting event can include the data for multiple transactions. This enables accounting at one time for all transaction changes of the same accounting event type.
As an example, an invoice which has not been accounted and therefore has an accounting event with the status of Unprocessed, is adjusted by adding a new line using the same GL date. The invoice is revalidated. Both the original and new lines must be included on the same accounting event.
-
If the previous events for a document have a status of Processed, a new accounting event should be created.
As an example, consider an invoice which has been previously approved and accounted. The user then cancels the invoice. A new accounting event must be created to record the cancellation.
Valuation Methods and the Financial Services Accounting Hub
In most applications there is one transaction recorded for each underlying accounting event. For example, when an invoice is issued to a customer or received from a supplier, a single invoice transaction is registered in the system. Although there may be many possible interpretations of the financial impact of the accounting event, and therefore many possible accounting representations of it, the underlying event has only one monetary value in the entered currency. Therefore, only one transaction is captured in the corresponding subledger application.
However, in some applications, a single underlying business event can give rise to one or more transactions, each with a different monetary value. For example, a fixed asset can be depreciated and therefore valued according to corporate policies in a corporate book and according to tax rules in one or more tax books. Each of these transactions may require accounting.
In the Financial Services Accounting Hub, each valuation of an underlying accounting event is called a valuation method. A valuation method can be considered to be a method of accounting for events in a particular environment. It is uniquely identified by a valuation method identifier. The Financial Services Accounting Hub supports a different accounting for each valuation.
Oracle E-Business Suite examples: In Oracle Assets, each asset book represents a valuation method. Another example of a valuation method is the costing method used by Oracle Cost Management and OPM.
Valuation Method and Accounting Representations
A ledger's subledger accounting method, accounting currency, calendar, and chart of accounts determine the nature of the accounting representation. Typically, an accounting representation refers to all journal entries that are stored in a ledger.
See: Accounting Representations
Like accounting representations, each valuation method often corresponds to a fiscal or corporate valuation of the underlying accounting events. In Assets, for example, the corporate book is often considered to be the corporate representation and the tax book the fiscal representation.
This aspect of valuation methods has important implications for the Financial Services Accounting Hub because each valuation method is in itself the equivalent of an accounting representation. For example, for an enterprise that has adopted a corporate first accounting standard, the corporate asset book feeds the primary (corporate) ledger and the tax asset book feeds the secondary (fiscal) ledger.
The table below summarizes the differences between standard applications in the Oracle E-Business Suite and those that support multiple valuation methods.
| Standard Application | Valuation Method Application |
|---|---|
| A subledger transaction is associated with the primary ledger only. | A subledger transaction is associated with either the primary ledger or a secondary ledger. |
| One accounting event is created per transaction. Accounting is simultaneously generated in all secondary ledgers. | Multiple transactions are created per business event, one for each valuation method, each of which are accounted. |
The difference between valuation and nonvaluation method applications is that valuation method applications link their representations directly to their respective primary and secondary ledgers. In nonvaluation method applications, the representations are only linked to the primary ledger.
Consider the following example, illustrated in the figure below, to demonstrate the differences between the two approaches.
In the diagram above, the Operations box for a French company shows a valuation method application Assets, which includes Assets Corporate Book, Assets Fiscal Tax Book, and Assets Federal Tax Book. The Ledger box shows the corporate fiscal, local fiscal, and federal accounting representations, ledgers for a French subsidiary of a multinational corporation.
Applications that opt to enable the use of multiple valuation methods also have the flexibility to choose whether to use the valuation method of the primary accounting representation for a secondary accounting representation or an alternate valuation method. For example Assets can choose to create accounting for the fiscal accounting representation based on the corporate book transactions rather than the fiscal tax book transactions. Similarly, Assets can choose to create accounting for the federal accounting representation based on the federal tax book transactions rather than the corporate book transactions.
The diagram above shows that the accounting events for the corporate book create accounting for both the primary (Corporate Accounting Method) and secondary ledger (Fiscal Accounting Method) simultaneously. The accounting events for the Assets Federal Tax Book only create accounting for the secondary ledger (Federal Accounting Method). Note that transactions must not be created for the Assets Fiscal Tax Book because its associated secondary ledger (Fiscal Accounting Method) already receives its accounting from the accounting books of the corporate book.
The Financial Services Accounting Hub creates accounting for the ledger associated with the accounting event. For applications that support multiple valuation methods, the accounting events should be associated with the appropriate primary or secondary ledger. For applications that do not support multiple valuation methods, the associated ledger is always the primary ledger. Accounting is simultaneously created for all the secondary ledgers.