AP changes in R12

Invoices

Invoice Header:Defines the common information about the invoice: invoice number and date, supplier information, remittance information, and payment terms. Information specified at the invoice header level defaults down to the line level, but can be overridden.

Invoice Lines:Defines the details of the goods and services as well as tax, freight, and miscellaneous charges invoiced by a supplier. There can be multiple invoice lines for each invoice header. The Lines Tab of the invoice Workbench captures all of the details for the invoice line necessary for accounting, as well as for cross-product integration with other Oracle EBS applications, such as Assets, Grants Accounting, Inventory, Projects, Purchasing, Property Manager, and Receivables.

New in R12 – allows Payables to enter additional information about the item purchasedthat may be Project or Asset related. Information entered would be integrated to otherapplications.

Invoice Distributions:Defines the source for an accounting entry generated from the invoice.

Trading Partner: Oracle has changed terminology in R12. A Supplier is known as a Trading Partner in R12.

Note: Not all areas of Oracle labels the Supplier as Trading Partner. A supplier can be referredto as either a Vendor, Supplier, or Trading Partner depending on the application and screen thatyou are working in. This can become confusing.

Bank Accounts

In 11i Bank Accounts were owned by AP, now they are owned by Cash Management.

eBusinessTaxIn 11i Oracle standard functionality was based out of User which determines tax by assigning Tax Codes at line level of invoice and Tax rules was controlled at underline code. There was global descriptive flex fields were captured for country-specific tax attributes. More important is most of the setup performed at OU level.

In R12 : A new module eBusinessTax determines tax based on facts about each transaction, this is reason why Oracle has introduced additional line information at invoice level. The module “ebusiness Tax” set and configure Tax rules which can be viewed. Tax attributes collected in fields on key entities. Configure tax rules once per regime and share with your legal entities

Tax Codes

Tax codes that are not part of a tax group represent the most straightforward migration flow of all existing options.  Tax codes in 11i become tax classification codes in Release 12.  The tax classification codes are entered on the transaction lines and the tax rate associated with the tax classification code is then applied to the transaction.

Behind the scenes, the upgrade process does several things to make this possible.

1)  A tax regime is created for each operating unit defined in 11i.  These tax regimes, named as 2 digit country code (from the Operating Unit Address) - tax, (ex: US-TAX) hold the tax setup that has been upgraded.

Note: Regimes created for use with integration partners such as Taxware and Vertex have a slightly different naming convention and are typically upgraded as "US-Sales-Tax-101"

2)  A Tax is created for each tax code

3)  A Tax Status is created for each tax code

4) A Tax Rate is created for each tax code

5)Tax codes are created and stored in a lookup table as "Output" tax classification codes (for O2C, Input for P2P)

6) The tax regime has a "subscription" defined to the operating unit(s) where taxes are to be calculated for the regime Country.

7)  A Tax "Rule" is then created as a "Direct rate rule".  This simple rule hard-codes the relationship between the tax classification code and the tax, tax status and tax rate.  When a transaction is entered and the user picks the tax classification code, the direct rate rule automatically retrieves and associates each of these items to the transaction and does the tax calculation.

Tax Groups

Tax groups are very similar in most regards to the tax codes except in a few key areas.  The chart below shows precisely how tax codes compare and contrast to tax groups in the migration process.  Note that in both cases the user enters the tax classification code, just as in 11i.  The key difference with tax groups is that the Direct Rate rule that is created has additional formulas that are used to determine when each of the underlying tax rates should apply.

Oracle Payments is an integration product. Source Products, such as Oracle Accounts Payable, use Oracle Payments setup information to default payment attributes to invoices during the invoice creation. These invoices are then selected based on the user-defined filters and submitted to Oracle Payments as a Payment Process Request. Oracle Payments uses the invoice information submitted in the Payment Request to create Documents Payable and then groups them into Payments and Payment Instructions for processing payments. This processed information is recorded in the database tables. The processed payment information is retrieved by Oracle Payments database views to generate the XML extract. The generated XML extract is used in conjunction with the RTF/ETEXT template by Business Intelligence Publisher to generate output.

Reports

--R11i Posted Invoice Register (APXINPIR) is still enabled in R12. It is replaced by the Payables Posted Invoice Register (APXPOINV) in R12 and should be disabled.

--R11i Posted Payment Register (APXPTDCR) is still enabled in R12. It is replaced by the Payables Posted Payment Register (APXPOPMT) in R12 and should be disabled.

--R11i Payables Transfer to General Ledger (APGLTRANS) is still enabled in R12. It is replaced by the Transfer Journal Entries to GL (XLAGLTRN) in R12 and should be disabled.

--R11i Payables Accounting Process (APACCENG) is still enabled in R12. It is replaced by Create Accounting (XLAACCPB) in R12 and should be disabled.

--R11i Accounts Payable Trial Balance (APXTRBAL) is still enabled in R12. It is replaced by Accounts Payable Trial Balance (APTBRPT) in R12 and should be disabled.

--R11i Payables Account Analysis Report (APXAAREP) is still enabled in R12. It is replaced by Account Analysis Report (XLAAARPT) in R12 and should be disabled.

Folders

All folders in R12 will have to be redefined.