This action might not be possible to undo. Are you sure you want to continue?
In R12, Oracle Payables has made some significant changes in the following areas.
• Supplier Representation in TCA (Trading Community Architecture)
• Invoice Lines
• Payment Process
• AP-AR Netting
Supplier Representation in TCA
Trading Community Architecture is a data model that allows the deploying
company to maintain information about its parties (customers, suppliers, banks etc) and
their relationships with the deploying company in a centralized place, thereby providing a
single source of truth. It also allows easier cross-product integration.
• New user interface presents a clear distinction between the supplier’s
company details and terms and controls for the trading relationship.
• Managing the attributes specific to particular functional areas such as Oracle
Payables, Purchasing and Receiving can be controlled with the use of
• Adding new locations or relationships with additional operating units is
• Each supplier is associated with a party and each supplier site is associated
with a party site.
• Addresses can be entered and formatted based on country specification.
• When new suppliers are created the system creates a TCA party behind the
scenes. The information that will be stored in TCA includes supplier name
and legal information, address and contact information. The parties are created
with a party usage of “supplier”
• Procurement and Payables specific attributes like terms and conditions,
accounts etc. are maintained in the supplier sites tables.
• Some payment and tax related information is no longer maintained in the
supplier sites tables - it was moved to the appropriate product tables (Oracle
Payments, Oracle E-business tax).
• Existing suppliers, sites or locations and their contact information are
automatically created in TCA.
• Existing tables that hold the supplier information are moved to a new set of
• New views, based on the old supplier table names have been added for
• When a supplier or supplier site is merged, the associated party or party site
does not change.
• During the supplier merge process, when a supplier site is “copied” from one
supplier to a different supplier, a new supplier site must be created. Hence, a
new party site will also be created.
• When merging suppliers, supplier merge should be performed before initiating
the party merge.
• Supplier or supplier site merge does not affect contacts. The contacts are
always transferred to the merged supplier site specified in the supplier merge
• Employees that were defined as suppliers in prior releases will not be
migrated, as their information would already exist in TCA.
• Supplier open interface processes are enhanced to support the creation of TCA
entities while importing suppliers. The creation of supplier bank accounts is
also supported from the supplier open interface.
The addition of invoice lines allows Oracle Payables to better model the paper or
electronic business document by representing the goods or services, as well as tax, freight
and other charges. The new invoice structure also more accurately models Oracle
Procurements PO shipment, allowing for improved allocation of charges, as well as
enhancing the matching function.
• The new Invoice Workbench now contains a multi-record block to represent
the invoice lines. In a separate window, users can enter one or more
distributions for every invoice line.
• Redesigned matching windows for PO/Receipt matching can be invoked from
the Invoice Workbench. Invoice lines that were generated by matching will
generate distributions at the time of match.
• New windows support price/quantity/invoice corrections.
• Freight/miscellaneous lines created automatically via request to the matching
process from the matching windows do not automatically generate
distributions at line creation time.
• Tax, freight, and miscellaneous type invoice lines can be prorated to all item
lines on an invoice.
• Users can enter freight at the invoice header and then prorate it across all item
lines on the invoice.
• Users can also do a quick match by entering just the PO number on the
invoice header. In this case, the invoice lines are automatically created.
• With the new invoice lines model, the R12 multi-period accounting is realized
at the invoice line level. Once Subledger Accounting is configured for multi-
period accounting, users can specify the deferred accounting period as a
parameter for each individual invoice line. To invoke this feature, users check
the “Deferred Option” box and specify the deferred period type, start date and
number of periods. Later on, when the accounting records are created for this
invoice line and distribution, a series of accounting records will be generated
reflecting the fact that the invoice expense is first recorded in an accrual
account then moved into expense account periodically.
• No new setup steps are required for using Invoice Lines.
• The standard upgrade process creates one invoice line for every distribution
existing in the 11i Payables distribution table.
• Exchange rate variance (ERV) and invoice price variance (IPV) amounts
become separate distributions in the upgrade process and so, are no longer
part of the item distributions.
• Charge (tax/freight/miscellaneous) distributions are created at the maximum
level of detail to represent detailed allocation information.
• In prior releases, the allocations were managed by a charge allocation table
which is now obsolete,
Payment Process Enhancements
The payment process has been significantly enhanced in Release 12. The following are
some of the new enhancements that were made in this release:
• More robust and flexible payment processing engine
• Improved visibility into payment processing via the centralized Payments
• Improved pay run automation
• Improved pay run management tools:
o Enhanced cash management report
o Comprehensive selected invoice information
o Improved online inquiry of selected invoices
• Process payments for multiple operating units from single responsibility
• A new Selected Invoices page displays summary and detail information used
to view and analyze invoices selected in a pay run.
• Powerful search tools improve online inquiry to invoices that you may want to
review, modify, or remove from a pay run.
• Users can now view invoices that were not selected due to various reasons
• A Payment Dashboard empowers your payment manager to monitor all
current pay run processing and gives them visibility to payment processes that
• If payment batch sets were used as a workaround for doing multi-currency pay
runs in 11i then, consider combining those pay runs into a single pay run. In
addition a single payment run can process multiple banks that includes both
electronic and printed payments
• The Payment Process Request template enables you to predefine invoice
selection criteria, thereby simplifying payment processing.
• Validation errors during the payment build process are automatically handled
based on the options that are specified on the payment process request. For
example, the process may be stopped for review, payments with errors can be
rejected, or all payments may be rejected in the request if errors exist.
• Usage rules and validations can be set up for a payment method.
• Pay runs can be stopped at two points. Users can choose to pause after the
invoices are selected. At this point, users can review selected payments, add
or remove scheduled payments or change payment and discount amounts. The
second point is after the scheduled payments are built into payments. Here, the
user can see the final amounts of each payment and can choose to drop any
• Scheduled Payment Selection report replaces many portions of the
Preliminary Payment register report. It can be used for reviewing the invoices
selected in a pay run, review invoice selection criteria, determine immediate
cash requirements for a pay run etc.
• All payment related setup has now been moved to the new Oracle Payments
module. Refer to the Oracle Payments User guide.
• In prior releases, Oracle Payables seeded four payment method types (Check,
Electronic, Wire, and Clearing). In Release 12, customers can setup their own
• Scheduled Payment Selection report cannot be run for historical data.
• Custom document categories for payments will not be upgraded.
• Disbursement type has been made obsolete and hence, it has been removed
from all reports.
• IMPORTANT: All custom payment formats must be migrated to XML in
order to work in R12.
• Check Payments and the Electronic Payments document categories have been
retained in Release 12. However, Payables no longer supports the Wire
Payments and Clearing Payments document categories.
The AP-AR Netting feature allows you to offset balances in both Oracle Payables and
Oracle Receivables to reduce the outstanding debt owed either from an internal company
or from a customer. It also supports foreign currency netting. Accounting for netting is
handled in the same way as if it had been closed in the subledgers. This feature allows
you to optionally give the trading partner the opportunity to review and approve
transactions before they are posted.
• A netting batch needs to be created using the Receivables responsibility. It can
include various parameters like operating unit, netting agreement, settlement
• Once the batch has been set up, submit the netting batch.
• Query the netting batch and view the proposed AP/AR netting amounts
online. Users can view the Receivables and Payables transactions that were
selected for possible netting. In the header portion of the screen users will be
able to see the total dollar amounts of the AP and AR transactions selected as
well as the proposed netting amount. Users could also run the proposed
AP/AR netting report.
• Optionally, users can review the netting batch. In this process users can
review, remove or add transactions before submitting it.
• Submit the netting batch and view the final netting report.
• Both customers and suppliers must be setup as a trading partner in TCA.
• Here are some of the additional steps that are required:
o Create a netting agreement.
o Create a netting bank account.
o Create a netting control account in General Ledger as well as exchange
rate types if using multi-currency netting.
o Establish a paying relationship for the customers in Accounts
o Associate the bank account used in the netting agreement with the
AP/AR netting receipt class.
• An internal dummy bank account will be seeded which will process receipts
generated in Oracle Receivables.
• When creating a netting agreement, if the (supplier?) site information is left
blank, then the system includes all the sites for the trading partner.
• If the option to include trading partner approval is selected, only one approver
can be selected. The approver name list of values is derived from the customer
• No netting batch information will be upgraded.
• Netting agreements will be created for every existing customer and supplier
relationship that is migrated. Agreement name will be created using customer
id and customer name.
• Users must review the migrated netting agreement setup to add or correct
upgraded information. Netting upgrade uses dummy values for certain
mandatory information not found in 11i setup. Users must change this to valid
• Transaction data residing in interface tables in 11i is not migrated to Release
12. All in-progress netting batches should be closed or completed before
See Oracle Payables Implementation Guide and Oracle Payables User Guide for more
This action might not be possible to undo. Are you sure you want to continue?