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

Oracle 12i - How to create accounting and transfer JE's to GL using SLA

Oracle 12i - How to create accounting and transfer JE's to GL using SLA

I. Create Accounting Program:

The Create Accounting program processes eligible accounting events to create subledger journal entries. To create the subledger journal entries, the Create Accounting program applies application accounting definitions that are created in the Accounting Methods Builder (AMB).

The Create Accounting program:
•Validates and creates subledger journal entries
•Optionally transfers the journal entries to GL
•Optionally posts the journal entries in GL
•Generates the Subledger Accounting Program Report, which documents the results of the Create Accounting program

Draft Accounting:
When you select draft accounting, Subledger Accounting creates the relevant journal entries in draft mode. Draft entries are not posted to General Ledger. You can review the resulting entries, update the transactions, or update the accounting rules. Any changes will be reflected when the transaction is processed again for accounting.

Online Accounting (Final):
Final entries are ready to be transferred to General Ledger and cannot be modified. The transactions are considered as processed for accounting. Any changes to the rules will not impact final entries.

Straight-Through Accounting (Final - Post):
If you select Final Post, Subledger Accounting posts the journal entries all the way through to General Ledger. This means that you can update GL balances straight from the invoice entry (or any other transaction entry) window.

Create Accounting Program:
The Create Accounting program creates subledger journal entries. In general, the parameters described in the table above determine which accounting events are processed.
Navigation Paths (example Payables)
Payables: Other > Requests > Run
Receivables: View > Requests (B) Submit a New Request

Paramaters:

1. Ledger - Required; limits accounting events selected for processing to those of a particular ledger. This program is run for primary ledgers or valuation method enabled secondary ledgers. Any reporting currency or secondary ledger associated with the selected primary ledger is also processed; i.e. entries are generated for the selected primary as well as reporting currencies and non-valuation method secondaries.

2. Process Category - Optional; restricts the events selected for accounting to a particular process category. For example, Invoices.

3. End Date - Required; end date for the Create Accounting program; processes only those events with event dates on or before the end date

4. Mode (Draft/Final) - Required; determines whether the subledger journal entries are created in Draft or Final mode

5. Errors Only (Yes/No) - Required; limits the creation of accounting to those events for which accounting has previously failed

6. Report (Summary/Detail/No Report) - Required; determines whether to generate a report showing the results of the Subledger Accounting program in summary or detail format

7. Transfer to General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to transfer the subledger journal entries to General Ledger

8. Post in General Ledger (Yes/No) - Required if Mode is set to Final; determines whether to post subledger journal entries in General Ledger

9. General Ledger Batch Name - Optional; user-entered batch name that appears on the transferred General Ledger subledger journal entries. Transfer to GL option must be set to Yes.

10. Include User Transaction Identifiers (Yes/No) - Required; controls whether the report displays user identifiers' names and values.


Create Accounting Program:
The Create Accounting program generates one or more accounting programs depending on the volume to be processed. The Subledger Accounting Program report is generated by the Create Accounting program and documents the results of the Create Accounting program. It lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events
You can run the report in summary, detail, or no report mode which are described as follows:
•Summary mode provides a summary of events processed and detailed information about their errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.
•No report mode will show an error count without actually generating the report.

II. Transfer Journal Entries to GL Program:

The Transfer Journal Entries to GL program enables you to transfer any eligible journal entries to General Ledger, including those from previous runs that have not yet been transferred to General Ledger.

Note: This program is used if you run accounting online in Final mode (not Final Post) or if you run the Create Accounting program and set the Transfer to GL parameter to No.

The only reason you would want to run the Create Accounting program and set the Transfer to GL parameter to No is if you want to run accounting at different intervals than the GL transfer, for example, you may run accounting every hour but only transfer to GL nightly.

The Transfer Journal Entries to GL program consists of a subset of parameters used in the Create Accounting program as listed below:
–Ledger
–Process Category
–End Date
–Post in General Ledger
–General Ledger Batch Name

III. Oracle Subledger Accounting Program Report:

The Subledger Accounting Program Report is generated by the Create Accounting program and lists the following:
•Successful events and the subledger journal entries created for those events
•Errors for failed events

You can run the report in summary or detail mode as follows:
•Summary mode provides a summary of events processed and detailed information about any errors.
•Detail mode provides details of subledger journal entries generated from the processing of completed events and a detailed error report.

IV. Transfer Journal Entries to GL Report:

The Transfer Journal Entries to GL report is generated by the Transfer Journal Entries to GL program and lists the following:
•Transfer to GL Summary
•Errors

Setting Profile Options:
The profile options listed above relate to data access and security and impact how accounting is generated through SLA in R12.

1. SLA: Enable Subledger Transaction Security in GL
•Use this profile option to combine subledger transactions security with data access security for General Ledger responsibilities when drilling down to multi-organization enabled subledger application. Transaction security in the respective subledger application is always applied when drilling down from subledger transactions to subledger journal entries.

2. SLA: Enable Data Access Security in Subledger
•This profile option determines whether the General Ledger Access Set security mechanism is applied for a subledger application responsibility when viewing, reporting, or creating subledger journal entries associated with a given ledger. The General Ledger Access Set security mechanism is always applied for responsibilities associated with the General Ledger application.
•The profile option enables you to combine data access security with subledger transaction security and therefore control access to subledger journal entries depending on the ledger to which they belong. For example, you can implement a Multi-Org Security Profile that allows you to create Oracle Receivables Invoices for two different operating units each associated with different ledgers but restrict drill-down from the subledger transaction to the associated subledger journal entry based upon the destination ledger contained in the Access Set.

3. SLA: Additional Data Access Set
•The SLA: Additional Data Access Set profile option, in conjunction with the GL: Data Access Set profile option, controls which ledgers and balancing or management segment values you can access when logging onto a responsibility. If SLA: Enable Data Access Security in Subledgers is enabled for the responsibility, you have access only to the ledgers and balancing or management segment values included in the data access sets assigned to the SLA: Additional Data Access Set and GL: Data Access Set profile options.

4. SLA: Allow Reports Journal Source Override
•This profile option applies only to the following reports:
-Open Account Balances Listing
-Third Party Balances Report
•Enable this option to change the Journal Source parameter during report submission. If the option is set to No, then you cannot change the value defaulted during report submission.
For example:
•Should the general ledger data access set security be enforced when generating accounting? For example, should journal entries be created if the user does not have ledger clearance even if they may have multiorg access to the operating unit?
•Should the transaction security model be applied when drilling down from GL? For example, should the user be allowed to inquire on journal entries of certain operating units if they do not have MO access, but have ledger clearance?
•If there are secondary ledgers and data access set security is enforced in the subledger module, then an additional data access set needs to be assigned to the user to enable access to the secondary ledger.
•Should the user be able to run certain reports across data from multiple subledger applications?

Purchasing and Inventory Accounts commonly defined during Setup

Purchasing and Inventory Accounts commonly defined during Setup

1. Purchasing:
Financial OptionsAccounting Information
· Liability Account
· Prepayment Account
· Discount Taken Account
· Rate Variance Gain Account
· Rate Variance Loss Account

Purchasing Options
Accruals
· Expense AP Accrual Account

Receiving OptionsReceiving Account (need one account per inventory organization; they can be the same).

2. Inventory:
Define Organization Parameters - All accounts in this section are required for each inventory organization; they can be the same between orgs.
· Inter-Org Transfer Accounts (required for setup)
· Inter-Org Receivable Account
· Inter-Org Payable Account
· Inter-Org Purchase Price Variance Account
· Intransit Inventory Account
Valuation Accounts
· Material Account
· Outside Processing Account (this won’t be used, so a suspense account is fine)
· Material Overhead Account (this won’t be used, so a suspense account is fine)
· Overhead Account (this won’t be used, so a suspense account is fine)
· Resource Account (this won’t be used, so a suspense account is fine)
Other Default Accounts
· Purchase Price Variance Account
· Invoice Price Variance Account
· Inventory Accrual Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Sales Account
· Cost of Goods Sold Account (this is a default; each item can have a COGS account as well)
· Average Cost Variance Account (this probably won’t be used, so a suspense account is fine)

Define Subinventory - All accounts in this section are required for each subinventory in each org; they can be the same as the org level, and can be the same between subinventories.
Subinventory Accounts
· Material Account
· Outside Processing Account (this won’t be used, so a suspense account is fine)
· Material Overhead Account (this won’t be used, so a suspense account is fine)
· Overhead Account (this won’t be used, so a suspense account is fine)
· Resource Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)

Define Freight Carriers - Need an account for each carrier defined; they can all be identical, overlapping (Ground account vs. Express account) or unique; freight carriers are optional, and may not be set up.

Define Inter-Org Shipping Information
· Inter-Org Transfer Credit Account
· Inter-Org Receivable Account
· Inter-Org Payable Account
· Inter-Org Purchase Price Variance Account
· Intransit Inventory Account

Define Overhead· Absorption Account

Define Item - need an account code for each item defined; they can be identical, overlapping, or unique; these accounts are optional since they will default from the subinventory or organization
· Cost of Goods Sold Account
· Encumbrance Account (this won’t be used, so a suspense account is fine)
· Expense Account
· Sales Account