This chapter covers the following topics:
In Release 12, the Oracle E-Business Tax module will manage tax across the E-Business Suite. In prior releases, Receivables managed the setup, defaulting and calculation of tax using tax codes, their associated rates and a hierarchy of defaulting options. This method of managing tax is still available to you in Release 12. During the upgrade, E-Business Tax migrates the tax codes to appropriate tax regime, rate and classification code entities so that your tax processing can work the same after the upgrade as it did before. If you choose to use the features of E-Business Tax, you can make the transition at your own pace.
In Release 12, there are new fields added to the customer, invoice and invoice lines entities that track tax attributes used by E-Business Tax. Many of these attributes were implemented with Global Descriptive Flexfields in prior releases and are upgraded to regular fields on these entities.
Also during the upgrade, E-Business Tax takes information from the AR invoice lines and creates summary and detail tax lines in the E-Business Tax repository. The tax lines are upgraded based on the time period you specify during the submission of the upgrade. For more information, refer to SLA Postupgrade section in this guide.
Additionally, many Global Descriptive Flexfields stored tax specific data have been migrated to the E-Business Tax data model. For more information about the Release 12 upgrade of E-Business Tax data, refer to the Oracle E-Business Tax chapter of this guide.
With the introduction of the Subledger Accounting (SLA) module in Release 12, Receivables will rely on the central SLA engine to create accounting entries. Receivables will continue to create accounting distributions, however, they are used as a source for the generation of the final accounting by SLA. You can trigger the generation of final accounting by selecting Create Accounting on the Tools menu. Once accounting has been created, you can view it by clicking View Accounting on the Tools menu.
During the upgrade, accounting options and their settings, and the existing accounting entries in the Receivables data model are moved to the new SLA accounting data model. Also during the upgrade, Receivables seeds default accounting definitions in SLA to replicate the accounting created in Release 11i.
If you have customizations based on the 11i AR accounting tables, you can continue to use them as long as you use the default accounting definitions provided by Receivables. If you choose to take advantage of the user-definable accounting definitions functionality provided by SLA, you need to transition your customizations to the SLA data model.
Receivables transactions created in Release 11i are upgraded based on a user-specified date range, with the default being one fiscal year or a minimum of six months. Optionally, users can choose to upgrade more data initially or run a postupgrade process to upgrade data for each ledger specifying the start period of the ledger. Refer to the Oracle Subledger Accounting chapter of this guide for more information about the upgrading of data to SLA.
Note: The SLA reports show the AR primary and MRC or secondary SOB upgraded data based on the entered date range.
Accounting reports run after the upgrade will display data differently depending on the following factors:
The transaction has been posted to GL.
The SLA accounting lines exist.
When running any Oracle Receivables reports that display accounting involving transactions that have been posted to GL, the following statements apply:
If SLA final accounting lines exist, then SLA accounting is displayed.
If SLA accounting lines do not exist, then AR distribution accounting is displayed.
When running any Oracle Receivables reports that display accounting involving transactions that have not been posted to GL, the following statements apply:
If SLA final accounting lines exist, then SLA accounting is displayed.
If SLA accounting lines do not exist, then no accounting is displayed and the following warning message is returned: "This report does not display transactions for which accounting has not yet been generated.”
Transaction Detail Report
AR Reconciliation Report
AR to GL Reconciliation
Potential Reconciling Items Report
Applied Receipts Journal
Unapplied Receipts Journal
Adjustments Journal
Credit Memo Gain or Loss Journal
Cumulative Activities Balance
Potential Reconciling Items
Open Items Revaluation Report
Aging - 7 Buckets Report
Aging - 4 Buckets Report
Inter Company Invoices Report
Sales Journal by Account
Sales Journal by Customer
U.S. Sales Tax Report (parameter for posting)
Receipt Journal Report
Invoice Exception (sort by balancing segment)
Invoices Posted to Suspense
Journal Entries
Inter Company Receipts
Aged Trial Balance - 7 Buckets - By Deduction
Aged Trial Balance - 7 Buckets - By LOB
Due to the introduction of Oracle Subledger Accounting, this form is no longer needed. Errors in GL accounting code combination can be identified by creating accounting in draft mode. Corrections can be made either by updating the underlying transaction data, or by changing the accounting definitions using the Accounting Methods Builder.
The upgrades to the integration with Oracle Payments for funds capture involve:
Migrated Remittance Formats
GDF Migration
The programs that controlled the formatting of remittances and bills receivables remittances are obsolete with Release 12 and the integration with Oracle Payments. The following table displays the mapping from seeded 11i.x AR Payment Formats to the new Release 12 Oracle Payments XML Formats.
Many payment features implemented in Release 11i using Global Descriptive Flexfields (GDF) will be implemented as integrated core features across Oracle Receivables, Payments and Cash Management in Release 12. It is important that you plan to review the setup relevant to each payment feature you plan to use.
To gain setup knowledge for Oracle Payments, refer to the Oracle Payments Implementation Guide.
Spain has a field named Charge Bearer on customer sites. This field is obsolete. Existing values are migrated to a new field, Bank Charge Bearer. This field is now standard in the Payment Details region of customer accounts and customer account sites. A new lookup type controls available values for the field. It is now user-extensible.
Germany has a field named Direct Debit Authorization Code on customer bank accounts. This field is obsolete. Existing values are migrated to a new field, Direct Debit Bank Instruction. This field is now standard in the Payment Details region of customer accounts and customer account sites. A new lookup type controls available values for the field. It is now user-extensible.
Portugal has a profile option of JEPT: Print Direct Debit Receipt Letter. The setting specifies whether the Portuguese Direct Debit Letter should be created automatically when the user runs the format of Portuguese Direct Debit File. This profile option is obsolete. It is replaced by the settings for Payer Notification in the new Payments Funds Capture Process Profile named Portuguese Direct Debit File Format.
There is a field for Magnetic Format Code on the Bills Receivable Remittances form, used only for the Spanish CSB32 Remittance format. This field is obsolete. The value for this field is migrated to the new XML Publisher Format template corresponding to the new Payments Spanish CSB32 Remittance Format.
Release 12 introduces direct integration with Oracle Payable for transacting all refunds with the exception of credit card refunds. Credit card refunds are transacted the same as in Release 11i by means of the generation and remittance of a negative miscellaneous receipt.
Balance-forward billing replaces the consolidated billing functionality; so all documentation will now refer to balance-forward billing.
During the upgrade, payment cycles will be created based on the cut-off dates of existing proxima payment terms and assigned to those payment terms. Balance forward billing payment terms cannot be assigned to transaction types and customer site uses. Therefore, during upgrade if a consolidated term was assigned at these levels, the upgrade script will override the assignment with a null value.
Customers that were enabled for consolidating billing will be enabled for balance-forward billing. If the payment term assigned could not be upgraded to a balance-forward-billing, payment term, that customer will not be enabled for balance-forward billing; the value for this check box will be null. This might occur if default payment term was not a proxima term and consolidated billing was not performed even though it was enabled.
Allow override of payment terms will cause a different action in Release 12. If allow override of payment terms is enabled, the payment term on the invoice can be changed to a non-balance-forward billing term. This means that the invoice will be processed separately from the balance forward bill. With consolidated billing, it would have been picked up on the bill, but the aging would have occurred based on the payment term of the invoice, not the bill.
Three concurrent programs are now needed to consolidate invoices:
Generate Balance Forward Bills program replaces Print Draft Consolidated Billing Invoices and Print New Consolidated Billing Invoices.
Confirm Balance Forward Bill program replaces Accept Consolidated Billing Invoices and Reject Consolidated Billing Invoices.
BPA Balance Forward Print Program replaces Reprint Consolidated Billing Invoices.
Consolidated billing was performed at the customer site level; so all customers converted to balance forward billing will be enabled at the site level. Following Upgrade, if you wish to implement balance forward billing at the customer account level, you will need to modify those records. See the Oracle Receivables User Guide for details.
Late charges are centrally calculated in Receivables, negating need for separate solutions in Oracle Financials for the Americas and Oracle Financials for Europe (Brazil and Scandinavia), as well as, Oracle Student Services.
Late charges can be derived as adjustments, invoices or debit memos. Prior to Release 12, adjustments were the only option in Receivables. The other Oracle products used interest invoices.
Global Flexfield setup values on the customer profile will migrate to these HZ tables in the TCA data model:
HZ_CUSTOMER_PROFILES
HZ_CUST_PROFILE_CLASSES
HZ_CUST_PROF_CLASS_AMTS
HZ_CUST_PROFILE_AMTS
The Interest Invoice feature becomes obsolete in Release 12, including tables, database triggers, packages, forms, reports and Application objects (profile options, concurrent requests, concurrent executables, menus, lookups, etc.). The GDF columns that exist on TCA tables (for example, JGZZ_ATTRIBUTE columns) will be obsolete.
The Accrue Interest check box on System Options form is retired in Release 12 because all charges are assumed to update the customer record and to be accompanied by accounting entries.
The new concurrent process, Late Charges Generate, replaces the code formerly called by the Dunning or Statements program to generate finance charges. The Late Charges Generate program can be run independent of other processes. Postupgrade, if late charges are to be included with Statements or Dunning, the late charges program should be included as part of a report set and run in final mode. Dunning is created via Oracle Advanced Collections in Release 12. For more information including late charges are dunning, see the Oracle Advanced Collections User Guide.
A new business purpose was created due to late charges creation being independent of dunning and statements. There will be an upgrade as follows:
If an account has a statement site and no dunning site, then an additional business purpose of Late Charges will be added to the statement site.
If an account has a dunning site and no statement site, then an additional business purpose of Late Charges will be added to the dunning site.
If an account has a dunning site and a statement site, then an additional business purpose of Late Charges will be added to the STATEMENT site only.
The following report has been obsolesced due to the new AP/AR Netting feature: AR Customer Supplier Netting Report.
An internal dummy bank has been seeded that will process receipts generated in AR when netting occurs. This bank does not require reconciliation since no cash is affected. The receipts will automatically close netted Receivables invoices. Users will access to OA Framework Netting forms via the seeded menu and the receipts workbench. These receipts cannot be modified, so there is no effect on existing users. Please refer to the Financials Common Modules section for details on the new AP/AR Netting feature.
A number of Release 11i features in Receivables are obsolete in Release 12.
A more robust, user-friendly product called Oracle Advanced Collections replaces the Receivables Collections Workbench. The user will automatically be redirected to the Advanced Collections forms if he is assigned the seeded Collections Sub-menu. If customer menus were created for collections users, you may need to modify your customer menus to point to Advanced Collections. See the Migration from AR Collections to Advanced Collections white paper (My Oracle Support Note #389443.1) for additional information.
The following forms will no longer be available: Account Overview, Aging, Correspondence, Customer Accounts, Customer Calls, and Scheduler. The Transaction Overview form will still be available through the Account Details form and the Transaction Workbench. The Account Details form has been modified to remove links to forms that are no longer available, such as Dunning History and Calls. This historical data is available via Advanced Collections.
The Activities form, which is available via Account Details, will now also be available via the Receipt Workbench and provide application activity history at both the receipt header and application level.
Reports retired: Call Actions, Collection Key Indicators, Collections Receipt Forecast, Collector Call History, Collector’s Follow Up, Customer Follow Up History, Collections by Collector, and Receipt Promises report.
Reports Modified: Bad Debt Provision Report, Disputed Invoice Report, Customer Credit Snapshot, and Customer Profiles.
The Dunning print program has been modified to only reprint Receivables historical days overdue dunning letters that may be needed due to legal reasons. The Program is called Dunning Letter Reprint-Historical Receivables Only. Dunning is replaced in Oracle Advanced Collections by a more robust and automated process that takes advantage of the XML reporting capabilities.
Trade Accounting has been replaced by Deductions Management functionality. The Deductions Management solution is delivered in partnership between Oracle Receivables, Oracle Trade Management, and Oracle Credit Management products. For more information about this solution, see E-Business Suite Solutions for Deduction Management, An Oracle White Paper Release 11i.10 (My Oracle Support Note #370763.1).
The system option to Enable Trade Accounting has been removed; Deductions Management will automatically be enabled if you setup Trade Management. A white paper has been created outlining the changes between Trade Accounting and the Deductions Management Solution.
Bills of exchange were originally implemented as a type of receipt, and therefore could not be systematically managed throughout the bill’s lifecycle. The Bills Receivable feature, introduced in Release 11i.3, replaces the bills of exchange functionality, creating unique documents that are managed via a comprehensive workbench.
If you have already converted to Bills Receivable, no action is required. If you have not, review the Bills of Exchange Obsolescence white paper (My Oracle Support Note #353280.1). Also refer to the Oracle Receivables User Guide for additional information.
Multiple Reporting Currencies (MRC) obsolescence involved removing the MRC functionality from the individual subledgers and centralizing it in SLA.
In the 11i release, AR maintained transaction amounts in their respective reporting currencies in its own tables and was able to provide reports for transaction information in MRC currencies by extracting information from the MRC tables.
In Release 12, the reporting currency functionality is centralized in SLA, and SLA stores only accounting amounts in reporting currency and not transaction amounts. Therefore, the transaction reports run in the context of the primary ledger and do not take into account the secondary ledger and the concept of reporting currencies. The transaction reports cannot be run for the reporting ledger because the data for the same is not available in the current data model.