In short: Most recoverable problems in an Oracle supply chain planning cloud deployment come from the collections layer, because plans run against a planning repository rather than against your transactional tables. An organisation left out of the collection is invisible to the plan, which then recommends building stock that already exists. Net change collections handle a record edited today and miss a back dated correction, because the change timestamp and the period the data affects are different dates. Work out how old the data in a published plan actually is, since the answer is usually older than anyone in the room assumes and the calculation takes ten minutes.
A supply plan runs clean, publishes on time, and recommends building 4,000 units of an item that already has 6,000 on hand at a location the plan cannot see. Two days of investigation produce a boring answer. The organisation was not enabled in the collection, so the plan had never been told the inventory existed. Nothing was wrong with the planning engine, the plan options or the sourcing rules.
Most of the recoverable problems in an Oracle Fusion Cloud Supply Chain Planning deployment come from the same layer: what gets collected, from where, how often, and what happens to a plan when the answer changes. This post is about designing that layer deliberately. Whether to move off a predecessor product at all is E3's subject. I work for a competing vendor, so I have kept this to how the pieces fit together rather than to comparisons.
The module set, briefly
Oracle packages cloud planning as a set of applications sharing a common repository and a common set of plan inputs. The set covers demand management, supply planning, sales and operations planning, replenishment planning, production scheduling, backlog management and supply chain collaboration, with a combined plan type available that spans demand and supply. Packaging and naming vary by release and by what you have licensed, so confirm against your own entitlement rather than against a general description.
The design consequence of a shared repository is worth stating early. Because the applications draw on the same collected data, a collection defect shows up in several places at once and looks like several unrelated defects. Diagnosing planning problems in this architecture works better from the data upwards than from the symptom downwards.
Collections are the actual design surface
Plans do not run against your transactional tables. They run against a planning repository populated by a collection process, and the design choices in that process determine what the plan can see.
Three things have to be decided per entity.
The source. Data can come from the Fusion applications themselves, from an external system through file-based import, or from a legacy source. A deployment with more than one ERP will have more than one source per entity, and the reconciliation between them belongs in the collection design rather than in a planner's head.
The collection type. A targeted collection replaces the data for the entities in scope. A net change collection brings only what has altered since the last run. Targeted is complete and slow; net change is fast and depends on the source correctly identifying what changed.
The cadence. Master data such as items, resources and sourcing rules changes slowly and can be collected less often. Transactional data such as on-hand balances, sales orders and work orders changes constantly and drives plan accuracy directly.
The failure that produces the opening scene is almost always in the first of those. An organisation, a subinventory or an item class that was never included in the collection scope is invisible to every plan, permanently and silently, because nothing errors.
The staleness arithmetic nobody runs
Work out how old the data in your published plan actually is, because it is usually older than anyone assumes and the calculation takes ten minutes.
Suppose sales orders are collected at 02:00, the plan runs at 03:00 and takes 90 minutes, and planners open it at 07:30. An order booked at 02:15 is invisible until the next day's plan, so it is 24 hours old when it first appears and the planner acts on it at 07:30 the following morning, which is 29 hours after it was placed. If order arrivals are spread across a 14-hour working day, then on average an order waits about 7 hours before the next collection plus the 5.5 hours from collection to the planner, so roughly 12.5 hours of latency, with a worst case near 29.
Whether that matters depends entirely on the decision. For a monthly supply plan, 29 hours is irrelevant. For a daily deployment or backlog decision on a short-lead-time item, it is the difference between a useful answer and a stale one. The design response is to collect the entities that drive short-horizon decisions more frequently than the ones that do not, which means the collection schedule has more than one entry in it. Latency as a per-feed design property is T4's subject and it applies directly here.
Net change collections and the back-dated correction
A net change collection identifies what has changed since the last run, usually by a change timestamp. That works for a record edited today. It works less well for a correction that alters a transaction dated three months ago, because the record's change timestamp is today while the data it affects is historical.
Two consequences follow. The plan may pick up the change and place it correctly, in which case the history moves and your forecast changes without an obvious cause. Or the change may not be detected at all, in which case the history is quietly wrong and stays wrong until the next full collection.
Both are manageable and neither is manageable by accident. Run a targeted collection on history-bearing entities on a schedule, weekly or monthly, so that back-dated corrections are picked up on a known cadence rather than randomly. And record when the last targeted run happened, so that when a forecast moves without an obvious cause, somebody can check whether the history moved underneath it. AA6 covers what a restatement does to each integration pattern in general.
Plan options are where the model actually lives
Plan options determine the horizon, the buckets, which organisations are in scope, whether the plan is constrained, which demand schedule is used and how supply is netted. They are configuration rather than data, and they get copied from a template and then edited by several people over the course of a project.
The practical risk is drift between plans that were supposed to be comparable. A sandbox plan and a production plan with different bucket structures or different scope will produce different answers, and the difference will be attributed to whatever change was being tested.
Keep a controlled record of the plan options for every plan that anyone makes decisions from, treat a change to them as a change requiring the same review as a code change, and include the option set in the header of any output somebody circulates. That last point sounds bureaucratic and it prevents a specific recurring argument about whose number is right.
The constrained and unconstrained distinction deserves its own note, because it produces the most misread output in any planning system. An unconstrained plan tells you what demand requires; a constrained plan tells you what the resources allow. Both are legitimate and they answer different questions. Trouble arrives when a plan configured one way is read as though it were the other, which is common when the output is circulated as a spreadsheet with the header removed. Label the two differently in every extract, and if a review meeting is looking at a supply gap, establish which of the two produced the number before anyone proposes a fix. I6 covers what a finite capacity run is actually telling you.
Migrating from a predecessor
Many deployments follow a predecessor on E-Business Suite, typically some combination of advanced supply chain planning, a demand product and an inventory optimisation product. The migration has a structure worth being clear about.
History and hierarchies move. Item masters, location structures, sales history and customer hierarchies transfer with mapping effort that is tedious and tractable.
The demand model does not move. Causal factors, level structures, engine parameters and any custom logic were built for a different engine, and rebuilding them is a modelling exercise rather than a data migration. Budget it as such. The common failure is a plan that assumes the forecast model transfers, which produces a phase where the new system's forecasts are worse than the old system's and everybody concludes the new system is worse.
Sourcing rules, bills of distribution and planning parameters need review rather than transfer. Many will have been set once at the original go-live and never revisited, and moving them across preserves a decade of accumulated defaults. P3 covers what happens to replenishment parameters nobody has touched since go-live.
Give the rebuild a number so it gets funded. If you have 12 demand model segments, and rebuilding and validating each takes roughly three weeks of an analyst's time including the backtest, that is 36 weeks of effort, which is two analysts for most of a project. A plan that shows two weeks for forecast configuration has not understood what is being asked.
What to test before go-live
Three tests catch most of what goes wrong in this architecture, and none of them is expensive.
A completeness test on the collection: for each entity, count rows in the source and rows in the planning repository, and explain every difference. Do it for organisations, items, on-hand, open orders and open supply, and do it on production volume rather than on a test extract, because a scope omission only shows up when the full estate is present.
A determinism test on the plan: run the same plan twice against frozen collected data and compare the outputs cell by cell. Any difference points at an uncontrolled input.
A latency test end to end: place a transaction in the source, then measure how long until it is visible in a published plan. Do this for the entity types that drive your shortest-horizon decisions, and record the measured figure somewhere planners can see it, because a planner who knows the on-hand is nine hours old will act differently from one who assumes it is live.
AA8 covers planning system testing as a discipline, including the parallel run design.
The limit
The collections design cannot fix data that is wrong in the source. A complete and timely collection of incorrect lead times produces a plan built on incorrect lead times, delivered promptly. Sequence the data quality work ahead of the planning configuration rather than alongside it.
Release detail also moves quickly in a cloud product. Application names, collection options and available entity types change between releases, and quarterly updates arrive whether or not the project is ready for them. Verify anything specific here against your own release documentation, and build a habit of reading the update notes for planning before each quarterly update rather than after.
The last limit is organisational. Collections sit between a source system team and a planning team, and in most organisations neither owns it. When something is missing, the investigation crosses a boundary and takes days. Naming an owner for the collection design, with the authority to change the schedule, saves more time than any technical improvement in this list.
Start by producing a single table listing every entity your plans depend on, its source, its collection type, its schedule and the date of the last targeted run. Most deployments have never had that table written down, and building it usually finds at least one entity nobody has collected since the original cutover.