Introduction
If you try to understand Oracle Fusion by memorizing menus, task names, or isolated module features, the platform feels endless. The names change, Redwood experiences replace older pages, quarterly updates introduce new capabilities, and one business process can cross four or five product families before it is finished.
The more durable way to learn Fusion is to understand the architectural ideas that keep repeating underneath those changes. A senior functional consultant does not need to remember every screen. They need to recognize ownership, scope, lifecycle, time, orchestration, security, accounting, and handoff.
This guide has a deliberately different job from the other two FusionLens guides. The Tables Reference explains where data is physically stored and how the physical data model is structured. The SQL Guide turns business questions into working query patterns. This guide stays one level above both of them: no SQL, no physical table names, and no step-by-step screen instructions.
The Guiding Philosophy
Understand the business architecture, not the current screen. When the UI changes, the architecture usually survives.
The Five Questions Behind Almost Every Fusion Requirement
- Who owns it? Which application or shared service is the system of record?
- What is the grain? Person, assignment, supplier, site, requisition line, order line, receipt, invoice installment, project transaction?
- What scope applies? Legal entity, business unit, ledger, inventory organization, legal employer, reference data set, project organization?
- Where is it in its lifecycle? Draft, submitted, approved, fulfilled, accounted, settled, closed, terminated?
- What happens next? Approval, orchestration, accounting, integration, scheduled processing, downstream handoff?
Chapter 1: Oracle Fusion Is a Business Platform, Not a Single Linear Process
Oracle Fusion is built around reusable business capabilities: enterprise structures, shared master data, configurable reference data, transactions, rule engines, approvals, accounting, analytics, integrations, and asynchronous processing. These capabilities appear repeatedly across ERP, HCM, SCM, Procurement, Projects, and Customer Experience.
A useful conceptual chain is:
But this is a mental model, not a mandatory sequence. Not every Fusion process uses every layer. An HCM goal update may never create accounting. An Order Management orchestration can branch, pause, call an external fulfillment system, or skip physical shipment for a digital product. A Payables invoice can have different approval-versus-accounting sequencing depending on configuration.
Common Consultant Mistake
Turning a useful architecture diagram into a universal transaction sequence. Fusion reuses architectural layers, but each product defines its own lifecycle and configurable gates.
Think Like Fusion
Ask which architectural layers participate in this business process. Do not assume every layer participates, or that they always execute in the same order.
Chapter 2: Enterprise Structure Is a Set of Intersecting Axes
The Enterprise Structure is not a single parent-child tree. Oracle models different kinds of organizational reality separately because they answer different questions.
| Architectural axis | Typical Fusion concept | The question it answers |
|---|---|---|
| Legal | Legal Entity / Legal Employer | Who is legally responsible? |
| Accounting | Ledger | Under which chart, calendar, currency, and accounting method is this recorded? |
| Operational | Business Unit | Which operating unit processes and secures the transaction? |
| Functional | Department and other organizations | Which functional organization performs the work? |
| Physical / Logistics | Inventory Organization | Where is material stored, manufactured, or transacted? |
| Workforce Legal | Legal Employer | Which legal entity employs the worker? |
| Payroll / Legislative | Payroll statutory and legislative structures | Which statutory and legislative rules govern payroll processing and reporting? |
A business unit can process transactions for more than one legal entity, while posting to one primary ledger. An inventory organization is associated with operational, legal, and accounting context for material transactions. HCM implementations may not need the same accounting structures as ERP implementations. The architecture is therefore better understood as a grid of intersecting identities than as a rigid organization chart.
Common Consultant Mistake
Creating a Legal Entity because management wants a reporting slice, or creating a Business Unit because a regional manager exists. Legal, operational, managerial, and reporting structures are different design problems.
Consultant's Checklist — Before Creating an Enterprise Structure Component
- Does it represent a legal obligation, an operational processing boundary, a reporting hierarchy, or a physical facility?
- Will it own transactions or merely classify them?
- Does it require independent accounting, currency, calendar, or statutory reporting?
- Will it be used as a security context?
- Can the requirement be represented more cleanly with a hierarchy or chart-of-accounts dimension?
Chapter 3: Setup, Reference Data, Master Data, Transactions, and Derived Results Are Different Things
One of the fastest ways to diagnose a bad Fusion design is to ask what category the information belongs to. Consultants often collapse several categories into the word “data,” but Oracle treats them differently.
| Category | What it represents | Examples |
|---|---|---|
| Enterprise Setup | Structural boundaries and application behavior | Ledgers, business functions, enterprise organizations, accounting options |
| Reference Data | Reusable controlled values used by many transactions | Payment terms, transaction types, jobs, grades, categories, reasons |
| Master Data | Reusable business entities | Workers, suppliers, customers, items, projects |
| Transactions | Business events and documents | Assignments, requisitions, purchase orders, invoices, receipts, journals, sales orders |
| Derived / Processed Results | Outputs created by engines | Accounting entries, payroll results, costing results, tax calculations, promise dates |
These categories have different governance expectations. A payment term is not merely a text field on an invoice. A supplier is not something Procurement should recreate because it needs a slightly different display. A tax result is not the same thing as a tax rule. A posted accounting result is not the same thing as the operational transaction that generated it.
Think Like Fusion
Before adding a field or a workaround, classify the requirement. Is it structure, reference data, master data, a transaction, or a derived result?
Chapter 4: Reference Data Sharing Is Controlled Reuse, Not Duplication
Oracle Fusion can share selected reference data across organizational contexts through Reference Data Sets. The core idea is simple: data that is common should be defined once and reused; data that must differ can be separated by context.
This lets an enterprise avoid creating twenty copies of the same reference value just because it has twenty business units. At the same time, it lets one business unit use a locally specific definition where policy genuinely differs.
The important nuance is that not every setup object is set-enabled. Reference Data Sets are a capability used by specific reference-data families. The functional consultant must verify whether the object supports set sharing rather than assuming every setup value participates.
Common Consultant Mistake
Duplicating common reference data per business unit “to keep things simple.” It looks simple on day one and becomes governance debt when the same value must be corrected, translated, inactivated, or audited twenty times.
Think Like Fusion
Share what is truly common. Separate only where policy, legislation, operating practice, or ownership genuinely differs.
Chapter 5: Thinking in Ownership — Who Is the System of Record?
The defining reflex of a senior functional consultant is not “Where can I see this?” It is “Who owns this?” Fusion applications constantly display data that they do not own.
A supplier is a global supplier entity, while a procurement business unit establishes transaction controls through its relationship with that supplier. Procurement consumes item definitions maintained in Product Management. Order Management consumes customer, item, pricing, promising, fulfillment, and receivables capabilities. Projects can consume workers, organizations, contracts, costs, accounting, and billing without becoming the owner of all of them.
| Requirement | Wrong mental model | Better ownership question |
|---|---|---|
| Supplier address is wrong on a PO | “Fix Purchasing” | Which supplier master attribute is the source? |
| Item description is wrong on a sales order | “Fix Order Management” | Which product definition owns the item attribute? |
| Worker's manager is wrong in an approval | “Fix BPM” | Is the supervisory relationship correct in HCM? |
| Project invoice has wrong customer data | “Fix Projects” | Which customer/account/site relationship is the source? |
Common Consultant Mistake
Fixing a symptom in the consuming module instead of correcting the source object. This creates duplicate logic, conflicting values, and fragile integrations.
Consultant's Checklist — Assessing Data Ownership
- Where is the object originally created?
- Which module can change its authoritative attributes?
- Which modules only consume or enrich it?
- Is the attribute global, organization-specific, site-specific, or transaction-specific?
- What downstream processes inherit the value?
Chapter 6: Time Is a First-Class Dimension
Fusion does not treat every change as “replace the old value with the new value.” In date-effective product areas, especially HCM, one logical business object can have past, current, and future versions.
That leads to one of the most important functional distinctions in Oracle Fusion:
- Update: change the business reality from an effective date, preserving history.
- Correction: fix information in an existing effective period because the stored history itself was wrong.
- Future-dated change: define what will become true later.
- Date-enabled object: has a start/end availability period but does not necessarily preserve attribute history in the same way as a fully date-effective object.
This difference is not cosmetic. A promotion effective next month and a correction to yesterday's incorrect job are different business events. One changes reality prospectively; the other repairs the recorded history.
Common Consultant Mistake
Using “Correct” when the business really means “Change from this date forward,” or using an update when the original historical record was simply entered incorrectly.
Think Like Fusion
Do not ask only “What is the value?” Ask “What was true, what is true, what will be true, and from which effective date?”
Chapter 7: Identity, Relationship, and Context Are Separate Concepts
Many Fusion objects make sense only when you separate the thing itself from the relationship the enterprise has with that thing.
A person can exist independently of a particular employment relationship. A supplier can exist globally while different procurement business units establish their own sites, policies, and controls for transacting with it. A product can have a global definition while organization-level behavior determines how it is stocked, sourced, costed, or transacted. A customer party can participate through different accounts, sites, and business purposes.
This pattern explains why “one master record” does not mean “one set of attributes everywhere.” Fusion often stores global identity once and then adds relationship-specific or organization-specific context around it.
Think Like Fusion
Separate “Who or what is this?” from “What relationship does this organization have with it?” and “Under which context does this relationship operate?”
Chapter 8: Think in Lifecycles, but Do Not Invent One Universal State Machine
Transactions in Fusion move through product-specific lifecycles. Requisitions, purchase orders, invoices, sales orders, projects, worker transactions, payroll flows, and journals all have status models, but those status models are not interchangeable.
Statuses are usually outcomes of processing, not arbitrary labels. An object may move because validation succeeded, an approver responded, a scheduled process completed, fulfillment confirmed, accounting was created, or a downstream application returned a result.
That means changing a status value outside the supported business process does not reproduce the actions that normally accompany the transition. The application may have created accounting, reservations, workflow history, payment instructions, fulfillment tasks, audit entries, or downstream messages as part of the real transition.
Common Consultant Mistake
Treating “status” as the process itself. A transaction is not truly complete because a label says Complete; it is complete because the required business actions and downstream effects have completed.
Chapter 9: Validation, Approval, Holds, Accounting, and Payment Are Different Gates
Fusion uses several control mechanisms that are often confused because they all seem to “stop” a transaction.
| Control | Purpose | Typical question |
|---|---|---|
| Validation | Is the transaction complete and internally consistent? | Does the data satisfy rules and tolerances? |
| Approval | Has an authorized person or group accepted the action? | Who must authorize this transaction? |
| Hold | Should processing stop because of an exception or policy? | What condition prevents the next step? |
| Accounting | How does the transaction affect the books? | What journals should the accounting engine create? |
| Settlement / Payment | Has the financial obligation been settled? | Has money actually moved or been instructed to move? |
The sequencing is product-specific and sometimes configurable. In Payables, invoice validation is required before payment or accounting. If invoice approval is enabled, approval is required before payment. But the relationship between approval and accounting can be configured: accounting can occur regardless of approval status, before approval, or only after approval.
Correction to a Common Simplification
Do not teach “Validation → Approval → Accounting → Payment” as a universal Fusion sequence. Teach the gates separately, then verify the configured lifecycle of the product you are implementing.
Chapter 10: Approval Is a Routing Engine, Not a Business Rule Catch-All
Oracle approval capabilities route human tasks to users or groups based on configured conditions. Depending on the product, routing can use supervisory hierarchies, positions, job levels, responsibilities, approval groups, transaction attributes, amounts, categories, and other criteria.
Approvals can be sequential or parallel. Some processes support automatic outcomes, FYI notifications, escalation, delegation, reassignment, or bypass rules. The exact tooling varies by product family, and newer product experiences may expose approval configuration differently even though the same architectural question remains: who must act, under which conditions, and what happens if they do not?
Approval should not be used to compensate for every upstream data-quality problem. If a transaction should never contain an invalid combination, validation or setup may be the right control. If the transaction is valid but requires human authorization, approval is the right control.
Consultant's Checklist — Designing an Approval
- What business risk requires human authorization?
- Can the condition be prevented earlier through setup or validation?
- Who is the approver source: manager, position, role, responsibility holder, named user, or approval group?
- Sequential or parallel?
- What happens when no approver is found?
- What is the escalation, delegation, and reassignment strategy?
- How will stuck approvals be monitored?
Chapter 11: Modules Hand Off Work; They Do Not Become Each Other
Cross-module architecture is best understood as a series of handoffs. The upstream application creates demand or intent. A downstream application performs the capability it owns. Status and results flow back.
Order Management is a good example. It can capture demand, determine an orchestration process, coordinate promising, reserve or request supply, initiate shipping, and request billing. But Inventory still owns inventory execution, Procurement owns purchasing, Product Management owns item definitions, and Receivables owns customer billing.
The same principle appears in source-to-pay: a requisition can become one or more purchase orders; receiving records fulfillment; Payables records the supplier liability; Payments settles that liability. The lifecycle is connected, but ownership remains distributed.
Think Like Fusion
An end-to-end process is not one giant module. It is a contract between specialized engines.
Chapter 12: “Submitted” Does Not Mean “Finished” — The Asynchronous Processing Mindset
Many Fusion operations are too large, too long-running, or too dependent on downstream processing to complete in the user's request. They run asynchronously as scheduled processes, process sets, imports, extracts, accounting jobs, payroll flows, costing runs, or orchestration tasks.
This changes how a consultant should troubleshoot. A user action may only enqueue work. The visible transaction may remain in an intermediate status while background processing is queued, blocked, running, warning, or waiting for another process.
Process hierarchies matter as well. One submitted process can launch child processes. A process set can contain multiple jobs. An orchestration can pause for an event. An import can first load interface data and then invoke an application-specific process.
Common Consultant Mistake
Treating a successful click or API response as proof that the end-to-end business process finished. In Fusion, success may mean only “the request was accepted.”
Troubleshooting an Asynchronous Process
- What request or process ID was created?
- Is the process queued, blocked, running, warning, error, or succeeded?
- Did it launch child processes?
- Did a downstream process fail after the parent succeeded?
- What parameters and scope did the process actually use?
- Is the business object waiting for an event or dependency rather than a batch job?
Chapter 13: HCM — Person, Work Relationship, and Assignment Are Not the Same Thing
One of the most important HCM mental models is the separation of person, work relationship, and assignment.
A person can be rehired without creating a second human identity. A new work relationship represents the new relationship with a legal employer. Depending on the configured employment model, a work relationship can support one or multiple assignments.
The primary work relationship and primary assignment are meaningful business designations, not generic duplicate-removal concepts. They identify the relationship that carries special significance when a single value must be chosen for the person.
Payroll, benefits, compensation, talent, absence, and security can all depend on different aspects of this employment model. That is why “employee” is too broad a grain for many HCM requirements.
Think Like Fusion
When an HCM requirement says “employee,” ask whether it really means person, work relationship, assignment, payroll relationship, or another workforce relationship.
Chapter 14: Source-to-Pay Is a Chain of Different Business Commitments
Procurement should not be reduced to “requisition becomes PO.” The broader source-to-pay model can include supplier onboarding, qualification, sourcing, negotiation, agreements, requisitions, purchasing, receiving, invoicing, and payment.
The chain can fan out. One requisition can be sourced into different procurement documents. A purchase order can have multiple schedules and partial receipts. An invoice can match only part of a receipt or purchase order. One invoice can have multiple payment installments. That means “the status of the requisition” is often shorthand for a collection of downstream statuses rather than one simple state.
Supplier identity is global, but procurement business units establish the controls and sites through which they transact with that supplier. A prospective supplier is not automatically authorized for spend transactions. Supplier qualification, registration, and spend authorization are separate lifecycle concepts.
Common Consultant Mistake
Designing one status field or one report row to summarize the entire procure-to-pay lifecycle without defining which document, line, schedule, receipt, invoice, or installment is the actual grain.
Chapter 15: Order-to-Cash Is Orchestration, Not Just Order Entry
Order Management is designed as an orchestration hub. Demand can arrive from direct entry or external capture systems. The order can then be priced, promised, enriched, assigned to an orchestration process, fulfilled by one or more systems, and billed through Receivables.
Not every order uses every step. A service may require billing without shipping. A back-to-back item may trigger supply creation. A drop-ship flow may involve a supplier. An external fulfillment system may execute the physical task while Order Management monitors the result.
Change management is also architectural. A change to quantity, warehouse, date, or line attributes may require Order Management to compensate, roll back, or rerun downstream orchestration steps.
Think Like Fusion
The sales order is demand. Orchestration decides how that demand becomes fulfillment.
Chapter 16: Projects Separate Delivery, Cost, Contract, Billing, and Revenue
A Project is not automatically a customer contract, an invoice, or revenue. Oracle Project Management separates the operational project structure from commercial contract terms, project costs, billing, and revenue recognition.
Revenue generation can identify eligible project transactions, map them to contract lines, apply billing controls and revenue methods, and create revenue distributions. Billing and revenue therefore depend on both project execution and contract configuration.
For functional design, this means “project revenue” is not simply the sum of project costs plus a margin. The contract, billing plan, revenue method, eligibility, controls, currency, and accounting configuration all matter.
Chapter 17: SCM Separates Product Definition, Physical Flow, Supply, and Cost
Supply Chain Management becomes easier when you separate four questions:
- What is the item? Product definition and attributes.
- Where is it? Inventory organization, subinventory, locator, lot, serial, and on-hand context.
- How will demand be supplied? Buy, make, transfer, reserve, promise, or orchestrate supply.
- What did the movement cost? Cost organization, valuation, costing methods, and accounting.
An item organization and an inventory organization are not interchangeable. An item organization can provide item-definition context without storing or moving physical stock. An inventory organization represents the context in which material is stored or transacted and is tied into operational, legal, and accounting structures.
This distinction prevents a common design error: treating “warehouse,” “business unit,” “inventory organization,” “item master,” and “cost organization” as different names for the same organizational node.
Think Like Fusion
Commercial ownership, physical custody, item definition, supply execution, and financial valuation are separate dimensions.
Chapter 18: Operational Truth and Accounting Truth Are Related, but Not Identical
Financial accounting in Fusion is intentionally separated from the operational applications that generate transactions. Payables owns supplier liabilities. Receivables owns customer receivables. Assets owns asset activity. Projects owns project costs and billing. Procurement and SCM create operational commitments and movements. Subledger Accounting translates eligible subledger events into accounting entries, which then flow to General Ledger.
This is why “the invoice account” can mean several different things: the account entered or derived on a transaction distribution, the final subledger accounting entry after accounting rules, or the posted General Ledger result. Functional specifications must name which accounting layer they mean.
Ledgers define accounting context through chart of accounts, calendar, currency, and accounting method. Secondary ledgers and reporting currencies provide additional accounting and reporting representations. Legal entity, business unit, and ledger are related, but they solve different business problems.
Common Consultant Mistake
Reconciling an operational amount directly to a GL balance without passing through the accounting layer that transformed, summarized, converted, or reclassified it.
Chapter 19: Security Is “Who Can Do What on Which Data?”
Oracle Fusion security is better understood as multiple layers rather than one switch.
| Layer | Question |
|---|---|
| Identity | Who is the user? |
| Role / Function Security | What functions and actions can the user perform? |
| Data Security | On which data instances can those actions be performed? |
| Product-Specific Scope | Which business unit, ledger, asset book, inventory organization, project organization, worker population, payroll, or other secured context applies? |
Job roles represent jobs, abstract roles represent enterprise-wide personas such as employee or line manager, and duty roles group privileges. Product families then apply data security through their own secured contexts. HCM commonly uses security profiles to identify permitted populations of people, organizations, positions, payrolls, and other objects. ERP and SCM commonly use business-unit, ledger, data-access-set, asset-book, inventory-organization, and similar contexts.
Security is not accurately described as “a database filter applied before every screen loads.” Oracle uses data security policies, role hierarchies, grants, product-specific application logic, security profiles, and secured contexts. The implementation mechanism varies by product.
Common Consultant Mistake
Creating a new custom job role when the function is already correct and only the data scope is wrong — or changing data access when the real issue is missing functional privileges.
Consultant's Security Diagnostic
- Can the user access the function at all?
- If yes, which secured business objects are missing or excessive?
- What is the security context for this product?
- Is HCM using managed-person versus public-person access differently?
- Does the user inherit wider access from another role?
- Does the reporting layer apply the same security semantics as the application transaction?
Chapter 20: Reporting Starts With the Business Question and the Grain
Functional consultants do not need to write SQL to design good reports. They do need to define the question precisely enough that a reporting tool can answer it.
The first decision is the grain: what does one row, one measure, or one event represent? Supplier? Invoice? Invoice installment? Purchase order schedule? Worker assignment? Payroll result? Project cost transaction?
After the grain, choose the right reporting architecture:
| Need | Best mental model |
|---|---|
| Real-time self-service analysis | OTBI subject area built around a fact and its dimensions |
| Pixel-perfect operational document or scheduled report | Oracle Analytics Publisher / BI Publisher data model and layout |
| Bulk extraction to another platform | Bulk extraction capability, not an interactive report |
| Cross-domain historical analytics and curated enterprise metrics | Fusion Data Intelligence warehouse + semantic model |
OTBI subject areas are intentionally contextual: they are designed around specific facts and dimensions. They are not a universal window over every master-data object. Fusion Data Intelligence is a separate analytics service that extracts Fusion data into an Oracle-managed analytics repository and provides a prebuilt semantic model and metrics.
Common Consultant Mistake
Choosing the tool before defining latency, grain, history, security, data volume, and whether the requirement is reporting or extraction.
Chapter 21: Integration Architecture Is a Trade-Off Across Latency, Volume, Semantics, and Recovery
“REST for real time, file loader for batch” is a useful beginner shortcut, but it is not a complete integration strategy. Oracle Fusion supports REST APIs, SOAP services, public business events, Oracle Integration, file-based import, product-specific loaders, extracts, and bulk data extraction. The correct choice depends on the business requirement.
| Decision axis | Questions to ask |
|---|---|
| Direction | Inbound, outbound, or bidirectional? |
| Latency | Synchronous response, near real time, scheduled, or overnight? |
| Volume | Single transaction, small batch, high-volume migration, or recurring bulk extract? |
| Business semantics | Does the integration need application validation and transaction semantics? |
| Eventing | Does the product raise a supported public event for this scenario? |
| Recovery | How will failures, duplicates, partial success, missed events, and replay be handled? |
| Security | Which identity, role, and data scope executes the integration? |
Public business events are useful for publish/subscribe patterns but are not a general high-volume event stream. Oracle documents volume constraints for SCM public events, notes that many bulk operations do not raise events, and recommends a reconciliation strategy because missed events generally cannot simply be regenerated.
For bulk inbound ERP data, file-based import stages data and then invokes product import processes. HCM has its own high-volume loader and spreadsheet loader architecture. HCM Extracts serve outbound HCM extraction needs. BICC supports bulk extraction, while Oracle is also introducing a read-optimized Data Extraction capability as the long-term replacement path in supported product areas.
Think Like Fusion
Choose an integration pattern by transaction semantics and recovery model, not by which technology your integration team prefers.
Chapter 22: Extend the Business Model at the Smallest Correct Layer
Fusion gives customers several extensibility mechanisms. The hard part is not knowing that they exist; it is choosing the smallest mechanism that correctly represents the requirement.
| Requirement shape | Better architectural starting point |
|---|---|
| Additional attribute on an existing business object | Descriptive flexfield or supported custom field |
| Repeated groups of extension attributes | Extensible flexfield where supported |
| Structured multipart business key | Key flexfield |
| Controlled values | Value set / lookup / reference data, depending on purpose |
| New object or richer supported application extension | Application Composer in supported product areas |
| Temporary isolated configuration testing | Sandbox-based change and publish lifecycle |
Descriptive flexfields extend existing entities with additional attributes. Extensible flexfields support richer context structures and can support multiple extension rows. Key flexfields define multipart keys such as account structures. Value sets validate flexfield values and can be reused, which means changing a shared value set can affect multiple usages.
Application Composer can extend supported applications with fields, relationships, logic, security, and custom objects. It is not universally available across every Fusion product in the same way, so the product's supported extensibility model must be checked before designing.
Common Consultant Mistake
Creating a DFF for data that should be a shared master or reference entity, then discovering that reporting, validation, integration, translations, and governance all need to be rebuilt around a text field.
Chapter 23: “The Date” and “The Amount” Are Usually Ambiguous
Fusion transactions carry multiple business dates because different parts of the process answer different questions.
- Effective date: when a business definition or workforce change becomes true.
- Transaction date: when the business event occurred.
- Accounting date: which accounting period receives the financial impact.
- Due date: when a receivable or payable installment becomes due.
- Receipt / shipment / fulfillment date: when physical activity occurred.
- Creation and update timestamps: when the system record was technically created or changed.
Amounts are similarly contextual. A transaction can have entered currency, ledger currency, reporting currencies, accounted amounts, tax amounts, open amounts, paid amounts, recognized revenue, or costed amounts. “Invoice amount” and “outstanding amount” are not synonyms. “Revenue” and “billing” are not synonyms. “Transaction currency” and “ledger currency” are not synonyms.
Think Like Fusion
Never accept “date” or “amount” in a requirement without asking: which business event, which currency, which accounting representation, and which point in the lifecycle?
Chapter 24: Reconciliation Is About Following the Same Business Event Through Different Representations
Most difficult Fusion defects are not “wrong data.” They are mismatches between representations of the same business event.
A useful reconciliation model has four checkpoints:
For an AP invoice, operational validation, approval, payment status, accounting status, and GL posting are different checkpoints. For an order, order status, fulfillment status, shipment confirmation, billing status, and receivables status are different checkpoints. For payroll, calculation, prepayments, payment generation, costing, and accounting are different checkpoints.
Consultant's Reconciliation Method
- Start from one business document or person, not from totals.
- Trace one lifecycle instance through every handoff.
- Record the identifier and status at each stage.
- Separate operational amount from accounting amount.
- Separate “processed successfully” from “downstream completed successfully.”
- Only aggregate after one instance reconciles end to end.
Chapter 25: Quarterly Updates Are Part of the Architecture
Oracle Cloud Applications deliver updates every quarter. Some features arrive enabled; others require opt-in or setup. Readiness material identifies impact and actions required. A mature Fusion operating model therefore treats release readiness as a permanent business process, not a temporary project activity.
The most stable implementations minimize assumptions about specific page layouts and maximize reliance on supported business objects, APIs, configuration, semantic models, and documented extension mechanisms. This matters even more as Redwood experiences continue to evolve.
Quarterly Update Regression Scope
- Critical end-to-end business processes
- Custom approvals and workflows
- Integrations and API contracts
- Bulk import and extraction processes
- Critical OTBI and Publisher reports
- Flexfields and custom extensions
- Security roles and data access
- Scheduled processes and process sets
- Features delivered enabled and expired opt-ins
The test goal is not to re-test the entire Oracle product. Oracle tests the standard product. Your job is to test the customer-specific configuration, extensions, integrations, reports, security, and business processes that make your environment unique.
Think Like Fusion
Design for quarterly change from day one. Upgrade resilience is an architecture requirement, not an operations afterthought.
Chapter 26: The Senior Consultant's Requirement Decomposition Framework
When a new requirement arrives, do not begin with configuration. Decompose it first.
The 15 Questions
- Business outcome: What decision or process outcome is required?
- Owner: Which product or shared master owns the authoritative data?
- Object: What business object is actually changing?
- Grain: What does one instance represent?
- Scope: Which legal, operational, physical, accounting, workforce, or project context applies?
- Time: Is this current, historical, future-dated, or event-dated?
- Lifecycle: Where does the object enter and leave the process?
- Controls: Validation, approval, hold, budgetary control, accounting, or security?
- Upstream: Which master/reference data must already be correct?
- Downstream: Which modules, reports, integrations, or accounting flows consume the result?
- Volume: One transaction or hundreds of thousands?
- Latency: Synchronous, event-driven, scheduled, or batch?
- Security: Who can perform the action and on which data?
- Extensibility: Can standard configuration solve it before custom logic?
- Upgrade resilience: What must be regression-tested every quarter?
If these questions are answered before configuration begins, most design debates become dramatically easier. They also create a specification that developers, security teams, integration teams, reporting teams, and testers can all understand.
Chapter 27: Oracle Fusion Architecture Anti-Patterns
| Anti-pattern | Why it fails | Better mental model |
|---|---|---|
| Model the org chart as legal entities | Management structure and legal structure are different | Use the correct organizational axis |
| Create a BU for every reporting slice | BU is a transaction-processing and security boundary | Use hierarchies or accounting dimensions where appropriate |
| Duplicate master data in consuming modules | Breaks single-source ownership | Fix the owning master |
| Use DFFs as a replacement for a real master entity | Creates weak governance and reporting | Choose the proper extension or reference model |
| Assume every status transition is manual | Many statuses come from engines and downstream events | Trace the lifecycle and process dependency |
| Assume approval means validation | Human authorization and data validity are different controls | Design each gate for its purpose |
| Assume all processes are synchronous | Fusion relies heavily on asynchronous jobs and orchestration | Track requests and child processing |
| Use one integration technology for everything | Latency, volume, semantics, and recovery differ | Choose per integration pattern |
| Use an operational report as a bulk extract | Reporting and data movement have different architectures | Use extraction tooling for extraction |
| Compare totals before reconciling one transaction | Aggregation hides lifecycle mismatches | Trace one business event end to end |
| Hard-code business rules into user instructions | People forget; configuration should govern repeatable policy | Move repeatable policy into supported rules/setup |
| Ignore quarterly update impact | Cloud change is continuous | Operate a permanent regression and readiness model |
Chapter 28: Frequently Asked Questions
Do I need to master every Oracle Fusion module?
No. You need enough cross-module architecture knowledge to identify ownership, handoffs, scope, and lifecycle. Deep specialization can then sit on top of that shared architecture.
Is Oracle Fusion really one platform if ERP, HCM, and SCM behave differently?
They share many platform capabilities and architectural patterns, but each product family has product-specific business objects, security, lifecycles, and processing. The useful skill is recognizing the shared pattern without erasing the product-specific differences.
Should every requirement start in Setup and Maintenance?
No. Start with the business architecture and ownership question. The solution may be enterprise setup, reference data, master data, transaction configuration, approval rules, security, a flexfield, integration, reporting, or no change at all.
Are Business Units always aligned one-to-one with Legal Entities?
No. A business unit can process transactions for multiple legal entities, subject to product configuration. Business units and legal entities solve different problems, even though implementations often align them closely for simplicity.
Does every Fusion transaction require approval before accounting?
No. The sequencing depends on the product and configuration. In Payables, for example, validation is required before payment or accounting, approval may be enabled, and the relationship between approval and accounting can be configured.
Is REST always the right integration method for real-time requirements?
REST is important, but the answer depends on transaction semantics, volume, supported business events, latency, response requirements, and recovery. Some near-real-time patterns are better event-driven; some business operations still require asynchronous application processing after the API call.
Why do OTBI, a Publisher report, and Fusion Data Intelligence sometimes show different numbers?
They can differ because they use different semantic grains, security models, refresh timing, filters, historical models, and data architectures. Reconcile the business definition and grain before assuming one tool is wrong.
When should I add a flexfield?
When the information is genuinely an additional attribute of an existing supported business object and standard configuration doesn't already model it. Do not use a flexfield to avoid designing real reference or master data.
Why can the same transaction look complete in one module and incomplete in another?
Because end-to-end processes cross module boundaries. One application's responsibility may be complete while the downstream application is still processing, waiting, accounting, settling, or handling an exception.
What is the single best troubleshooting habit in Oracle Fusion?
Take one business instance and trace it end to end: owner, scope, lifecycle status, background process, downstream handoff, accounting or settlement, and reporting representation. Do that before comparing aggregate totals.
Chapter 29: Conclusion
Oracle Fusion is large, but size is not the real difficulty. The real difficulty is that a single business outcome often depends on several independently governed dimensions: legal structure, operational scope, shared master data, time, workflow, security, orchestration, accounting, asynchronous processing, integration, and reporting.
Once you learn to separate those dimensions, the platform becomes predictable.
The senior consultant's advantage is not memorizing more screens than everyone else. It is being able to look at an unfamiliar requirement and correctly predict which part of Fusion should own it, which boundaries apply, which lifecycle will process it, and which downstream systems will feel the effect.
Final Mental Model
Do not memorize Oracle Fusion. Learn how it separates responsibility. Once you see the boundaries, the modules stop looking separate.
Continue Through the FusionLens Knowledge Hub
Use the three guides together. Mental Models explains the business architecture. Tables Reference explains the physical data model. SQL Guide shows how to ask the data a question.