Oracle bundles the RPAS planning family into overlapping cloud services metered on multiplicative SKU-location and position counts. This guide names where retailers overbuy modules they never enable and how to buy only what deploys.
Oracle bundles the RPAS planning family into overlapping cloud services metered on multiplicative SKU-location and position counts. This guide names where retailers overbuy modules they never enable and how to buy only what deploys.
Start with a fact Oracle's own documentation makes plain: the Retail Predictive Application Server (RPAS) is not a product you buy. Per Oracle's platform description (Nov 2022), RPAS is the underlying engine providing a multidimensional database, batch and online processing, a configurable calculation engine, and import/export utilities. What you license sits on top of it: Demand Forecasting, Merchandise Financial Planning, Assortment Planning, Item Planning, Size Profile Optimization, Replenishment Optimization, and Advanced Inventory Planning, each a separately-priced application.
The modern delivery is the RPAS Cloud Edition (RPASCE), now folded into Oracle's Retail Analytics and Planning (RAP) umbrella. Per the RAP Implementation Guide (25.1.101.0, April 2025), RAP is a single Autonomous Data Warehouse instance per customer containing multiple application schemas across three pillars: Retail Insights (RI), AI Foundation (AIF), and Planning. This matters commercially because the physical platform is shared, but the entitlements are not. You pay per module, and the modules you did not buy sit dark inside the same environment.
That architecture is where overbuy hides. In our experience negotiating this vendor, retailers routinely sign for a planning suite because it looked cheaper as a bundle, then deploy two or three components. The sunk subscription on the rest recurs every year at full rate. If you are also carrying the merchandising and store estate, read the Oracle Retail Merchandising and Xstore licensing buyer guide to see how the whole footprint interlocks before you touch planning.
You pay per module. The modules you did not buy sit dark inside the same shared environment, recurring at full rate every year.
This is not a buyer's cynical read. The RAP Implementation Guide (24.1.201.0, 2024) states directly that the platform "comprises many application modules (some of which you may not use)." The deployment process bears this out. Oracle sends a single welcome email pointing to Retail Home, and the implementation team must "verify that the modules purchased by the customer are enabled" (RAP Implementation Guide 25.1.101.0, April 2025). Provisioning and entitlement are decoupled by design.
The practical exposure: your Retail Home tile set will show modules like MFP, IPO, AP, POM, RI, and AI Foundation regardless of what you signed. If your implementation partner enables something you did not license, you are exposed on audit. If your contract lists modules your team never deploys, you are paying for shelfware. Both errors run in the same environment and neither is visible unless you reconcile the order document line by line against what is actually enabled and used.
What to do: within 30 days of provisioning, produce a two-column map (contracted modules versus enabled tiles) and reconcile it every quarter. This is the same discipline we recommend for the wider estate in what an Oracle audit examines across the retail estate.
Demand forecasting is where the double-buy risk is sharpest. Oracle sells Retail Demand Forecasting Cloud Service (RDFCS) as a distinct service (RDFCS Get Started, July 2023). Inside RDF, sub-modules (Forecast, Promote, Curve) are gated by contract: the RDF User Guide states outright that "available modules are based upon licensing agreement." So even within one service, buying RDF does not automatically give you Promote or Curve.
Here is the trap. Forecasting increasingly lives inside AI Foundation, not the legacy RDF engine. Per the RAP Implementation Guide (24.1.201.0, June 2024), AIF "covers forecasting and integration needs for Planning application usage," and its forecasts leverage the Lifecycle Pricing Optimization (LPO) jobs. Both the MFP RAP Integration guide (July 2023) and the APCS RAP Integration guide (July 2023) confirm that planning apps can consume forecasts generated in AIF and imported via RAP integration. In plain terms: if AI Foundation is already generating the forecasts your MFP and Assortment Planning consume, a standalone RDF license may be redundant.
| Forecasting path | What it is | When you actually need it | Overbuy risk |
|---|---|---|---|
| RDFCS (standalone RDF) | Legacy RPAS forecasting engine, Forecast/Promote/Curve sub-modules gated by contract | Deep, retail-specific causal and promotional forecasting not served by AIF | High if AIF already feeds your plans |
| AI Foundation forecasting | Generates multi-level forecasts consumed by MFP, AP, IPO via RAP integration | Already licensed as part of a RAP planning footprint | Low, but verify it is entitled and enabled |
| RDF sub-modules (Promote, Curve) | Add-on forecasting capabilities inside RDF | Specific promotional lift or new-item curve needs | High if bought reflexively with base RDF |
What to do: before signing any RDFCS line, force Oracle to confirm in writing whether the forecasts your planning modules will consume are generated by AIF or require standalone RDF. If AIF suffices, strike the RDF line. If you genuinely need RDF's Promote or Curve, license only those sub-modules, not the whole suite as a reflex.
If AI Foundation already generates the forecasts your MFP and Assortment Planning consume, a standalone RDF license is money spent twice.
Merchandise Financial Planning ships in two mutually exclusive variants: MFP Retail Cloud Service and MFP Cost Cloud Service (MFP Cost CS User Guide, 22.2.401.0, Nov 2022). This is a re-implementation trap. Buy the wrong one (retail-method when your finance team plans at cost, or vice versa) and you rebuild the deployment. MFP covers pre-season and in-season planning with sales, receipts, inventory, gross profit, and open-to-buy KPIs, so the retail-versus-cost decision is a finance-department call, not an IT one. Get your merchandise finance lead to sign off on the variant before the order is cut.
Assortment Planning is a separate service sold in editions, including an Advanced Edition (Retail Cloud Service Descriptions, Sept 11, 2025). It carries a dependency: per the AP CS Implementation Guide (25.2.401.0, 2025), Assortment Planning integrates with MFP for financial-target data "while creating assortments." Buying AP without MFP leaves you with assortments that have no financial targets to plan against. Conversely, do not assume you need both editions of AP; the Advanced Edition is a licensing tier, and the base edition may cover your use case.
Allocation is downstream and, critically, is often not a required license alongside AP. The AP CS Administration Guide (26.1.101.0, Dec 2025) describes an "Export to Allocation" set that pushes approved receipt quantities to an Allocation system in its required format. That export can feed an allocation engine you already own or a separate service. Do not let Oracle bundle an allocation module on the assumption that AP mandates it. Confirm whether your allocation is handled by an existing system before adding the license.
The current planning cloud catalogue (Oracle Retail docs index, ~Aug 2026) lists Inventory Planning Optimization, Lifecycle Pricing Optimization, MFP, Assortment & Item Planning for Fashion/Softlines, Assortment & Item Planning Enterprise Edition, Assortment Planning & Optimization for Grocery/Hardlines, and Item Planning. Several of these overlap in function by vertical. A grocery retailer does not need the fashion assortment service, and vice versa. Match the module to your merchandise type and strike the rest.
The commercial core sits in the metrics, and both of Oracle's planning metrics are multiplicative, meaning they grow far faster than intuition suggests. The primary metric is Active SKU-Location, defined in the Retail Cloud Service Descriptions (Sept 11, 2025) as the product of Active Items and Locations. Oracle's own example: a single active SKU available in 500 store locations counts as 500 Active SKU-Locations. Multiply your real assortment breadth by your store count and the number is large before you add anything unusual.
The location definition then expands the multiplier. Per the same document, a Location is any stockholding or non-stockholding store (including franchise and company stores) or virtual warehouse, and that explicitly includes e-commerce sites, micro-sites, and warehouses. A single Location also equals three wholesale locations. Retailers who count only physical stores routinely under-scope, then get surprised when e-commerce and micro-sites push the metric up. Count every virtual node before you agree a quantity.
| Metric | Definition | Worked example (Oracle's own) | Buyer risk |
|---|---|---|---|
| Active SKU-Location | Active Items × Locations | 1 SKU × 500 stores = 500 Active SKU-Locations | Grows multiplicatively with assortment × footprint |
| Analytical Cloud Positions | Product of dimensions × time buckets | 800 subclasses × 600 stores × 208 weeks = 99,840,000, billed in 100M increments | Explodes with dimensionality and history depth |
| Location count | Includes stores, e-comm, micro-sites, warehouses; 1 = 3 wholesale | Virtual sites count as full locations | Under-counting physical-only under-scopes the deal |
The second metric, Analytical Cloud Positions, is worse for dimensionality. Oracle's example (Retail Cloud Service Descriptions, Sept 11, 2025): 800 subclasses planned across 600 stores for 208 weeks totals 99,840,000 positions, then divided by 100,000,000 and rounded to the nearest 100M increment. Extend your planning horizon or add planning levels and this figure climbs steeply. Exceeding purchased quantities forces additional purchase and risks SLA breach, so you cannot simply run hot and settle later without exposure.
What to do: model both metrics against a realistic 3-year assortment and footprint plan, not today's snapshot. Negotiate the initial quantity to your real projected use, then cap the unit price on overage in the contract so growth does not reprice you at list. This is the same overage discipline covered in how Oracle prices merchandising cloud service by revenue band and what overage costs.
Your leverage is highest before the first order and at renewal. Three moves matter most. First, unbundle: insist on line-item pricing per module and per sub-module so you can see and strike shelfware. Oracle's default is to quote a suite; make them decompose it. Second, right-size the metric: agree Active SKU-Location and Analytical Cloud Position quantities to a defended forecast, with a documented true-up mechanism rather than an open exposure. Third, resolve the forecasting overlap in writing before signing, so you do not carry both RDF and AIF forecasting for the same plans.
At renewal, the metrics are also your defense. Because both grow multiplicatively, Oracle's renewal quotes often assume your peak, not your steady state. Bring your own reconciled usage data. If you are moving from an older on-premise RPAS deployment, the shift in metric basis is material and worth modeling separately; see what the on-premise to cloud licensing shift costs. And when the renewal uplift lands, cap it: the approach in negotiating an Oracle Retail renewal and capping uplift applies directly to the planning suite.
One further watch item that sits under every RPAS deployment: the restricted-use database. Oracle Retail applications ship with an embedded Oracle Database entitlement that is restricted to the application. Use it beyond that scope and you create a separate, full-price database exposure. Understand those limits before your team writes custom reports or integrations against it, as detailed in the restricted-use Oracle Database hiding under Oracle Retail applications.
No. RPAS (the Retail Predictive Application Server) is the underlying engine, not a product you buy on its own. You license the applications that run on it, such as Demand Forecasting, MFP, and Assortment Planning. In the current RAP cloud model these all share one Autonomous Data Warehouse instance, but each application is separately entitled.
Often not. AI Foundation (AIF) generates multi-level forecasts that MFP, Assortment Planning, and IPO can consume via RAP integration, per Oracle's own integration guides. If AIF already feeds your plans, a standalone RDFCS license may be redundant. Confirm the forecasting path in writing before signing an RDF line, and license RDF only where you need capabilities like Promote or Curve that AIF does not cover.
The primary metric is Active SKU-Location, defined as Active Items multiplied by Locations. Oracle's example: one SKU across 500 stores counts as 500 Active SKU-Locations. A second metric, Analytical Cloud Positions, multiplies planning dimensions by time buckets and is billed in 100 million increments. Both grow multiplicatively, so model them against a realistic multi-year plan and cap overage pricing.
Functionally, yes for most retailers. Assortment Planning Cloud Service integrates with MFP to pull financial targets while creating assortments (per Oracle's AP implementation guide). Without MFP, your assortments have no financial target to plan against. Allocation, however, is downstream and does not necessarily require a separate license alongside AP, because AP exports approved quantities to whatever allocation system you already run.
They are two mutually exclusive variants of Merchandise Financial Planning. Retail plans at retail method, Cost plans at cost. Choosing the wrong one for how your finance team plans means re-implementing the deployment, so this is a merchandise-finance decision that must be made before the order is signed, not an afterthought.
Three places: carrying both RDF and AIF forecasting for the same plans, buying an assortment service for the wrong vertical (fashion versus grocery), and under-counting locations at negotiation only to over-provision on the metric. Reconcile contracted modules against the Retail Home tiles that are actually enabled, quarterly, to catch shelfware you are still paying for.
Oracle Cloud at Customer enterprise licensing framework. Buyer side framework across OCI Dedicated Region, Exadata Cloud at Customer, autonomous database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
