Monday, February 16, 2009

New Accounts Payable architecture for 12i

Suppliers in the Trading Community Architecture (TCA) :

The Trading Community Model:
•Is a highly flexible architecture
•Allows you to model real world entities in your trading community
•Allows you to accurately represent complex relationships among entities
•Is the core data model for trading partners used by Oracle E-Business Suite applications

TCA Security by Functional Areas:
A 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 Function Security.
•You can add new locations or relationships with additional operating units
•You can modify a quick update page with those values most often updated for faster maintenance
•Additional tax and legal registrations provide key information to meet reporting and compliance needs
The new supplier UI also includes a Survey section that provides administrators with access to the results of questionnaires that the supplier has been asked to complete, either during self-registration or as part of profile maintenance through iSupplier Portal. Purchasing Category assignments further designate the type of goods and services the supplier will provide.

Bank Accounts are:
•Centrally defined
•Managed and secured
•Include the legal ownership and operating unit access for each bank account

Supplier Bank Accounts:
The bank account is tied directly to the trading partner allowing one bank account definition to be leveraged by a ‘supplier’ trading partner and shared if the trading partner is also an employee or customer. This approach provides for easier and centralized maintenance and security of the bank account information.

This definition is targeted directly towards ‘trading partner’ bank accounts leaving internal bank accounts out of the user interface. In other words, the supplier’s banking information is entered and assigned right in the Supplier Entry and Maintenance user interface.

Collaboration with Suppliers to Resolve Disputes:

Holds on invoices that are a result of differences between the invoiced and planned amounts or quantity result in disputes that must be resolved. Invoices that have been approved by the owner of the purchasing transaction but rejected during the approval process may also be subject to disputes with the supplier.

Leveraging workflow notification, disputes are communicated and negotiations can be suggested to the Supplier. Suppliers are able to accept the suggested changes, withdraw their invoice, or submit their counter proposal. The negotiation continues until the issues are finally resolved. Suppliers can also negotiate online via iSupplier Portal. All changes and comments entered during the collaboration are tracked in Payables and can be viewed at any time.

Invoice Requests:

•Invoices entered by Suppliers via iSupplier Portal where a purchase order has not been obtained
•Are visible in Oracle Payables
•Are not paid or accounted until the invoice can be verified and approved

2 comments:

Anonymous said...

Very well listed. If that's the new architecture for the 12i accounts payable, it would definitely make change. Thanks for the post! Good luck and keep us updated. Thanks.

Denise

business payroll software

sap upgrades said...

This is brilliant work. I don't have much idea about this topic but I learned a lot about new accounts payable architecture with the help of your post as I have to submit my project on this topic only. I am very impressed with your work.