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 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:
Identifies accounting events eligible to be processed
Populates the events temporary table
Raises the oracle.apps.xla.accounting.extract workflow business event, which can only be used for customizations
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.
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:
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.
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:
Location A uses account segment value 1000.
Location B uses account segment value 2000.
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 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:
Create Accounting Overview, Oracle Subledger Accounting Implementation Guide
Defining Segment Qualifiers, Oracle General Ledger User Guide
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.
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:
Oracle Payables Example: Users can elect to use the Distribution line type source to determine the subledger journal line type. For example, use the Freight journal line type if the Distribution line type is equal to Freight. The Distribution line type must therefore be defined as a source and be included in the transaction objects to allow users to create this condition.
Oracle Inventory Example: Users may want to use a purchase price variance account for an inventory issue only when the Distribution line type is equal to Invoice Price Variance.
Oracle Receivables Example: Users can elect to use a specific revenue account based on a transaction type.
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
This section includes the following parts:
The Financial Services Accounting Hub classifies sources as follows:
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.
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:
System variables, such as Today's Date or Language
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.
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
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 are source values that are never translated into more than one language. Examples of untranslated sources include all numbers, dates, and lookup codes.
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 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.
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:
Transaction Objects Headers
Transaction Objects Multi Language Support Headers
Transaction Objects Lines
Transaction Objects Multi Language Support Lines
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
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.
This section describes the following 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 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 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 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.
The transaction object columns must be one of the following:
The appropriate primary key columns must be defined in all transaction objects. The table below lists the primary key column definitions.
Column Name | Description | Data Type | Comment |
---|---|---|---|
EVENT_ID | Event identifier | Integer | There should be one row per event. |
Column Name | Description | Data Type | Comment |
---|---|---|---|
EVENT_ID | Event identifier | Integer | |
LINE_NUMBER | Transaction objects line number | Integer | Unique within the event identifier (ID) |
Column Name | Description | Data Type | Comment |
---|---|---|---|
EVENT_ID | Event identifier | Integer | |
LANGUAGE | Language code | Varchar(30) | Corresponds to the language column in _TL tables |
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.
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 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:
Long
Raw and Long Raw
Rowid
MLSLABEL
See: Create Sources and Assignments
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:
Sources common to several event classes
A single transaction object can store sources that are common to several event classes. Such transaction objects can be assigned to multiple event classes. Sources that are specific to a single event class can be stored in a transaction object that is assigned only to that particular event class.
Sources that are conditionally available
Different transaction objects store sources that are populated under different conditions. For example, a transaction object can store all sources that are populated when an optional foreign key is populated. Other transaction objects can store sources that are always available.
Column limit
If the number of sources that correspond for a transaction object type exceeds 1000, multiple transaction objects are necessary to store them.
Not all transaction objects need to return rows for all transaction object headers and lines.
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:
For each event class, define at least one header transaction object as always populated.
If line transaction objects are assigned to an event class, define at least one of them as always populated.
If MLS header or MLS line transaction objects are assigned to an event class, it is not necessary for any of them to be always populated; however, there must be at least one corresponding header or line transaction object assigned to the same event class.
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.
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.
In the Accounting Event Class Options window, define reference objects and define relationships between reference objects and transaction objects.
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
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:
Validates transaction objects
Creates sources
Assigns sources
Duplicates column definitions
See: Create and Assign Sources Program
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.
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.
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:
Accounting Attributes Guideline
Accounting attributes values are needed by the accounting program to successfully create subledger journal entries.
Distribution Identifiers Guideline
Distribution identifiers should be stored in the transaction object as accounting attributes.
Multiperiod Accounting Guideline
To invoke multiperiod accounting for a transaction distribution, the transaction object should populate multiperiod accounting attributes with the appropriate values.
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.
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.
Foreign Currency Amounts Guideline
Appropriate currency and rate information should be stored in the transaction object.
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.
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.
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.
Independence from Accounting Method Guideline
The transaction object should be insensitive to the application accounting definitions that determine how transactions are accounted.
Balanced Debits and Credits Guideline
Balanced debits and credits should not be included in the transaction object.
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.
Third Party Control Accounts Guideline
Third party data should be stored in the transaction object as accounting attributes.
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.
Ensure that sources stored in the transaction object are stored in a consistent manner across different types of transactions.
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.
The transaction object should store flexfield column values as sources if they can be used in creating subledger journal entries.
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.
Existing setup accounting options should be stored in the transaction object as sources.
Internal Identifiers Guideline
In general, values that are never displayed to users should not be stored in the transaction object.
System sources are independently populated by the accounting program. They are not stored in the transaction object.
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.
The accounting program uses accounting attributes values to create subledger journal entries. The types of accounting attributes values are as follows:
Values that are subject to special processing or values that are stored in named columns in journal entry headers and lines
Examples of accounting attributes of this type are Entered Currency Code and Entered Amount.
Values that control the behavior of the accounting program when processing a specific accounting event or transaction object line
Examples of accounting attributes of this type are Accounting Reversal Indicator and Multiperiod Option.
Each accounting attribute is associated with a level:
Header to create subledger journal entry headers
Line to create subledger journal entry lines
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.
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.
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.
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:
When the accounting attribute value can be derived from more than one source
For example, in a cross-currency receipt application transaction, the value of the accounting attribute Currency Code can vary from journal line to journal line within a single journal entry.
The currency code accounting attribute can be derived from either the Invoice Currency Code or the Receipt Currency Code standard sources depending on the journal line type. Typically, the Receivable journal line type uses the Invoice Currency Code while the Cash Clearing journal line type uses the Receipt Currency Code.
When the accounting attribute may be relevant to the processing of one journal line type and not to another
For example, values for the accounting attribute Statistical Amount are relevant to journal line types used to record invoice expenses but not for journal line types used to record invoice liability.
Implementers and users can define journal line type accounting attributes assignments.
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.
The table below describes the 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 are presented in functional groupings in table format. The table below describes the columns used in the tables.
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. |
The table below describes accounting attributes for entered currency.
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:
The table below describes accounting attributes for ledger currency.
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:
The table below describes 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.
The table below describes 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
The table below describes 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
The table below describes 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
The table below describes 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:
Next Day
The GL date of the accrual reversal will be the day following the GL date of the accrual entry. If there is a transaction calendar assigned to the ledger, this will be the next business day.
First Day Next GL Period
The GL date of the accrual reversal entry will be the first day of the following period. If there is a transaction calendar assigned to the ledger, this will be the first business day.
Last Day Next GL Period
The GL date of the accrual reversal entry will be the last day of the following period. If there is a transaction calendar assigned to the ledger, this will be the last business day.
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
The table below describes 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:
Defining Segment Qualifiers, Oracle General Ledger User Guide
The table below describes the 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.
The table below describes 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.
The table below describes the 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.
The table below describes 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
The table below describes 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.
The table below describes 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
The table below describes the 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.
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.
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.
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:
The entered currency is SEK.
The conversion rate is 0.1.
The transaction rounding reference is 400067.
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.
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:
The rounding class is Liability.
The entered currency is SEK.
The conversion rate is 0.1.
The transaction rounding reference is 400010.
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 |
The table below describes 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.
The table below describes 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:
Grouping transactions by the budgetary control code
Enabling both allocations and business flows to coexist in the same transaction line
For example, burdening that is computed on the raw cost coming from an invoice is allocated to the invoice, yet both the invoice and the burdening may have a business flow relative to a purchase order or a requisition.
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:
To establish a link between transaction distributions and subledger journal entry lines by creating reconciliation reports between the subledger transactions and their corresponding accounting
To support custom sources
Since the distribution identifier represents the lowest level of detail available in the transaction data model, it is possible to create PL/SQL functions that return any data item related to the transaction distribution, transaction, or set up.
See: Custom Sources, Oracle Subledger Accounting Implementation Guide
To support the accounting reversals feature by identifying distributions whose accounting should be reversed
To support the business flows feature by identifying journal entries for prior transactions in the business flow
See: Business Flows, Oracle Subledger Accounting Implementation Guide
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.
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 |
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:
Transaction Header table and Distribution table (owned by subledger applications)
Transaction Objects Lines table (owned by subledger applications)
Subledger Journal Entry Lines table (owned by the Financial Services Accounting Hub)
Financial Services Accounting Hub Distribution Link Table Lines table (owned by Financial Services Accounting Hub)
The table below shows the header details for a Receivables transaction.
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 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.
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.
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.
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 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.
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:
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.
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.
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.
Appropriate currency and rate information should be stored in the transaction object. The following accounting attributes relate to foreign currency transactions:
Entered Currency Code
Entered Amount
Accounted Amount
Conversion Rate
Conversion Date
Conversion Rate Type
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:
Stand alone foreign currency transactions: foreign currency transactions that are not applied to other transactions
Foreign currency transactions that are applied to other transactions
These transactions give rise to the following scenarios:
Foreign currency transactions applied to transactions of the same currency
Cross-currency transactions: transactions applied to transactions of a different currency
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.
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 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.
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 |
There are two distinct scenarios that can result in a gain or loss:
Foreign Currency Transactions Applied to Transactions of the Same Currency
Cross-Currency Transactions: Transactions Applied to Transactions of a Different 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:
Conversion Rate
Conversion Date
Conversion Rate Type
Accounted Amount
Entered Amount
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.
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.
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.
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.
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.
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 |
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.
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.
The types of rounding errors are:
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
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.
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 |
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.
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 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.
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.
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.
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.
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
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 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:
If an account derivation rule derives a control account, the accounting program verifies that the account is set in General Ledger to support Supplier, Customer, or Any, and validates that the third party accounting attributes are populated as described in the table below.
Accounting Attribute | Supplier | Customer |
---|---|---|
Third Party Type | S | C |
Party Identifier | AP_SUPPLIERS.VENDOR_ID | HZ_CUST_ACCOUNTS_ALL.CUST_ACCOUNT_ID |
Party Site Identifier | AP_SUPPLIER_SITES_ALL.VENDOR_SITE_ID | HZ_CUST_SITE_USES_ALL.SITE_USE_ID |
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.
The business flow feature ensures that accounting information, such as Accounting Flexfields, are automatically copied from the previous transaction in the business flow.
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:
The subledger associated with the third party control account and the subledger of the journal entry must be the same.
The third party information must not be null.
If an error is returned, the Create Accounting program does not create a subledger journal entry.
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
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
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
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:
Reduce the number of source values that need to be stored in the transaction objects
As part of the definition of standard sources, you can optionally specify a lookup type. If a lookup code is defined as a source that is assigned a lookup type, there is no need to define a source for the corresponding meaning. The Financial Services Accounting Hub converts the lookup code into the appropriate and translated meaning whenever it is displayed to users.
Help prevent errors by displaying valid, user friendly names for sources that are lookup codes
Users select from the list of valid values.
Overcome many of the restrictions associated with translated sources
When defining conditions in the AMB, the Financial Services Accounting Hub displays the translated meaning to users and stores the untranslated lookup code. Since the untranslated lookup code is used as the condition, conditions function independently of the language of the user or the ledger.
Payables Example: The transaction object should store the Invoice Line Type lookup code and not the corresponding (translated) meaning.
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.
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.
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.
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.
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:
Detail Tax Line Reference
Summary Tax Line Reference
Detail Tax Distribution Reference
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.
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.
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.
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.
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.
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;
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
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:
Cash Basis
Accrual Basis
Southern European Permanent Inventory
Southern European Non Permanent Inventory
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:
Distribution identifiers, a minimum set of surrogate keys, should be stored in the transaction objects.
Translated sources and value sets (surrogate keys or internal codes) are stored in the transaction objects but not displayed to users.
See: Translated Sources, Lookup Types, and Value Sets Guideline
The code combination identifiers of key flexfields and Accounting Flexfields are stored in the transaction objects but not displayed to users.
See: Flexfields Guideline
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 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 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.
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 |
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 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.
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 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:
Setting up Subledger Accounting Options, Oracle Subledger Accounting Implementation Guide
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.
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.
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.
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.
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
Implementation of the accounting reversal functionality in the Financial Services Accounting Hub is discussed in the following sections:
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:
The Accounting Reversal Option must contain the value Y.
Distribution identifiers of the reversed (original) distributions:
Reversed Distribution Link Type
Reversed Distribution Identifiers
Distribution identifiers of the reversal (new) distributions:
Distribution Link Type
Distribution Identifiers
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.
When the accounting program encounters a line level transaction object with the Line Accounting Reversal Option set to Y, it does the following:
Uses the Reversed Distribution Identifiers to identify all subledger journal entry lines created by the reversed transaction distributions
Generates subledger journal entry lines that reverse the accounting impact of the reversed (original) distributions
These lines are created with information in tables as follows:
Derive entered, base, and statistical amounts from the distribution link table.
Derive Accounting Flexfield, accounting class, third party identifiers, description, and conversion rate information from the subledger journal entry lines table.
Creates distribution links that link the reversal (new) distributions with the new subledger journal entry lines
Creates standard accounting for the transaction distribution in addition to the line accounting reversal if the line Accounting Reversal indicator contains the value B
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.
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
The examples in this section illustrate the mechanism for accounting reversals. They are analyzed through the use of the following tables:
Invoice Header (owned by the Financial Services Accounting Hub)
Invoice Distribution (owned by the Financial Services Accounting Hub)
Transaction Objects (owned by subledger applications)
Subledger Journal Entry Lines (owned by subledger applications)
Distribution Link Table Entries (owned by subledger applications)
Assume that the event entity Invoice in the AMB has the First Distribution Identifier accounting attribute assigned to the Invoice Distribution Identifier standard source.
This section includes the following parts:
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.
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 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 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.
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.
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 |
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.
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 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:
For the lines that complete the reversal, set the transaction object line column Accounting Reversal Option to Y.
Populate the reversed distribution identifier columns with the distribution identifiers of the reversed (original) transaction distributions.
Populate the standard sources that are mapped to the distribution identifier accounting attributes with the distribution identifiers of the reversal transaction distributions.
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 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.
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.
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 |
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.
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 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 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:
Liability account that is the same as the original
Expense account that is different from the original
The table below shows the subledger journal entry lines for the cancellation.
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.
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 |
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:
01/18/06: Bond Inception. The original bond price is $100.
01/19/06: Bond market price is $105. An MTM of $5 is booked to adjust the bond price.
01/20/06: Bond market price is $103. The previous MTM is reversed and a new MTM of $3 is booked.
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.
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.
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.
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.
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 |
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:
01/09/06: Bond is purchased (Bond Inception) with an issue price of $1000 and a premium of $100.
01/10/06: The entire transaction is reversed (Bond Reversal). The corresponding extract header is marked as a transaction accounting 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.
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:
Debit = 1100
Credit = 1100
Event Type | Line Number | Account | Debit | Credit |
---|---|---|---|---|
Bond Reversal | 1 | 9100000 | 1000 | |
Bond Reversal | 2 | 9100020 | 100 | |
Bond Reversal | 3 | 2010000 | 1100 |
Debit = 1100
Credit = 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.
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.
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.
The accounting reversal upgrade case feature is based on the following assumptions:
Implementers can create reversal distributions that have access to the entered amounts, ledger amounts, and Accounting Flexfields for the subledger journal entry lines that are subject to the accounting reversal.
Implementers can derive transaction object lines for the reversed distributions that contribute to no more than two subledger journal entry lines, one debit and one credit.
Note: A transaction amount such as an invoice line can contribute to any number of journal entry lines. Typically, however, transaction amounts contribute to no more than two journal entry lines; for example, a liability line and an expense line.
Note: The restriction for the upgrade case dictates that the Financial Services Accounting Hub can only deal with cases where a transaction amount contributes to two journal entry lines.
For the accounting reversal upgrade case, the line level transaction objects must contain the following:
The value U for the Accounting Reversal Option accounting attribute
The following line accounting attributes that are defined to specifically deal with the upgrade case:
Reversed upgrade debit account
Reversed upgrade credit account
The standard sources mapped to the following accounting attributes:
Entered amount
Ledger amount
Rate information
Statistical amount
Third party identifiers
Distribution identifiers
Note: In the upgrade case, it is not necessary to populate the transaction object line columns: Reversed Distribution Link Type and Reversed Distribution Identifier.
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.
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.
The table below lists the details of the 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 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.
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.
On 20-Feb-2006, the invoice is canceled. The table below shows the invoice header for this cancellation.
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 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.
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.
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.
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.
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 |
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.
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.
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 |
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 |
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 transaction object lines are at the lowest level of detail.
For example, the VAT is allocated to each of the item distributions.
The transaction object lines contain values for sources drawn from the transaction distribution or allocation and related transaction or distributions.
For example, the tax distributions contain source values from the item distribution to which they are related.
The following are some examples of requirements that could be met using the above sources:
Nonrecoverable tax account should be the same as the item expense account. (The account derivation rule uses line type Non Recoverable Tax and item distribution account.)
The AMB supports two alternative ways of achieving this:
Users can create a single subledger journal entry line which includes the item and related Non Recoverable Tax amount. (The journal line type condition includes line types Item and Non Recoverable Tax.)
Users can create two subledger journal entry lines (Item and Non Recoverable Tax) that use the same account derivation rule.
See: Account Derivation Rules, Oracle Subledger Accounting Implementation Guide
Non Recoverable Tax account should use an account associated with the tax code. (The account derivation rule uses line type Non Recoverable Tax and tax code account.)
Liability account should be different for asset and expense items. (The account derivation rule uses line types Item, Non Recoverable Tax, and the Track as Asset flag.) To meet this requirement, the invoice distribution allocation Track as Asset option must be available for both the Invoice Validated and Payment Issued transaction objects.
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.
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 |
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 |
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 |
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.
Liability account should be different for asset and expense items. (The account derivation rule uses line type Payment, allocation types Item, Non Recoverable Tax, and Track as Asset flag.)
Discount account for Non Recoverable Tax should be the same as the item expense account. (Account derivation uses line type Discount, allocation type Non Recoverable Tax, and the item distribution account.)