Demo – Release 12 Functionalities

--
Definition:-

 Business Group
 Legal Entity
Operating Unit
 Architecture Organization Model – Release 12

Business Group Oracle Modules:

This is an Organization that
represents the consolidated  HRMS
enterprise, a major division,
Payroll
or an operation company and
has no accounting impact.
The Business Group partitions
Human Resources information
and the Purchasing Approval
Hierarchy.
 Architecture Organization Model – Release 12
Organization Definition:

Legal Entity Oracle Modules:

A legal entity represents a legal company  GL

for which you prepare fiscal or tax reports.
You assign tax identifiers and other legal entity  FA
information to these types of organizations.
Future enhancements will include greater
functionality at this organization level.
 Architecture Organization Model – Release 12
Organization Definition:

Operating Unit
Oracle Modules:
The Operating Unit is an organization that uses
Oracle, Cash Management, Order Management
and Shipping Execution, Oracle Payables,  PO
Oracle Purchasing and Oracle Receivables.  Payables
The operating unit may be a sales office, a  Payments
division or a department. The Operating Unit has
to be assigned to a Legal Entity and a Set of  AR
Books.  Cash Management
 What is TCA and its Background
• A Trading Community is…
– The participants in a community and their
relationship to one another
Competitor of Partner of
Competitor Partner

Customer /
Organization

Employee of Supplier of
Employee Supplier
 What is TCA and its Background
• TCA = Trading Community Architecture
• Provides a single, universal definition of trading
partners across applications and job function
• TCA is an Data Model – it is not a Module

Oracle E-Business Suite Application Families*

3rd Party
Sales / Financials – Financials – Systems
Marketing
AP, AR GL, FA, PO
HR
Service

TCA Enabling Infrastructure

Common Party UI, DQM, D&B Integration, APIs

TCA Data Model

HZ Schema
What is TCA and its Background

TCA (Trading Community Architecture) Party Definition

 TCA Central Data Model

 Supplier Representation
 New Bank Model
 TCA in R12: Leveraging centralized data
model

Global Recieva
Payable Tax bles Cash
Purchasi s Governments, Party Manageme
ng “Geographies”, Informatio nt and
Suppliers Banks
Authorities, etc n
Branches

Trading
Trading
Community
Community
Architecture
Architecture

Oracle

ERP CRM 3rrdd Party

 TCA in R12: Supplier
• Representation
Suppliers are organizations in TCA
• Supplier organization, address, contact, phone, email
etc. are all in TCA
• Employees are already in TCA, Payables use the same
employee records in TCA
• New supplier maintenance are done using UI in TCA
components (DQM)
• Terms of doing business with the supplier are
in Purchasing / Payables
 TCA in R12
New Bank Account Model
• Central place to define internal bank
accounts
– Keep track of all bank accounts in one place
– Explicitly grant account access to multiple
operating units/functions and users
• Multi-Org Access
– In the new model, bank accounts are owned by
Legal Entities with the option to grant account
use to Operating Unit (Payables, Receivables),
Legal Entity (Treasury), Business Group (Payroll)
 TCA in R12: Bank Account Model
Pay invoices from different OUs with 1 instruction

• New Payments Module

OU A
• New Bank Module
• New Bank & Credit Card Features

OU B

Payments
OU C Single Bank
Payment
Instruction

Sub
Ledger
Invoices
Accounti
ng
MOAC: Multi-Org Access Control

 Role based access to Operating Units

 Define Security Profile
 MOAC Usage
Area of Impact
Impact on Business Processes
Day-to-day business processes
e.g., Invoice creation, Payment
processing etc
Running Reports in Sub-ledger
Month-end operations
Visibility of master data e.g. Visible for all business functions within Only master data is shared between the
Vendors (Suppliers), Customers the same organization
etc.
Single Organizations Multiple Organizations
Potentially executed once for all three Executed multiple times – once for each
business functions combined organization
Potentially executed once for all three Depending on security and access typically
business functions combined executed multiple times – once for each
organization. Consolidated reports can be
run for those with multiple organizational
access
Done once per month in each module To be done multiple times – once per
organization per month in each module.
However R12 allows users to close multiple
organizations at once in order to streamline
efficiency.
organizations. The other data needs to be
assigned to each organization e.g.: only
Vendor header level data is shared while
vendor-site level data needs to be assigned
separately in each organization. This is
handled through a centralized access
screen
Area of Impact
Impact on Project (Implementation Effort)
Application configuration
Need for custom extensions
Reporting
Single Organizations Multiple Organizations
Configuration is required for one Configuration is required for each organization
organization (less effort). (more effort).
However, the complexity of configuration However, it offers more flexibility to meet
may increase (more effort). requirements of each business function.
The FAO HQ and Field share similar Custom extensions are less likely (less effort)
business processes but their focus differs.
As a result, there is a higher likelihood of
custom extensions to support these
differences. (more effort) This is
particularly true with respect to the FAO
HQ requirements.
Report development could be complex Reporting will be less of a challenge with
particularly if the reporting requirements separation by organization and will not have
between the three areas differ the complexity of a single organization.
significantly. There will also be an issue
to segregate the FAO HQ and Field report
data.
Area of Impact Single Organizations Multiple Organizations

Testing With all of the FAO’s business processes Testing effort will be higher as the testing needs
sharing the same organization, the potential will have to ensure each Field & FAO HQ are in
for intrusive customizations (changes to place.
Oracle code) may be required. Future
Oracle patches could increase IT effort
(testing and planning). Since all of the FAO
HQ business processes would be contained
in one organization, only one organization
would require testing, which could involve a
shorter testing cycle.
However, if the future business processes
vary significantly, even though, one
organization is used, future testing
complexity is increased.

Configuration Migration Final configuration will need to be migrated Configuration needs to migrated for each
only once per organization per applications organization environment (more effort).
environment setup However, configuring separate organizations is
less of an effort with R12.

Training The training process and learning curve will
be similar regardless of the number of
organizations. The difference will be user
access as some users may have access to
multiple legal entities. This data restriction
might be more of an issue with only one
organization.
The training process and learning curve will be
similar regardless of the number of
organizations. The difference will be user
access as some users may have access to
multiple legal entities. Data restriction and
security is not an issue with multiple
organizations. Data segregation is a standard
feature.
Area of Impact Single Organizations Multiple Organizations

IT Efforts With all of the FAO HQ & Field business With Multiple organizations, intrusive
processes sharing the same customizations will likely not be required.
organization, the potential for intrusive Therefore, impact to the FAO’s patching
customizations (changes to Oracle strategy and upgrades could be reduced.
code) may be required. Future Oracle
patches could increase IT effort (testing
and planning). This would primarily be
due to ensuring mock data segregation
and to meet reporting requirements.
With custom code, there is always a
risk of invaliding areas of support from
Oracle.

Oracle Support With one organization, as mentioned
above, there is a potential for the
requirement for intrusive
customizations (changes to Oracle
code). This could impact the
effectiveness of Oracle Support as
intrusive customizations, by nature, are
not supported by Oracle.
With Multiple organizations, intrusive
customizations will likely not be required.
In this scenario, there should be little
impact to the effectiveness of Oracle
Support.
 MOAC: Multi-Org Access Control
Role based access to Operating Units

Perform multiple tasks across operating

units without changing responsibilities
HQ Functional Tasks
Legal Entity  Requisition,
Purchase Orders
 Receiving & Drop
Mozambiq FAO HQ Congo
Ship
ue Operating Operating  Supplier Invoices
Operating Unit Unit
 Payments
Responsibility
Unit SingleResponsibility
ResponsibilityResponsibility
 Customer Data
Management
 Accounting Setup
 MOAC - Usage
Typical Screen in daily use

 Invoice Entry
Quick Invoices
PO Entry
Receiving
Supplier Sites
Customer Sites
OU Specific Set Ups
OU Specific Reports
S
&
Q U E S T I O N
A N S W E R S
Oracle Architecture / TCA /
MOAC
 FAO Architecture
 Components of TCA
TCA and its implications w.r.t
FAO
MOAC – Definitions &
Implications
MOAC Demo’s
Purchasing – Part 1

Buyers Workbench
 Personalization of Buyers
Workbench
PO Types
Line Types
 PO Requisitions
Standard PO’s, Contract
Agreements,
Global PO’s
 Service Orders, Goods
Purchasing - Part 2

 PO on the Field
 Receiving
 Pay on Receipt
 6 Different Scenarios
 iProcurement
Payables

 Quick Invoices
Invoice Import
 Centralized Shared Services
 Invoice Workbench
Payments
 New Payment Process
 Centralized Payments
 Quick Payments
 Organization
AR s AP/PO
Old Model (Customer) (Organizatio (Supplier)
n)
John, XYZ Inc fao.org John, XYZ Inc

Customer Party:
Party: of
TCA Model John, XYZ
ABC Co. Supplier
of * Inc.
TCA Data Model: Visualization
PARTY Bill to

SITE Ship to

Division Of

PARTY
PARTY

SITE
SITE

Bill to Bill to

Ship to Ship to

Account Account Account

Acct

Acct
Site

Acct
Site

Site

Bill to, Ship to Bill to, Ship to Bill to, Ship to