مكتب الوثائق

سيرة ذاتية أُخفيت هويتها آلياً: حُذف الاسم وبيانات الاتصال والروابط. العبارات بين معقوفتين تعوّض معلومة محذوفة.

سيرة ذاتية مجهولة الهوية

ND-CV-B529DDF7

أنظمة ERP والبرمجيات المندمجة

المغرب الهوية وبيانات الاتصال تقدمها NextData

Oracle EBS R12 Application

[nom]

for Functional consultants

Presenter

Presenter: Sivakumar Ganesan

B.Sc, ACA, ICWA, PMP, PDIM, CIMA (Adv Dip)

Mail: [e-mail]

About the Author

14 Years of Oracle EBS Experience
Have Implemented Oracle EBS for Complex Industries
Solution Architect and Subject Matter Expert
Well known for his Publications in
Business Flow in Oracle Applications
Accounting Flow in Oracle Applications
Involved in development of several custom extensions
Experience in Fresh, Upgrade & Re-implementation Projects
Problem solver & Alternate Solution provider
Convincing Customers on the Best Practices
Specialized in Accounting impact across Oracle EBS modules
Integration / Interface of Multiple Systems

Reviewer: My Sincere Thanks to my friend Ramesh Bommisetty for review of this document and providing valuable feedback

Agenda

Oracle R12 Application Architecture - [nom]
Advantages and Disadvantages of each model
Recommendations

Acronyms

BG – Business Group
LED – Ledger
LE – Legal Entity
OU – Operating Unit
Inv Org – Inventory Organization
LOB – Line of Business (Refers to Balancing Segment in this document)
MOAC – Multi Org Access Control
GBPA – Global Blanket Purchase Agreement
VMI – Vendor Managed Inventory

Disclaimer

The information in this document is the opinion of the author, not of Oracle

Corporation. Any content, materials, information or software downloaded or otherwise obtained through the use of the site is done at your own discretion and risk. Oracle shall have no responsibility for any damage to your computer system or loss of data that results from the download of any content, materials, information or software.

My First ERP Implementation Lesson from the CFO of the Client

“Software should be configured according to Business and Business should not be amended according to the Software”

Introduction

The primary purpose of this document is to enhance the knowledge of Oracle Application R12

Architecture to

Ø Functional Consultants

Ø Project Managers

Ø Technical consultants

Ø and last but not the least to the Customer as well

Suggested Way forward for Oracle EBS

R12 Application Architecture

Make the Customer to understand the Oracle Application Architecture

Suggested Way forward for Oracle EBS

R12 Application Architecture

Evaluate the Right Model for Customer Organization along with customer

Suggested Way forward for Oracle EBS

R12 Application Architecture

Discuss with Stakeholders of the Organization to decide the most suitable model

Suggested Way forward for Oracle EBS

R12 Application Architecture

Configure the Most Suitable Model for the Organization with scalability for the future

Suggested Way forward for Oracle EBS

R12 Application Architecture

Implement and Gain acceptance from the Business

Introduction

In order to explain the concept, I am using the example of AVIS Business

Group throughout this presentation (Reverse of my name SIVA · )

The AVIS Group is selling Sports equipment in the name of AVIS Sports

Goods LLc., in US and UK and they have another business of owning play grounds in US in the name of AVIS Sports Grounds LLc.,.

Prerequisites for proper Oracle Application

Architecture

v Organization Structure v Clearly defined Policies and Procedures of the Organization

Financials
Human Resources
Purchasing v Business Functions Centralized or Decentralized
Financials
Human Resources
Purchasing v Delegation of Authority (Approvals) v Implementation of Shared Services v Reporting Requirements

Oracle R12 Architecture

Business Group · Employees HR

Management

Control & Reporting

Ledger · Financial Reporting

Legal Entity · Tax Information

Operating Unit · Operational Control

Operational

Control & Reporting

Inventory · Inventory / MFG /

Organization · Stock Control

Job

Grade

Position

Competency

People Group

CAGR

Balancing Entity/Funds · Personal

Analysis

Payroll

Bal Seg 1

Accounting

Bal Seg 2 · Flex field

Flexfield Security Rule

Access Control by

[lien]

Organization Structure Example

Important Note: Always Design your structure to have BG, Ledger, LE, OU and inventory org in Parent /child model and never design one child linked to multiple

Parents

Example: Please follow the application architecture design as per sample Diagram provided below in Oracle Applications Administrator user guide

Important Control at Each Level per

Instance

Common Components

Party

Employees · Customers · Suppliers

Business Group · • Employees · • Payroll

Employee Numbering · • Key Flex fields (Job, Grade)
Employee Movement · • Assignment

Ledger · • Calendar · • Accounting Convention

Currency · • P&L and Balance Sheet
Chart of Accounts · • Balancing Segment

Legal Entity · • Establishment · • Bank

Registrations · • Inter company Transactions
Tax · • Link to Balancing Segment

Operating Unit · • Sub ledger Transactions · • Intra company Transactions

Security · • Document Category
Sub Ledger Period closing · • Customer / Supplier Sites

Inventory Org · • Costing Method · • Access Control

Sub Inventory Transactions • Sub Inventory
Inventory Period Closing · • Items (Row /Rack /Bin)

Bank · Legal Entity

[information personnelle] or Multiple BG
HR Organizations
Security Profile
[information personnelle] or Multiple Ledgers
Document Sequencing
Journals / Period Closing
[information personnelle] / Multiple Legal Entities
Intercompany Exceptions
History and Contact Info
[information personnelle] or Multiple OU
Shared Services
SLA/Reconciliation/Reporting
[information personnelle] or Multiple Inv Org
Inventory Transfers
Reconciliation / Reporting

Control Level for Key Flex fields

Key Flex fields · Module

Accounting Flex field · General Ledger

Category Flex field · Assets

Asset Key Flex field · Assets

Location Flex field · Assets

Account Aliases · Inventory

Item Catalogs · Inventory

Item Categories · Inventory

Oracle Service Item Flex field · Service

Sales Orders · Inventory

Stock Locators · Inventory

System Items · Inventory

Sales Tax Location Flex field · Receivables

Territory Flex field · Receivables

Public Sector Budgeting · Public Sector Budgeting

Control

Ledger Level

Instance

Application

Instance

Application

Instance

Application

Control Level for Key Flex fields

Key Flex fields · Module

Bank Details Key Flex Field · Payroll

Cost Allocation Flex field · Payroll

People Group Flex Field · Payroll

Training Resources · Learning Management

CAGR Flex field · Human Resources

Competence Flex field · Human Resources

Grade Flex field · Human Resources

Job Flex field · Human Resources

Personal Analysis Flex field · Human Resources

Position Flex field · Human Resources

Soft coded Key Flex field · Human Resources

Activity Flex field · Enterprise Performance Foundation

AHL Route · Complex Maintenance, Repairs and Overhaul

Control

Business Group

Application

Instance

[nom] Architecture [nom]

Data Partition between HR & Finance

Business Group

Business Group represents the highest level in the structure such as the consolidated enterprise or a major division of a company.
The business group is an organization that is set up and configured in Oracle Human Resources.
Currently ‘Business Group’ has no other purpose but to segregate HR information. If you request a list of employees (in any module) you will only see those employees in the ‘Business Group’ of which your ‘Operating Unit’ is a part.
Multiple ‘Legal Entities’ can relate to a [information personnelle] ‘Business Group’.
The business group is used to administer Human Resources payroll and benefits for employees.
A business group is often related to country- specific legislation
The jurisdictions it represents roughly correspond to nations. If a group of nations unite together on employment laws, it is possible to implement a

[information personnelle] business group for them.

The business group is partitioned into separate files of Human Resources information and is used to administer Human Resources payroll and benefits for employees.
Has no accounting impact

Business Group

Difference between [information personnelle] BG Vs

Multiple BG

Touch Point · [information personnelle] Business Group

Key Flex field · Only one Key Flex field Segments across

all Ledger, Legal Entity and Operating

Unit

(Job, Grade, Position, Costing, People

Group, Competency)

Payroll Processing · Only One Currency

Employee numbering · You can use either Manual or Automatic.

Employee Movement · Possible to transfer employees across

[nom] entities

Payroll · You can have multiple Payrolls linked to

one or more ledgers. Payroll entries are transferred to GL or CM and not to AP

HR Legislation · You can have only one Localization

Patch Applicable to the country

Multiple Business Group

You can have [nom] Key Flex field

Structure for each Business Group

Each BG can have [nom] currency.

More Suitable, if you have operation in more than one country

For each Business Group, you can set either Manual or Automatic

You cannot transfer employee from one

Business Group to another. You need to End date and Recreate in another

Business Group

Same as [information personnelle] Business Group

Each BG can have [nom] Localization applicable to specific country

[information personnelle] Business Group (BG)

[information personnelle] Business Group Advantages &

Disadvantages

Touch Point · Advantages

Key Flex field · More suitable to setup multiple

companies under one Business Group having common Job, Position, Grade

Etc.,

Payroll Currency · Each Company under one Business

Group can have separate or multiple

Payroll if the payment currency is same

Employee Numbering · You can use either Manual or Automatic.

Employee Movement · Possible to transfer employees across

[nom] entities

Payroll · You can have multiple Payrolls linked to

one or more ledgers. Payroll entries are transferred to GL or CM and not to AP

Approval Hierarchy · Position Hierarchy across multiple

companies can be set under one BG

Localization · You can have only one Localization

Patch Applicable to the country

Disadvantages

If you have [nom] Job, Grade, Position etc., for each company, then you need to define multiple business groups

If Payment currency is [nom], then there is only a workaround solution and the company needs to bear the exchange differences

If you have multiple companies under one Business Group, then you cannot have for one company manual and another company automatic

You cannot have multiple Localization

Patch within one Business Group

Multiple Business Group (BG)

Multiple Business Group

Advantages & Disadvantages

Touch Point · Advantages

Key Flex field · You can have [nom] Key Flex field

(Job, Grade, Position etc.,)Structure for each Business Group

Payroll Currency · Each BG can have [nom] currency.

More Suitable, if you have operation in more than one country

Employee Numbering · For each Business Group, you can set

either Manual or Automatic

Employee Movement · You cannot transfer employee from one

Business Group to another. You need to End date and Recreate in another

Business Group

Payroll · You can have multiple Payrolls linked to

one or more ledgers. Payroll entries are transferred to GL or CM and not to AP

Approval Hierarchy

Localization · Each BG can have [nom] Localization

applicable to specific country

Disadvantages

Setting Position Hierarchy across multiple companies under multiple BG is not possible

Deciding factors for Business

Group (BG)

Determining factors for [information personnelle] Business Group or Multiple

Business Group

v No of country in the scope of implementation and HR

Modules is in scope for all countries or not v More than one Key Flex field Requirement v Job, Grade, Position, Costing, Competency, People

Group

v Employee Numbering v HR Legislation

Ledger

Ledger consists of your Chart of Accounts, Calendar, Functional

Currency and Accounting Convention (new in R12).

Ledger

Chart of accounts

structure · Accounting

calendar

Accrual

Cash

Functional

currency

Differences between [information personnelle] Ledger

& Multiple Ledger

Touch Point · [information personnelle] Ledger

Period Closing · GL Period closing will be only one for all

entities

Calendar, Currency, · Same for all but GL Period closing is one

Chart of Accounts · for all entities

and Accounting

Convention

Document Sequence · Multiple Journal Categories to be created

for each entity and some Personalization is required to restrict one entity using another entity Journal category

Consolidation · Not Required, Managed through FSG

Reports

Multiple Ledger

Each Entity can have separate GL

Period closing

It can be same or [nom], but GL period closing is separate for each entity. If the Calendar and COA is same across multiple ledgers, then we can set a Ledger set to simplify the transaction process

Each Entity can have unique Journal category and Document sequence. No

Personalization is required

Consolidation Required. No of Steps are more (Revaluation, Translation, Consolidation and Elimination)

[information personnelle] Ledger Model

AVIS US

Ledger

AVIS

SPORTS

US · Legal

Entity

Business Unit

for Operational · Operating · Operating

Control for PO, · Unit · Unit

AP, AR

Inventory,

Transactions

and Stores · Inv Org · Inv Org

Control

AVIS Group

AVIS

Legal · GROUNDS

Entity · US

Operating

Unit

Inv Org · Inv Org

[information personnelle] Ledger Model Advantages &

Disadvantages

Touch Point · Advantages

Document Sequencing · The Transaction Numbers will be jumbled

across multiple entities and there will not be any audit trail

Period Closing · GL Period close is one step across all

legal entities.

Security Rules · We need to define security rules to restrict

access of one legal entity accessing other legal entity within one ledger

Cross Validation Rules If an account combination not to be created, then we need to define CVR

Consolidation · Consolidation handled through FSG.

Data Partition

Chart of Accounts · Maintenance is simple with one chart of

Structure · accounts

Security Access to · Controlled through Data Access Set

Balancing Segment

Disadvantages

The Transaction numbers will not be unique for a legal entity it is across all legal entities. The Sequence numbers are for a Ledger and not for a Legal

Entity

It serves as a centralized control, but in real practice it is not a practical solution.

Each entity cannot close the ledger as and when they complete their work.

Involves lot of maintenance work

Involves lot of Maintenance work

Extremely Difficult

Only one Chart of Account Structure for all Legal Entities under one ledger.

Excessive standardization

Multiple Ledger Model

AVIS

SPORTS · Ledger 1

AVIS

SPORTS

Legal

Entity

Business Unit

for Operational · Operating

Control for PO, · Unit

AP, AR

Inventory,

Transactions · Inv Org

and Stores

Control

AVIS

Ledger 2 · GROUNDS

AVIS

Legal · GROUNDS

Entity · US

Operating · Operating

Unit · Unit

Inv Org · Inv Org · Inv Org

Multiple Ledger – Advantages &

Disadvantages

Touch Points

Document Sequencing

Period Closing

Consolidation

Data Access Set

Chart of Accounts Structure

Data Partition

Shared Services

Ledger set

Advantages · Disadvantages

The Transaction Numbers will be unique for a Ledger

GL Period close is separate for each ledger

Consolidation Set up, Mapping of COA and need to perform

Consolidation Process of Revaluation, Translation, Consolidation and Elimination

Not Required

We can have [nom] chart of account structure for each

Ledger

Possible

Can be defined if Calendar and Chart of Accounts is same

Deciding factors for Ledger (LED)

Determining factors for [information personnelle] Ledger or Multiple

Ledger

v GL Period Closing v Document Sequence v Financial Consolidation v Calendar, Currency, Chart of Accounts, Accounting

Convention

v [information personnelle] Country or Multiple Country Operation v Data Partition in future v Shared Services

Legal Entity (LE)

"Legal entity" in the Oracle system corresponds to "legal entity" or "company" in the legal world.
You can store information about a registered company or other real world legal entity in the "legal entity“
In the real world, legal entities have the right to own property, the right to trade, and the responsibility to comply with appropriate laws.
They also have the responsibility to account for themselves (balance sheet, income statement, specified reports) to company regulators, taxation authorities, and owners according to rules specified in the relevant legislation.
The Oracle E-Business Suite reflects the real world for legal entities.
The system legal entity is the first party on business transactions and is the transaction tax filer and payer.
Legal entities belong to a Ledger and also belong to respective business group.

One or more legal entities may be associated to a Ledger, and multiple legal entities may be associated to a business group.

A Legal Entity Configurator is provided in Oracle to capture attributes which help in various functions like tax calculation, intercompany processing, bank ownership etc.

Difference between [information personnelle] LE &

Multiple LE

Touch Point · [information personnelle] Legal Entity

Establishment, · All can be defined

Registration,

Jurisdiction, Legal

Authorities

Banks · Banks are owned by Legal Entity and it is

created as a Party in TCA

Tax Set up · Governed based on Tax requirements

Legal and Statutory · If there are no Legal or Statutory

Requirements · requirement, then one Legal entity can

be considered if it does not have multiple

(EIN/TIN) Tax Identification Number

Inter Company · Not Possible

Multiple Legal Entity

Can be defined based on [information personnelle] or multiple (EIN/TIN) Tax identification

Number

Banks are owned by Legal Entity but

Bank related Transactions are controlled at Operating Unit level in AP, AR and CE

Decided based on [information personnelle] or multiple

(EIN/TIN) Tax identification Number

More Suitable if Line of Business are governed by Legal and Statutory and have distinct (EIN/TIN) Tax

Identification Number

Transactions between two legal Entities are considered as Intercompany

Transactions if it is within or across ledgers

[information personnelle] Legal Entity Model

[information personnelle] Legal Entity - Advantages &

Disadvantages

Touch Points · Advantages

Registration · Can be defined

Establishment · Can be defined

Bank Definition · [information personnelle] or Multiple Bank Accounts can be

defined for a bank and attached to the Legal Entity. We can use either a Wire

Transfer or EFT Payments for One Bank

Account making Payments to multiple operating units

Bank Transfer across · Possible

Bank Accounts

Tax Definition · Tax Set up is centralized and control can

be established at individual OU level

Intercompany · Not Applicable. Since it is only one Legal

Transactions · entity.

Period Closing for · Not Applicable. Since it is only one Legal

Intercompany · entity.

Transactions

History of Legal Entity · Maintained

Disadvantages

If Payments to be made by Cheque then, we need to attach the Bank

Account at Operating unit level since the Cheque Print Numbering is controlled at Operating unit level

Multiple Legal Entity

Multiple Legal Entity – Advantages &

Disadvantages

Touch Points · Advantages

Registration · Country-wise details can be maintained

Establishment · Country-wise details can be maintained

Bank Definition · [information personnelle] or Multiple Bank Accounts can be

defined for a bank and attached to the Legal

Entity. We can use either a Wire Transfer or EFT Payments for One Bank Account making Payments to multiple operating units

Bank Transfer across · Possible to perform bank transfer from within

Bank Accounts · and across legal entities

Tax Definition · In 11i Tax Set up is controlled at OU level. In

R12 this has been shifted to LE level. Hence all OU linked to same LE can share the Tax codes in PO, AP and AR modules.

Intercompany · Intercompany Transactions are handled

Transactions · through AGIS Set up with either

Purchase/Sale Invoices or through Journal

Period Closing for · Possible, but an optional set up

Intercompany

Transactions

History of Legal · Can be maintained

Entity

Disadvantages

If Payments to be made by Cheque then, we need to attach the Bank

Account at Operating unit level since the Cheque Print Numbering is controlled at Operating unit level.

Deciding factors for Legal Entity (LE)

Determining factors for [information personnelle] Legal Entity or Multiple

Legal Entities

v No. of Registered Entities v No. of Establishment v Banks per Legal Entity v Tax if applicable v Intercompany Transactions

Operating Unit (OU)

An operating unit represents an organization that uses any Oracle sub-ledger application, for example, Order Management, Payables. It may be a sales office, a division, or a department.

An operating unit is associated with a legal entity. Information is secured by operating unit for these applications. Each user sees information only for their operating unit. Responsibilities are linked to a specific operating unit by the MO: Operating Unit profile option

In the financial applications of Oracle's E-Business Suite, an Operating Unit (OU) is a system organization that:

Stores sub ledger data separately from the data associated with other OUs that support a particular ledger ("Partitions").
Administers sub ledger rules such as those associated with transaction types, sequencing schemes, and other sales tax or VAT regulations ("Complies").
Administers user access to the data for processing and reporting ("Secures").
Is not product specific and automatically links all sub ledger products that post to a specific ledger.
Applies to sub ledger business transaction and document data and associated data such as customer details. Sub ledger accounting data is not tagged with OU identification unless you elect to do so. General ledger and Fixed Assets data is not managed through OUs.

Difference between [information personnelle] OU &

Multiple OU

Touch Point · [information personnelle] OU

Modules Impacted · All the modules need to be set only once.

Payables
Receivables
Cash Management
Purchasing
Order Management
Projects
Advance Collections
Release Management
Incentive Compensation
Sales Online
Marketing Online
Service Modules

Business Need · More suitable for Centralized Control

Data Access · Data is not partitioned. Need to set

security rules and Cross Validation rules

Period Closing · Each Sub ledger has a period closing.

Document · Control is at Ledger Level.

PO & INV

security rules needs to be modified every time when there is addition or modification to LOB

[information personnelle] Operating Unit - Advantages &

Disadvantages

Touch Point · Description

Fixed Assets · FA is not OU specific

Access to Data in · Access and posting

General Ledger · transactions which in

turns update Trial

Balance using Data access set

Reports · All Reports are Operating

Unit Specific

Splitting one Operating · Need to identify data and

Unit to Multiple · segregate Data for each

Operating Unit

Advantages · Disadvantages

Nil

GL is not Operating unit specific. Using Data

Access set we can restrict access to each

LOB

Reports are partitioned · Only few standard

by each OU. · Reports are Customer

Site / Supplier Site

Specific. If there are no

Standard report available at Site Level, it needs to be customized

Need to perform a set up · Time Consuming and

for all the modules and · Complex exercise and

Load the transactions for · need an Implementer to

the split OU · handle this issue

[information personnelle] Operating Unit - Advantages &

Disadvantages

Touch Point · Description

Trial Balance · We can generate Trial Balance

for each LOB

Intra Company · Transactions across LOB

Transactions

Data Partition · Data Partition each LOB wise

Maintenance · Maintaining the OU Setup post

Implementation

Advantages · Disadvantages

With separate balancing segments for each LOB, trial balance generation is simple

Intra company Journals are created automatically.

Very Difficult and cumbersome exercise

It is simple. Because you · The Parameter will be

need to make change in · same for all LOB

one place so it is automatically reflected for all LOB

Multiple Operating Unit

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Sub Ledger · All the modules need to be set · 1. Data Partition

Modules · separately for each OU. · 2. Set up Parameters can

Impacted · • Payables · be [nom] for each OU

Receivables
Cash Management
Purchasing
Order Management
Projects
Advance Collections
Release Management
Incentive Compensation
Sales Online
Marketing Online
Service Modules

Business Need · Based on Business need, we can · 1.Use Single Instance to

decide whether to go for [information personnelle] · support Multiple

org or Multi Org. If you have · Organizations

more than one line of Business, it · 2.Secure data based on

is suggested to go ahead with · user

multi org · 3.Access multi org data

using single responsibility using MOAC

Disadvantages

Set up has to be done for each OU for same module (i.e) Payables each LOB wise

Conceptual

Understanding is difficult

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Prerequisites · 1. · Business Group · Most Suitable for

· Ledger · Decentralized Control in
· Legal Entity · 1. Finance
Purchasing

Set Up Parameters · Set up for every Module · Data is partitioned

for Multi Org has to be · Access is restricted

performed which is time · Security established

consuming exercise if number of OU is more

(PO,AP, AR, CE,OM, Inv etc.,)

Data Access Control · Securing Data Access · User access restricted

from one LOB to another · based on the access to

LOB · the responsibilities

Disadvantages

· Large Effort

Required for set up

· Maintenance is difficult

Maintenance of Data

Reports across Org to be

Customized

GL is not OU specific and hence if the user has access to GL he can access other OU Data.

Need to set data access set for each LOB

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Suppliers · Defining Suppliers each · Each LOB will have

LOB wise · separate Supplier

Account ([nom]

Supplier Number for each

OU) and Supplier Site

Customers · Defining Customers each · Each Line of Business

LOB wise · will have separate

Receivables, Revenue, Earned and Unearned

Revenue account and Payment Terms etc., We can create those many sites based on line of Business. Each LOB will have separate Customer

Account ([nom]

Customer Number for each OU) and Customer

Site

Document Sequence · Transaction Voucher · You can segregate

Numbering · Vouchers based on Line

of Business.

Disadvantages

Customer Relationship

can be established only between two customer accounts of same OU or

[nom] OU and not between two sites of same customer.

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Purchasing function · Purchasing Function is · 1. · Each Line of Business

Decentralized with each · will have access only

line of Business · to their own PR & PO

and not to other LOB.

· Purchasing is

Decentralized and the Document Control, Document Sequence for PR, PO can be established for each

OU.

Purchase Invoice · Creation of Purchase · Decentralized Control

Invoice and Payment

Separate for each OU (LOB)

Payments · Payment to Suppliers · Payment across OU

possible only through Wire

Transfer and EFT

Disadvantages

· Global Blanket Purchase

Agreement cannot be used across Operating

Unit for Budgetary

Control purpose

· The PR, PO creation cannot be combined for multiple LOBs and separate PR, PO needs to be created
· While creating PR, PO you cannot choose other

LOB in Distributions lines

Purchase Invoice needs to be created to specific OU and one Invoice cannot be matched to two POs belong to two [nom] OU Payment across OU is NOT possible using cheque

Payment

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Sales Invoice · Each Source like OM , · 1. · Each Customer

Projects, Property · Balance specific to

Manager and External · each OU (LOB)

System can be integrated · 2. · AR to GL

with [nom] OU · Reconciliation can

be performed by each OU (LOB)

Credit Limit · Credit Limit can be set for · Better credit control and

each LOB at Customer · credit review can be

level or site level. · performed

Receipts · If Customer has given · Each LOB Can collect

One Receipt for multiple · money only for his LOB

LOB then the receipt · and not for other LOB

needs to be split into two and created separately in each OU Disadvantages

Customer Statements

and Dunning Letters needs to be customized to get Consolidated outstanding for the customer across multiple

Reports are generally for an Operating Unit.

Receipts needs to be split and created for each

LOB.

Splitting [information personnelle] Receipt into two is not accepted by many Business people

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Banks · Same Bank Account · Bank Reconciliation is

needs to be defined for · made simple if we have

each OU and [nom] · separate Bank for each

Bank account can be · LOB.

attached if there is only one bank

Bank Reconciliation · Bank Reconciliation is · Reconciliation is simple

simplified, if we have one

Bank across LOB

Period Closing · Separate Period closing · Suitable for

for each LOB for AP, AR, · Decentralized Control.

PO & INV · Biggest advantage each

business can decide according to their own choice without waiting for other line of Business

Security Rules · No need to define · Data itself is partitioned

Security Rules · based on each OU

Disadvantages

Segregating customer

collections and Supplier

Payments for each LOB is difficult if we have only one Bank account

Banker cannot provide a separate Bank Statement for each LOB. Hence data segregation LOB wise is difficult.

Time consuming

exercise. In order to close GL, all the Sub ledger Periods needs to be closed for all OU’s

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Fixed Assets · FA is not OU specific · Nil

Access to Data in · Access and posting · GL is not Operating unit

General Ledger · transactions which in · specific. Using Data

turns update Trial · Access set we can

Balance using Data · restrict access to each

access set · LOB

Reports · All Reports are Operating · Reports are partitioned

Unit Specific · by each OU.

Merging Multiple · Extract Open · Need to Load the Open

Operating Unit into · Transactions Data from · Transactions from the

[information personnelle] Operating Unit · the Closing OU and End · closing Operating Unit

Date the OU and related · into the open operating

Responsibilities · unit

Disadvantages

If a Report is required across multiple OU, then it needs to be customized

Data Partition after merger is very difficult

Multiple Operating Unit -

Advantages & Disadvantages

Touch Point · Description · Advantages

Trial Balance · We can generate Trial Balance · We need to define

for each LOB and each LOB · separate Balancing

can be linked to a OU · segments for each LOB

and link to OU

Intra Company · Transactions across LOB · Intra company Journals

Transactions · are created automatically.

Data Partition · Data Partition across LOB · Very simple and

supported by the multi org architecture

Maintenance · Maintaining the OU after · Each LOB have the

System is up and running · flexibility to define

Parameter according to the business needs

Disadvantages

Maintenance is complex.

If you need to make a change in one parameter, we need to make the change for all OU

Deciding factors for Operating Unit

(OU)

Determining factors for [information personnelle] Operating Unit or Multiple

Operating Unit

v Purchasing / Finance function is Centralized or Decentralized v Data Partition / Data Access Security across LOB v Receipt and Payment at Operating unit level v Sub Ledger Level Period Closing v No. of Banks per entity v Report Requirements v Business need of Split/merger of Operating Units in future

Inventory Organization (Inv. Org)

Inventory Organization is an ‘Organization’ for which you track inventory transactions and balances, and/or that manufactures or distributes products.
Oracle Inventory, Bills of Material, Engineering, Work in Progress, Master Scheduling/MRP, Capacity, Quality, Cost Management, Supply Chain Planning and Purchasing (receiving functions) secure information by ‘Inventory Organization’. ‘
An inventory org rolls-up through one operating unit, but can be used in more than one operating unit within the same business group.
Inventory orgs to be accessed can be controlled as per responsibility by using Organization Access function.
In addition, the following can be controlled by Inventory Organization:
Serial or Lot Number Control
Manufacturing Workday Calendar
Item Sourcing Rule for Replenishment etc
Inventory Costing/Valuation Method’.
Various functions in the Oracle E-Business Suite use this organization classification. For example, to activate the "Purchasing Receiving" function, your responsibility must have access to an organization that is classified as an Inventory Organization.
Through its parent Operating Unit, the Inventory Organization financially impacts the Ledger to which it rolls up. For example, requisition transactions or replenishment of supplies are created against an Inventory Organization, which then have a financial impact on the Ledger.

Differences between [information personnelle] Inv Org

& Multiple Inv Org

Touch Point · [information personnelle] Inv Org

Key Flex Field · Control is at Instance level

Costing Method · You can have any one of the costing

method (Standard, Average, FIFO, LIFO)

Location

Default Inventory · Accounts will be defaulted to Sub inventory

Accounts · from the main Inventory org definition which

cannot be modified if you follow average costing if any transaction is created.

Other Control · Following are controlled at Inventory Org

Level

Serial or Lot Number Control

Manufacturing Workday Calendar

Item Sourcing Rule for Replenishment etc

Enabled · Can be enabled at Inventory Org level

Organization · Manufacturing Partner Organization,

Process Manufacturing Enabled, EAM Enabled, WMS Enabled

WCS Enabled, LCM Enabled

Multiple Inv Org

Same as [information personnelle] Inventory Org

Each inventory Org can have [nom]

costing method

Depending on the Location and Type of Inventory, we can define as many inventory org

Each Inventory org can be defined with

[nom] Material, Resource & Overhead accounts

If the Business needs multiple Serial or Lot control, Manufacturing workday

Calendar or Item Sourcing Rule for Replenishment, then we have to define multiple inventory org

Need to be enabled at every Inventory org level based on business need

[information personnelle] Inventory Organization

[information personnelle] Inventory Org - Advantages &

Disadvantages

Touch Points · Advantages

Key Flex Field · Control is at Instance level

Costing Method · You can have any one of the costing

method (Standard, Average, FIFO,LIFO)

Default Inventory · Accounts will be defaulted to Sub

Accounts · inventory from the main Inventory org

definition. You can change Material, Resource, Overhead etc., Account before any transaction is entered

Disadvantages

You cannot define Multiple Key Flex field like System Items, Item Catalog etc., You cannot have each sub inventory

[nom] costing method

You cannot modify account code combination for material, Resource, Overhead etc., at sub-inventory level after any transaction is created

Multiple Inventory Organization

Multiple Inv Org – Advantages &

Disadvantages

Touch Points · Advantages

Key Flex Field · Same as [information personnelle] Inventory Org

Costing Method · Each inventory Org can have [nom]

costing method. Either Average, FIFO or Standard Costing

Default Inventory · Each Inventory org can be defined with

Accounts · [nom] Material, Resource & Overhead

accounts

Disadvantages

Control is at Instance Level

Convincing auditor for multiple

Inventory valuation method will be an issue.

Deciding factors for Inventory

Organization (Inv Org)

Determining factors for [information personnelle] Inventory Organization or Multiple

Inventory Organization

v No of Inventory Locations v How the client needs Inventory Organization classification for Raw Materials, WIP and Finished Goods v EAM, LCM, WCM, WMS and Process Manufacturing in scope of Implementation or not v Costing Method v Locator, Lot, Serial Control v Accounts for Material, Resource and Overheads etc.,

Critical Points

Following critical points need to be clearly explained to customer

v Purpose of Business Group, Ledger, Legal Entity, OU & Inv Org

v Difference between Balancing Segment and Operating Unit

v Difference between HR Organization and Operating unit

v Pros and Cons of [information personnelle] & Multiple BG, Ledger, Legal Entity, OU, Inv Org

v Data Partition and Data Access set, Ledger Set

v Purpose and usage of Security & Cross Validation Rules

v Security Profile and Multi Org Access Control

v Financial Consolidation Difference between [information personnelle] & Multiple Ledgers

Critical Points - contd

Following critical points need to be clearly explained to customer v Entering Receipts across Operating Unit and applying to invoice - Not possible

v Payments by Cheque across Operating Unit - Not possible

v Two Balancing Segments – Not Possible (Possible in Fusion Financials)

v Fixed Assets and General Ledger are not OU Specific

v Budgeting will not work for Global Blanket Purchases and VMI Org

v Profile control at Site, Application, Responsibility and User Level

v Key Flex field Control at BG Level, Instance Level, Application Level etc.,

v One BG is sufficient if client is not planning to use HRMS in future as well

Deciding Factors for an Appropriate

Oracle Application Architecture

Key Points to consider v Nature of Client Business / Industry v Geographical Spread of Client Business v Clearly defined Organization Structure v Policy, Procedures and Business Processes v Business Functions (FIN, PO &HR) – Centralized or Decentralized v [information personnelle] or Multiple Line of Business v Approval Hierarchy (Position and Supervisory) v Receipts and Payments – Centralized or Decentralized v Business Control and Reporting Requirements (IFRS or GAAP) v Roles and Responsibility Matrix (SOD & SOX Compliance) v Mergers, Acquisitions and Divestitures v Number of Secondary Ledgers & Reporting Ledgers required v Global Single Instance or Multiple Instances v Connection to Server and Instances if it is geographically spread

Changing the Organization Structure

At some point, your company may need to make organization changes.

Companies usually make organization changes to better adapt themselves to the new business needs and challenges of the market.

One type of organization change you can make is to discontinue one organization. You can use the Define Organizations window to discontinue one organization by putting an end date in its definition.
You can perform other organization changes by enabling or disabling organization classifications, or changing the classification attributes. When you do that, you must consider the following:
The Define Organizations window does not re-validate the relationships among legal entities, operating units, and inventory organizations.

Changing the Operating Unit

You should not try to move one ledger or legal entity to another because your data may not be valid for the new ledger or legal entity. Instead, you should disable the old organization and create a new one for the appropriate ledger or legal entity. The new organization will contain your new data, and the disabled organization will act as an old or history entity that stores past transactions.
If you create a new organization, you can still access your historical transactions by logging to the responsibility tied to the disabled organization.

To enter new transactions, you must log into the responsibility tied to the new organization. The data for each of the two organizations are kept separate from one another, and must be accessed separately.

Other Organizations in Oracle EBS

HR Organization

HR organizations represent the basic work structure of any enterprise. They usually represent the functional management, or reporting groups that exist within a business group. In addition to these internal organizations, you can define other organizations for tax and government reporting purposes, or for third party payments.

Organizations in Oracle Projects

Oracle Projects allows you to define organization hierarchies to reflect your company's organizations structure. You can add Oracle Projects-specific organization types to the organization hierarchy (for example, projects organizations or Expenditure organizations) to help you manage your project control requirements. You assign project and expenditure hierarchies to operating units.

Asset Organizations

An asset organization is an organization that allows you to perform asset-related activities for a specific Oracle Assets corporate book. Oracle Assets uses only organizations designated as asset organizations

Conclusion

Designing the structure for an Oracle EBS implementation is like

Architecting for a Building. If it is wrongly designed, the only way to rectify is to demolish and re-implement the solution. Hence please take adequate care to understand the client Business requirements while designing the Oracle Application Architecture.

V ALUE Ê Q UALITY Ê R OADMAP = S UCCESS

Caution: The main reason for many troubled or failure implementation is due to poor design of Oracle application Architecture.

Lessons Learned - 1

I was talking to my colleague in the office cafeteria today...

My colleague is a veterinary surgeon and works in the inventory department in the company where I work.

It is always a pleasure to talk to Doctor. He is always positive, ebullient and has an impish sense of humour. I am always amused by the way he follows up his one liners with a loud laughter, as if providing a cue for others that it is time to laugh....

Doctor was talking to me about an exam that he took during his graduation days.

"There was a question in the exam about the medicine that you give to a horse which is suffering from an acute infection. I wrote the answer quickly and moved on to answer other questions. After about an hour, I realized that the answer that I had written to that question was wrong. So, like any student would do, I crossed out the original answer and wrote the new, correct answer."

"As you can imagine, I was pleased as a punch, for having realized my mistake just in time"

Lessons Learned – 1 - contd

"Imagine my surprise, when the marks came, my Professor had given me Zero marks for that answer. I was livid. I barged into Prof's room, with all the text books to back my claim and demanded that he give me full marks for my correct answer."

"My Professor pacified me. He asked me to sit down. I sat down"

"Then he went on to give me an advise which I will never forget for the rest of my life"

We (other friends had joined us by now) looked at Doctor in expectantly.

"Assume that you have become a doctor", said my Professor, "and a farmer brings a horse to you with an acute infection as mentioned in the question paper. You immediately diagnose the case and give a medicine. The grateful farmer and the horse leave you. After about an hour suddenly you realize that the medicine you gave was wrong. Do you think you will get a chance to rectify to your mistake in real life?"

"In real life, by the time you realize your mistake, the horse would be probably dead because of your wrong prescription. That is the reason I gave you zero marks for your correct answer, said my Professor"

Lessons Learned – 1 - contd

"That was an eye opener" Doctor continued. "I suddenly realized that many a time in your life, you will get situations which calls for the 'correct answer'. You do not have any scope for mistakes. Since talking to Professor, I have become very careful about how I respond to my challenges. "

Doctor completed his anecdote.

When Doctor was talking to us, I remembered an incident that happened when I was working as an engineer in a Steel Manufacturing Company.

We were attending a training on Quality.

"Do you feel that we can achieve 100% quality in what we do? " asked the trainer.

General consensus was 'No'. 'How can we achieve 100% Quality? Aren't we human beings and are prone to make mistakes? Possibly we could achieve 90% quality at best, you need to factor in human errors'.

We were all very happy that we had given a well thought out answer.

Lessons Learned – 1 - contd

Our trainer continued, "Yesterday, I went to a doctor to talk to him about an impending surgery. Being a quality person, I asked him the same question. He also gave me the same answer that you gave. He told me that while the chances of success was about 90%,he had to factor in 10% for human error. Do you think I will go to that doctor again?"

"Why is it that when it comes to our work and our output, we compromise on quality by factoring in 'Human Errors', but when we expect things from others, we expect

100% quality? Why can't we deliver the same level of quality that we always expect from others?"

A food for thought, perhaps?

Source: Ramaswamy V Krishnamurti – Linkedin Posts

Lesson Learned - 2

A German once visited a temple under construction where he saw a sculptor making an idol of God. Suddenly he noticed a similar idol lying nearby. Surprised, he asked the sculptor, "Do you need two statues of the same idol?" "No," said the sculptor without looking up, "We need only one, but the first one got damaged at the last stage." The gentleman examined the idol and found no apparent damage. "...Where is the damage?" he asked. "There is a scratch on the nose of the idol." said the sculptor, still busy with his work. "Where are you going to install the idol?"

The sculptor replied that it would be installed on a pillar twenty feet high. "If the idol is that far, who is going to know that there is a scratch on the nose?" the gentleman asked. The sculptor stopped work, looked up at the gentleman, smiled and said, "I will know it."

The desire to excel is exclusive of the fact whether someone else appreciates it or not.

"Excellence" is a drive from inside, not outside. Excellence is not for someone else to notice but

for your own satisfaction and efficiency... Source: Anonymous · 86

Questions & Answers

Shoot your questions to [e-mail]

Conclusion & Thanks

للتواصل مع صاحب هذا الملف، اذكر المرجع ND-CV-B529DDF7: contact@nextdata.ma

مكتب الوثائق

ملف من قاعدة السير الذاتية

ملف المترشح تمّ دمج 2 بطاقات (الشخص نفسه)

أنظمة ERP والبرمجيات المندمجة

AVIS US

PO & INV