Accounting Setup Manager in R12 Comment on this Topic

The ledger is a basic concept in Release 12. The ledger replaces the 11i concept of a set of books. It represents an accounting representation for one or more legal entities or for a business need such as consolidation or management reporting. Companies can now clearly and efficiently model its legal entities and their accounting representations in Release 12. This seems to be a major area in getting success of the shared service center and single instance initiatives where many or all legal entities of an enterprise are accounted for in a single instance, and data, setup, and processing must be effectively secured but also possibly shared. Now, legal Entities can be mapped to entire Ledgers or if you account for more than one legal entity within a ledger, you can map a legal entity to balancing segments within a ledger. While a set of books is defined by 3 C's 1. chart of accounts 2. functional currency 3. accounting calendar, The addition in this list the ledger is defined by a 4th C: the accounting method, This 4th C allows you to assign and manage a specific accounting method for each ledger. Therefore, when a legal entity is subject to multiple reporting requirements, separate ledgers can be used to record the accounting information. Accounting Setup Manager is a new feature that allows you to set up your common financial setup components from a central location. What is Accounting Setup Manager

Accounting Setup Manager is a new feature that streamlines the setup and implementation of Oracle Financial Applications. The Accounting Setup Manager will facilitate the setup required for simultaneous accounting for multiple reporting requirements. With the Accounting Setup Manager, you can perform and maintain the following common setup components from a central location: * Legal Entities * Ledgers, primary and secondary * Operating Units, which are assigned to primary ledgers * Reporting Currencies, which is an enhanced feature * Subledger Accounting Options. This is where you define the accounting methods for each legal entity subledger transaction and associate them to the ledger where the accounting will be stored. * Intercompany Accounts and Balancing Rules * Accounting and Reporting Sequencing * Both Intercompany and Sequencing

Upgrading?

The upgrade creates a separate accounting setup for each primary ledger that is Upgraded from a set of books. The status of the accounting setup will be completed. Each accounting setup is a grouping of accounting-related setup components. The following lists the Release 12 setup components and how the Release 11i features map to them: Legal Entities: HR Organizations classified as GRE/ LE in Release 11i will be preserved as Legal Entities in Release 12. Legal entities can be manually assigned to a ledger and balancing segment values can optionally be mapped

to legal entities to help you identify transactions by legal entity during transaction and journal processing. One Primary Ledger: Most sets of books in Release 11i will become primary ledgers in Release 12. Operating Units: All HR Organizations classified as operating units will be Preserved in Release 12. If operating units are assigned to a set of books, then they will be associated to a primary ledger in an accounting setup. You can now view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager. Reporting Currencies: Multiple Reporting Currency (MRC) reporting sets of books become reporting currencies in Release 12. Secondary Ledgers: Multiple-Posting set of books (Global Accounting Engine) will upgrade to secondary ledgers. Intra-company Balancing: Inter-company Accounts in Release 11i is renamed to intra-company Balancing Rules, a feature provided by the new Advanced Global Inter-Company System. Inter-company Accounts The Release 11i Global Inter-company System (GIS) will be Replaced by Advanced Global Inter-company System (AGIS).

Differences between Data Access Set and Security Rules

In General Ledger, security is provided by Data Access Sets and Security Rules. Their usages may overlap in some cases, but each has its own limitations. Following table illustrates the key differences between the two.

Scenario 1 2 Availability Purpose

Data Access Set behavior New in R12 To Provide access to users to Ledger. Either full access or restricted access to ledger (read only access).

Security Rule behavior

Has been there in 11i as well as in R

To provide restrictions/provide acce values. It doesnt grant you access o access should already be there befo in.

Defaults

By Default Data Access Set is created with full By Default security rules are not pre access. It is created automatically when you create created based on business need. a ledger

Applicability

You can only restrict access on Balancing segment You can restrict /grant access based or management segment. Not available for all COA. segments.

levels of access

On segments / ledgers, you can provide one of the Either you can give full read/write a three levels of access there is no read only access. if the * Read only access read/write, then he or she can not s * Read / Write Access * No Access. * You can assign only ONE Data Access Set to a responsibility * You can not mix both Balancing and management segments into one Data Access Set. Either create a rule for balancing segment or for management segment. This rule works more like backend security at ledger level, which makes it more powerful. All features of GL are protected by this security

Rules

* There a many-to-one relationship rules and responsibility. That means rules together and assign the rule to * Because of many-to-one relations many rules that apply to different se and apply to a responsibility.

Strength/Vulnerability

Works at UI level (pick lists, etc.). W reports, inquiries etc. It is recomme extensive testing to make sure ther and accounts are truly hidden from through any inquiries or reports.

Limitations / Restrictions

You need full access to do some of the critical activities. You can nor connect through restricted access. Ex of these activities are * manage Periods. * Run Mass Allocations * Create Summary Accounts * Create Budget Versions You define the rule with include rules. Ex: Include these ledgers.

No such restrictions.

Definition

Can be defined in ranges You first include a range of account Then you exclude a range of accoun similar to defining cross validation r

10

Violation message

A standard system message pops up in case of rule A custom message can be provided violation by a user. violated by a user.

Additional points: 1) Both rules are applied to responsibility and not directly to users. 2) You can use both the rules together. Data Access set is mandatory. 3) You can use parent values in case of both rules. For security use the heirarchical security to include child values when parent is defined.

Functional consultant's role in Implementation ============================= Requirement Study in detail Preparation of RD020 document (As-Is process document) and get sign-off from client Mapping the requirements to Application process Preparing BP080 Document (Mapping of As-Is process to To-Be Process) and get sign-off from client Identification of GAP Preparing MD050/60 for customization Conference Room Pilot environment Setup Conduct CRP and Resolve CRP issues Training Environment Setup (Optional, Same CRP instance may be used) Prepare SOP manuals Testing of Customizations (Forms, Interfaces and Reports) UAT environment Setup Prepare TE040 document (Test Case Document) Assist users in UAT and resolve UAT issues Prepare BR110 document and get the access details requirement from the client Production Instance Setup Assist Developers to upload the master data and open transactions Verify the uploaded masters and open transactions Post Live support Prepare BR100 document (Setup Document) Co-ordination with DBA and Oracle Support Functional Consultants Role in Support Projects ============================== Handling tickets and application support to the end-users. When an issue is received, it needs to be analyzed and resolved. In case, if the issue requires the support of development, then transfer the issue to development team with the inputs. Monitor and help development team to complete the task In case, if the issue requires support from Oracle, then raise SR and co-ordinate with oracle support team till closure Preparing MD050/MD060 documents for any customizations Preparing Test Cases, Test Data & testing. Interaction with client/end users & updating the issue status. Training the end users and preparing end user training material. There will also be interaction with other modules consultants/DBAs Creation of process documents & its updation Functional consultant should know the basic SQL and the important tables. Data Loader is an easy to use tool, hence it is better to know it. Knowledge of discoverer is a plus. Forms and Reports, PL/SQL are not required.

Non-PO Invoice Management - Some Thoughts

I had the pleasure recently to watch two customers go live and to spend a day talking about e-Invoicing with another. After reflecting on those meetings I thought I would post to the Exchange about one theme that we spent much of our time discussing, "Non-PO Invoice Management". Today, the reality is that many companies have a relatively large number of non-po invoices coming into their AP department. These invoices are on the higher end of the scale relative to total invoice cost because of the following reasons: 1. Non-PO by definition is an invoice that was based on shipping goods to a buyer without the supplier having been given a Purchase Order. Therefore there is no Purchase Order available to use the Ariba Network based Supplier Feature, PO-Flip(TM). Without an orginal PO many issues can come up that are just simply subtotal accuracy, line item price compliance, and even just Vendor match against the Vendor Master File, etc. 2. Non-PO is by definition not based on pre-spend approval so in most cases a Non-PO Invoice must be workflowed after receipt to the business unit and person that ordered the items or services being invoiced. This opens a few challenges. First if the supplier doesn't accurately put reference to the business organization then AP must chase down what part of the business needs to approve the invoice. Even worse, if the supplier puts down either no "purchaser" or puts down the wrong person's name then the invoice could be stuck in review for weeks finding a home. 3. Non-PO invoices may end up on blocked and hold reports because they have triggered "Exceeds Budget" or "Vendor Mismatch". This can, after all the work of gathering approval, cause again another exception handling activity that can waste time and delay payment. When a supplier calls AP asking about the status of an invoice and it is a Non-PO invoice the call typically runs longer than a normal inquiry. So, what to do about Non-PO? Well, if you break down the problem into it's pieces you can actually successfully achieve a reasonable STP %, Straight Through Processing Percentage, for your Non-PO invoices. Especially if you are the type of company that purchases more on budget than based on Purchase Orders. What are the key steps to take? First, don't take Non-PO invoices and try to enter them directly into your ERP. Second, attempt to implement a policy where the Vendor MUST enter the requestor's email address on the Non-PO Invoice. This will allow your workflow solution to pick up on the email and route the Invoice directly to the business unit that ordered the services or products. Set your business policies to immediately reject Non-PO invoices back to a supplier if they have not provided the employee's email address. If you are based in Europe, especially Germany, you may want to use something other than email address depending on your privacy policy and if your email address shows employee names. Finally, you should establish a Non-PO approval flow in your worklfow that allows for procurement to get visibility into the vendors, commodity types, etc. that are being purchased Non-PO as a feeder into the typical processes for consolidating vendor master/suppliers, make them aware that this kind of purchase may be a good candidate for Purchase Order Spend, and to give them insight into potential one-time Vendors who may be creating leakage in negotiated pricing for a given commodity. So, if you find yourself with a reasonable amount of Non-PO Spend, I suggest you consider breaking down the issues you have with Non-PO Invoices and put in solutions and procedures to remove the negative impact and maybe even add Non-PO invoices to your STP based invoices. Remember the Ariba Network can be configured to require suppliers to provide an employee email on Non-PO Invoices so if you have not turned this on you should consider looking at configuring your Business Rules on the Ariba Network to help you with getting approval of invoices that don't have Purchase Orders. I would invite you to add comments to the posting to share with the Ariba Exchange other ways that your organization addresses the challenge of Non-PO Invoices. Regards,

Bala