Solutions Used in Previous Projects - R12 AP

1. Requirement
Do we need Cash Clearing Account At each payment Document?

Details
How do you set up different GL account at the payment document level ?

Description of Solution:
n R12, there is no field to set Cash Clearing for the payment document in the Payment document setup user interface.
There was an intentional decision to move the GL accounts up to the bank account use level and remove them from the check stock level.  This was largely motivated by the fact that check stocks can be used only in the case of printed checks – not electronic payments. (Prior to R12, check stocks needed to be created even in the case of electronic payments. This is no longer the case in R12.) In order to have consistent accounting setup between check printing and electronic payments, it was decided to keep the GL accounts at the bank account use level.
The user could use the flexibility of SLA if they desire to set up their bank GL accounts at a level lower than the bank account use (e.g., they could setup an account derivation rule that takes the check stock as an input).
This was validated with the field before the change was made. Note that the input from some of the countries indicated that companies may require cash clearing/bank fee GL accounts to be set up at a level more granular than bank account use (e.g., one GL account for each payment format or payment method used for a certain bank account). However, as noted above,it was agreed that SLA should be able to deal with these requirements. This is possible since all of these attributes are made available through the AP SLA extract. "

2. Requirement:
How to divide the payment responsibility into operating units specific so that each responsibility show in the home page and in the payment process request tab only the payment processes made for that specific operating unit?

Detail:
In R12 there is NO concept of PPR ownership. It is not owned by an Organization nor a Legal Entity.A PPR can legitimately pay the Documents Payable from more than one Organization or Legal Entity.
PPR restricts the Selection of Invoices according to Security profile for User.
A Payment Process Request is NOT owned by a Legal Entity. When user submits a PPR; he/she can choose to include the Documents Payable from any Pay Groups, Legal Entities, Payment Currencies or Operating Units.

Description of Solution:
A possible workaround may be:
1) Setup different Security Profile option for each Payment manager Responsibility which has access to list of Orgs.
2) While creating a Payment Process Request, in the "Scheduled Payment Selection Criteria", if you specify Operating Units as "All" invoice selection is restricted to the operating units which the user/responsibility has access to and PPR will select invoices for payment which belong to other OUs as well.
This will help to achieve the cleaner separation of PPR

3. Requirement:
Can a user create a Payment Process Request that will pay 2 invoices that are assigned to 2 different operating units that are linked to 2 different ledgers?

Details:
The answer is "No".
Generally speaking, the accounting structure in Oracle E-Business Suite starts with a Ledger and its functional currency.
For each ledger, you have one or more Legal Entities (LE) attached.
For each Legal Entity, you have one or more Operating Units (OU) attached.
Internal bank accounts are entered at the Legal Entity level (see the Bank Account Owner field on the "Account Owner and Use" page of the Manage Bank Accounts window), and by this association, are also linked to the same Ledger that the Legal Entity is attached to.

Description of the Solution:
Each internal bank account can be accessed by one or more specified Operating Units that are attached to its associated Legal Entity (see the Account Access page of the Manage Bank Accounts window > Add Organization Access button).
Through these associations, when you create a Payment Process Request (PPR), and specify an internal bank account, you are telling the system which Legal Entity and Ledger these payments are for. Therefore, all payments in a single PPR can be generated for only one Ledger.

Oracle Payables R12 Overview

Suppliers Added to Trading Community Architecture
The Oracle eBusiness Suite has a single repository called the Trading Community Architecture (TCA) to store information about your trading partners. TCA provides a single common definition that can be used to identify customers, suppliers, and organizations that provide you with goods or services, and are in turn, a customer of your own products or services. The TCA repository stores the key elements that define an organization, identity, business locations, and key contacts, so that different Oracle products use a common trading partner definition.

Various applications in the Oracle E-Business Suite can view, create, and update the TCA Registry data. Because this information is shared, any change made in one application is reflected in all applications. A range of information that can be viewed through the Suppliers pages is also available through the Customers Online pages.


Invoice lines
Invoice Lines are introduced as an entity between the invoice header and invoice distributions in order to better match the structure of real world invoice documents and improve the flow of information in the Oracle E-Business Suite. With the new model, the invoice header remains unchanged, and continues to store information about the supplier who sent the invoice, the invoice attributes and remittance information. Invoice lines represent the goods (direct or indirect materials), service(s) and/or associated tax/freight/miscellaneous charges invoiced. Invoice distributions store the accounting, allocation and other detail information that makes up the invoice line.


Centralized banks and bank account definitions in oracle cash management
In Release 12, the ownership of internal banks and bank accounts will move to Oracle Cash Management for all products in the E-Business Suite. A Legal Entity now owns the bank accounts and their payment documents, rather than being owned by an Operating Unit, as in prior releases.

The Bank Account model allows users to define and keep track of all bank accounts in the e-Business Suite in one place and explicitly grant account access to multiple operating units/functions and users.

The Bank Account model reduces the number of access points to manage bank accounts by providing a centralized user interface where all internal bank accounts can be set up.

Bank account access in this model can be granted to multiple operating units, thus eliminating the redundant duplicate bank account setup under different operating units in case these operating units share the same bank account. This will also simplify the reconciliation process since now one bank account is the system corresponds to one bank account at the bank.


Document Sequencing of PaymentsIf you used document sequencing for payment documents in Release 11i, your document sequence category is migrated from the payment document, which is associated with a bank account and, hence a legal entity, to the bank account uses entity. This change preserves the option of having document sequence categories vary across operating units.


Integration with Oracle payments for funds disbursement
The process to issue payments from Oracle Payables (AP) changes in Release 12 to use the new Oracle Payments funds disbursement process.

Oracle Payments is a product in the Oracle E-Business Suite of applications, which serves as a funds capture and funds disbursement engine for other Oracle applications. As the central payment engine, Oracle Payments processes transactions, such as invoice payments from Oracle Payables, bank account transfers from Oracle Cash Management, and settlements against credit cards and bank accounts from Oracle Receivables.

Oracle Payments' funds disbursement features support the process to pay funds owed to creditors, such as suppliers. Oracle Payments supports functionality to achieve straight through processing of electronic funds transfers and the ability to format and manage check or other payment document printing.


Integration with oracle subledger accounting
Release 12 introduces a new module, Subledger Accounting (SLA), for managing accounting across subledger transactions. With the introduction of SLA, Payables will no longer create accounting entries, but will instead rely on the central SLA engine to do so.

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.


Integration with Oracle E-Business Tax
In Release 12, Oracle E-Business Tax, a new product, will manage transaction tax across the E-Business Suite. In prior releases, the setup, defaulting and calculation of transaction tax for Payables was managed within Payables using tax codes, their associated rates and a hierarchy of defaulting options. The new module will cover standard procure-to-pay and order-to-cash transaction taxes, with the exception of withholding taxes.


Multiple Organizations Access Control

Multiple Organizations Access Control is an enhancement to the Multiple Organizations feature of Oracle Applications. Multiple Organizations Access Control (MOAC) allows a user to access data from one or many Operating Units while within a given responsibility. Data security is maintained using the Multiple Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.

In Release 12, several controls are moved from the Payables Options or Financials Options forms to a new setup form that is common for Oracle Payables across all operating units, the Payables System Setup form. If the upgrade finds conflicts in the settings across multiple operating units, it will choose the most frequently occurring setting.


Payables and Receivables NETTING
The Payables and Receivables Netting feature enables the automatic netting of Payable and Receivable transactions within a business enterprise. You can predefine a netting agreement that incorporates the netting business rules and transaction criteria needed to run your tailored netting process.
Oracle Payments - Enhanced Disbursement Process
The new Oracle Payments disbursement engine allows businesses to greatly simplify their user procedures around managing complex payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations, and bank accounts. Oracle Payments has redesigned the payment build process that Oracle Payables used in previous releases. The Oracle Payables payment batch process required the submission of the invoice selection process to be segregated according to the way the invoices needed to be paid (printed checks, electronic funds transfer, different formats, and so on).

The new Oracle Payments funds disbursement process allows the invoice selection process in Oracle Payables and other products to be neutral to the way documents will be paid. This is achieved by effectively splitting the payment build process into two separate processes. The first process creates payments by grouping documents according to various rules such as the payment method and currency. Accounts Payable managers are able to simplify their processes by submitting fewer invoice selection batches, each one spanning multiple payment methods, formats, bank accounts, and payment currencies. Invoices can be selected for payment based on business reasons such as maximizing discounts. The second process then aggregates payments into formatted payment instruction files, and handles any additional processing. The cost of the disbursement process is lowered by creating fewer check runs and EFT payment files by grouping payments across the criteria of the first process.