Transaction Objects Analysis

Transaction Objects Overview

For each eligible accounting event, source data from the transactions is stored in transaction objects (tables or views). To successfully complete the processing of accounting events, the Financial Services Accounting Hub selects the source values it needs from these transaction objects.

This chapter provides details on how the Financial Services Accounting Hub uses the transaction object data model to generate accounting.

The figure below provides a high-level overview of the transaction objects process and the Financial Services Accounting Hub. Implementers implementing the uptake of the accounting program are responsible for creating and populating the transaction objects.

Financial Services Accounting Hub Structure and Transaction Objects

the picture is described in the document text

The figure above illustrates the structure of the Financial Services Accounting Hub and its relationship with transaction objects. As shown, the Load Transaction Objects program is called by the accounting program for each accounting event eligible to be accounted. The Load Transaction Objects program populates the source values for the event into the transaction objects.

Transaction objects refer to the tables or views from which the Accounting Program takes the source values to create journal entries. The phrase, "stored in the transaction objects," means that the source values are available as column values in transaction objects to the accounting program. You can create a program to populate columns in transaction objects or use views of your transaction data as the transaction objects. Transaction objects and load programs are created and maintained by subledger applications. The Financial Services Accounting Hub manages the interaction between the transaction objects and the accounting program.

The accounting program performs the following tasks:

The list of accounting events eligible to be processed by the accounting program is stored in the accounting events temporary table (XLA_EVENTS_GT).

See: Accounting Program Workflow Business Events for Non-Oracle Ledgers

The accounting program selects the source values it requires from columns in the transaction objects. Using these source values, the accounting program applies application accounting definitions and ledger setups to process the accounting event and create subledger journal entries.

How Sources Are Used in the Financial Services Accounting Hub

See: Introduction to Events and Sources

Sources defined in the Accounting Methods Builder (AMB) are the basis of all application accounting definitions created by implementers and users. Use sources in setting up the following AMB components:

Account Derivation Rules

Use sources in account derivation rules to determine the Accounting Flexfields used in subledger journal entry lines.

An Accounting Flexfield or segment value stored on a transaction can be used as a source. For example, users can create an account derivation rule that takes the Invoice Distribution Account source from a Payables invoice distribution and use it for an Expense subledger journal entry line.

Mapping Sets

Use mapping sets to derive Accounting Flexfield values from nonaccounting related sources. For example, if a source such as Asset Location is available, a mapping set can be based on it. This mapping could take the following form:

Journal Entry Descriptions

Use sources to determine what information is included in the descriptions of subledger journal entry headers and lines. For example, if a customer name is to be included in the description of a subledger journal entry, then it must be available as a source.

Third Party Control Accounts

Third party control accounts are natural accounts that record a subledger's balance or activity in relation to third parties. In many countries with detailed accounting regulations, legal requirements mandate the creation of views and reports of all subledger transactions and corresponding journal entry lines for a particular customer or supplier. Users can set up third party control accounts for each subledger application. Control account balances from subledger journal entries are maintained for each related third party.

Note: The Financial Services Accounting Hub maintains third party balances for accounts that are flagged as third party control accounts.

See:

Supporting References

Supporting references are used to store additional information about a subledger journal entry either at the header or line level. They can also be used to establish a subledger balance for a particular source and account. Users can decide on the references they would like to use for a journal line type. Users use sources to set up supporting references.

By providing additional business information about the subledger journal entry and balances of an account, supporting references are useful for accounting reconciliation and analysis.

Conditions

Use conditions to determine which of several alternative journal line types, , or descriptions are used to create subledger journal entries.

Consider the following examples for using conditions:

GL Reconciliation Functionality

Specify a source to be used as a reconciliation reference with the GL Reconciliation feature. Reconciliation functionality enables reconciliation of transactions in any account that should balance to zero.

See: Reconciliation Reference Accounting Attribute

Transaction Objects Data Model

This section includes the following parts:

Types of Sources

The Financial Services Accounting Hub classifies sources as follows:

Standard, System, and Custom Sources

Standard Sources

Standard sources are sources defined by the subledger application. They are stored in transaction objects and made available to the accounting program. The definition of what transaction information must be made available as standard sources vary by application and the kind of transaction.

Examples of standard sources for a Payables invoice are Supplier Type and Invoice Number. Examples of standard sources for a Receivables receipt are Bank Account Name and Receipt Number.

System Sources

Subledger accounting defines system sources and they are always available to the accounting program. Therefore, implementers do not need to define system sources or include them in their transaction objects. System sources include the following:

  1. System variables, such as Today's Date or Language

  2. Event and ledger sources

    These values are associated with the accounting event or with the ledgers for which the accounting event is being processed. Event Date is an example of an event source. Ledger Name and GL Period Name are examples of ledger sources.

    See: System Sources Guideline

Custom Sources

Users can use custom sources to extend the pool of sources available to create accounting definitions. Using standard and system source values as parameters, users can write PL/SQL functions that define custom sources.

See: Custom Sources, Oracle Subledger Accounting Implementation Guide

Untranslated and Translated Sources

Translated Sources

Some sources can be translated into more than one language. The translation can be created by users using Oracle MLS features or created as part of the seed data.

An example of a user-created translated source for the Costing module is Inventory Item Name. Inventory Item Name can be translated using MLS features.

An example of a seeded translated source for Receivables is Term Name. Payment Terms, such as Immediate, are delivered as seed data.

Note: The Financial Services Accounting Hub offers features that help limit the number of values that are defined as translated sources.

See: Translated Sources, Lookup Types and Value Sets Guideline

Untranslated Sources

Untranslated sources are source values that are never translated into more than one language. Examples of untranslated sources include all numbers, dates, and lookup codes.

Header and Line Sources

Header 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 Payables invoice is Invoice Supplier Name. An invoice can have only one supplier name. This name is created at the header level and does not vary by line. Examples of header sources for a Receivables receipt application include Receipt Customer Name and Receipt Number. These sources have the same value for all related transaction lines.

Line Sources

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.

Examples of line sources for a Payables invoice include Invoice Line Tax Code and Invoice Distribution Expense Account. Examples of line sources for a Receivables receipt application are Receipt Applied to Transaction Number and Receipt Currency Code.

Transaction Objects

In addition to establishing what transaction attributes are available to the accounting program as sources, implementers determine which type of transaction objects object is appropriate to store them.

The Financial Services Accounting Hub supports the following types of transaction objects to store source values:

The name and number of transaction objects and their associated columns, with the exception of the primary keys, are determined by implementers. The relationships between different types of transaction objects and the primary key for each transaction object type are shown in the figure below and described in the Transaction Objects Types section.

Relationships Between Different Types of Transaction Objects

the picture is described in the document text

Transaction Objects and Event Classes

In the AMB, transaction objects are assigned to event classes. The list of source values available to the accounting program and therefore to users for inclusion in application accounting definitions can vary by event class. However, this does not mean that implementers need to create new transaction objects for each event class as a transaction object can be assigned to more than one event class.

Transaction Objects Types

This section describes the following transaction objects:

Header Transaction Objects

Implementers need to provide at least one header transaction object for each 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 Invoice Number for an invoice or the Bank Account Number for a receipt.

Header Multi-Language Support (MLS) Transaction Objects

Header MLS transaction objects are relevant to applications that support the Oracle E-Business Suite MLS feature. Header MLS transaction objects store translated header level 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.

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 Payment Terms for a Payables invoice.

Implementers can avoid having to store source values in header MLS transaction objects by using value sets and lookup types.

See: Translated Sources, Lookup Types, and Value Sets Guideline

Line Transaction Objects

Line transaction objects are relevant to transaction types that can have more than a single line or distribution.

Line transaction objects store untranslated line level standard 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 Invoice Number for a payment or the Invoice Line System Item for an invoice.

Line Multi-Language Support (MLS) Transaction Objects

Line MLS transaction objects are relevant to applications that support the Oracle Applications MLS feature. Line MLS transaction objects store translated line level standard source values. There should be one row per transaction distribution and language. The primary key of a Line MLS transaction objects is the event identifier, transaction object line number, and language.

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.

Transaction Object Columns

The transaction object columns must be one of the following:

Primary Key Columns

The appropriate primary key columns must be defined in all transaction objects. The table below lists the primary key column definitions.

Header Transaction Objects
Column Name Description Data Type Comment
EVENT_ID Event identifier Integer There should be one row per event.
Line Transaction Objects
Column Name Description Data Type Comment
EVENT_ID Event identifier Integer  
LINE_NUMBER Transaction objects line number Integer Unique within the event identifier (ID)
Header MLS Transaction Objects
Column Name Description Data Type Comment
EVENT_ID Event identifier Integer  
LANGUAGE Language code Varchar(30) Corresponds to the language column in _TL tables
Line MLS Transaction Objects
Column Name Description Data Type Comment
EVENT_ID Event identifier Integer  
LINE_NUMBER Transaction objects line number Integer  
LANGUAGE Language code Varchar(30) Corresponds to the language column in _TL tables

If a transaction object is implemented as a persistent or temporary table, the Financial Services Accounting Hub recommends creating a unique index that contains the primary key columns. For example, all line transaction objects should have a unique index on the event_id and line_number columns.

The accounting program uses the transaction objects primary keys to join transaction objects when selecting source values. As such, the line number primary key value should be consistent across line and MLS line transaction objects rows. Conversely, rows from both types of transaction objects with the same value for event_id and line_number should store source values that correspond to the same underlying transaction line or distribution.

Standard Source Columns

The majority of the columns in transaction objects are used to store standard sources. Transaction objects column names correspond to the AMB source codes.

Source codes and names should be unique across transaction and reference objects for an event class if they do not represent the same transaction attribute and there is the likelihood that they may have different values. For example, when transaction object 1 and transaction object 2 both have ENABLED_FLAG columns, the Create and Assign Sources program creates a single source for ENABLED_FLAG. When the values of these columns for the two transaction objects are different, the extract may return incorrect values. In this case, the objects need to have unique column names.

The data type of the transaction object columns corresponds to source data types as shown in the table below.

Transaction Object Column and Source Data Type Correspondence
Transaction Object Column Data Type Source Data Type
Number Number
Date Date
Varchar2 Alphanumeric
Char Alphanumeric

The Financial Services Accounting Hub does not support the following data types in transaction objects and are ignored by the Create and Assign Sources program:

See: Create Sources and Assignments

Multiple Transaction Objects of the Same Type

For a single event class, the Financial Services Accounting Hub supports multiple objects of each type. There are several reasons why implementers may wish to define multiple transaction objects of the same type for a single event class:

Population of Transaction Objects

Not all transaction objects need to return rows for all transaction object headers and lines.

Always Populated Check Box

When a transaction object is assigned to an event class, define whether it is always populated.

See: To Set Up Accounting Event Class Options

The following additional rules apply to the Always Populated check box:

Transaction Objects Return No Rows

If a header or line level transaction object returns no rows for a transaction or transaction distribution respectively and it is marked as Always Populated, the accounting program returns an error.

Reference Objects

Use reference objects to define transaction objects without having SLA primary keys. To enable you to define relationships between reference objects, you can define up to two levels of reference objects, primary and secondary. The following steps describe how to define, maintain, and use reference objects.

  1. In the Accounting Event Class Options window, define reference objects and define relationships between reference objects and transaction objects.

  2. Run the Create and Assign sources program which completes the following tasks:

    • Creates sources for the application owning the reference object

    • Assigns source from a reference object to the event class to which the reference object is assigned

    Use reference objects to share sources across applications. For example, Payables implementers can assign sources from Oracle Projects to Payables event classes.

See: Create and Assign Sources Introduction

Create Sources and Assignments

Having created transaction objects and assigned them to event classes, run the Create and Assign Sources program. Based on the transaction objects definitions and corresponding database data dictionary definitions, the Create and Assign Sources program:

See: Create and Assign Sources Program

Transaction Objects Guidelines

For each eligible accounting event, source data from the transactions must be stored in transaction objects. The accounting program selects the source values it requires from these transaction objects to create subledger journal entries.

This section provides guidelines to help determine what transaction data should be stored in the transaction objects.

Introduction to Transaction Objects Guidelines

Source values are stored in transaction objects. The accounting program uses these source values and the application accounting definitions in the AMB to create subledger journal entries.

When determining what transaction object information should be defined as sources, consider including all relevant data that can potentially be used for creating application accounting definitions. This includes data from your application as well as related applications. In general, all transaction data that users may find useful to create subledger journal entries should be made available as sources.

In analyzing the sources that should be made available to the accounting program, a good place to start is with the values referenced by the current programs used to create accounting. Values that determine how transactions are accounted prior to the uptake are used as sources that determine how the same types of transactions are accounted by the Financial Services Accounting Hub.

In many subledgers, transaction data is captured in a header and distribution lines format. As this data is the primary origin of information in the transaction, all of it should be made available as sources. While the header consists of information which is constant for the transaction, distribution data varies by line.

Summary Listing of Guidelines

When implementing the uptake of the Financial Services Accounting Hub consider the following guidelines when deciding on the sources to store in the transaction objects:

  1. Accounting Attributes Guideline

    Accounting attributes values are needed by the accounting program to successfully create subledger journal entries.

  2. Distribution Identifiers Guideline

    Distribution identifiers should be stored in the transaction object as accounting attributes.

  3. Multiperiod Accounting Guideline

    To invoke multiperiod accounting for a transaction distribution, the transaction object should populate multiperiod accounting attributes with the appropriate values.

  4. Monetary Amounts Guideline

    For any given accounting event, the sum of the monetary amounts stored in the transaction object should represent the total value of the underlying transaction in the subledger.

  5. Gains and Losses Guideline

    The transaction object should not include explicit gain or loss transaction object lines. Instead, each transaction object line should include the ledger currency amounts and rate information for all related transactions for which gain or loss subledger journal lines are generated.

  6. Foreign Currency Amounts Guideline

    Appropriate currency and rate information should be stored in the transaction object.

  7. Reporting Currency Amounts Guideline

    For each transaction object line, the reporting currency amounts and associated rate information for all primary and secondary ledgers, as well as for all reporting currencies, should be stored in the transaction objects.

  8. Corrections for Rounding Guideline

    The accounting program detects rounding differences and accounts for them. Therefore, you do not need to include rounding distributions in the transaction objects.

  9. Related Transactions, Lines, and Distributions Guideline

    The data from related transactions should be made available as sources. These transactions include applied to transactions, matched with transactions, and created from transactions. As an example, a Payables invoice line may require transactional information from the original purchase order.

  10. Independence from Accounting Method Guideline

    The transaction object should be insensitive to the application accounting definitions that determine how transactions are accounted.

  11. Balanced Debits and Credits Guideline

    Balanced debits and credits should not be included in the transaction object.

  12. Granularity of Transaction Objects Lines Guideline

    For any transaction, the maximum level of detail should be stored in the transaction object and made available to the accounting program.

  13. Third Party Control Accounts Guideline

    Third party data should be stored in the transaction object as accounting attributes.

  14. Translated Sources, Lookup Types, and Value Sets Guideline

    The transaction object should store a translated source in each installed language used by ledgers linked to the accounting event's primary ledger.

  15. Consistency Guideline

    Ensure that sources stored in the transaction object are stored in a consistent manner across different types of transactions.

  16. Tax References Guideline

    The transaction object should store tax references as accounting attributes. The Accounting Program uses tax references to establish a link between information stored in the tax repository and subledger journal entries.

  17. Flexfields Guideline

    The transaction object should store flexfield column values as sources if they can be used in creating subledger journal entries.

  18. Accounting Flexfield Derivation Mechanisms Guideline

    All values used to derive accounts prior to the uptake of the Financial Services Accounting Hub should be made available as sources.

  19. Accounting Options Guideline

    Existing setup accounting options should be stored in the transaction object as sources.

  20. Internal Identifiers Guideline

    In general, values that are never displayed to users should not be stored in the transaction object.

  21. System Sources Guideline

    System sources are independently populated by the accounting program. They are not stored in the transaction object.

  22. Accounting Reversals Guideline

    To invoke an accounting reversal for a transaction header or distribution, the transaction object should populate the appropriate header or line level accounting reversal options.

Accounting Attributes Guideline

The accounting program uses accounting attributes values to create subledger journal entries. The types of accounting attributes values are as follows:

Each accounting attribute is associated with a level:

The accounting attribute level should not be confused with the transaction object type. The accounting attribute level refers to the way in which the accounting program uses accounting attribute values to generate journal entries. The transaction object type refers to the kind of transaction object that is used to store the source values.

Accounting Attribute Assignments

The accounting program derives the values of accounting attributes by looking at the sources that are assigned to them. Almost all accounting attributes have sources assigned at the event class level. Depending on the accounting attribute, the accounting attribute assignment defaulted from the event class can be overridden on journal line types or application accounting definitions.

Event Classes

Assign sources to accounting attributes in the Accounting Attributes Assignments window. If the default assignment for an accounting attribute can be overridden on journal line types or application accounting definitions, assign one or more sources to the accounting attribute at the event class level. Designate one of the sources as the default.

If the source assigned to an accounting attribute cannot be overridden on journal line types or application accounting definitions, assign only one source to the accounting attribute at the event class level. In this case, the accounting attribute is not displayed in the Journal Line Types window or the Application Accounting Definitions window.

Journal Line Types

Assign sources to accounting attributes in the Journal Line Types window. The source assigned to an accounting attribute on a journal line type determines how the value of the accounting attribute is derived for all journal lines generated by the Financial Services Accounting Hub using that journal line type.

Journal line type accounting attributes are used in one of the following cases:

Application Accounting Definitions

For each event class or event type, assign sources to accounting attributes in the Application Accounting Definitions window. The source assigned to an accounting attribute for an application accounting definition determines how the value of the accounting attribute is derived for all journal headers generated by the Financial Services Accounting Hub for events belonging to the event class or event type.

Use application accounting definition accounting attribute assignments when the accounting attribute value can be derived from one of many sources depending on accounting policies. For example, the accounting attribute GL Date for payment clear transactions can be derived from either the Event Date system source, the Clearance Date, or the Value Date standard sources.

Implementers and users can define application accounting definition accounting attribute assignments.

Accounting Attribute Levels and Transaction Object Types

The table below describes the relationships between transaction objects and accounting attribute levels.

Relationships Between Transaction Objects and Accounting Attribute Levels
Transaction Object Type Accounting Attribute Level Permitted Comment
Header or MLS Header Header Yes Sources defined in header or MLS header transaction objects can be used for journal entry header processing. For example, the standard source assigned to the accounting attribute Document Category Code can be defined in a header transaction object.
Header or MLS Header Line Yes Sources defined in header or MLS header transaction objects can be used for journal entry line processing. For example, the standard sources assigned to the accounting attribute Entered Currency Code can be defined in a header transaction object.
Line or MLS Line Header No Sources defined in line or MLS line transaction objects cannot be used for journal entry header processing. For example, the standard source assigned to the accounting attribute Document Category Code cannot be defined in a line transaction object.
Line or MLS Line Line Yes Sources defined in line or MLS line transaction objects can be used for journal entry line processing. For example, the standard sources assigned to the accounting attribute Entered Amount can be defined in a line transaction object.

Accounting Attributes

Accounting attributes are presented in functional groupings in table format. The table below describes the columns used in the tables.

Accounting Attributes Column Descriptions
Column Name Description
Name Displayed to implementers and users when creating accounting attribute assignments
Data Type Only sources that have a compatible data type can be assigned to an accounting attribute.
Journal Entry Level The accounting attribute level is header or line.
Accounting Method Builder Components Accounting attributes can be assigned to sources for event classes, journal line types, or application accounting definitions.
Assignment Rules Some accounting attributes must always be assigned to sources. Others must be assigned only if necessary to invoke a Financial Services Accounting Hub feature.
Optional or Mandatory Assigning a source to an accounting attribute does not mean that the corresponding transaction object columns should necessarily have a value. Some accounting attributes are mandatory. Others are mandatory only if the corresponding subledger transaction values are populated.
Validation Rules If populated, some sources assigned to accounting attributes are subject to special validation.

Entered Currency Accounting Attributes

The table below describes accounting attributes for entered currency.

Entered Currency Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Currency Code Alphanumeric Line Event class and journal line type Must be assigned Mandatory Must be a valid currency code
Entered Amount Number Line Event class and journal line type Must be assigned Mandatory  

Entered currency accounting attributes are relevant to all applications that use the Financial Services Accounting Hub. The accounting program 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, more than one event class accounting attribute assignment is created.

Receivables Example: For the receipt application event class, the standard sources Invoice Currency Code and Receipt Currency Code are assigned to the accounting attribute Currency Code and one of them is designated the default accounting attribute assignment. Users choose which standard source to use depending on the journal line type.

See:

Ledger Currency Accounting Attributes

The table below describes accounting attributes for ledger currency.

Ledger Currency Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Conversion Rate Type Alphanumeric Line Event class and journal line type Should be assigned Optional Should be a valid General Ledger conversion rate type or User
Conversion Date Date Line Event class and journal line type Should be assigned Mandatory if the conversion rate type is not User  
Conversion Rate Number Line Event class and journal line type Should be assigned Mandatory if the conversion rate type is User  
Accounted Amount Number Line Event class and journal line type Must be assigned if the Financial Services Accounting Hub does not calculate accounted amounts Mandatory if the Financial Services Accounting Hub does not calculate accounted amounts  

Ledger currency accounting attributes are relevant to all applications that use the accounting program. The accounting program uses them to populate journal entry accounted amounts.

If a transaction's entered currency is different from the ledger currency, the accounting program 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 accounting program 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, more than one event class accounting attribute assignment is created.

Receivables Example: For the receipts and receipt application event class, the standard sources Invoice Accounted Amount and Receipt Accounted Amount are assigned to the accounting attribute Accounted Amount and one of them is designated the default accounting attribute assignment. Users choose which standard source to use depending on the journal line type.

Payables Example: For a payment clear event class, the standard sources Invoice Exchange Rate, Payment Exchange Rate, and Clear Exchange Rate are assigned to the accounting attribute Conversion Rate and one of them is designated the default accounting attribute assignment. Users choose which standard source to use depending on the journal line type.

See:

Gain/Loss Accounting Attributes

The table below describes gain/loss accounting attributes.

Gain/Loss Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Component Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Exchange Gain Account Number Header Event class and application accounting definition Must be assigned if there is exchange gain on the transaction but no gain/loss journal line type is assigned to the journal line definition. Optional  
Exchange Loss Account Number Header Event class and application accounting definition Must be assigned if there is exchange loss on the transaction but no gain/loss journal line type is assigned to the journal line definition. Optional  
Gain or Loss Reference   Line Event class Must have same value for each set of debit and credit lines. Required only if debit and credit side entries are passed to the Financial Services Accounting Hub as separate transaction object lines and there is exchange/gain loss on the transaction.  

When the Financial Services Accounting Hub calculates gain/loss amount, if no gain/loss journal line type is defined then the Exchange Gain/Loss accounts are used.

The Gain/Loss Reference accounting attribute groups entry lines together when calculating gain/loss. The Financial Services Accounting Hub combines the accounted debit and accounted credit amounts for lines with the same gain/loss reference and compares the total of accounted debit and total of accounted credit to calculate the exchange gain/loss.

Distribution Identifier Accounting Attributes

The table below describes distribution identifier accounting attributes.

Distribution Identifier Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Distribution Type Alphanumeric Line Event class Must be assigned Mandatory  
First Distribution Identifier Alphanumeric Line Event class Must be assigned Mandatory  
Second Distribution Identifier Alphanumeric Line Event class Optional Optional  
Third Distribution Identifier Alphanumeric Line Event class Should not be assigned if second distribution identifier is not assigned Optional  
Fourth Distribution Identifier Alphanumeric Line Event class Should not be assigned if third distribution identifier is not assigned Optional  
Fifth Distribution Identifier Alphanumeric Line Event class Should not be assigned if fourth distribution identifier is not assigned Optional  

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 Financial Services Accounting Hub 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 combination of the values of the system transaction identifiers with the values of the distribution identifiers uniquely identify a subledger transaction distribution line.

See: Distribution Identifiers Guideline

Line Accounting Reversal Accounting Attributes

The table below describes line accounting reversal accounting attributes.

Line Accounting Reversal Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Accounting Reversal Indicator Alphanumeric Line Event class Should be assigned if another line accounting reversal accounting attribute is assigned Optional Should be:
Y – reversal transaction object line
B – reversal and standard transaction object line
N or null – standard transaction object line
Accounting Reversal Distribution Type Alphanumeric Line Event class Should be assigned if another line accounting reversal accounting attribute is assigned Mandatory if the accounting reversal indicator is populated  
Accounting Reversal First Distribution Identifier Alphanumeric Line Event class Should be assigned if another line accounting reversal accounting attribute is assigned Mandatory if the accounting reversal indicator is populated  
Accounting Reversal Second Distribution Identifier Alphanumeric Line Event class Should not be assigned if reversal first distribution identifier is not assigned Mandatory if the corresponding second distribution identifier is populated  
Accounting Reversal Third Distribution Identifier Alphanumeric Line Event class Should not be assigned if reversal second distribution identifier is not assigned Mandatory if the corresponding third distribution identifier is populated  
Accounting Reversal Fourth Distribution Identifier Alphanumeric Line Event class Should not be assigned if reversal third distribution identifier is not assigned Mandatory if the corresponding fourth distribution identifier is populated  
Accounting Reversal Fifth Distribution Identifier Alphanumeric Line Event class Should not be assigned if reversal fourth distribution identifier is not assigned Mandatory if the corresponding fifth distribution identifier is populated  

Line accounting reversal accounting attributes are relevant to applications that wish to take advantage of the accounting reversal feature. The accounting program uses them to identify transaction (distributions) whose accounting impact should be reversed.

For the accounting program 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.

See: Accounting Reversals Guideline

Transaction Accounting Reversal Accounting Attributes

The table below describes transaction accounting reversal accounting attributes.

Transaction Accounting Reversal Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Transaction Accounting Reversal Indicator Alphanumeric Header Event class Optional Optional Should be:
Y – reversal transaction object header
N or null – standard transaction object header

The transaction accounting reversal accounting attribute is relevant to applications that wish to take advantage of transaction level accounting reversals feature. The accounting program uses them to invoke the reversal of all accounting generated for the transaction associated with the accounting event.

For the accounting program to successfully create a transaction accounting reversal, the accounting reversal indicator should be assigned to a source.

See: Accounting Reversals Guideline

GL Date Accounting Attributes

The table below describes GL date accounting attributes.

GL Date Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
GL Date Date Header Event class and application accounting definition Must be assigned Mandatory Should be in open GL period
Accrual Reversal GL Date Date Header Event class and application accounting definition Optional Optional Should be later than the GL date

The GL Date accounting attribute is relevant to all applications. The accounting program uses it to derive the GL date of journal entries. Normally, the event date system source is the only source assigned to the GL Date accounting attribute.

The Accrual Reversal GL Date accounting attribute is relevant to applications using the accrual reversal feature.

Users can assign system and any standard date source to the Accrual Reversal GL Date in the Accounting Attribute Assignments window. The system sources are as follows:

When the accrual reversal GL date accounting attribute returns a value, the Create Accounting program generates an entry that reverses the accrual entry.

See: Accounting Reversals Guideline

Third Party Accounting Attributes

The table below describes third party accounting attributes.

Third Party Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Party Type Alphanumeric Line Event class Should be assigned if another third party accounting attribute is assigned Mandatory if the party identifier is populated Should be C for customer or S for supplier
Party Identifier Number Line Event class and journal line type Should be assigned if another third party accounting attribute is assigned Mandatory if the party type is populated If party type is 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 type Should be assigned if another third party accounting attribute is assigned Should not be populated unless the party type and party identifier are populated. If party type is C, should be a valid customer account; if party type is S, should be a valid supplier site

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.

Some types of transactions involve more than one third party. For these types of transactions, more than one event class accounting attribute assignment is necessary to support the accounting for third party control accounts.

Receivables Example: Since a receipt and the invoices that it is applied to can have different customers or customer sites, the Bill To Customer Account Identifier and Pay to Customer Account Identifier are both defined as standard sources and assigned to the third party accounting attribute Party Identifier in the Journal Line Accounting Attribute Assignments window. One of them is designated the default accounting attribute assignment. Users choose which standard source to use depending on the journal line type.

See:

Statistical Amount Accounting Attribute

The table below describes the statistical amount accounting attribute.

Statistical Amount Accounting Attribute
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Statistical Amount Number Line Event class and journal line type Optional Optional  

The statistical amount is relevant to applications that currently pass statistical amounts to General Ledger. It is stored on subledger journal entry lines and subsequently passed to General Ledger for statistical analysis.

Tax References Accounting Attributes

The table below describes tax references accounting attributes.

Tax References Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Detail Tax Line Reference Number Line Event class and journal line type Optional Optional  
Detail Tax Distribution Reference Number Line Event class and journal line type Optional Optional  
Summary Tax Line Reference Number Line Event class and journal line type Optional Optional  

The tax reference accounting attributes are relevant to applications that uptake the tax initiative. The tax team uses the tax reference accounting attributes to link subledger transaction tax distributions to their corresponding journal entry lines.

The Oracle E-Business Tax development team specifies which tax reference values are mandatory in transaction objects and should be assigned to standard sources.

See: Tax References Guideline

Reconciliation Reference Accounting Attribute

The table below describes the reconciliation reference accounting attribute.

Reconciliation Reference Accounting Attribute
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Reconciliation Reference Alphanumeric Line Journal line type Optional Optional  

The reconciliation reference is relevant to all applications. However, since users have full control over which sources are used as the reconciliation reference, it is not necessary to assign a source to the accounting attribute at the event class level. The reconciliation reference is displayed only on journal line types. When users create journal line types, they can assign any of the sources assigned to the event class to the reconciliation reference.

The reconciliation reference is stored on subledger journal entry lines and subsequently passed to General Ledger for use in the journal entry reconciliation feature. 

Budgetary Control Accounting Attributes

The table below describes budgetary control accounting attributes.

Budgetary Control Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Budget Version Identifier Number Header Event class Should be assigned for event classes that support budgets Mandatory for events with budgetary amounts Should be a valid General Ledger budget identifier

The budget version identifier is relevant to applications that support budgetary journals.

To assign the budget version identifier to a standard source and create budget journal line types, the event class must be enabled for budget entries. For the accounting program to successfully create budget journals, there must be a valid budget version identifier.

See: Allocation Accounting Attributes

Document Sequencing Accounting Attributes

The table below describes document sequence accounting attributes.

Document Sequence Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Document Sequence Category Code Alphanumeric Header Event Class Should be assigned if another document sequence accounting attribute is assigned Mandatory if document sequence value is populated Should be a valid sequence category
Document Sequence Identifier Number Header Event class Should be assigned if another document sequence accounting attribute is assigned Mandatory if document sequence value is populated Should be a valid document sequence identifier
Document Sequence Value Number Header Event class Should be assigned if another document sequence accounting attribute is assigned Mandatory if document sequence version identifier is populated  

The document sequence accounting attributes are relevant to applications that use the Application Object Library document sequencing feature to assign sequence numbers to subledger transactions. The accounting program 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.

Either none of the document sequence accounting attributes should be assigned to standard sources or all document sequence accounting attributes should be assigned to standard sources.

Multiperiod Accounting Attributes

The table below describes multiperiod accounting attributes.

Multiperiod Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Multiperiod Option Alphanumeric Line Event class Should be assigned if another multiperiod accounting attribute is assigned Optional Should be Y for yes or N for no
Multiperiod Start Date Date Line Event class Should be assigned if another multiperiod accounting attribute is assigned Mandatory if multiperiod option is populated  
Multiperiod End Date Date Line Event class Should be assigned if another multiperiod accounting attribute is assigned Mandatory if multiperiod period type is not populated  

The multiperiod accounting attributes are relevant to applications providing the multiperiod accounting feature to their customers.

Either no multiperiod accounting attributes should be assigned to sources or all multiperiod accounting attributes should be assigned to sources.

See: Multiperiod Accounting Guideline

Transfer to GL Accounting Attribute

The table below describes the Transfer to GL accounting attribute.

Transfer to GL Accounting Attribute
Name Data Type Journal Entry Level Accounting Method Builder Components Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Transfer to GL Indicator Alphanumeric Header Event class Optional Optional Should be Y or N

The transfer to GL accounting attribute is relevant only to applications that wish to generate historical journal entries using the Financial Services Accounting Hub. The Transfer to GL process uses this accounting attribute to determine whether to transfer subledger journal entries to 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 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 General Ledger.

Transaction Rounding Reference Accounting Attribute

The transaction rounding reference determines the level at which the transaction rounding difference is calculated. It is used along with the rounding class to detect and correct subledger transaction rounding differences. If a transaction rounding reference is not provided, transaction rounding is not calculated.

Subledger transaction rounding differences occur when the sum of the accounted amounts for a subledger transaction is not equal to the sum of the entered amounts multiplied by the conversion rate. Rounding differences can also occur on functional currency transactions when the sum of an unrounded entered amount after rounding the minimum accountable units and precision of the currency does not equal the final rounded entered amount. The accounting program compares the sum of the rounded accounted amounts with the sum of the unrounded accounted amounts by transaction rounding reference and rounding class to detect subledger transaction rounding differences.

Transaction rounding differences are corrected by adding the rounding difference amount to one of the subledger journal entry lines with the same transaction rounding difference and rounding class. Specifically, it is added to the journal entry line with the largest amount.

Subledger Transaction Rounding Example

The subledger transaction rounding example describes a journal entry with a subledger transaction rounding difference and illustrates how the rounding class is used to detect and correct the rounding difference.

For this example, the table below describes the accounting attributes and the sources that are mapped for the journal line types Invoice Liability and Expense.

Accounting Attribute Source
Entered Amount Entered Amount
Conversion Date GL Date
Conversion Rate Type Invoice Conversion Rate Type
Transaction Rounding Reference Invoice Identifier

The rounding class for the journal line type Invoice Liability is Liability. The rounding class for the journal line type Expense is Expense.

The table below describes a Payables invoice with entered currency SEK and a conversion rate of 0.1. The invoice identifier (transaction rounding reference) is 40067.

Invoice 123 from Supplier ABC, 18-JAN-2003
Number Description Invoice Entered Amount
1 item   10.04
2 item   10.04
    Invoice Total (SEK): 20.08

The table below describes the temporary journal entry records for the Payables invoice. The following information applies to this example:

Line Number Account Rounding Class Entered DR Entered CR Accounted DR (USD) Accounted CR (USD)
1 01-Expense Expense 10.04   1.00  
2 02-Expense Expense 10.04   1.00  
3 01-Liability Liability   10.04   1.00
4 02-Liability Liability   10.04   1.00

Since lines 1 and 2 have the same rounding class and transaction rounding reference, they are grouped together for comparison for subledger transaction rounding.

Although the journal entry is balanced, a rounding difference has occurred since the sum of the entered amounts multiplied by the conversion rate is $2.01, but the sum of the accounted amounts for the lines is only $2.00.

The accounted amount for the subledger transaction is calculated as described in the table below.

Subledger Transaction Entered Amount X Conversion Rate = Unrounded Accounted Amount Rounded Accounted Amount
20.08 X 0.10 - 2.008 2.01

The accounted amount for the individual lines is calculated as described in the table below.

Subledger Transaction Entered Amount X Conversion Rate = Unrounded Accounted Amount Rounded Accounted Amount
10.04 X 0.10 = 1.004 1.00
10.04 X 0.10 = 1.004 1.00
          Total: 2.00

Since lines 3 and 4 have the same rounding class and transaction rounding reference, a similar calculation is performed as described above and a rounding difference of 0.01 is calculated.

The Financial Services Accounting Hub corrects the transaction rounding differences and the table below describes the final journal entry.

Account Rounding Class Entered DR Entered CR Accounted DR (USD) Accounted CR (USD)
01-Expense Expense 10.04   1.00  
02-Expense Expense 10.04   1.01  
01-Liability Liability   10.04   1.00
02-Liability Liability   10.04   1.01

A rounding amount of $0.01 is added to the 02-Expense. A rounding amount of $0.01 is added to the 02-Liability account.

Rounding Class Example

Using the same Payables invoice from the Subledger Transaction Rounding example, assume that the rounding class is Expense for both journal line types Invoice Expense and Invoice Liability.

Although the journal entry has the same amounts as the previous example, the rounding class is the same for all four lines. Since the sum of the accounted amount for the lines with the same rounding class and transaction reference is zero, and the sum of entered amount from the lines with the same rounding class and transaction rounding reference multiplied by conversion rate is also zero, no rounding reference is detected.

The table below describes the final journal entries for the invoice. The following information applies to the example:

Line Number Account Rounding Class Entered DR Entered CR Accounted DR (USD) Accounted CR (USD)
1 01-Expense Expense 10.04   1.00  
2 02-Expense Expense 10.04   1.00  
3 01-Liability Expense   10.04   1.00
4 02-Liability Expense   10.04   1.00

Business Flows Accounting Attributes

The table below describes business flows accounting attributes.

Business Flows Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Component Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Applied To Amount Number Line Event class and journal line type   Mandatory if the currency for prior entry is different than the currency currently selected Validation only takes place if validation an amount is previously enabled.
Applied to Application ID Number Line Event class and journal line type Optional Optional Must be a valid application ID
Applied to Entity Code Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated Must be a valid Entity for the application selected in Applied to Application ID
Applied to First System Transaction Identifier Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated  
Applied to Second System Transaction Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to First System Transaction Identifier is not assigned Optional  
Applied to Third System Transaction Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Second System Transaction Identifier is not assigned Optional  
Applied to Fourth System Transaction Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Third System Transaction Identifier is not assigned Optional  
Applied to Distribution Type Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated  
Applied to First Distribution Identifier Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated  
Applied to Second Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to First Distribution Identifier is not assigned Optional  
Applied to Third Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Second Distribution Identifier is not assigned Optional  
Applied to Fourth Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Third Distribution Identifier is not assigned Optional  
Applied to Fifth Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Fourth Distribution Identifier is not assigned Optional  

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 accounting program 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 accounting program 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/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 using business flows, certain accounting attribute values are unavailable for source assignment in the Accounting Attributes Assignment window because they will be copied from the prior journal entry.

Allocation Accounting Attributes

The table below describes allocation accounting attributes.

Allocation Accounting Attributes
Name Data Type Journal Entry Level Accounting Method Builder Component Accounting Attribute Assignment Rules Optional or Mandatory Validation Rules
Allocated to Application ID Number Line Event class and journal line type Optional Optional Must be a valid application ID
Allocated to Entity Code Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated Must be a valid Entity for the application selected in Applied to Application ID
Allocated to First System Transaction Identifier Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated  
Allocated to Second System Transaction Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to First System Transaction Identifier is not assigned Optional  
Allocated to Third System Transaction Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Second System Transaction Identifier is not assigned Optional  
Allocated to Fourth System Transaction Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Third System Transaction Identifier is not assigned Optional  
Allocated to Distribution Type Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated  
Allocated to First Distribution Identifier Alphanumeric Line Event class and journal line type Must be assigned if Applied to Application ID is assigned Mandatory if Applied to Application ID is populated  
Allocated to Second Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to First Distribution Identifier is not assigned Optional  
Allocated to Third Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Second Distribution Identifier is not assigned Optional  
Allocated to Fourth Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Third Distribution Identifier is not assigned Optional  
Allocated to Fifth Distribution Identifier Alphanumeric Line Event class and journal line type Must not be assigned if Applied to Fourth Distribution Identifier is not assigned Optional  
Actual Upgrade Option Alphanumeric Line Event Class Should be assigned to use Actual Upgrade accounting attributes to derive a reversal accounting entry or a business flow accounting line Optional  
Encumbrance Upgrade Option Alphanumeric Line Event Class Should be assigned to use Encumbrance Upgrade accounting attributes to derive a reversal accounting entry or a business flow accounting line Optional  

The allocation accounting attributes are always enabled and they are used in tracking transactions that are allocated to other transactions. No accounting is derived from these attributes. These attributes are also used for the following:

Distribution Identifiers Guideline

Distribution identifiers are stored in the transaction object and must be mapped to accounting attributes.

Distribution identifiers are the internal (surrogate) keys that uniquely identify the transaction distribution associated with a transaction object line.

The purpose of distribution identifiers is:

Distribution Link Type

All distribution identifiers have a distribution link type to differentiate between distributions. This is a mandatory source and must always be populated by the Load Transaction Objects program.

The distribution link type ensures that other distribution identifiers uniquely identify the underlying transaction's distribution associated with a transaction object line. Implementers should use a distribution link type source analogous to a table alias.

Each of the distribution identifiers is populated for the corresponding distribution link type.

Receivables Example: The distribution link type distinguishes between transaction distributions stored in the transactions distribution data model and those stored in the receipt or adjustments distribution data model.

Payables Example: The distribution link type distinguishes between transaction distributions stored in the invoice distribution data model and those stored in the payment distribution data model.

Distribution Identifiers

The Financial Services Accounting Hub supports up to five distribution identifiers for each distribution link type. The distribution link type is the same for all transaction object lines for an accounting event and therefore should normally be mapped to a header level source.

Payables Example: The table below lists the components for distribution identifiers that can be defined for the invoice event entity.

Source Name Source Value Accounting Attribute Name
Distribution Type AP_INV Distribution Link Type
Invoice Distribution Detail Identifier 12345 First Distribution Identifier

Receivables Example: The table below lists the components for distribution identifiers that can be defined for the transaction event entity.

Source Name Source Value Accounting Attribute Name
Transaction Type AR_TRANS Distribution Link Type
Transaction Line Identifier 23456 First Distribution Identifier
Transaction Line Detail Identifier 2 Second Distribution Identifier

Distribution Link Example

When the accounting program creates a subledger journal entry line, it inserts a row into the distribution link table for each transaction object line that contributes to it.

The example below shows how the distribution link table is populated. Assume that the event entity Transactions has the First Distribution Identifier accounting attribute mapped to the Transaction Distribution Identifier standard source.

The example is illustrated in the tables below:

The table below shows the header details for a Receivables transaction.

Transaction Header
Customer Name / Number Transaction Type Transaction Number GL Date VAT Date
ABC Ltd./123 Domestic Invoice A-1234 02-Jan-2002 30-Dec-2001

The table below shows the distribution details for the same transaction.

Transaction Distribution
Transaction Distribution Identifier Transaction Line Number Distribution Detail Number Transaction Line Type Amount Description
1234 1 1 Item 1000 Standard Item
1235 1 2 Tax 160 VAT @16%
1236 2 1 Item 2000 Standard Item
1237 2 2 Tax 500 VAT @25%
1238 3 1 Item 3000 Standard Item
1239 3 2 Tax 480 VAT @16%

The table below shows the details of the transaction object lines for the transaction.

Transaction Object Lines
Event ID Transaction Objects Line No. Transaction Distribution Identifier Transaction Line Number Distribution Detail Number Distribution Type Amount Description
1 1 1234 1 1 Item 1000 Standard Item
2 2 1235 1 2 Tax 160 VAT @16%
3 3 1236 2 1 Item 2000 Standard Item
4 4 1237 2 2 Tax 500 VAT @25%
5 5 1238 3 1 Item 3000 Standard Item
6 6 1239 3 2 Tax 480 VAT @16%

The table below shows the subledger journal entry lines for the above invoice.

Subledger Journal Entry Lines
Entry Header Identifier Entry Line Number Ledger (ID) Accounting Class Account Debit Credit Description
6000 1 101 Receivable 01.4300.000 7140   All lines
6000 2 101 Revenue 01.6000.000   4000 Transaction Objects lines 1 + 5
6000 3 101 Revenue 01.6001.000   2000 Transaction Objects line 3
6000 4 101 Tax 01.4372.000   1140 Transaction Objects lines 2 + 4 + 6

The table below records how each of the transaction object amounts have contributed to the subledger journal entry lines.

Financial Services Accounting Hub Distribution Link Table Lines
Entry Header Identifier Journal Entry Line No. Ledger (ID) First Distribution Identifier Entered Amount Ledger Amount
6000 1 101 1234 1000 1000
6000 1 101 1235 160 160
6000 1 101 1236 2000 2000
6000 1 101 1237 500 500
6000 1 101 1238 3000 3000
6000 1 101 1239 480 480
6000 2 101 1234 1000 1000
6000 2 101 1238 3000 3000
6000 3 101 1236 2000 2000
6000 4 101 1235 160 160
6000 4 101 1237 500 500
6000 4 101 1239 480 480

Multiperiod Accounting Guideline

Multiperiod accounting provides accounting for transaction distributions to be spread over one or more accounting periods.

The features of multiperiod accounting depend on a combination of accounting attribute values and application accounting definitions created in the AMB. To invoke multiperiod accounting, the transaction object should store source values relating to multiperiod accounting and these sources should be mapped to the multiperiod accounting attributes.

Monetary Amounts Guideline

The accounting program uses the entered and ledger currency amounts to create subledger journal entry debit and credit amounts. The following guidelines apply to monetary amounts and are described in this section:

Currency Precision

It is not necessary to round entered amount or ledger currency amount in the transaction objects. The Financial Services Accounting Hub rounds the amount in the final journal entries based on the precision and minimum accountable unit of the currency.

Monetary Amount Sign (positive or negative)

Users can view underlying transactions in transaction windows. In general, the sign of a monetary amount stored in the transaction object for an accounting event should be the same as that which is displayed to users. For example, if both invoices and receipts are displayed to users as positive amounts in transaction windows and on reports, then positive amounts should also be stored in the transaction object.

It increases understanding if amounts that represent reversals or cancellations of earlier transactions are represented with the opposite sign of the original amount. For example, an invoice cancellation amount should be negative if the corresponding invoice amount is positive.

Gains and Losses Guideline

If Calculate Gain or Loss Amounts is enabled for the event class, the transaction object should not include explicit gain or loss lines. The gain or loss amount is calculated by the Financial Services Accounting Hub by subtracting the total unrounded credit amounts from the total unrounded debit amounts. If it results in a positive amount, a loss line is created; otherwise, a gain line is created according to the defined journal line type.

If Calculate Gain or Loss Amounts is disabled for the event class, an explicit gain or loss transaction object line is needed if a gain or loss journal line needs to be generated.

Foreign Currency Amounts Guideline

Appropriate currency and rate information should be stored in the transaction object. The following accounting attributes relate to foreign currency transactions:

The following sections describe two distinct cases of foreign currency transactions. They contain examples of how the accounting attribute assignments can be used to create the appropriate subledger journal entries in each case.

The ledger currency is made available to the accounting program as a system source.

See:

If the Financial Services Accounting Hub is not configured to calculate accounted amount, the accounted amount accounting attribute must be mapped to a source. If the Financial Services Accounting Hub is configured to calculate accounted amounts, it does not use the accounted amount provided in the transaction object and it does not generate warnings even if there is no value in the source mapped to this accounting attribute.

See: Override Calculated Accounted Amount

From the perspective of the Financial Services Accounting Hub, the two distinct cases of foreign currency transactions are:

Foreign Currency Transactions Not Applied to Other Transactions

In cases where foreign currency transactions are not applied to other transactions, no gain or loss is created and all journal line types can use the same accounting attribute.

Receivables Example: Assuming that Calculate Accounted Amount is disabled, an invoice of GBP 110 is recorded in the system on January 18th with a rate of 1.60 (USD 176).

The table below lists source values that should be stored in the transaction object.

Invoice Transaction Object Lines
Line No. Line Type Entered Currency Code Entered Amount Ledger Currency Amount Conversion Rate Conversion Date Conversion Rate Type
1 Item GBP 100.00 160.00 1.60 18-Jan-05 User
2 Tax GBP 10.00 16.00 1.60 18-Jan-05 User

The table below lists accounting attribute assignments for all journal line types for the Invoice event class.

Accounting Attribute Assignments for all Journal Line Types for the Invoice Event Class
Accounting Attribute Name Standard Source
Entered Currency Code Entered Currency Code
Entered Amount Entered Amount
Accounted Amount Ledger Currency Amount
Conversion Rate Conversion Rate
Conversion Date Conversion Date
Conversion Rate Type Conversion Rate Type

Based on the standard source values, the accounting attribute assignment and some simple application accounting definitions, the table below lists details of the resulting subledger journal entry. The conversion rate is 1.60.

Invoice Issued Subledger Journal Entry
Entry Line No. Journal Line Type Account Entered Currency Code Entered Amount Accounted DR (USD) Accounted CR (USD)
1 Receivable 01.6000.001 GBP 110.00 176.00  
2 Revenue 01.4300.000 GBP 100.00   160.00
3 Tax 01.4700.000 GBP 10.00   16.00

Foreign Currency Transactions Applied to Other Transactions

There are two distinct scenarios that can result in a gain or loss:

Foreign Currency Transactions Applied to Transactions of the Same Currency

In the case of foreign currency transactions applied to transactions of the same currency, the following values can be different between the transaction and the transactions to which it is applied:

Consider a foreign currency receipt applied to an invoice where the receipt and invoice are in the same currency. If business flow is implemented, the Financial Services Accounting Hub gets the conversion information from the invoice and calculates the accounted amount for the receipt application.

Receivables Example: Assuming Calculate Accounted Amount and Calculate Gain or Loss Amounts are both enabled for the receipt event class, a receipt of GBP 110 is recorded in the system on January 31st with a rate of 1.70 (USD 187). It is applied to and fully pays the GBP 110 invoice recorded on January 18th with a rate of 1.60 (USD 160).

The table below lists source values that should be stored in the transaction object.

Note: For both lines, the receipt line type is Application, the invoice exchange rate is 1.60, and the invoice exchange date is 18-Jan-05.

Receipt Transaction Object Lines
Line No. Receipt Currency Receipt Entered Amount Receipt Exchange Rate Receipt Exchange Rate Type Applied to Invoice Applied to Distribution
1 GBP 132.00 1.7 Corporate 445 3021

Based on a simple application accounting definition, the table below lists the details of the accrual basis subledger journal entry for the receipt.

Accrual Basis: Receipt Applied Subledger Journal Entry
Line No. Journal Line Type Entered Currency Code Entered DR Entered CR Exch. Rate Accounted DR (USD) Accounted CR (USD)
1. Cash 01.4300.000 GBP 110.00   1.70 187.00  
2. Receivable 01.6000.001 GBP   110.00 1.60   176.00
3. Gain or Loss 01.7000.000 GBP   0 1.70   11.00
          Total 187.00 187.00

The Financial Services Accounting Hub identifies the accounting entries of the invoice based on the applied to information. It then retrieves the currency conversion information, currency code and General Ledger account from the invoice's accounting entry. This information is used for the receipt accounting entries line number 2. Accounted amount is calculated as the receipt's entered amount multiplied by the invoice's conversion rate.

Cross-Currency Transactions: Transactions Applied to Transactions in a Different Currency

This scenario is similar to Foreign Currency Transactions Applied to Transactions of the Same Currency, with the same currency receipt application. The receipt currency is EUR with a conversion rate of 1.4 as shown in the table below.

Receipt Transaction Object Lines
Line Number Receipt Currency Receipt Entered Amount Receipt Exchange Rate Receipt Exchange Rate Type Applied to Invoice Applied to Distribution
1 EUR 132.00 1.4 Corporate 445 3021

Based on a simple application accounting definition with business flows set up, the table below lists the details of the resulting accrual basis subledger journal entry for the receipt.

Accrual Basis: Receipt Applied Subledger Journal Entry
Line No and Journal Line Type Account Entered Currency Code Entered DR Entered CR Exch. Rate Accounted DR (USD) Accounted CR (USD)
1. Cash 01.4300.000 EUR 132.00   1.40 184.80  
2. Receivable 01.6000.001 GBP   110.00 1.60   176.00
3. Gain or Loss 01.7000.000 EUR   0 1.40   8.80
          Total 184.80 184.80

Reporting Currency Amounts Guideline

If the Financial Services Accounting Hub is configured to calculate reporting currency amount, there is no need to provide any reporting currency information in the transaction objects.

If the Financial Services Accounting Hub is not configured to calculate reporting currency amount and if there is subledger level reporting currency associated with the primary ledger, then the reporting currency amount must be provided in the transaction objects for the subledger application.

Receivables Example: Assume that the Financial Services Accounting Hub is not configured to calculate reporting currency amount for the Receivables application. A ledger is defined with functional currency USD. A subledger level reporting currency CAD is assigned to the USD primary ledger. An invoice of GBP 100 is recorded in the system on January 18th with a conversion rate of 1.60 to USD and 1.40 to CAD.

The table below lists the source values that are stored in the transaction object lines for each transaction distribution.

Transaction Object Lines
Line No. Line Type Entered Currency Code Entered Amount Ledger ID Accounted Amount Conv. Rate Conv. Date Conv. Type
1 Item GBP 100 25 160* 1.6 18-Jan-05 User
2 Tax GBP 10 25 16* 1.6 18-Jan-05 User
3 Item GBP 100 26 140 1.4 18-Jan-05 Reporting
4 Tax GBP 10 26 14 1.4 18-Jan-05 Reporting

Note: * The Financial Services Accounting Hub calculates this amount if the Calculate Accounted Amounts is enabled for the event class.

Corrections for Rounding Guideline

The types of rounding errors are:

Transaction rounding differences

Journal rounding differences

Transaction Rounding Differences

Transaction rounding differences arise when transaction amounts are distributed to a higher level of detail than the original transaction. In this case, the total accounted amounts for a subledger transaction may not equal the sum of the entered amounts multiplied by the conversion rate. The Financial Services Accounting Hub uses transaction rounding references and rounding class to calculate the transaction rounding difference. This is corrected by adding the difference in the amount into one of the journal lines.

See: Transaction Rounding Reference Accounting Attribute

Journal Rounding Errors

The Financial Services Accounting Hub stores unrounded and rounded entered amount as well as unrounded and rounded accounted amounts on a journal entry. All amounts in the transaction objects are treated as unrounded amounts. The unrounded amounts on the journal entry lines are rounded based on the precision and minimum accountable unit defined for the currency. If appropriate, an explicit rounding line is created to correct journal rounding differences. This rounding line uses the rounding difference tracking account defined in the ledger.

Only one rounding line is created per unbalanced balancing segment value and entered amount and accounted amount. It is also possible that it debits rounding in entered amount but credits in accounted amount or vice-versa. In this case, the entered amount is negative and shares the same side as the accounted amount.

To illustrate journal rounding errors, the table below lists the details of transaction object lines on an invoice.

Transaction Objects Lines
Line Number Invoice Line Type Invoice Entered Currency Code Invoice Entered Amount
1 Item USD 10.004
2 Item USD 10.004

Journal line types Invoice Liability and Expense are used to create journal entries for this invoice. The Merge option is set to Yes for Expense and to No for Invoice Liability.

The table below lists the resulting journal entries before the journal rounding routine is performed.

Note: Entered amount and unrounded entered amount are also stored in the Financial Services Accounting Hub although only accounted amounts are shown in the table below.

Line Number Account Unrounded Accounted DR Unrounded Accounted CR Accounted DR Accounted CR
1 Expense 20.008   20.01  
2 Liability   10.004   10.00
3 Liability   10.004   10.00

Since Unrounded Accounted DR equals the total of Unrounded Accounted CR but Accounted DR does not equal the total of Accounted CR, an explicit journal rounding line is created as described in the table below.

Line Number Account Unrounded Accounted DR Unrounded Accounted CR Accounted DR Accounted CR
1 Expense 20.008   20.01  
2 Liability   10.004   10.00
3 Liability   10.004   10.00
4 Rounding   0   0.01

Related Transactions, Lines, and Distributions Guideline

The data from related transactions should be made available as sources. These transactions include applied to transactions, matched with transactions, and created from transactions. This is because transaction amounts in a subledger can be allocated within the originating transaction or across different transactions.

Sources should be stored in transaction objects that are not only associated with the event's underlying transaction but also with its related transactions.

Payables Example: An invoice tax amount is allocated to item or freight amounts for the same invoice. The transaction object should include sources values relating to the tax distribution or allocation as well as the item or freight distributions to which it is allocated.

Receivables Example: A receipt can be applied to one or more invoices. Source values should be stored in the transaction object that relates not only to the receipt but also to the invoices, invoice lines, and distributions to which it is applied.

For receipt amounts allocated to invoice tax lines, sources for the related item lines should also be included in the transaction object. This allows subledger journal entry lines to be created based upon the amount allocated to the invoice or the amount allocated to each line on the invoice.

The Business flow feature ensures that accounting information, such as Accounting Flexfields, is automatically copied from the previous transaction in the business flow. For this feature to work, store the transaction and distribution identifiers from the applied to transaction in the transaction objects.

Independence from Accounting Method Guideline

The transaction objects should be independent from the accounting representation represented by the subledger accounting methods, which determine how transactions are accounted and represented by subledger journal entries.

Subledger transactions can be subject to more than one accounting representation. For example, the alternative representation to cash basis could be accrual basis. The alternative representation to corporate could be fiscal.

Note: Valuation methods are a way of storing alternative representations directly in the subledger applications. The Financial Services Accounting Hub assumes that each subledger transaction and accounting event is for a single valuation method.

Examples of Oracle applications that support more than one valuation method for a transaction are Assets, through asset books, and Costing, through costing methods. These applications must capture one accounting event for each valuation method.

See: Valuation Methods and the Financial Services Accounting Hub

In addition, users and other groups outside development can also create and modify accounting methods. It is therefore not possible to predetermine how transactions are accounted. The source values that are stored in the transaction object must depend solely on the nature of the transaction and its related setup and not on the seeded subledger accounting methods.

As an example, there must be a complete transaction object with all possible sources for an invoice validated accounting event, even if the user has assigned a cash basis accounting method to the corresponding ledger. This is because an implementer cannot know whether users need to use cash or accrual basis accounting. Providing all the sources as part of the transaction object gives users the flexibility to make this decision.

Balanced Debits and Credits Guideline

Balanced debits and credits should not be stored in the transaction object.

Typically, a transaction amount contributes to two subledger journal entry lines, one debit and one credit. However, multiple accounting representations and specific vertical or geographical accounting requirements can result in a transaction amount contributing to none or more than two subledger journal entry lines.

The total transaction amount is the same no matter how many subledger journal entry lines are generated for it. Therefore, the Financial Services Accounting Hub mandates that balanced debits and credits should not be stored in the transaction object.

Oracle Receivables: Consider a Receivables invoice with a single $100.00 item that is not subject to tax. The invoice results in a single transaction object distribution or allocation being stored in the transaction object. Accounting definitions for the Invoice Completed accounting event determines how to use the $100.00 to create subledger journal entry lines. Typically, the single distribution or allocation of $100.00 is used to create two subledger journal entry lines, Debit to Trade Receivables for $100.00 and Credit to Revenue for $100.00.

However, there are many examples of requirements for more than two subledger journal entry lines to be generated for a single transaction amount. These include the requirements of the US federal public sector (USSGL Transaction Codes), and requirements for multiple representations (Combined Basis or Corporate and Fiscal). In all these cases, multiple subledger journal entry lines must be created.

In this particular example, the Financial Services Accounting Hub requires that an unbalanced transaction amount of $100 be stored in the transaction object. The subledger accounting method determines the distributions for this transaction amount.

Transaction Objects Lines and Default Accounting Flexfields

The startup application accounting definitions delivered with the application should emulate the current accounting for transactions. Therefore, all Accounting Flexfields used for subledger journal entry lines generated prior to the uptake of the Financial Services Accounting Hub must be stored in the transaction object. This implies that each distribution or allocation must be associated with at least two Accounting Flexfields that correspond to the original debit and credit Accounting Flexfields.

Receivables Example: Consider a receivables invoice with a single $100.00 item that is not subject to tax. This results in a single transaction object line that has both the Trade Receivables and Revenue Accounting Flexfields as sources.

The fact that these Accounting Flexfields are stored on each transaction object line does not imply that there is one subledger journal entry line for each transaction object line. The Financial Services Accounting Hub has features that automatically summarize subledger journal entry lines to the appropriate level of detail so that there is one Trade Receivables subledger journal entry line per invoice.

Specific accounting requirements can result in no subledger journal entry or one with multiple lines being created.

Granularity of Transaction Objects Lines Guideline

For any transaction, the maximum level of detail is stored in the transaction objects and made available to the accounting program. The level of detail refers to all transactions, lines, and distributions to which transaction amounts are allocated.

The transaction objects should normally allocate transaction amounts to the maximum level of detail. This provision affords users greater flexibility in the method of accounting for transaction object amounts.

Since the transaction object has no means of knowing how transaction amounts are accounted, the level of detail of the transaction object cannot be adjusted according to the application accounting definition. The most flexible solution is to allocate transaction amounts to the maximum level of detail.

Receivables Example: An invoice is issued with a single tax amount that is allocated to many invoice distributions. To provide the maximum level of detail, the transaction object should allocate the tax amount to each of the invoice distributions and make them available to the accounting program.

Providing the maximum level of detail enables users to account for the tax amount either at the level of the tax code and rate or at the level of invoice lines. If the user has elected to account at the tax code level, the accounting program normally creates a single subledger journal entry line for all the allocations or distributions.

Transaction Objects Detail vs. Application-specific Allocation Options

When uptaking the Financial Services Accounting Hub, analyze application setup options that control the level of detail of allocations to determine whether such setup options can be obsoleted by the Financial Services Accounting Hub.

Oracle Example: Some Oracle applications support application and transaction specific options that control how transaction amounts are allocated to each other. For example, in Receivables, the Application Rule Set determines how cash receipt amounts are allocated to invoice lines. In Payables, the Payment Discount Method determines how discount amounts are allocated to invoice lines. Providing the lowest level of detail enables users to either use that detail or summarize it.

In most cases, these options are simply mechanisms that affect the level of detail of allocations. The same results can be obtained by always providing the maximum level of detail and letting the application accounting definitions in the AMB determine how the amounts should be grouped together for accounting purposes. Summarize lines by using the merge matching lines option on the journal line type in the AMB.

Providing the maximum level of detail to the AMB eliminates the need to set up application-specific accounting options to control the level of detail of allocations.

Identifying Distribution or Allocation Amounts in the Transaction Object Detail

To take advantage of the transaction amounts allocated at the maximum level of detail, it should be possible for users to identify and distinguish between different types of transaction object lines. The transaction object must therefore provide sources that describe both the type of transaction amount that has been allocated as well as the type of transaction amount to which it is allocated.

Payables Example: Classify payment amounts into Payment Discount, Gain or Loss, and Rounding. Allocate invoice line distribution amounts to Freight and Item, Recoverable Tax, and Non Recoverable Tax. By storing each of these in the transaction object, users can create a separate subledger journal entry line for each amount.

See: Transaction Objects Example for Payables

Transaction Object Detail: Exceptions to Providing Detailed Allocations

There may be some circumstances under which it is acceptable not to provide the maximum level of detail in an allocation. There are cases where the transaction model does not support allocations to the maximum level of detail. If there is no business case served by allocating a transaction amount down to the maximum level of detail, you can decide not to store the detailed amounts in the transaction object.

Receivables Example: Receivables does not support the allocation of adjustment amounts to invoice lines. In this case, you can choose to implement a simple allocation rule in the module; for example, by prorating an adjustment amount to all transaction lines. The allocated amounts should be stored in the transaction object.

Third Party Control Accounts Guideline

Third party data should be stored in the transaction object as accounting attributes. Several countries in Europe and Latin America require that subledger systems support third party control account reporting and reconciliation.

Third party control accounts record a subledger's balance or activity in relation to third parties. These third parties are legal entities with which the company engages in business transactions. Examples of third party legal entities are customers and suppliers.

Whenever a subledger transaction that is associated with a customer or supplier is accounted, the Financial Services Accounting Hub records the customer or supplier and site on the journal entry lines for subsequent user analysis and reporting. To accurately account for the subledger transaction and meet all control requirements, third party identifiers must be stored in the transaction objects.

If third party control accounts are enabled for applications, the accounting program performs the following validation:

Transactions Associated with Third Parties

For subledger transactions associated with a third party, you should include the values in the table below as standard sources and also map them to the corresponding accounting attributes.

Standard Source Description Accounting Attribute Name
Third party internal identifier; for example, party_id or vendor_id Party Identifier
Third party site internal identifier; for example, party_site_id or vendor_site_id Party Site Identifier
Third party type (C for customer or S for supplier) Party Type

See: Accounting Attributes Guideline

Payables Example: An invoice is registered in the system with a supplier and supplier site. The vendor_id or party_id should be stored as the party identifier; the vendor_site_id or party_site_id should be stored as the party site identifier; and S should be stored as the party type. The standard sources containing this information should be assigned to the corresponding accounting attributes.

Receivables Example: A receipt is registered in the system with a customer but no customer site. The party_id for the customer should be stored as the party identifier; the party site identifier should be left blank; and C should be stored as the party type.

Applied to Transactions Associated with Third Parties

The business flow feature ensures that accounting information, such as Accounting Flexfields, are automatically copied from the previous transaction in the business flow.

Subledger Journal Entry Creation

If the Create Accounting program finds a subledger journal entry line with a third party control account, it calls an API to check the following:

If an error is returned, the Create Accounting program does not create a subledger journal entry.

Subledger Accounting Balances Updates

The Subledger Accounting Balances Updates program is generated by the Create Accounting program when final journal entries are created and maintains balances for third party control accounts.

Related Topics

Third Party Control Accounting Attributes

Defining Segment Qualifiers, Oracle General Ledger User Guide

Translated Sources, Lookup Types, and Value Sets Guideline

The transaction objects should store a translated source value in each installed language that is used by ledgers linked to the accounting event's primary ledger. The accounting program creates subledger journal entry descriptions and supporting references using the language that is selected as part of the ledger setup.

You can determine what languages are required to process a primary ledger and its accounting events.

See: SQL Query to Determine Languages Used

Translated Sources

When analyzing transaction object requirements, determine whether the column value on which a source is based is translatable. If it is, then the source should be defined as translatable in the AMB.

Sources that are translated cannot be used in AMB conditions.

See: Account Derivation Rule Conditions, Oracle Subledger Accounting Implementation Guide

Lookup Types

If a source is a lookup code, the Financial Services Accounting Hub displays its corresponding meaning in the appropriate language when it is used in header and line descriptions or supporting references. Lookup types can:

Value Sets

Value sets provide features similar to lookup types for lists of values not stored as lookups. Instead of a lookup type, the value set derives the user meaning corresponding to a hidden identifier, such as a surrogate key.

The disadvantage of using a value set instead of a lookup type is that it requires more setup; you should define a value set to link the hidden identifier to its user friendly and translated meaning.

Optionally, specify a value set as part of the definition of standard sources. If a hidden identifier, such as a surrogate key, is defined as a source that is assigned a value set, there is no need to define a source for the corresponding meaning. The Financial Services Accounting Hub converts the hidden identifier into the appropriate and translated meaning whenever it is displayed to users.

See: Assign Sources

The value sets associated with sources should not rely on contexts such as operating unit or asset book to return a unique value. For example, it is not possible to use a value set for tables that are partitioned by operating unit. If the value set uses a secure view, no values are displayed because the accounting program does not run within the context of a single operating unit. If the value set uses the base table, it is possible that duplicate values will be returned. Therefore, value sets should not be used if the value set cannot return a list of unique values without recourse to another explicit parameter.

Displayed Name of Sources that have been Assigned Lookup Types or Value Sets

The displayed name of sources that have been assigned lookup types or value sets should describe the source's meaning. Although the transaction object contains only a lookup code or value set ID, the source's displayed name should describe the corresponding meaning.

Payables Example: Create a source with the display name Invoice Type. Assign a lookup type of INVOICE_TYPE to this source. The transaction object contains the invoice type lookup code.

SQL Query to Determine Languages Used

The following sql statement returns a list of the languages used to generate subledger journal entries for the subledger application's primary and secondary ledgers. The values returned, language_code, corresponds to fnd_languages.language_code.

The sql accepts the subledger application identifier and the primary ledger identifier as parameters.

select distinct nvl(led.sla_description_language, userenv('LANG')) language_code

from  gl_ledgers led, xla_ledger_options lopt 

where led.ledger_category_code in ('PRIMARY', 'SECONDARY') 

and  led.ledger_id = lopt.ledger_id and lopt.enabled_flag = 'Y' 

and  lopt.application_id = &subledger_application_id 

and  led.primary_ledger_id = &primary_ledger_id;

The transaction object program should populate the transaction objects with the translated source values for the languages codes. The language codes are the same for all accounting events that belong to a primary ledger.

Consistency Guideline

Ensure that sources stored in the transaction objects are stored in a consistent manner across different types of transactions.

For example, if the source Purchase Order Number is made available for invoice lines that are matched to a purchase order line, then the Purchase Order Number must be stored whenever an invoice line is matched to a purchase order number.

Sources corresponding to the same underlying transaction values should be defined only once and assigned to all event classes using them.

Receivables Example: A Transaction Type source should be defined once and assigned to both the Invoice and Receipt Application event classes.

It is not correct to define separate Invoice Transaction Type and Applied To Transaction Type sources for the underlying transaction type and assign them separately to the Invoice and Receipt Application event classes.

This guideline is important because users can share journal entry setups, such as account derivation rules and descriptions, across event classes if they use the same sources. If separate sources are defined for each event class or event entity, separate account derivation rules and descriptions must be defined for each event entity or class. This results in increased complexity, maintenance, and inconsistencies.

Receivables Example: Assume that separate sources are defined for the underlying transaction type and assigned separately to the Invoice and Receipt Application event classes. In this case, it is not possible to share a Receivable account derivation rule between the Invoice and Receipt Application event classes even though the account derivation rule is exactly the same.

Tax References Guideline

The transaction objects should store these tax references as accounting attributes. Tax references establish a link between information stored in the tax repository and subledger journal entries. Tax reports and inquiries use the link to provide a complete reconciliation of tax amounts and accounting.

When calling tax routines to calculate the tax amounts for their transactions, the routines return one or more of the following tax references:

The transaction objects should store these tax references as accounting attributes. If the tax references are not correctly stored in the transaction objects, it is not be possible to reconcile subledger journal entry lines with tax amounts in the tax repository.

Note: The accounting attribute assignment for tax group accounting attributes will not enforce mapping of all related attributes.

When the accounting program inserts records into the distribution link table, values of the tax references are stored along with the distribution identifiers.

Flexfields Guideline

The transaction objects should store flexfield column values as sources if they can be used in creating subledger journal entries. This guideline is only applicable if Oracle subledger applications are used.

Accounting Flexfields

All Accounting Flexfields that may be related to a transaction distribution or entered as part of the default setup should be stored in the transaction objects as sources.

It is necessary to store only the code combination identifier of the Accounting Flexfield in the transaction objects. The Financial Services Accounting Hub can retrieve individual segments values of the flexfield directly from the code combinations table.

Key Flexfield Segments

Wherever a key flexfield, other than an Accounting Flexfield, stores important information about a transaction or distribution, the key flexfield code combination identifier should be stored in the transaction objects. Individual segment values do not need to be stored, as the Financial Services Accounting Hub can retrieve them from the underlying code combinations table. For example, users working with the Assets subledger application store information in the Asset Category flexfield. They may want to create application accounting definitions based on the value of an individual segment in this flexfield. Therefore, the Asset Category Flexfield Combination identifier should be stored in the transaction objects.

In cases where applications provide features that enable users to define multiple key flexfields and assign them directly or indirectly to transactions, decide which values should be stored in the transaction object. For example, Costing may want to store both the default item category set and the accounting category set.

Descriptive Flexfield Attributes

Not all descriptive flexfield attributes need to be stored in the transaction objects. At a minimum, the Financial Services Accounting Hub recommends that you define those descriptive flexfields associated directly with the transaction header and lines as sources. For each descriptive flexfield, the context column must be included in the transaction objects. Include other descriptive flexfields that you think are commonly used.

Global Descriptive Flexfield Attributes

Only global descriptive flexfields that the Global Financial Applications Technical Reference Manual indicates are in use should be stored in the transaction objects.

Oracle Applications strategy is to incorporate the globalization features into the base applications. However, to the extent that this incorporation is in progress, some global descriptive flexfields may need to be stored in the transaction objects.

The following sql statement can be used to identify global descriptive flexfields that are in use:

select  distinct f.APPLICATION_TABLE_NAME,c.APPLICATION_COLUMN_NAME

from   fnd_descr_flex_column_usages c, 

     fnd_descriptive_flexs_vl f

where   c.application_column_name like 'GLOBAL_ATTRIBUTE%'

and    f.DESCRIPTIVE_FLEXFIELD_NAME = c.DESCRIPTIVE_FLEXFIELD_NAME 

order by f.APPLICATION_TABLE_NAME, c.APPLICATION_COLUMN_NAME;

Accounting Flexfield Derivation Mechanisms Guideline

All values used to derive accounts prior to the uptake of the Financial Services Accounting Hub should be made available as sources.

In prior releases of the Oracle E-Business Suite, applications used a variety of mechanisms to provide flexibility in Accounting Flexfield derivation. These include Receivables AutoAccounting and Projects AutoAccounting, Assets Flexbuilder, Workflow Account Generator, and OPM's MAC. For these solutions to be replaced by the Financial Services Accounting Hub, the values available for creating entries with these mechanisms must be stored in the transaction objects.

Examples of the types of values used for creating accounting in prior releases of the Oracle E-Business Suite include the following:

Assets: Asset Category Accounts, Asset Assignment Accounts, and Asset Book Control Accounts

Projects: Expenditure Types, Service Codes, and Class Codes

Purchasing: Deliver to Location, Deliver to Subinventory, and Expenditure Category

Receivables: Transaction Type, Customers, and Sales Representatives

Accounting Options Guideline

Existing setup accounting options should be stored in the transaction objects as sources. The journal entry setups that make up the startup data application accounting definitions use these sources to determine how to account for subledger transactions.

If users require more than one accounting representation, each based on a different value of an accounting option, they can use the AMB to create application accounting definitions. These definitions implement journal entry setups that correspond to a specific value of an accounting option.

Oracle Payables: Values for the Use Future Dated Payment Account accounting option should be stored in the transaction objects. The account derivation rules for the future dated payment account can take this source value into account when deriving the liability account from the supplier site or payment document.

For accounting options that have a significant impact on accounting, consider creating a dedicated application accounting definition.

The following are examples of accounting options that should be implemented as separate application accounting definitions:

Internal Identifiers Guideline

Internal Identifiers

Internal identifiers, such as surrogate keys, should not be included as sources. Internal identifiers typically have no business value and will not be understood by users.

Oracle Receivables: The Transaction Type Name, not the Transaction Type Id should be stored in the transaction objects.

Note the following exceptions:

Processing Statuses

Internal processing statuses such as posting status flags or enabled or disabled flags should not be stored in transaction objects.

Payables Example: The accrual posted flag should not be included as a source.

Who Columns

Who columns should not be included as sources. The names of the application's user who created the accounting event and who submitted the accounting program are available as system sources.

System Sources Guideline

System sources are independently populated by the Financial Services Accounting Hub. They should not be stored in transaction objects.

See: Standard, System, and Custom Sources

The table below shows a list of system sources supported by the Financial Services Accounting Hub.

System Sources Supported by the Financial Services Accounting Hub
Name Data Type Description
Accounting Event Date Date Accounting event date
Accounting Event Creator Alphanumeric User who created or updated the subledger transaction at the time that the accounting event was captured
Accounting Event Type Code Alphanumeric Accounting event type code
Accounting Event Type Name Alphanumeric Accounting event type name
Accounting Event Class Code Alphanumeric Accounting event class code
Accounting Event Class Name Alphanumeric Accounting event class name
Journal Entry Creation Date Date Journal entry creation date (system date)
Journal Entry Creator Alphanumeric User who submitted the accounting program
Journal Entry Source User Name Alphanumeric User who entered journal entry source
First Day Next Accounting Period Date Used in accrual reversal to indicate that the first day in the next GL period will be used to create the accrual reversal entry. The day can be rolled forward to the next business day only if the GL transaction calendar is used.
Last Day of Next Accounting Period Date Used in accrual reversal to indicate that the last day in the next GL period will be used to create the accrual reversal entry. The day can be rolled backward to the last business day only if the GL transaction calendar is used.
Ledger Name Alphanumeric Primary or secondary ledger name associated with the journal entry
Transaction Legal Entity Identifier Alphanumeric Transaction legal entity identifier
Next Day Date Used in accrual reversal to indicate that the next day will be used to create the accrual reversal entry. The day can be rolled forward to the last business day only if the GL transaction calendar is used.
Accounting Period Name Alphanumeric Period name associated with the journal entry
Accounting Period Type Alphanumeric Period type associated with the journal entry
Application Accounting Definition Name Alphanumeric Application accounting definition associated with the journal entry
Application Accounting Definition Owner Alphanumeric Indicates whether the application accounting definition is owned by Oracle or User
Application Accounting Definition Version Alphanumeric Application accounting method version associated with the journal entry
Financial Services Accounting Hub Method Name Alphanumeric Subledger accounting method name
Ledger Currency Code Alphanumeric Primary or secondary ledger currency code associated with the journal entry; not reporting currency code
Ledger Language Alphanumeric Determines the text format in the description language; ISO language code for the description language
Ledger Language for Dates and Number in Description Alphanumeric Determines the format of the number and dates in the description
Event Numeric Reference 1 Number Accounting event reference information captured on the accounting event
Event Numeric Reference 2 Number Accounting event reference information captured on the accounting event
Event Numeric Reference 3 Number Accounting event reference information captured on the accounting event
Event Numeric Reference 4 Number Accounting event reference information captured on the accounting event
Event Alphanumeric Reference 1 Alphanumeric Accounting event reference information captured on the accounting event
Event Alphanumeric Reference 2 Alphanumeric Accounting event reference information captured on the accounting event
Event Alphanumeric Reference 3 Alphanumeric Accounting event reference information captured on the accounting event
Event Alphanumeric Reference 4 Alphanumeric Accounting event reference information captured on the accounting event
Event Date Reference 1 Date Accounting event reference information captured on the accounting event
Event Date Reference 2 Date Accounting event reference information captured on the accounting event
Event Date Reference 3 Date Accounting event reference information captured on the accounting event
Event Date Reference 4 Date Accounting event reference information captured on the accounting event

Accounting Reversals Guideline

To invoke an accounting reversal for a transaction or transaction distribution, the transaction objects should include the appropriate header or line level accounting reversal options.

Accounting Reversals

Accounting reversals enables users to reverse the accounting impact of a previously accounted transaction distribution or all existing accounting for a transaction. Enable this functionality by implementing the accounting reversals setups described in this section.

The Financial Services Accounting Hub uses the following accounting reversal specific terminology.

Reversed (original) Distribution. Refers to a transaction distribution that although successfully accounted, is either incorrect or canceled. The transaction distribution is therefore reversed.

Reversal Distribution. Refers to a transaction distribution which reverses the effect of the original distribution on transaction balances. Typically, reversal distributions are identical to the reversed distributions in all respects except for entered (ledger) amounts that reverse the sign of the original.

Replacement Distribution. Refers to a transaction distribution which replaces the reversed distribution with the correct value

The table below illustrates the distributions described above.

Distributions Example
Invoice Distribution Line Number Invoice Line Type GL Date Amount Description
1 Item 10-Jan-2006 1000 Reversed
2 Item 12-Jan-2006 -1000 Reversal (of line 1)
3 Item 12-Jan-2006 2000 Replacement (of line 1)
Transaction Total     2000  

Note that the original accounting impact of the reversed distributions is undone, even if the subledger journal setups or accounting configurations have changed since the original subledger journal entry was generated.

Accrual Reversals

Accrual reversal enables users to define how and when accrual reversals are automatically performed . To schedule the automatic reversal of a journal entry at the time it is created, users assign the Accrual Reversal GL Date accounting attribute at the event class level in the Accounting Attributes Assignments window. Users can override this value in the journal entry header in the Application Accounting Definitions window. This value determines the GL date of the accrual reversal entry. The Financial Services Accounting Hub creates the accrual reversal entry to negate the impact of the accrual entry. Depending on the selection for Reversal Method for the ledger accounting options in the Update Accounting Options window, the accrual reversal will have the debit and credit signs reversed or it will have negative amounts.

See:

Accrual Reversal GL Date Example

A company receives material worth $100 on Monday, January 12, 2006 that has not been invoiced. To book the accrual, the Accrual Expense account is debited $100.00 and the Accrual Liability account is credited $100.00 as shown in the example below.

GL Date: 12-Jan-2006
Account Entered DR Credited DR Accounted DR (USD) Accounted CR (USD)
Accrual Expense 100.00 - 100.00 -
Accrual Liability - 100.00 - 100.00

If the Accrual Reversal GL Date is Next Day and the Reversal Method for the ledger and subledger application is Switch DR/CR, the journal entry in the table below is created to reverse the accrual.

GL Date: 13-Jan-2006
Account Entered DR Credited DR Accounted DR (USD) Accounted CR (USD)
Accrual Liability 100.00 - 100.00 -
Accrual Expense - 100.00 - 100.00

If the accrual reversal GL Date is First Day Next GL Period and the Reversal Method for the ledger and subledger application is Change Signs, then the following journal entry is created to reverse the accrual.

GL Date: 01-Feb-2006
Account Entered DR Credited DR Accounted DR (USD) Accounted CR (USD)
Accrual Expense (100.00) - (100.00) -
Accrual Liability - (100.00) - (100.00)

If the accrual reversal GL Date is Last Day Next GL Period and the Reversal Method for the ledger and subledger application is Change Signs, then the following journal entry is created to reverse the accrual.

GL Date: 28-Feb-2006
Account Entered DR Credited DR Accounted DR (USD) Accounted CR (USD)
Accrual Expense (100.00) - (100.00) -
Accrual Liability - (100.00) - (100.00)

See: Accrual Reversals, Oracle Subledger Accounting Implementation Guide

Line Accounting Reversals

Implementation of the accounting reversal functionality in the Financial Services Accounting Hub is discussed in the following sections:

Transaction Objects

To successfully invoke a line accounting reversal for a transaction distribution, the information stored in the transaction objects is different from that of a standard transaction object line.

To reverse the accounting impact of the original distribution, the accounting program must have access to the identifiers that were stored in the transaction objects when the reversed (original) distribution was first accounted. For all reversal distributions, the accounting program stores the reversed (original) distribution identifiers along with the reversal distribution identifiers in the distribution links table.

Accounting attributes enable you to pass the accounting reversals options to the accounting program. Assign sources to these accounting attributes for all event classes that you want to enable accounting reversals for.

For reversal distributions, the transaction object line must provide values for the following accounting attributes:

It is not necessary for the transaction objects to store any other line level sources except if standard accounting is required for the reversal distribution in addition to the line accounting reversal. In this case, the source mapped to the accounting attribute Line Accounting Reversal Option must contain the value B.

The processing of line accounting reversals does not affect the header level transaction objects. Users can use header level sources to create the subledger journal entry header description.

Accounting Program

When the accounting program encounters a line level transaction object with the Line Accounting Reversal Option set to Y, it does the following:

Uniqueness of Distribution Identifiers.

The accounting program does not enforce the uniqueness of distribution identifiers. Distribution identifiers must uniquely identify the transaction distribution or the accounting feature does not work.

Transaction Accounting Reversals

Populate the accounting attribute header Transaction Accounting Reversal Indicator with the value Y. The accounting program reverses all existing accounting for the transaction associated with the accounting event. Line extract objects do not need to be populated.

See: Transaction Accounting Reversal Accounting Attribute

Accounting Reversal Examples

The examples in this section illustrate the mechanism for accounting reversals. They are analyzed through the use of the following tables:

Assume that the event entity Invoice in the AMB has the First Distribution Identifier accounting attribute assigned to the Invoice Distribution Identifier standard source.

Example 1: Line Accounting Reversal Only

This section includes the following parts:

Invoice Validated

Consider an invoice that is entered into the system and validated on 10-Jan-2006. The table below lists the details of the invoice header.

Invoice Header
Supplier Name/Number Invoice Type Invoice Number
ABC Ltd./XYZ Invoice A-1234

The table below lists the details of the invoice distribution.

Invoice Distribution (Validated)
Invoice Distribution Identifier Invoice Distribution Line Number Invoice Line Type GL Date Amount Description
1234 1 Item 10-Jan-2006 1000 Standard Item
1235 2 Tax 10-Jan-2006 200 VAT @20%

The table below shows the simplified line level transaction object that stores the information for this distribution.

Invoice Validated Transaction Objects Lines
Invoice Distribution Line Number Accounting Reversal Option Invoice Distribution Identifier Invoice Line Type Invoice Entered Amount Description First Reversed Distribution Identifier
1 N 1234 Item 1000 Standard Item  
2 N 1235 Tax 200 VAT @20%  

The table below shows the subledger journal entry lines that are created for the invoice.

Invoice Validated Subledger Journal Entry Lines
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
6000 1 101 Liability 01.4300.000   1200 Lines 1 + 2
6000 2 101 Expense 01.6000.001 1000   Line 1
6000 3 101 Tax 01.6001.000 200   Line 2

The following subledger accounting distribution link table records how each of the transaction object amounts contributed to the subledger journal entry lines.

Financial Services Accounting Hub Distribution Link Table Lines
Entry Header Identifier Entry Line Number Ledger ID First Distribution Identifier Entered Amount Ledger Amount Accounting Reversal Option
6000 1 101 1234 1000 1000 N
6000 1 101 1235 200 200 N
6000 2 101 1236 1000 1000 N
6000 3 101 1237 200 200 N

Invoice Canceled

Assume the user cancels the invoice on 20th January, 2006. A new accounting event and invoice distributions are created for the invoice cancellation. The table below lists the details of the invoice header of this invoice.

Invoice Header (Canceled)
Supplier Name/Number Invoice Type Invoice Number
ABC Ltd./XYZ Invoice A-1234

The table below lists the details of the original (distribution identifiers 1234 and 1235) and new (distribution identifiers 1400 and 1401) distribution lines.

Invoice Distribution (Canceled)
Invoice Distribution Identifier Invoice Distribution Line Number Invoice Line Type GL Date Amount Description
1234 1 Item 10-Jan-2006 1000 Standard Item
1235 2 Tax 10-Jan-2006 200 VAT @20%
1400 3 Item 20-Jan-2006 -1000 Cancels Line 1
1401 4 Tax 20-Jan-2006 -200 Cancels Line 2

Assuming that an accounting reversal is required, the line level transaction object should store the following:

It is not necessary for the transaction object to store any other source values. The table below shows the line level transaction object for the lines that complete the reversal.

Invoice Canceled Transaction Objects Lines
Invoice Distribution Line Number Accounting Reversal Option Invoice Distribution Identifier Invoice Line Type Invoice Entered Amount Comment First Reversed Distribution Identifier
3 Y 1400 No value required No value required   1234
4 Y 1401 No value required No value required   1235

The Financial Services Accounting Hub takes account of the ledger level Reverse Side or Sign user preference when determining the side and sign of the subledger journal entry line amounts. The preference is set for a ledger within the context of an application.

In this example, assume that the preference is set to Reverse Sign. The table below shows the subledger journal entry lines for the cancellation.

Invoice Canceled Subledger Journal Entry Lines
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
20000 1 101 Liability 01.4300.000   -1200 Lines 3 + 4
20000 2 101 Expense 01.6000.001 -1000   Line 3
20000 3 101 Tax 01.4372.000 -200   Line 4

The corresponding distribution link table lines are shown in the table below.

Financial Services Accounting Hub Distribution Link Table Lines
Entry Header Identifier Entry Line Number Ledger ID First Distribution Identifier Entered Amount Ledger Amount Accounting Reversal Option
20000 1 101 1400 -1000 -1000 Y
20000 1 101 1401 -200 -200 Y
20000 2 101 1400 -1000 -1000 Y
20000 3 101 1401 -200 -200 Y

Example 2: Line Accounting Reversal and Standard Accounting, Separate Distribution

Assume that instead of canceling the invoice as in the prior example, the user adjusts one of the invoice distributions. The table below lists the header details of the adjusted invoice.

Invoice Header (Adjusted)
Supplier Name/Number Invoice Type Invoice Number
ABC Ltd./XYZ Invoice A-1234

The table below lists the distribution lines of the invoice.

Invoice Distribution (Adjusted)
Invoice Distribution Identifier Invoice Distribution Line Number Invoice Line Type GL Date Amount Description
1234 1 Item 10-Jan-2006 1000 Standard Item
1235 2 Tax 10-Jan-2006 200 VAT @20%
1600 3 Item 20-Jan-2006 -1000 Reverses Line 1
1601 4 Freight 20-Jan-2006 1000 Replaces Line 1

Assume that an accounting reversal is required to account for the reversal of the item line. The transaction objects contain an accounting reversal transaction object line for the reversal line and a standard transaction object line for the replacement distribution. The table below shows the transaction object lines of the adjusted invoice.

Invoice Adjusted Transaction Objects Lines
Invoice Distribution Line Number Accounting Reversal Option Invoice Distribution Identifier Invoice Line Type Invoice Entered Amount Comment First Reversed Distribution Identifier
3 Y 1600       1234
4 N 1601 Freight 1000 Replaces Line 1  

Assume that the application accounting definitions applied to the replacement distribution create subledger journal entry lines with the following Accounting Flexfields:

The table below shows the subledger journal entry lines for the cancellation.

Invoice Adjusted Subledger Journal Entry Lines
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
30000 1 101 Expense 01.6000.001 -1000   Accounting Reversal
30000 2 101 Expense 01.6000.000 1000   Standard Accounting
30000 3 101 Liability 01.4300.000   -1000 Accounting Reversal
30000 4 101 Liability 01.4300.000   1000 Standard Accounting

Since the liability lines cancel each other out, the Financial Services Accounting Hub eliminates them, leaving a subledger journal entry with two subledger journal entry lines.

The table below shows the corresponding distribution link table lines.

Financial Services Accounting Hub Distribution Link Table Lines
Entry Header Identifier Entry Line Number Ledger ID First Distribution Identifier Entered Amount Ledger Amount Accounting Reversal Option
30000 1 101 1600 -1000 -1000 Y
30000 2 101 1601 1000 1000 N
30000 3 101 1600 -1000 -1000 Y
30000 4 101 1601 1000 1000 N

Example 3: Standard Accounting and Line Accounting Reversal, Same Distribution

The previous accounting reversal example assumes that each time the user modifies a transaction that has already been accounted, the application creates new reversal and replacement transaction distributions.

However, it is not necessary to create new reversal and replacement transaction distributions to correctly process accounting reversals. The transaction object that creates the accounting reversal and replacement can use the same distribution link identifiers as the original transaction distribution.

This example assumes a bond that is mark to market (MTM) at the end of each business day.

Note: Mark-to-market is the act of recording the price of a security on a daily basis to calculate profits and losses or to confirm that margin requirements are being met; it reflects the current market value and not the book value.

The scenario is described below and in the following table:

Transaction Objects Lines for the Bond Inception, MTM, Reversal and Creation of New MTM
Event Type Event ID Distribution ID GL Date Amount Accounting Reversal Indicator Reversal Distribution ID
Bond Inception 102 1001 18-JAN-2006 100    
Bond MTM 103 1002 19-JAN-2006 5    
Bond MTM 104 1003 20-JAN-2006 3 B 1002

The table below describes the subledger journal entry lines for the bond inception with a GL Date of 18-JAN-2006.

Subledger Journal Entry Lines, 18-JAN-2006
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
30001 1 101 Asset 01.7010007.000 100   Standard Accounting
30001 2 101 Cash 01.7017002.000   100 Standard Accounting

In the above table, the total accounted amount is $100 for Debit and $100 for Credit.

The table below describes the subledger journal entry lines for the Bond MTM with a GL date of 19-JAN-2006.

Subledger Journal Entry Lines, 19-JAN-2006
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
30002 1 101 Asset 01.7010007.000 5   Standard Accounting
30002 2 101 Unrealized Gain 01.7017002.000   5 Standard Accounting

In the above table, the total accounted amount is $5 for Debit and $5 for Credit.

The Financial Services Accounting Hub takes account of the ledger level Reverse Side or Sign user preference when determining the side and sign of the subledger journal entry line amounts. The preference is set for a ledger within the context of an application.

In this example, it is assumed that the preference has been set to Switch Sides. The table below describes the subledger journal entry lines for the reversal of the previous MTM and the creation of the new MTM with a GL date of 20-JAN-2006.

Subledger Journal Entry Lines, 20-JAN-2006
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
30003 1 101 Asset 01.7010007.000   5 Accounting Reversal
30003 2 101 Unrealized Gain 01.7017002.000 5   Accounting Reversal
30003 3 101 Asset 01.7010007.000 3   Standard Accounting
30003 4 101 Unrealized Gain 01.7017002.000   3 Standard Accounting

For Account 701000, $5 is credited for the reversal of the original MTM and $3 is debited for the booking of the new MTM.

For Account 7017002, $5 is debited for the reversal of the original MTM and $3 is credited for the booking of the new MTM.

The table below shows the corresponding distribution link table lines for the Accounting Reversal Entry.

Financial Services Accounting Hub Distribution Link Table Lines
Entry Header Identifier Entry Line Number Ledger ID First Distribution Identifier Entered Amount Ledger Amount Accounting Reversal Option
30003 1 101 1003 5 5 Y
30003 2 101 1003 5 5 Y
30003 3 101 1003 3 3 N
30003 4 101 1003 3 3 N

Example 4: Transaction Accounting Reversal

The following is an example of a header level transaction accounting reversal (Transaction Accounting Reversal = Y).

The scenario is described below and in the following table:

Extract Lines for Both the Bond Purchase and Premium and Extract Header for Bond Transaction Reversal
Event Type Event Identifier Distribution Identifier GL Date Amount Transaction Accounting Reversal
Bond Inception 1000 1 09-Jan-2006 1000  
Bond Inception 1000 2 09-Jan-2006 100  
Bond Inception 1001   19-Jan-2006   Y

Note: Notice that both the Accounting Reversal Indicator and Reversal Distribution Identifier are Null.

Subledger Journal Entry Lines for the Bond Inception with a GL Date of 09-JAN-2006
Event Type Line Number Account Debit Credit
Bond Inception 1 9100000 1000  
Bond Inception 2 9100020 100  
Bond Inception 3 2010000   1100

The Total Accounted Amounts for the above table are as follows:

Subledger Journal Entry Lines for the Bond Reversal with a GL Date of 10-JAN-2006
Event Type Line Number Account Debit Credit
Bond Reversal 1 9100000   1000
Bond Reversal 2 9100020   100
Bond Reversal 3 2010000 1100  

The Distribution Links table (XLA_DISTRIBUTION_LINKS) below displays the link between the distributions on the transaction and the resulting journal entries.

Event Type Temporary Line Number
 Event Identifier Journal Entry Header Identifier Journal Entry Line Number Distribution Identifier Amount Reference Journal Entry Header Identifier Reversed Journal Entry Line Number
Bond Inception 1 1000 2000 1 1 1000 2000  
Bond Inception 2 1000 2000 2 2 100 2000  
Bond Inception 3 1000 2000 3 1 1000 2000  
Bond Inception 4 1000 2000 3 2 100 2000  
Bond Reversal -1 1001 2001 1   1000 2000 1
Bond Inception -2 1001 2001 2   100 2000 2
Bond Inception -3 1001 2001 3   1000 2000 3
Bond Inception -4 1001 2001 3   100 2000 3

The first two lines in the above table represent the creation of the two original debit subledger journal entry lines for the Bond Inception.

The third and fourth lines in the above table represent the creation of the one original credit subledger journal entry line for the Bond Inception. The distribution lines are added and summarized in the subledger journal entry line.

The fifth and sixth lines in the above table represent the reversal of the two debit subledger journal entry lines for the Bond Inception with a Journal Entry Header Identifier of 2000 and Journal Entry Line Numbers of 1 and 2 respectively. The Temporary Line Numbers are multiplied by -1 to reflect the reversal of the original lines.

The seventh and eighth lines in the above table represent the reversal of the one summarized credit subledger journal entry line for the Bond Inception with a Journal Entry Header Identifier of 2000 and a Journal Entry Line Number of 3. The Temporary Line Numbers are multiplied by -1 to reflect the reversal of the original lines.

Upgrade Case Scenario for Accounting Reversals

The upgrade case arises when a transaction distribution that has been accounted prior to the uptake of the Financial Services Accounting Hub is subject to an accounting reversal after the uptake of the Financial Services Accounting Hub.

Overview

Accounting reversal relies on distribution links to identify the prior accounting impact of transaction distributions. However, transactions accounted prior to the uptake of the Financial Services Accounting Hub do not have these links.

To support the accounting reversal of transactions accounted prior to the uptake of the Financial Services Accounting Hub, users can use specifically designed upgrade features. In the upgrade case, Financial Services Accounting Hub uses amounts and Accounting Flexfields stored in the transaction objects instead of deriving them from prior subledger journal entries. There are specific accounting attributes defined to deal with the accounting reversals upgrade case.

Assumptions

The accounting reversal upgrade case feature is based on the following assumptions:

Transaction Objects

For the accounting reversal upgrade case, the line level transaction objects must contain the following:

Instead of searching for distribution links, the Financial Services Accounting Hub creates accounting reversal lines based on the line transaction objects.

If a transaction object line populates both the accounting reversal upgrade debit and credit account accounting attributes, the Financial Services Accounting Hub creates two subledger journal entry lines for the transaction object line. If the transaction object line populates only one of the accounting reversal upgrade debit or credit account accounting attributes, one subledger journal entry line is created by the Financial Services Accounting Hub. In effect, the transaction object passes subledger journal entry lines directly to the Financial Services Accounting Hub.

Note that subledger journal entry lines created by the upgrade case do not have subledger journal entry descriptions or accounting classes.

Accounting Reversal Upgrade Case Example

The invoice shown below is the same as that used in previous examples. However, in this example, it has been accounted prior to the uptake of the Financial Services Accounting Hub.

Upgrade Case: Invoice Validated

The table below lists the details of the invoice header.

Invoice Header
Supplier Name/Number Invoice Type Invoice Number
ABC Ltd./XYZ Invoice A-1234

The table below lists the details of the invoice distribution.

Invoice Distribution (Validated)
Invoice Distribution Identifier Invoice Distribution Line Number Invoice Line Type GL Date Amount Description
1234 1 Item 10-Jan-2006 1000 Standard Item
1235 2 Tax 10-Jan-2006 200 VAT @20%

Since it was accounted prior to the upgrade, no transaction object and no distribution links exist. The table below lists the details of the subledger journal entry.

Invoice Adjusted Subledger Journal Entry Lines
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
6000 1 101 Liability 01.4300.000   1200 Lines 2 + 3
6000 2 101 Expense 01.6000.001 1000   Line 2
6000 3 101 Tax 01.4372.000 200   Line 3

Assume that the user now upgrades to the Financial Services Accounting Hub. All subsequent accounting is created using the Financial Services Accounting Hub.

Upgrade Case: Invoice Canceled

On 20-Feb-2006, the invoice is canceled. The table below shows the invoice header for this cancellation.

Invoice Header
Supplier Name/Number Invoice Type Invoice Number
ABC Ltd./XYZ Invoice A-1234

The table below shows the invoice distribution for the cancellation.

Invoice Distribution (Canceled)
Invoice Distribution Identifier Invoice Distribution Line Number Invoice Line Type GL Date Amount Description
1234 1 Item 10-Jan-2006 1000 Standard Item
1235 2 Tax 10-Jan-2006 200 VAT @20%
1400 3 Item 20-Feb-2006 -1000 Cancels line 1
1401 4 Tax 20-Jan-2006 -200 Cancels line 2

The transaction object can take one of two alternative formats depending on whether the debit and credit amounts are supplied on separate lines or merged into a single line. You can decide based on your own criteria whether to merge the debit and credit lines.

The table below lists the transaction object line details for the first format.

Upgrade Case: Invoice Canceled Transaction Objects Lines (Alternative 1 - Subledger Journal Entry Lines are merged)
Invoice Distr. Line Number Accounting Reversal Option Invoice Distribution Identifier Invoice Entered Amount First Reversed Distribution Identifier Reversed Upgrade Debit Account Reversed Upgrade Credit Account
3 U 1400 -1000 Not required for upgrade 01.6000.001 01.4300.000
4 U 1401 -200 Not required for upgrade 01.4372.000 01.4300.000

Alternatively, you need not merge the subledger journal entry lines. The table below lists the transaction object line details for the second format.

Upgrade Case: Invoice Canceled Transaction Objects Lines (Alternative 2 - Subledger Journal Entry Lines not merged)
Invoice Distr. Line Number Accounting Reversal Option Invoice Distribution Identifier Invoice Entered Amount First Reversed Distribution Identifier Reversed Upgrade Debit Account Reversed Upgrade Credit Account
3 U 1400 -1000 Not required for upgrade 01.6000.001  
4 U 1401 -200 Not required for upgrade 01.4372.000  
3 U 1400 -1000 Not required for upgrade   01.4300.000
4 U 1401 -200 Not required for upgrade   01.4300.000

Depending on the ledger level user preference, the Financial Services Accounting Hub creates subledger journal entry lines that reverse the side or sign of the reversed subledger journal entry lines.

Using the new distribution link identifiers, the Financial Services Accounting Hub creates distribution links that tie the Invoice Canceled invoice distributions to the Invoice Canceled subledger journal entry lines.

Assuming that the user has chosen to reverse the sign, rather than the side, the table below lists the details of the Invoice Canceled subledger journal entry. Since this is an upgrade case, there are no accounting classes on the subledger journal entry lines.

Upgrade Case: Invoice Canceled Subledger Journal Entry Lines
Entry Header Identifier Entry Line Number Ledger ID Accounting Class Account Debit Credit Comment
20000 1 101   01.4300.000   -1200  
20000 2 101   01.6000.001 -1000    
20000 3 101   01.4372.000 -200    

The corresponding distribution link table lines are shown below.

Upgrade Case: Invoice Canceled Financial Services Accounting Hub Distribution Link Table Lines
Entry Header Identifier Entry Line Number Ledger ID First Distribution Identifier Entered Amount Ledger Amount Accounting Reversal Option
20000 1 101 1400 -1000 -1000 U
20000 1 101 1401 -200 -200 U
20000 2 101 1400 -1000 -1000 U
20000 3 101 1401 -200 -200 U

Transaction Objects Example for Payables

To illustrate this example, consider the following invoice:

Invoice Number: A615243

Invoice Date: January 15th

Invoice Due Date: January 31st

The table below provides details of this invoice.

Invoice Details
Line No. Description Amount
1 Big Machine 200.00
2 Installation 100.00
3 VAT @ 10% 30.00
  Invoice Total 330.00

Assume that the invoice is in the ledger currency and that the VAT on Installation (line 2) is 50% recoverable.

The transaction object lines for this invoice are seen in the three tables shown below. Note that all three tables are components of the same transaction object lines.

Note: The sources shown in these tables are just a subset of the sources that should be made available.

Invoice Validated Related Sources
Transaction Objects Line No. Invoice Line No. Payment Line Type Invoice Line Type Entered Amount
1 1 Item   200.00
2 2 Item   100.00
3 3 Recoverable tax Item 20.00
4 3 Recoverable tax Item 5.00
5 3 Non Recoverable tax Item 5.00
Tax Distribution Related Sources
Transaction Objects Line No. Invoice Line No. Payment Line Type Tax Code Account Tax Name Recoverable Option Tax Rate
1 1 Item        
2 2 Item        
3 3 Recoverable tax 01.4700.000 STD Domestic Y 10.00
4 3 Recoverable tax 01.4700.000 STD Domestic Y 10.00
5 3 Non Recoverable tax 01.4730.000 STD Domestic N 10.00
Item Distribution Related Sources
Transaction Objects Line No. Invoice Line No. Payment Line Type Distribution Account Track as Asset Option Description
1 1 Item 01.6100.210 Y Big machine
2 2 Item 01.6000.210 N Installation
3 3 Recoverable tax 01.6100.210 Y Big machine
4 3 Recoverable tax 01.6000.210 N Installation
5 3 Non Recoverable tax 01.6000.210 N Installation

The above three tables demonstrate the following aspects of transaction object guidelines.

The following are some examples of requirements that could be met using the above sources:

The linking of related distributions extends across documents. Assuming that the invoice is paid taking a 10% discount, the transaction object lines are provided in the four tables shown below. Note that all four tables are components of the same transaction object lines.

Payment Issued Related Sources
Transaction Objects Line No. Invoice Line No. Payment Line Type Invoice Line Type Entered Amount (EUR)
1 1 Payment Item 200.00
2 1 Discount Item -20.00
3 2 Payment Item 100.00
4 2 Discount Item -10.00
5 3 Payment Recoverable tax 20.00
6 3 Payment Recoverable tax 5.00
7 3 Payment Non Recoverable tax 5.00
8 3 Discount Recoverable tax -2.00
9 3 Discount Recoverable tax -0.50
10 3 Discount Non Recoverable tax -0.50
Invoice Related Sources
Ext. Line No. Inv. Line No. Payment Line Type Invoice Line Type Invoice Type Invoice Number Invoice Date
1 1 Payment Item Standard A615243 15-Jan-06
2 1 Discount Item Standard A615243 15-Jan-06
3 2 Payment Item Standard A615243 15-Jan-06
4 2 Discount Item Standard A615243 15-Jan-06
5 3 Payment Recoverable tax Standard A615243 15-Jan-06
6 3 Payment Recoverable tax Standard A615243 15-Jan-06
7 3 Payment Non Recoverable tax Standard A615243 15-Jan-06
8 3 Discount Recoverable tax Standard A615243 15-Jan-06
9 3 Discount Recoverable tax Standard A615243 15-Jan-06
10 3 Discount Non Recoverable tax Standard A615243 15-Jan-06
Item Distribution Related Sources
Ext. Line No. Inv. Line No. Payment Line Type Invoice Line Type Distribution Account Track as Asset Indicator Description
1 1 Payment Item 01.6100.210 Y Big machine
2 1 Discount Item 01.6100.210 Y Big machine
3 2 Payment Item 01.6000.210 N Installation
4 2 Discount Item 01.6000.210 N Installation
5 3 Payment Recoverable tax 01.6100.210 Y Big machine
6 3 Payment Recoverable tax 01.6000.210 N Installation
7 3 Payment Non Recoverable tax 01.6000.210 N Installation
8 3 Discount Recoverable tax 01.6100.210 Y Big machine
9 3 Discount Recoverable tax 01.6000.210 N Installation
10 3 Discount Non Recoverable tax 01.6000.210 N Installation
Tax Distribution Related Sources
Ext. Line No. Inv. Line No. Payment Line Type Invoice Line Type Tax Account Tax Name Recoverable Indicator Tax Rate
1 1 Payment Item        
2 1 Discount Item        
3 2 Payment Item        
4 2 Discount Item        
5 3 Payment Recoverable tax        
6 3 Payment Recoverable tax 01.4700.000 STD Domestic Y 10.00
7 3 Payment Non Recoverable tax 01.4700.000 STD Domestic Y 10.00
8 3 Discount Recoverable tax 01.4730.000 STD Domestic N 10.00
9 3 Discount Recoverable tax 01.4700.000 STD Domestic Y 10.00
10 3 Discount Non Recoverable tax 01.4700.000 STD Domestic Y 10.00

Note that the payment discount amount is allocated to each of the invoice distribution or allocations.

The following are examples of requirements that could be met using the above sources.