This chapter covers the following topics:
Oracle Subledger Accounting gives users the ability to create the accounting definitions to address their specific accounting requirements. Users that do not have specific requirements can use the seeded accounting definitions that are provided out of the box.
When you use Oracle Subledger Accounting out of the box, you can generate the accounting equivalent to the one generated by Oracle E-Business Suite applications in Release 11i. To use Oracle Subledger Accounting, refer to the Oracle Subledger Accounting Implementation Guide.
If you use Oracle Subledger Accounting with the Oracle E-Business Suite subledgers, you can tailor the accounting journal entries to take full benefit of the Subledger Accounting features as follows:
Modify and customize all the elements of the journal entries (descriptions, reference data).
Modify and define new account derivation rules to generate the corresponding account based on different pieces of information present in the transaction.
Assign different accounting methods to different ledgers.
For functional information on the Oracle Subledger Accounting, refer to the Oracle Subledger Accounting Implementation Guide.
You can use the Oracle Financial Services Accounting Hub to create subledger accounting for third-party applications. This allows you to take advantage of the full potential of the Oracle Subledger Accounting engine to generate accounting journal entries in a consistent way across your Oracle and third-party applications.
Note: The Oracle Financial Services Accounting Hub is licensed separately.
For functional and technical information on the Oracle Financial Services Accounting Hub, refer to the Oracle Financial Services Accounting Hub Implementation Guide.
Each Oracle subledger has adopted a different strategy concerning the upgrade of accounting data into Subledger Accounting, based on functional considerations:
No Upgrade - No historical accounting data is upgraded into Subledger Accounting.
Partial Upgrade - Some historical data is upgraded into Subledger Accounting. In this case, the range of periods to be upgraded is defined by Oracle by default as one fiscal year worth of data, and can be changed by the user to upgrade more data based on the specific requirements. For more details, refer to the Oracle E-Business Suite Upgrade Guide: Release 11i to Release 12, "Preparing for the Upgrade," Financials and Procurement Tasks, Subledger Accounting.
Full Upgrade - In this case, all the historical accounting data existing in the subledger is upgraded into the Subledger Accounting.
Note: When running the Subledger Accounting Upgrade program for EMEA VAT, rerun the SLA upgrade as required to process all accounting since the earliest final reported transaction date.
The following table shows the upgrade mode for each subledger:
| Subledger | Upgrade Mode |
| Payables | Partial upgrade |
| Receivables | Partial upgrade |
| Assets | Partial upgrade |
| Cost Management (includes Purchasing and Inventory) | Partial upgrade |
| Projects | Partial upgrade |
| Global Accounting Engine | Full upgrade |
| Loans | Full upgrade |
| Processing Manufacturing | No upgrade |
| Cash Management | No upgrade |
| Property Management | No upgrade |
| Federal/Public Sector | No upgrade |
This section describes the SLA postupgrade process.
You can run the SLA postupgrade process to upgrade existing data at any time after the upgrade. Review the following sections and your existing requirements to plan your postupgrade strategy.
To avoid a long downtime period, the user can choose to upgrade only a subset of the accounting data, if, for example, historical data do not need to be permanently available for daily operations. This decision has a direct impact on hardware resources because less data requires less storage space. During normal business operations, however, some situations may require historical data to be available. For example, if the user needs to reverse an old invoice, Oracle Subledger Accounting requires the original accounting data for the invoice to generate the correct accounting reversal.
The SLA postupgrade process allows the user to upgrade accounting data that was not upgraded as part of the downtime upgrade process. This can be performed at any time and for any number of periods. For example, the user may want to run the SLA postupgrade process for a complete year or for only one period.
At any time after the downtime upgrade has been run, the user may experience the need to access some accounting data that has not been upgraded during the Subledger Accounting upgrade (because the corresponding period was not included in the range of periods to be upgraded). There may be many reasons for this:
The user needs to run a report or perform a query that requires the accounting data that has not been upgraded.
A transaction that had already been accounted is updated and the Subledger Accounting program requires some information from the original journal entry to create the new journal entry.
For example, an invoice has been accounted in July 2005 and the journal entry has been generated in the same period. But the journal entry has not been upgraded because only the data for the fiscal year 2006 has been upgraded. When a new transaction occurs against the invoice (such as a cancellation or a payment) and the new journal entry requires some information from the original journal entry (such as the liability account), Subledger Accounting requires the existence of the original journal entry. In this case, the user has the possibility of running the SLA postupgrade process to upgrade the accounting data for the corresponding period.
Because the SLA postupgrade process is run while the system is up and running, it is important that users consider the following elements when deciding the number of periods to upgrade:
The periods to be upgraded must be consecutive, so the date entered by the user is used to determine the initial period to be upgraded; all the periods between this period and the first upgraded period are upgraded by the SLA postupgrade process. For example, consider that the first upgraded period is JAN-2006 and the user enters 10-JUL-2005 as the initial date. (This date belongs to the period JUL-2005) All the periods between JUL-2005 and JAN-2006 will be upgraded.
Since the system is up and running, and the users are performing the daily operations, it is more efficient to run the upgrade during the downtime than to run the SLA postupgrade process. The user must take this into account when making the decision about the number of periods to upgrade.
It is important to consider the impact on resources when determining the upgrade strategy:
The SLA postupgrade process runs at the same time as the daily operations. If the upgrade is run for a large volume of data, the impact on overall system performance may be an important consideration.
A downtime upgrade can process a large volume of data in a more efficient way. The length of the downtime period, however, increases as the volume of data increases.