Monday, 25 April 2011

Oracle Apps Reporting Tools


Oracle Apps Reporting Tools

Introduction : Oracle provides over a thousand standard reports within the application. These standard reports are developed to cover common generic needs. Before creating any new reports, one should examine the standard report sets to determine if any meet the requirements. If requirements cannot be met with the standard Oracle report sets, tools are available to create custom reports.

The following matrix addresses reporting tool options, including:

A brief description
Who should be provided the access to the tool?
Advantages
Disadvantages
When is it appropriate to use?
(Click anywhere on the below image to ZOOM and read the complete table):


R12 Multi-Org Access Control - features and benefits


R12 Multi-Org Access Control - features and benefits

Multi-Org Access Control - Description:

In 11i, when users had to enter or process data for multiple operating units, they had to login to different responsibilities because each responsibility could only access one operating unit. So if there were a centralized payment processing center where users processed payments for multiple organizations, they would have to keep logging in and out of different responsibilities to process payments for a different organization or operating unit.

Now in Release 12, Multi-Org Access Control enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing users to access, process, and report on data for an unlimited number of operating units within a single application’s responsibility.

This increases the productivity of Shared Service Centers as users no longer have to switch application responsibilities when processing transactions for multiple operating units. Data security and access privileges are still maintained using security profiles that will now support multiple operating units.

Multi-Org Access Control - Example:

For example, if you have three operating units in the center you were managing, such as a Belgium Operating Unit, a Holland Operating Unit, and a Denmark operating unit, in 11i you needed to define three different responsibilities. If you had one user who processed payables invoices across all three operating units, then you would need to assign the three responsibilities to that user and then the user would need to log in and out of each responsibility to process invoices.

In Release 12, you can create a Security Profile and assign as many operating units as you want to that security profile. So in this example, you could assign all three operating units to the same security profile. Then, you can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all three operating units.

Processing payables invoices is just one example, with Multi-Org Access Control, you can efficiently perform other processes, such as processing receivables invoices, viewing consolidated requisitions, performing collections using Advanced Collections, and process receiving and drop shipments.

MOAC - Benefits:

•Improve Efficiency
–Process data across multiple OUs from one responsibility
–Process transactions more efficiently for companies that have centralized business functions or operate Shared Service Centers
•Obtain better information for decision making
–Obtain a global consolidated view of information
–View information, such as supplier sites and customer sites across multiple OUs
•Reduce Costs
–Speed data entry
–Reduce setup and maintenance of many responsibilities


Multi-Org Access Control Process Summary:

Each Financials product team has implemented MOAC to best suit their business process flows. For example, in AP, there’s a new operating unit field on their Invoice Workbench. The OU list of values reads from the Security Profile assigned to the responsibility to determine which OUs should be displayed in the LOV. In general, when a user logs in to a responsibility and opens an application, the application will determine which operating units can be accessed and used for processing. The user can then view or process transactions for multiple operating units.

R12 Multi-Org Access Control - Setups


R12 Multi-Org Access Control - Setups

Multi-Org Access Control Setup:

•Responsibility: Human Resources
•Navigation: Security > Profile
In Release 12, when you define your security profile in HR using the Security profile form or the Global Security profile form, you must:
•Assign all of the operating units that you want a responsibility to access. Run a concurrent request called “Run Security List Maintenance” from HR which makes those security profile available and allows you to assign them to a responsibility via a profile option called MO: Security Profile.


Multi-Org Access Control – Setup – Create Operating Unit:
•Responsibility: General LedgerNavigation: Accounting Setup Manager > Financials : Accounting Setup : Accounting Setup Manager

•Responsibility: Human Resources:Navigation: Work Structures : Organization > Description
In Release 12, you can define your operating units in two places. You can continue to define them in the Oracle HRMS Organization Form or you can define them in the new Accounting Setup Manager feature in General Ledger.

The Accounting Setup Manager streamlines the setup and implementation of Oracle Financial Applications. It centralizes the setup and maintenance of common financial components, such as legal entities, operating units, and ledgers. So when you create an accounting setup, assign a legal entity and create the ledgers that will perform the accounting for that legal entity, you can also define and assign the relevant operating units. By leveraging Accounting Setup Manager to define your OUs, you can streamline your setup.

In R12, is instead of attaching an OU to a LE, you assign it to a default legal context. All Release 11i 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 will be able view all operating units assigned to an upgraded primary ledger using Accounting Setup Manager.


Multi-Org Access Control – setup Define Security Profile:
•Responsibility: Human Resources
•Navigation: Security : Profile or
•Navigation: Security : Global
Using Oracle HRMS, you can define your security profile using two forms:
•The Security Profile form, which allows you to select operating units from only one Business Group
•The Global Security Profile form, which allows you to select operating units from multiple Business Groups

Enter a name, and select the Security Type called “Secure organizations by organization hierarchy and/or organization list”. This allows you to assign multiple OUs.

When assigning operating units, first select classification Operating Unit, and then select the organization or Operating Unit name. You can assign multiple operating units.

Multi-Org Access Control – Setup – Run System List Maintenance:

•Once the security profile has been created, run the Security List Maintenance program.
–This ensures that all of the security profiles that you created are available for assignment to your responsibilities.


Multi-Org Access Control – Setup – System Profile Options:

•The MO Security Profile controls the list of operating units that a responsibility or user can access. If you set the security profile at the responsibility level, then all users using that responsibility will have access to only the operating units available in the security profile. If you set the security profile at the user level, then the user will have access to only those operating units, irrespective of application responsibility that they log into.

•The MO: Default Operating Unit is optional and allows you to specify a default operating unit that defaults when you open different subledger application pages. Because you can access multiple operating units, you may want to set up a default one instead of forcing users to constantly have to choose one. User Preferences allows you to specify a default operating unit at the user level. Use the MO: Default Operating Unit profile option to set the operating unit context or default operating unit when accessing an applications.

•The last profile option is for backwards compatibility and to support products that do not use Multiple Organizations. The release 11i setting was for this is preserved during upgrade. The Release 11i MO: Operating Unit profile option is supported in Release 12 as not all customers of Oracle products require multiple organizations.

Implementation Considerations:

•Oracle HRMS
–Define operating units
–Set up Multi-Org Security Profiles
•Accounting Setup Manager
–Define operating units
–View all operating units assigned to the primary ledger
•Oracle E-Business Suite Products that Use Operating Units
–Process data across multiple operating unitsusing Multi-Org Access Control

R12 Multi-Org Access Control - Preferences


R12 Multi-Org Access Control - Preferences


Multi-Org Access Control Preferences - Description :
Multi-Org Preferences allows you to control the list of operating units to which you have access. For example, a system administrator may create a security profile that has ten operating units assigned to it and assign it to your responsibility. But, you may only deal with five of the operating units on a daily basis and do not want work space cluttered with extraneous operating units. You could set up Multi-Org preferences to restrict the list of operating units; you have complete control over this and can change it at anytime. In addition, you can specify a default operating unit.
Multi-Org Access Control Preferences - Benefits:

•Increase Efficiency
–Save key strokes with default operating unit
–Limit access to operating units you use most
•User Level Control
–Eliminate using System Administrators; you can control your own access
•Reduce cost
–Perform processes quicker


Multi-Org Access Control Preferences Setup:
Most products have added the Preferences user interface to their responsibility menus. You can select preferred operating units which represent a subset of operating units assigned to your responsibility’s security profile. You can also set a default operating unit.


Multi-Org Access Control Preferences – Setup – Add to SubMenu:

To enable and display Preferences in your menu
1.Request that your System Administrator to add the function FNDMOPREFS to your menu definition
•The System Administrator should use either the System Administrator or Application Developer responsibility, and select the Menu (Application) option
2.Select your product’s menu and add the function named User Preferences (FNDMOPREFS)


Multi-Org Access Control Preferences – Setup – Set Preferences:

Multi-Org Preferences page:
•The header displays:
–The user name that you are logged in as
–The responsibility name
–The Security Profile that you are currently assigned to
•The Default Operating Unit region is where you select a default OU.
•Preferred Operating Units is where you select the subset of operating units you want to work with.

Implementation considerations for R12 General Ledger setups


Implementation considerations for R12 General Ledger setups

Many clients ask for best practices and implementation considerations for implementing a new GL in 12i, here are some important implementation considerations:

Chart of Accounts:
–Share the same value set for the balancing segment across charts of accounts

Determine the Number of Legal Entities to Assign in an Accounting Setup based on:–Statutory and legal requirements for legal entity accounting, such as document sequencing, tax accounting, and intercompany accounting
–Business Needs

Types of Accounting Setups:

1. Accounting Setup with No Legal Entity (LE)
–Can be used for GL only implementations
–Used for a business need where no legal entity is required or management reporting
–Cannot maintain legal entity context in subledger transactions
–Cannot set up Operating Units
–Cannot use Advanced Global Intercompany Accounting System

2. Accounting Setup with One LE
–Cannot perform lump sum payments across legal entities in AP

3. Accounting Setup with Multiple LEs
–Cannot perform autonomous document sequencing and tax that is unique per legal entity
–Consider local laws that prohibit commingling transactions with multiple LEs

Choosing the Ledger to be the Corporate Representation:

Best practice is to choose the primary ledger to be the corporate representation in the local currency:
–Provides the most detail
–Allows you to assign a subledger level reporting currency if you want to maintain a detailed additional currency representation
–Note: Secondary Ledgers cannot have subledger level reporting currencies assigned

Legal Entity (LE) Accounting:

1. LE above Ledger
–If you require multiple primary ledgers to perform accounting for the same legal entity, you must create dummy legal entities because a legal entity can only be assigned to one accounting setup, not multiple accounting setups

2. LE = Ledger
–If legal entity equals the primary ledger, you may choose not to assign balancing segment values to the legal entity

3. LE Below Ledger
–Legal entities should be represented by one or more balancing segment values

Balancing Segment Value (BSV) Assignment:

1. No BSVs Assigned = All values available for data entry
2. Assign specific BSVs to LEs at any time
3. Behind the scenes, BSVs assigned to LEs are automatically assigned to the ledgers
4. No BSV validation performed across accounting setups
5. BSV assignment is required for Intercompany Accounting
6. Optionally assign BSVs to the ledger for non-legal entity related transactions, such as management adjustments
7. Before BSVs can be assigned to the ledger, they must be assigned to LEs first, if used

Reporting Currencies (RC):

1. Journal and Subledger level RCs act like regular ledgers
2. To automatically populate historical data, run the Create Opening Balance Journals in Reporting Currency program.
3. Conversion for subledger sources that uptake SLA are disabled for Subledger Level SLs
4. When posting a journal to the PL, journals for the RC will be automatically created/posted in the same batch
–Ensure same open periods for source ledger and RC
5. Data access set should include same write access to source ledger and RCs to prevent posting errors

Subledgers that uptake SLA (Assets, Budget Execution, Cash Management, Cost Management, Inventory, Oracle Loans, Payables, Payroll, Property Manager, Purchasing, and Receivables)

Secondary Ledgers (SL):

1. Can be added at any time with an unlimited number allowed
2. To populate historical data, use Consolidation (GCS)
3. Secondary Ledgers cannot have Subledger Level RCs assigned
4. COA Mapping required if COAs are different between the PL and SL
–COA Mapping can be used if the COAs are the same except for Subledger Level SLs
5. Conversion for subledger sources that uptake SLA are disabled for Subledger Level SLs

Bank Account Model in Release 12i


Bank Account Model in Release 12i

Here is a summary of the new features introduced by 12i in the area of Bank Account Model:

Bank Account Model Definition:
The new bank account model allow you 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. Bank accounts for internal use in Cash Management, Payables, Receivables, Treasury and Payroll are consolidated in Release 12. If you were using internal bank accounts in prior releases, all bank accounts will be migrated into the centralized bank account model automatically during the upgrade.

UMX-based Security:
The CE UMX Security Wizard is available under the User Management (UMX) responsibility. The wizard helps you quickly define the legal entities available for a role. To launch the wizard, log in as System Administrator, then in the User Management responsibility, go to Roles & Role Inheritance.

Bank Account Model Interaction :
In previous releases, Oracle Accounts Payable owned banks, bank branches and bank accounts. Such bank accounts could also be used by Accounts Receivable. Payroll and Treasury, however, had their own bank account models. In Release 12, banks and bank branches are created as Trading Community Architecture parties. The bank accounts are associated with Bank Branches but reside within the Cash Management application. During the bank account creation, you will be able to define in which applications this bank account can be used.

Bank Account Model Benefits:
The new 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 the new 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 simplifies the reconciliation process since now one bank account is the system corresponds to one bank account at the bank.

Cash Management Security Components:
Set up security for access to Cash Management activities by using components from different applications. The specific steps required to secure access to your bank accounts depend on the type of access you want to secure, the applications that you use for your business, and your organization structure.
•Use the CE UMX Security Wizard to grant a role (responsibility) the ability to perform bank account activities in the following areas:
-Use: View bank statements, reconcile cashflow transactions, work with cash forecasting, cash positioning, and cash pools
-Maintenance: Create and update bank accounts
-Bank Account Transfers: Transfers funds from and to internal bank accounts.
•When creating bank accounts, specify the legal entity that owns the account and the organizations that the account is used for (Payables, Receivables, Treasury, Payroll).
•Create security profiles to define the list of organizations that a user can access. Set up security profiles in the following applications as needed:
-MOAC: to define the list of operating units a user can access for Payables and Receivables and be able to reconcile AP and AR bank statement lines.
-Cash Management: to define the list of organizations a user can access to reconcile cashflow transactions. This security profile also allows users to access bank accounts for cash forecasting, cash positioning, and cash pools if no other security profiles are set up.
-Treasury: to define the legal entity that the Treasury user can access and be able to reconcile Treasury bank statement lines.
-Payroll: to define the business groups a user can access and be able to reconcile payroll transactions.

Bank Account Model Setup and Process:
•Responsibility: Cash Management
•Navigation: Setup:Banks > Banks
The key setup steps are:
•Define Banks in Oracle Cash Management.
•Define Bank Branches in Oracle Cash Management.
If you intend to use this bank account in Oracle Treasury as a company bank account, switch to that application, define Bank Counterparties and link them to Bank Branches that you have created. If you do not intend to use this bank account in Oracle Treasury, skip this step and proceed straight to the Bank Account definition.
At this point the system verifies your privileges for bank account maintenance. If you are authorized to maintain bank accounts for this legal entity, you will be able to create your Bank Accounts in Oracle Cash Management.
If you do not intend to use this bank account in Payroll, then the setup process is complete for you. If you intend to use this bank account in Payroll, switch to that application and add this bank account to the organizational payment method.

Implementation Considerations:
The bank new account model has several dependencies on other applications and centralized features.
•There is a dependency on the Trading Community Architecture because this is where the banks and the bank branches are stored.
•The organizational hierarchy comes from Human Resources.
•Finally, the General Ledger accounts that are assigned to the bank accounts are defined in General Ledger.
•If you are using Payroll or Treasury, then the bank account set up depends on those applications as well.

New Accounts Payable architecture for 12i


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