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 Financials Overview and new features at a glance (PART 2)

Oracle E-Business Tax (eBTax):
consists of a tax knowledge base, a variety of tax services that respond to specific tax events, a set of repositories (for tax content and tax recording) that allow customers to manage their local tax compliance needs in a proactive manner, as well as the ability to integrate with external tax content providers through a single integration point.


Advanced Global Intercompany System:
•Addresses the Top Barrier to a Fast Close
•Generates subledger invoices
•Controls transaction entry with Intercompany Calendar
•Has a Fully Configurable Approval Rules
•Has a Flexible Security Model
•Has a Centrally defined Intercompany Accounts


Centralized Banking:
•Bank account is now associated with the LE instead of the Operating Unit
•A single bank account serves multiple Operating Units
•Any and all Operating Units associated with a ledger can be permitted to use the bank account
•There is a centralized Credit Card Model
•There is Credit Card Encryption
•The Supplier & Customer Banks are in TCA

Multi-Dimensional Analysis & Reporting:
•In product row/column UI or within a Spreadsheet
•You can create the following reports & graphs:
– Historical
– Current
– Projected data
•You can analyze performance:
– Detect trends
– Define
– Variance
– Thresholds
•Receive auto-alerts

Financial Consolidation Hub:
R12 includes interactive spreadsheet reporting with live drill down to transactions


XML Publisher:
Enables you to format, manage, and deliver documents
•Meets business requirements such as:
-Removes complexity
-Reduces maintenance cost
-Reduces TCO
•Integrated with: R9 CRM, ESA, FMS, HCM, and SCM

New Standard Reports:
•Uses XML Publisher
•835 Templates are available
•Merges custom templates and data extracts at run-time
•Delivers output in PDF, HTML, RTF, Excel (HTML), or text for use with EFT and EDI transmissions
•98 Global reports have been replaced with 19 Extracts, 86 Templates

Other new features:

•Live AR-Inventory. Revenue-COGS Match
•Deferred COGS and Revenue Automation
•Advanced collection, Dunning, Loans
•Invoice Lines
•Suppliers in TCA: one setup per partner
•Supplier, users invoice self service
•Straight through processing (STP) at banks
•Per diems, approval enhancements
•Expense Bar Codes
•Self Service receipt matched invoices
•Real time contract T&Cs in PO, AP
•Asset Automatic Depreciation Rollback

R12 Financials Overview and new features at a glance (PART 1)

Why R12:

Release 12 is defined as “The Global Business Release.” Global is not just a geographic perspective, but also a comprehensive perspective; release 12 functionality spans across both industries and business functions.
•Flexible, centralized, global accounting structure
•300+ enhancements to best practice business processes
•Comprehensive governance, risk and compliance platform
•Truly integrated performance management
•Real-time profitability analysis
•Unified financial and operational analytic applications
•Integration with core industry applications
•Self-service report formats and publicationSuperior ownership experience

New architecture and benefits:

The major components of the new architecture include:
•Multi-Org Access Control
•Ledger and Ledger Sets
•Subledger Accounting
•Tax Engine
•Intercompany
•Bank Model

Benefits of the new architecture include:
•Maintain 1 Ledger with 1 OU for each Company (LE)
-Get privacy for each company’s data
-Manage each company’s national and local compliance
•Combine many companies’ ledgers in a set
-Share GL services and workload
-Get combined data
•Use MOAC to enable access to many OUs
-Process in and report across many Companies’ Operating Units


MOAC: Multi-Org Access Control:
MOAC provides role based access to Operating Units, and allows you to perform multiple tasks across operating units without changing responsibilities.


Subledger Accounting:
Subledger accounting provides centralized rules and a common repository, and global control of your accounts. Features include:
•Accounting Rules
-SarBox & 8th Dir.
-User Editable
•Subledger Daybooks (Journals)
•Subledger Balancing
•Reports, inquiries, open items, et cetera
•Multiple Representations
•Common Posting to GL Ledgers
•Real time or Periodic

Benefits of subledger accounting are:
•Faster, Easier Reconciliation
•Corporate Rules = Accounting Standardization
•Local Rules = Improved Local Compliance
•Automate “Apples to Apples” Adjustments
•Improved Audit- ability
•Improved Internal Control

Ledger:

•One Repository of Financial Truth
•Implements the 4 C’s:
–Chart of Accounts
–Currency
–Calendar
–Accounting Convention
•Example:
–The balance on Creditors (COA)
–is 4.2M Eur (Currency)
–on March 31, 2006 (Calendar)
–according to IAS/IFRS definitions (Accounting Convention)


Ledger Sets:
Ledger sets provide global information at a glance. Ledger sets share a chart of accounts and a calendar. The key benefits to many Ledgers in one set are:
•Decision-driving business information always available
•Simpler processing and General Ledger management
•Data and definitions that can be shared and secured


Ledger Architecture:
Typical Ledger Sets:
•All IAS/IFRS or US GAAP ledgers
•26 Subs in 1 country
•35 countries in 1 region


Legal Organization:
Legal Entities (Les) such as Parent companies, own or control subsidiaries. There are no group entities
•LEs pay the taxes and therefore need tax registrations
•Trade between LEs needs intercompany
•LEs own the money and bank accounts
•LEs file the accounts and take care of accounting
•LEs comply with whatever needs compliance: “legal” in LE


Enhanced Legal Support:
•Did not replace GRE/LE - employer
•Added TCA parties for the Authorities
•Added a Legal Entity Configurator
•Introduced the following new terms:
-Jurisdiction: A legislative category and territory, has legal rules
-Legal Authority: Legal body who enforces legislation, collects fees / taxes, etc
-Legal Function: Functions that companies are required to perform (e.g. produce yearly report, pay taxes, etc.)
-Legal Associations: Mapping companies to Ledgers, BSVs, OUs and other system entities


Examples of using Legal Entities:
•Accounting Setup Manager: Assign books, bookkeeping rules and currency management to your registered companies
•EBusiness Tax: Have your registered companies calculate, file, and pay the transaction taxes they owe
•Intercompany: Do business between and across your registered companies with full legal documentation
•Bank Model: Have your registered companies use their money to pay their bills, etc.

Oracle 11i Upgrade Model Questionnaire

Click on the Excel image below to get a readable view:

Understanding Oracle Bill Of Materials (BOM)

BOM Overview:

A bill of material is a list or Items associated with a parent Item, such as an assembly, and information about how each item relates to the parent item.

# A single level BOM consists of one parent Item and its immediate component Items
# Multilevel BOMs are displayed by linking together single level BOMs stored in the system
# A subassembly is both a parent and a component
# All items in a BOM model, including the parent Item being configured, must be defined in the Item Master and enabled in the Inventory Organization where BOM Model is created
# A BOM Model can be shared among other Inventory Organizations by creating common bills
# After a valid combination of options is selected from BOM Model, a Standard BOM is created to guide manufacturing planning and execution
# Repetitive combinations of option selections can be stored and retrieved as pre-configured Items


BOM Types:

1. Standard Bill
2. Model Bill
3. Option Class
4. Planning Bill


BOM Models:

•Create Model bills to represent products and service that allow user-selected options:
# Option Classes are groups of optional items
# Optional Items
# Required Items
•Model bills and Option Class bills of material can include:
# Stock Items
# Assemble-to-Order Models
# Mandatory and Optional Components

PTO and ATO BOM Models:


•ATO BOM Models:
# Represent product models that require assembly “downstream” in Oracle Work In Process
# Are assembled using manufacturing work orders that can be costed
•PTO BOM Models:
# Represent product Models in which included items appear on pick slips and selected when the order ships
# Are not costed


Configurable PTO and ATO BOM Models:


# The inventory Item that represents the top level in your BOM Model must have the BOM Item Type attribute set to Model
# PTO and ATO BOM Models can contain Standard Items and Option Classes as components
# ATO and PTO BOM Models can also contain other ATO BOM Models as components
# An ATO BOM Model cannot contain a PTO BOM Model
# A PTO BOM Model can contain a PTO BOM Model


Implicit Rules:


•Basic rules are included with Oracle Bills of Material:
# Optional or Required
# Mutually Exclusive
# Maximum and Minimum Quantity
# Quantity Cascade
•These rules provided by Oracle Bills of Material are called Implicit Rules.
•Oracle Configurator honors these rules as well as the rules defined using Oracle Configurator Developer


Option Classes:

Option Class is an element of a Configuration Model.The purpose of Option Classes are to group and prevent viable alternatives. The end user typically selects one or more options from each Option Class during runtime to create a valid configuration.

Option Class Selection Rules:


BOM Model rules for selecting options from an Option Class during order entry:
•Required and Mutually exclusive:You must select one and only one Item in this Option Class
•Required:You must select one or more optional items in this Option Class
•Optional and Mutually Exclusive:You can select only one optional item in this Option Class
•Optional:Select none, some, or all optional items in this Option Class


BOM Example:

Oracle Configurator Fundamentals

Oracle Configurator Introduction:

A configurator is a tool for configuring products and services. The configuration process can include assessing customer needs, selecting product and service components, and viewing configurations. Oracle Configurator can be integrated with the following applications,
•iStore
•Order management
•TeleSales
•Sales Online
•Quoting
•A custom Web Application


Oracle Configurator Supports:

# Configuration for Simple to Complex products and services
# Guided Buying or Selling for non-expert users
# Real-time validation during option selection
# Multiple User Interfaces (Uis) for different types of users accessing the same model
# Batch validation of configuration models
# Custom rule extensions to the configuration model
# APIs for integrating with other hosting applications, including custom Web applications
# BOM Synchronization
# Multiple Instantiation in Solution-based Models
# Model Networks and Connectivity
# Configuring Attributes

Oracle Configurator Architecture:

I. Three-Tier Architecture
• Data tier for Oracle Applications Database Server
• Application Tier for the Oracle Configurator Servlet and Internet or Web Server
• UI Tier for Configurator Thin Client UI
II. Runtime Oracle Configurator and Oracle Configurator Developer use the same data tier architecture .
III. Production Oracle Configurator and the test runtime Configurator. User Interface invoked from Oracle Configurator Developer are thin Client Uis using the same application tier architecture


Oracle Configurator Implementation Overview:

•Setup an Oracle Configurator development or test environment
•Import PTO and ATO BOM Model structures and Item Master data into Oracle Configurator Developer
•Use Oracle Configurator Developer to enhance the configuration model:
# Structure (imported from Oracle BOM or structure you create in Developer)
# Rules
# User Interface
•If required, extend the configuration model by using Functional Companions to:
# Access information outside the configuration model
# Perform engineering calculations
# Integrate with an alternative User Interface
# Write custom rules that cannot be created using OCD
•Test the configuration model and any Functional Companions against defined Test Cases.


Conceptual Overview of Configurator Implementation Flow:

RMA (Return) Order Cycle

RMA Defined:

•Permission for a customer to return lines.
•Oracle Order Management allows you to authorize the return of your sales orders as well as sales made by other dealers or suppliers, as long as the items are part of your item master and price list.

Standard Return Flow:

Typical RMA Business Processes:

•RMA with credit only
–Your company issues a credit without the customer returning the product.
–Accept returns for credit by applying credits to original invoices or creating on account credits.
•RMA with receipt and credit
–Customer returns a product and receives credit.
•RMA with receipt and no credit
–Your customer returns a product you sent to them on a trial basis or at no charge, therefore they receive no credit.

Other RMA Types:

•RMA with repair
–Your customer returns a damaged product. Your company repairs and returns the product to the customer.
•RMA with replacement
–Your customer returns a product and your company sends a replacement product rather than issuing a credit.
•Returned item fails inspection
–Customer returns product, company inspects product and rejects it. Company scraps product or sends product back to customer.
•Trade in
–Return line on the same order as the product that the customer is purchasing.

Accounting Impact:

•During receipt of RMA in Receiving Inventory
Receiving Inventory Dr.
COGS Cr.
•During receipt into Subinventory
Material Dr.
Receiving Inventory Cr.
•During generation of Credit Memo
Revenue a/c Dr. to Receivables a/c Cr.

Tables that get updated:

•OE_ORDER_HEADERS_ALL
•OE_ORDER_LINES_ALL
•RCV_SHIPMENT_HEADERS
•RCV_SHIPMENT_LINES
•RCV_TRANSACTIONS
•RA_INTERFACE_LINES
•RA_CUSTOMER_TRX_LINES_ALL
•RA_CUSTOMER_TRX_ALL