Skip Headers

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

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

the picture is described in the document text

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:

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:

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:

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.

the picture is described in the document text

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:

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.

Accounting Event Attributes
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.

Payables Invoice
User Transaction Identifier Description
Supplier Name ABC Supplies
Supplier Number 1234
Invoice Number Z-181723
Invoice Date 10-Jan-2005
Payment
Transaction Identifier Description
Bank Name Wells Fargo
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.

Event Status
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.

Accounting Events Life Cycle

the picture is described in the document text

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:

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:

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:

The third party merge event differs from other accounting events in the following ways:

Third Party Merge Process

The following components make up the third party merge process flow:

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

  2. 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:

  3. Creation of journal entries

    The journal entries are created in one of the following ways:

The Create Accounting for the Third Party Merge program performs the following tasks for third parties:

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:

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.

the picture is described in the document text

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.