c






 

÷
 

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.

÷
  
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 purchased
that may be Project or Asset related. Information entered would be integrated to other
applications.

÷
 
 
Defines the source for an accounting entry generated from the invoice.


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

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

   

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

   
In 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     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 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.

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 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.


   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.

 
„
 

--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.

! 


All folders in R12 will have to be redefined.