Phase
1: Planning and Scoping
Phase 2: Configuration and Setup
Phase
3: Data Migration and Integration
Phase 4: Testing
Phase 5: Training and Deployment
Phase 6: Post-Implementation Support
and Optimization
Common
for All Module Implementations.
Phase
4: Testing
Phase
5: Training and Deployment
This phase prepares the organization
for the new system and manages the transition to the production environment.
Phase
6: Post-Implementation Support and Optimization
Documents to be Prepared while
implementation:
 |
|||||
 |
|||||
 |
|||||
Detailed: Document Meaning
·
Project Charter: A formal, high-level
document that outlines the project's purpose, objectives, scope, stakeholders,
and high-level timeline. It gets signed off by the executive sponsor.
·
Business Requirements Document (BRD):
This document details the functional and non-functional requirements of the
business. It captures the "as-is" processes, identifies pain points,
and outlines the desired "to-be" processes. It's often broken down by
module (e.g., GL BRD, Procurement BRD).
·
Solution Design Document (SDD) / High-Level
Design (HLD): This is the blueprint for the entire solution. It translates
the business requirements into a technical design. It includes:
o
System architecture overview.
o
Module-specific designs (e.g., Chart of Accounts
design, workflow rules).
o
Integration strategy.
o
Data migration strategy.
o
Reporting and analytics strategy.
·
Project Plan: A detailed plan that
includes tasks, milestones, resource assignments, and a timeline for all
project activities.
·
Risk and Issue Log: A living document
used to track potential risks to the project and any issues that arise, along
with their mitigation or resolution plans.
·
Configuration Workbook: This is a key
implementation document. It's typically a spreadsheet-based workbook that
records all the configuration settings made in the system. It's used to:
o
Document the setup of enterprise structures
(Legal Entities, Business Units).
o
Record the setup of master data (e.g., supplier
profiles, item master).
o
List all the values for lookups, DFFs
(Descriptive Flexfields), and key configurations.
o
Often, the configuration is broken down into
separate workbooks for each module (e.g., GL Configuration Workbook, Accounts
Payable Configuration Workbook).
·
Design Documents (for extensions): If
custom reports, integrations, or workflows (extensions) are required, separate
design documents are created:
o
Functional Design Document (FDD): Details
the business logic and functional requirements of the custom component.
o
Technical Design Document (TDD):
Describes the technical specifications, including the tables, APIs, and code
logic for the custom component.
·
Data Conversion Strategy / Data Migration
Plan: Outlines the approach for migrating data from legacy systems to
Oracle Fusion. It defines the scope of data to be migrated (e.g., master data,
open transactions), the migration tools (e.g., FBDI, ADFdi), and the cleansing
and validation process.
·
Data Mapping Document: A detailed
spreadsheet that maps fields from the source system to the target fields in
Oracle Fusion. This is crucial for the technical team building the data
conversion programs.
·
Integration Design Document: Describes
the design of each integration point, including the data formats, security, and
frequency of data exchange.
·
Test Strategy / Test Plan: Defines the
overall testing approach for the project, including the different types of
testing to be performed (Unit, SIT, UAT), the test environments, and the roles
and responsibilities.
·
Test Scripts / Test Cases: Detailed
step-by-step instructions for testers to follow. Each script includes a test
scenario, the expected result, and a space to record the actual result.
·
User Acceptance Testing (UAT) Sign-off
Document: A formal document signed by key business users or stakeholders to
confirm that they have tested the system and accept it as meeting the business
requirements.
·
Training Plan: A schedule and curriculum
for training end-users, specifying who needs to be trained, on what topics, and
when.
·
Training Materials: Includes user
manuals, process guides, presentation decks, and quick reference cards. These
are often role-based to provide specific instructions for each user group.
·
Cutover Plan: A detailed,
minute-by-minute plan for the go-live weekend. It outlines all the steps
required to transition from the old system to the new one, including data
migration, system shutdown, and final validations.
·
Support Model Document: Defines the
post-go-live support structure, including who to contact for issues, the
escalation process, and roles for managing the system (e.g., administrators,
help desk).
·
System Administration Guide: A technical
document for administrators on how to manage the system, including user
security, new user provisioning, and running maintenance jobs.
·
Lessons Learned Document: A summary of
what went well, what could be improved, and key recommendations for future
projects. This is a critical document for continuous improvement.
General
Ledger
This phase lays the
groundwork for the entire project. It's where you define the business
requirements, design the future state, and plan the project's execution.
·
Project Kick-off and Team
Formation:
o Project Charter: Create a
document that defines the project's objectives, scope, timeline, and key
stakeholders.
o Team: Assemble the
implementation team, which should include:
§ Project Manager: To oversee
the project plan, resources, and communication.
§ Functional Consultants: GL
and other financials module experts.
§ Technical Consultants: For
data migration, integration, and reporting.
§ Business Subject Matter Experts (SMEs): From the finance and accounting departments who
understand the current processes.
·
Business Requirements
Gathering:
o "As-Is" Analysis:
Document the current accounting and reporting processes. This includes
understanding the existing chart of accounts, accounting calendars, and
financial reports.
o "To-Be" Process Design: Design the new processes in Oracle Fusion GL, leveraging
standard functionalities and best practices.
o Chart of Accounts (COA) Design:
This is arguably the most critical step. The COA is the foundation of the
financial structure.
§ Analyze Reporting Needs:
What financial statements (income statement, balance sheet) and management
reports are required?
§ Define Segments: Determine
the segments of the COA (e.g., Company, Department, Account, Intercompany). A
good COA design is flexible, scalable, and meets all reporting needs.
§ Value Sets: Define the
value sets for each segment and their validation types (e.g., independent,
dependent).
·
Solution Design Document (SDD):
o Create a comprehensive document that outlines the final
design of the GL solution, including the COA structure, ledger setup, and
reporting requirements.
This phase involves
configuring the GL module in Oracle Fusion using the Functional Setup Manager
(FSM).
·
Enterprise Structures:
o Enterprise: The highest
level of the organizational hierarchy.
o Legal Entities: Define the
legal entities that will be responsible for statutory and tax reporting.
o Business Units: Define
Business Units to manage business functions, such as processing transactions.
·
Chart of Accounts (COA)
Configuration:
o Manage Chart of Accounts Structures: Create the COA structure based on the design from Phase
1.
o Manage Value Sets: Define
the value sets for each segment, including the values and their hierarchies.
o Manage Account Hierarchies:
Build and maintain hierarchies (trees) for segments like Company and Account.
These hierarchies are crucial for reporting and security.
o Deploy Flexfield: After all
segments and value sets are defined, the COA structure must be deployed to be
used by the system.
·
Ledger Configuration:
o Primary Ledger: This is the
main ledger that records all financial transactions. The primary ledger is a
combination of four components:
§ Chart of Accounts: The COA
you just created.
§ Accounting Calendar: Define
the accounting periods (e.g., monthly, quarterly).
§ Currency: The functional
currency of the ledger.
§ Accounting Method: The
accounting standard (e.g., U.S. GAAP, IFRS).
o Secondary Ledgers (Optional):
If needed, configure secondary ledgers to maintain an alternate accounting
representation for specific legal or reporting requirements.
o Data Access Sets (DAS):
Create DAS to control which ledgers and balancing segment values a user can
access, ensuring data security.
·
Other Key GL Configurations:
o Journal Setup:
§ Journal Sources and Categories:
Define sources (e.g., Payables, Receivables) and categories (e.g., Purchase
Invoice, Sales Invoice) for journals.
§ Journal Approval Rules:
Configure the approval workflow for journal entries.
§ AutoPost Criteria Sets:
Define rules to automatically post journals that meet specific criteria.
o Intercompany Setup:
§ Intercompany System Options:
Configure rules for automatic intercompany balancing.
§ Intercompany Balancing Rules:
Set up rules to automatically generate intercompany balancing segments for
cross-company transactions.
o Revaluation and Translation:
§ Manage Revaluation:
Configure how foreign currency balances are revalued.
§ Manage Translation:
Configure how ledger balances are translated for consolidation purposes.
This phase is about
populating the new system with data and ensuring it can communicate with other
applications.
·
Master Data Migration:
o Use tools like File-Based Data Import (FBDI)
and ADF Desktop Integrator (ADFdi) to load master data,
such as:
§ Chart of accounts segment values (if not using the rapid
implementation spreadsheet).
§ Journal entry batches.
o Rapid Implementation Spreadsheet: For a quick start, this spreadsheet allows you to define
enterprise structures, COA, ledgers, and legal entities in a single file and
upload it.
·
System Integration:
o Subledger Integration:
Verify that subledgers (e.g., Accounts Payable, Accounts Receivable) are
properly configured to send accounting data to the GL via Subledger Accounting (SLA).
o External System Integration:
Use Oracle Integration Cloud (OIC) or other integration
tools to connect the GL with external systems for data exchange.
Payables
·
Project Kick-off and Team Formation:
o
Project Charter: Establish a formal
document outlining project goals, scope, and key stakeholders.
o
Team: Form a cross-functional team
including a Project Manager, Payables functional and technical consultants, and
business subject matter experts (SMEs) from the Accounts Payable department.
·
Requirements Gathering and Business Process
Analysis:
o
"As-Is" Analysis: Document the
current invoice processing and payment methods. This includes understanding
manual invoice entry, approval workflows, and how payments are made and
reconciled.
o
"To-Be" Process Design: Design
the future state business processes leveraging Oracle Fusion Payables'
capabilities. This includes defining the flow from invoice receipt (e.g.,
email, supplier portal) to final payment and accounting.
o
Integration Points: Identify and document
key integration points with other modules, especially Procurement (for Purchase
Order matching), General Ledger (for accounting), and Cash Management (for bank
reconciliation).
·
Solution Design Document (SDD):
o
Create a detailed blueprint of the Payables
solution. This document will cover the design of invoice processing rules,
payment formats, bank account setup, and reporting requirements.
·
Enterprise Structures:
o
Ensure the foundational enterprise structures
(Legal Entities, Business Units, Ledgers) are already set up as part of the
General Ledger implementation.
·
Common Payables and Procurement
Configurations:
o
Common Options: Configure common options
for Payables and Procurement, such as payment terms, freight terms, and bill of
lading types.
o
Lookups and Flexfields: Set up and enable
any necessary custom lookups or Descriptive Flexfields (DFFs) to capture
additional information on invoices or payments.
·
Payables Specific Configurations:
o
Payables Options: Configure core Payables
options at the Business Unit level. This includes:
§ Invoice
Options: Invoice type defaults, payment options, and tax handling.
§ Payment
Options: Payment processing methods, payment request defaults, and payment
file formats.
o
Invoice Configuration:
§ Invoice
Holds and Releases: Define the types of holds (e.g., quantity variance,
price variance) and their corresponding release rules.
§ Distribution
Sets: Configure distribution sets for recurring non-PO invoices to automate
the creation of accounting distributions.
§ Payables
Approval Workflow: Design and configure the approval workflow for invoices
based on business rules (e.g., by amount, by supplier, by expense category).
o
Payments Configuration:
§ Payment
Process Profile: This is a crucial setup that defines how payments are
generated. It links payment methods, payment formats (e.g., ACH, wire
transfer), and bank accounts.
§ Payment
Method: Define the methods of payment used by the organization (e.g.,
Check, ACH, Wire).
§ Payment
Format: Configure the layout and content of the payment file that will be
sent to the bank. This often requires working with the bank to get their
specific file format specifications.
§ Bank
and Bank Account Setup: Define the company's banks and bank accounts, and
link them to the Cash Management module for reconciliation.
o
Supplier Configuration:
§ Supplier
Profile: Configure supplier attributes, address types, and the approval
workflow for new supplier requests.
§ Supplier
Sites: Define supplier sites and their payment options.
§ Supplier
Bank Accounts: Configure supplier bank accounts for electronic payments.
·
Data Migration Strategy:
o
Master Data: Plan the migration of
supplier data, including supplier profiles, addresses, and bank accounts.
o
Open Transaction Data: Decide whether to
migrate open invoices and unapplied payments. This requires careful planning
and coordination to avoid double-entry.
·
Data Migration Tools:
o
Use File-Based Data Import (FBDI)
templates for bulk loading of suppliers and invoices.
o
Use ADF Desktop Integrator (ADFdi) for
creating journal entries for cutover balances.
·
System Integration:
o
Procurement: Ensure the integration with
Oracle Fusion Procurement for invoice matching is working correctly. This is
essential for the Procure-to-Pay flow.
o
General Ledger: Verify the integration
with GL through Subledger Accounting (SLA). Payables transactions are sent to
SLA, which creates the final accounting entries that are posted to the GL.
o
Cash Management: Confirm that the
integration with Cash Management is set up for bank statement reconciliation.
o
External Systems: If required, integrate
with external systems for payment processing or tax calculation.
Receivables
·
Project Kick-off and Team Formation:
o
Project Charter: Create a document that
defines the project's goals, scope, timeline, and key stakeholders, including
the executive sponsor and project manager.
o
Team: Assemble a cross-functional team
with a strong understanding of the business. This includes Receivables
functional and technical consultants, and business Subject Matter Experts
(SMEs) from the Accounts Receivable department, Sales, and Credit and Collections.
·
Requirements Gathering and Business Process
Analysis:
o
"As-Is" Analysis: Document the
current invoicing, cash application, and collections processes. Understand how
invoices are generated, how payments are received and applied, and how
collections are managed.
o
"To-Be" Process Design: Design
the future state business processes in Oracle Fusion Receivables, leveraging
standard functionality and best practices. This includes defining the flow from
sales order or billing to invoice creation, payment processing, and final
revenue recognition.
o
Integration Points: Identify and document
key integration points, especially with Sales and Order Management (for invoice
creation), General Ledger (for accounting), and Cash Management (for bank
reconciliation).
·
Solution Design Document (SDD):
o
Create a detailed blueprint of the Receivables
solution. This document will cover the design of invoice and receipt classes,
revenue recognition rules, and reporting requirements.
·
Enterprise Structures:
o
Ensure the foundational enterprise structures
(Legal Entities, Business Units, Ledgers) are already set up as part of the
General Ledger implementation.
·
Receivables Specific Configurations:
o
Receivables System Options: Configure
core Receivables options at the Business Unit level. This includes:
§ Customer
and Bill-to settings: Defaults for customer creation.
§ Invoice
settings: Automatic invoice numbering, grouping rules, and transaction
types.
§ Payment
settings: Receipt numbering and cash receipt accounts.
o
Transaction Configuration:
§ Transaction
Types: Define different types of invoices (e.g., standard invoice, credit
memo, debit memo).
§ Transaction
Sources: Configure sources for transactions, such as manual entry, billing
systems, or external applications.
§ AutoInvoice:
This is a key feature for implementing Receivables. Configure AutoInvoice to
import and validate invoices from external systems. Define the grouping rules
to ensure lines are grouped correctly into invoices.
o
Receipts and Payments:
§ Receipt
Class and Method: Define the types of receipts (e.g., manual, lockbox,
electronic) and their corresponding payment methods.
§ Automatic
Receipts and Remittances: Configure rules for automatically generating and
applying receipts from bank files (e.g., lockbox).
§ Lockbox
Processing: Set up lockbox to automatically process bank files containing
customer payments.
o
Revenue Recognition:
§ Revenue
Contingencies: Configure rules for recognizing revenue based on events,
such as customer acceptance.
§ Revenue
Scheduling Rules: Define rules for how revenue is recognized over time
(e.g., in equal installments, on a specific date).
o
Collections:
§ Collections
Setup: Configure collections settings, including collections scoring,
strategies, and dunning letters.
§ Dunning
Letters: Design and configure dunning letter formats and send methods.
·
Customer Setup:
o
Customer Profile Classes: Define customer
profile classes to group customers with similar credit, collections, and
reporting requirements.
o
Customer and Site Creation: Plan for the
creation of customers and their associated sites (e.g., bill-to, ship-to).
·
Data Migration Strategy:
o
Master Data: Plan the migration of
customer data, including customer profiles, addresses, and credit information.
o
Open Transaction Data: Decide whether to
migrate open invoices and unapplied receipts. This is a critical cutover
decision that requires careful planning.
·
Data Migration Tools:
o
Use File-Based Data Import (FBDI)
templates for bulk loading of customers, invoices, and receipts.
o
Use ADF Desktop Integrator (ADFdi) for
creating journal entries for cutover balances.
·
System Integration:
o
Order Management/Billing: The most common
integration point is with a billing or order management system that feeds
invoices to Receivables via AutoInvoice.
o
General Ledger: Verify the integration
with GL through Subledger Accounting (SLA). Receivables transactions are sent
to SLA, which creates the final accounting entries that are posted to the GL.
o
Cash Management: Confirm that the
integration with Cash Management is set up for bank statement reconciliation.
Fixed
Assets
·
Project Kick-off and Team Formation:
o
Project Charter: Establish a formal
document outlining project goals, scope, and key stakeholders.
o
Team: Form a team including a Project
Manager, Fixed Assets functional consultants, and business Subject Matter
Experts (SMEs) from the accounting and finance departments.
·
Requirements Gathering and Business Process
Analysis:
o
"As-Is" Analysis: Document the
current process for managing fixed assets, including how assets are acquired,
depreciated, and disposed of. This includes understanding the existing asset
categories, depreciation rules, and reporting requirements.
o
"To-Be" Process Design: Design
the future state business processes in Oracle Fusion Fixed Assets. This will
involve defining how asset information will flow from procurement or projects
into Fixed Assets and how depreciation will be calculated and posted to the
General Ledger.
·
Solution Design Document (SDD):
o
Create a detailed blueprint of the Fixed Assets
solution. This document will cover the design of asset categories, depreciation
books, and integration points.
·
Enterprise Structures:
o
Ensure the foundational enterprise structures
(Ledgers, Legal Entities) are already configured from the General Ledger
implementation.
·
Fixed Assets Specific Configurations:
o
Book Controls: This is a crucial first
step. A depreciation book is a set of asset records and financial rules.
You'll set up:
§ Corporate
Book: The primary book for financial reporting (e.g., for GAAP or IFRS).
§ Tax
Book: If needed, a separate book for tax reporting that can have different
depreciation rules.
o
System Controls: Define the fiscal year
and accounting period for each depreciation book.
o
Asset Calendars: Create calendars for
depreciation, prorate, and retirement. The depreciation calendar
determines the periods for which depreciation is calculated. The prorate
calendar defines the conventions for when depreciation starts.
o
Asset Categories: Set up asset categories
(e.g., Computer Equipment, Office Furniture) and assign default values to them,
such as:
§ Depreciation
Method: The method used to calculate depreciation (e.g., straight-line,
declining balance).
§ Life:
The useful life of the asset in years.
§ Prorate
Convention: The rule for when depreciation begins (e.g., full month,
mid-month).
o
Location and Employee Setup:
§ Define
asset locations to track where assets are physically located.
§ Link
employees to assets for accountability.
o
Mass Additions: Configure the rules for
loading assets from other modules, such as Procurement and Projects. This is a
key part of the integration process.
·
Data Migration Strategy:
o
Master Data: Plan the migration of
existing assets, including asset descriptions, costs, accumulated depreciation,
and asset location.
o
Data Conversion: Decide on the method for
converting legacy asset data. This usually involves cleansing the data and
preparing it for loading.
·
Data Migration Tools:
o
Use File-Based Data Import (FBDI)
templates for bulk loading assets and asset transactions. FBDI is the most
common and efficient method for this.
o
Use ADF Desktop Integrator (ADFdi) for
loading smaller sets of assets or transactions.
·
System Integration:
o
Procurement: Configure the integration to
bring asset-related purchase orders and invoices from Procurement into Fixed
Assets as Mass Additions.
o
Projects: Set up the integration with
Oracle Fusion Projects to capture project-related asset costs and import them
into Fixed Assets.
o
General Ledger: Ensure the integration
with GL through Subledger Accounting (SLA) is configured. Fixed Assets
transactions (e.g., depreciation, retirement) are sent to SLA, which creates
the final accounting entries that are posted to the GL.
o
Cash Management: For asset disposals and
sales, ensure the necessary cash receipts and journals are passed to Cash
Management
Cash
Management
·
Project Kick-off and Team Formation:
o
Project Charter: Create a document
outlining the project's goals, scope, and stakeholders, including the project
manager, functional consultants, and business SMEs from treasury and finance.
o
Requirements Gathering: Understand the
current bank account structure, reconciliation processes (e.g., manual vs.
automated), and cash forecasting needs. Document all business requirements in a
Business Requirements Document (BRD).
·
Solution Design Document (SDD):
o
Develop a blueprint for the Cash Management
solution. This document will detail the bank account structure, reconciliation
rules, bank statement formats, and integration points with other modules.
·
Enterprise Structures:
o
Ensure the foundational enterprise structures
(Legal Entities, Ledgers) are already set up as part of the General Ledger
implementation.
·
Bank, Branch, and Bank Account Setup:
o
Manage Banks: Define the banks your
organization uses.
o
Manage Bank Branches: Create the branches
of each bank.
o
Manage Bank Accounts: This is the most
critical step. Create the company's bank accounts, linking them to legal
entities and ledgers. Key settings include:
§ Currency:
The currency of the bank account.
§ Account
Use: Specify if the account is used for Payables, Receivables, Payroll,
etc.
§ GL
Account: Link the bank account to the corresponding General Ledger cash
account.
§ Reconciliation:
Enable and set up parameters for automatic reconciliation.
·
Reconciliation Setup:
o
Reconciliation Matching Rules: Define
rules to automatically match bank statement lines with system transactions
(e.g., matching a payment on the statement to an invoice payment in Payables).
o
Transaction Codes: Map bank statement
transaction codes to internal system transaction types. This is essential for
automatic reconciliation.
·
Cash Positioning and Forecasting:
o
Cash Positioning: Configure cash
positioning, which provides a real-time view of cash balances across all bank
accounts.
o
Cash Forecasting: Define sources and
rules for forecasting future cash flows. This can include data from Receivables
(invoices), Payables (invoices), and other modules.
·
Bank Statement Integration:
o
Work with your bank to determine the format of
their bank statements (e.g., BAI2, SWIFT MT940). This is a critical technical
step.
o
Set up the Bank Statement Loader process
to automatically or manually import bank statement files into Fusion.
·
Internal Module Integration:
o
Payables and Receivables: Ensure Payables
payments and Receivables receipts are configured to flow into Cash Management
for reconciliation.
o
General Ledger: Verify that all
cash-related transactions from the GL are properly linked and available for
reconciliation.
Budget
·
Project Kick-off and Team Formation:
o
Project Charter: Create a document that
defines the project's goals, scope, and key stakeholders.
o
Team: Assemble a team including a project
manager, financial consultants with expertise in Oracle GL and budgeting, and
business subject matter experts (SMEs) from the finance and departmental budget
owners.
·
Requirements Gathering and Business Process
Analysis:
o
Budgeting Methodology: Understand the
organization's budgeting methodology. Is it a top-down or bottom-up approach?
What is the frequency (e.g., annual, quarterly)?
o
Control vs. Reporting: Define the purpose
of the budget. Is it primarily for financial reporting and analysis, or is it
also used to enforce spending controls on transactions?
o
Budgetary Control Rules: Document the
specific rules for budgetary control, such as:
§ Which
transactions should be checked for funds (e.g., requisitions, purchase orders,
invoices)?
§ What
is the tolerance for overspending (e.g., a certain percentage or fixed amount)?
§ Are
there any exemptions?
·
Solution Design Document (SDD):
o
Create a detailed blueprint of the budgeting
solution. This document will outline the budgetary control segment, control
budgets, and reporting requirements.
·
General Ledger Setup:
o
Chart of Accounts (COA): Ensure the COA
is designed to support budgeting. This often involves a specific segment (e.g.,
a "Budgetary Account" segment) used for budget vs. actuals reporting.
o
Ledgers: Confirm the primary ledger is
set up correctly, as all budgetary control will be linked to it.
·
Budgetary Control Configuration:
o
Control Budget: Create a Control
Budget to act as the container for your budget amounts. You can create
multiple control budgets for different purposes (e.g., a Corporate Budget
and a Project Budget).
o
Budget Scenarios: Define budget scenarios
to capture different versions of a budget (e.g., Original Budget, Revised
Budget).
o
Budgetary Control Profile Options: Set up
profile options to enable budgetary control across various modules like General
Ledger, Payables, and Procurement.
o
Control Budget Structure: This is a
crucial setup. Define the dimension(s) on which you will enforce control. This
is typically a combination of segments from your COA (e.g., Company,
Department, and Account).
o
Control Rules: Configure the control
rules, which dictate the level of control:
§ Absolute
Control: No spending is allowed beyond the budget.
§ Advisory
Control: A warning is issued, but spending is allowed.
o
Control Level: Set the level at which the
budget is checked (e.g., at the fund level, fund and department level, or a
combination).
·
Budget Data Migration Strategy:
o
Decide on the method for loading budget data. It
can be a simple spreadsheet for a small organization or an automated process
for a large one.
·
Data Loading Tools:
o
File-Based Data Import (FBDI): This is
the most common tool for loading budget amounts. Use the FBDI template to
prepare your budget data and then upload it to the system.
o
ADF Desktop Integrator (ADFdi): You can
also use ADFdi to enter budget amounts directly from a spreadsheet, which is
useful for smaller loads or adjustments.
·
Budget Submission:
o
Once the data is loaded, you will run a process
to submit and import the budget into your control budgets. This process
validates the data and populates the budget balances.
Inter
Company
·
Project Kick-off and Team Formation:
o
Project Charter: Create a document that
defines the project's goals, scope, and key stakeholders.
o
Team: Assemble a team including a project
manager, financial consultants with expertise in Intercompany and General
Ledger, and business subject matter experts (SMEs) from the finance, treasury,
and accounting departments.
·
Requirements Gathering and Business Process
Analysis:
o
"As-Is" Analysis: Document the
current process for handling intercompany transactions. Understand how
transactions are initiated, approved, and settled.
o
"To-Be" Process Design: Design
the future state business processes. This will involve defining how
transactions will be initiated in various subledgers (e.g., Payables,
Receivables) or directly in the General Ledger. The process should automate
journal creation and reconciliation.
o
Transaction Types: Identify all types of
intercompany transactions (e.g., corporate recharges, shared service billing,
cost allocations).
·
Solution Design Document (SDD):
o
Create a detailed blueprint of the Intercompany
solution. This document will outline the setup of legal entities, balancing
segments, and the specific rules for intercompany balancing and transaction
processing.
·
Enterprise Structures:
o
Ensure the foundational enterprise structures (Legal
Entities, Business Units, Ledgers) are already configured
from the General Ledger implementation. The intercompany balancing segment is a
critical part of the Chart of Accounts (COA) setup.
·
Intercompany System Options:
o
General Options: Set up global options
for Intercompany, such as the maximum number of journals allowed in a batch.
o
Invoicing: Determine if you will use the
Intercompany invoicing feature to create invoices in Payables and Receivables
automatically.
·
Intercompany Organizations and Relationships:
o
Intercompany Organizations: Create and
define the legal entities or business units that will transact with each other.
o
Trading Partners: Establish trading
relationships between Intercompany organizations. This is where you define
which pairs of organizations are allowed to trade.
·
Intercompany Balancing Rules:
o
Balancing Segments: Define the balancing
segment that will be used to track intercompany transactions. This is
typically a segment in your COA that represents the legal entity or company.
o
Balancing Rules: Configure the rules that
automatically generate intercompany balancing segments for transactions that
cross legal entities or balancing segments. These rules ensure that each legal
entity's debits and credits are in balance.
·
Intercompany Transaction Rules:
o
Transaction Types: Define the transaction
types (e.g., Corporate Recharges) that will be used.
o
Receivables/Payables Invoicing: Configure
the rules for automatic invoice generation. This includes defining the
Receivables and Payables transaction types to be used.
This phase involves setting up the flow of intercompany data across the
system.
·
Master Data:
o
While there isn't a large amount of master data
to migrate for Intercompany itself, you must ensure that all legal entities
and their balancing segment values are correctly set up and linked.
·
System Integration:
o
General Ledger: The Intercompany module
is tightly integrated with the GL. Transactions created in Intercompany will
automatically generate journals in the GL. The system uses the Subledger
Accounting (SLA) to create the accounting entries.
o
Subledgers: Ensure that subledgers like
Payables and Receivables are configured to recognize and process intercompany
transactions, especially for the automatic invoicing feature.
o
Projects: Configure the integration to
allow intercompany transactions to originate from Oracle Fusion Projects.
Procurement
Phase
1: Planning and Scoping
Phase
2: Configuration and Setup
Phase
3: Data Migration and Integration
Inventory Management Configuration and Setup
·
Enterprise: This is the top-level structure.
·
Legal Entities: These represent the legal companies within your
enterprise.
·
Business Units: A business unit is the container for business functions,
such as procurement or sales. You'll link inventory organizations to business
units.
·
Ledgers: You must have a primary ledger to manage financial
transactions.
·
Create Inventory Organization: Go to the Functional Setup Manager (FSM) and search for
the Manage Inventory Organization task.
·
Assign Business Unit: Link the inventory organization to a specific business
unit to enable it for business functions like procurement and sales.
·
Assign Legal Entity: Associate the inventory organization with a legal
entity. This is vital for financial and tax reporting.
·
Define Accounting Information: Set up the accounting information for the organization,
including cost, valuation, and expense accounts that will be used for inventory
transactions.
·
Define Inventory Parameters: Set up key parameters that control inventory behavior
within the organization. This includes settings for:
o Costing Method: Select a
costing method like Standard, Average, or FIFO.
o Transaction Processing:
Define how transactions are handled (e.g., immediate, deferred).
o Material Status: Set up
statuses to control an item's usability (e.g., Active, Hold, Inactive).
·
Subinventories: A subinventory is a physical or logical subdivision of
an inventory organization. It represents a storage area, such as a warehouse, a
production floor, or a shipping dock. You need to define subinventories to
track inventory accurately.
·
Locators: A locator is a specific storage space within a
subinventory (e.g., a row, aisle, bin). Locators provide the most granular
level of inventory tracking.
·
Units of Measure (UOM): Define the units in which items are bought, sold, and
stored (e.g., Each, Carton, Kilogram). You will set up UOM classes and then
define the UOMs within those classes.
·
Item Categories and Catalogs: Group similar items into categories and
organize them into catalogs. This helps with
searching, reporting, and managing item data.
·
Transaction Types: Configure transaction types to control the movement of
items, such as material transfers, miscellaneous receipts, and issues.
·
Item Statuses: Define the statuses that control what can be done with
an item. This ensures items are only used for their intended purpose.
·
Create Items: Use the Manage Items task to
create new items. When creating an item, you'll need to:
o Assign to Inventory Organization: Link the item to the inventory organization where it
will be used.
o Define Item Attributes:
Configure attributes such as Purchased, Stocked,
Inventory Item, and Shippable to control the
item's behavior in different modules.
o Assign to Categories:
Assign the item to the appropriate categories for reporting and management.
·
Item Relationships: If needed, you can define relationships between items,
such as cross-references, substitutes, or related items.
·
Use FBDI: The most common and recommended method for bulk loading
is using a File-Based Data Import (FBDI) spreadsheet. This
template allows you to populate on-hand quantities for multiple items in
various subinventories and locators.
·
Manual Entry: For a small number of items, you can use the Miscellaneous Receipt transaction to manually add
quantities to a specific subinventory.
Order Management Configuration and Setup
·
Enterprise Structures: Confirm that your Legal
Entities, Business Units, and Ledgers are defined. Order
management will be linked to a specific business unit.
·
Inventory Organizations: Ensure that the Inventory
Organizations where items will be sourced from are set up and that the
items themselves are defined with the appropriate attributes.
·
Customer Master: Customers and their site
locations must be configured in the system.
·
Order Management Parameters: Set up
global parameters that govern the behavior of the Order Management application.
This includes defaults for order entry, pricing, and fulfillment.
·
Order Types: Define different types of
sales orders based on your business needs (e.g., Standard Sales Order, Return
Order, Drop Ship Order).
·
Fulfillment Lines: Configure settings for
fulfillment lines, which represent the individual items on an order. You can
set up fulfillment lines to be fulfilled from a specific inventory
organization.
·
Pricing: The pricing setup is critical.
You'll need to define:
o
Price Lists: Create price lists that
contain the prices for your items. A price list is a collection of prices for
different items.
o
Pricing Rules and Tiers: Set up rules to
apply discounts, surcharges, and tiers based on factors like customer type,
order quantity, or date.
·
Shipping: Configure shipping parameters
to manage the logistics of order fulfillment:
o
Shipping Methods: Define the various
shipping methods your company uses (e.g., Ground, Air, Express).
o
Freight Terms: Set up freight terms to
determine who is responsible for paying shipping costs (e.g., Prepaid,
Collect).
·
Approval Rules: Design and configure the
approval workflows for sales orders. You can set up rules based on the order
amount, customer, or other attributes that require a manager's approval before
the order can be processed.
·
Sourcing Rules: Sourcing Rules are
crucial for determining where an item should be sourced from. You can define
rules to source an item from a specific inventory organization or supplier.
·
Fulfillment Orchestration: This is the
core of Order Management. Orchestration manages the end-to-end lifecycle
of a sales order. You'll need to:
o
Define Orchestration Process: Set up the
steps in the order fulfillment process (e.g., Await Scheduling, Await Shipping,
Await Invoicing).
o
Assign Orchestration Process: Assign the
appropriate orchestration process to each order type.
·
Customer and Item Data: Ensure that all
customer and item master data is loaded and validated.
·
Open Order Data: Decide whether to
migrate open sales orders from your legacy system. This is a crucial cutover
decision.
·
Integration with Other Modules:
o
Inventory Management: Order Management is
tightly integrated with Inventory Management to reserve and ship items.
o
Receivables: The system will
automatically create invoices in Receivables once an order has been shipped.
o
Financials: The transactions will flow to
the General Ledger for financial reporting.
·
System Integration Testing (SIT): Perform
end-to-end testing of the entire Order-to-Cash cycle.
1. Create
a sales order.
2. Verify
that pricing rules are applied correctly.
3. Confirm
that the order is fulfilled from the correct inventory location.
4. Verify
that shipping and invoicing are processed correctly.
·
User Acceptance Testing (UAT): Business
users will perform UAT to ensure the solution meets all their business
requirements.
·
Go-Live: Once UAT is successful, you can
deploy the solution and begin live operations.
