Capital and Projects, and the tree they must share

Capital plans assets and their depreciation. Projects plans initiatives and, for contract work, their revenue. Both borrow dimensions from the rest of the application, and the borrowing is where designs go wrong.

Note: Capital and Projects are the parts of Planning, Oracle's module where budgets and forecasts are built, that plan assets and initiatives. This page is the objects each one uses, an asset row and a project row, and the rule that keeps their hierarchies honest.

The whole module is mapped on the Planning index.

RulePick only the project types you need now, plan depreciation from the in-service date, and maintain every shared hierarchy in exactly one place.

Neverlet two cubes carry their own copies of the same hierarchy. They will diverge, and every report that crosses them will disagree.

◆ One row from each side, an asset in flight, a project with its type rules.

One row from each side of the sample world:

Capital asset row
Asset	Santiago office fit-out, entity 1010-CL, the Chilean subsidiary
Status	In flight: part of the 27.3M under construction
Plan effect	Capex now, then depreciation to the P&L at in-service date

Project row
Project	Warehouse automation, type Capital Project
Type rules	Project types are Contract, Capital, and Indirect. Contract projects subdivide into Cost Plus, Time and Materials, and Fixed Price. Revenue planning exists only for Contract projects; project benefits exist only for the non-revenue types, per a practitioner configuration guide.
Rules behind it	The OPF_ rule family: add project, calculate direct and capitalized expense, calculate benefits, approve. Approving copies plan data to the forecast scenario, per Oracle's Projects rules page.

◆ The spine, and the sharing rule, the 74.0M footed, and the one-tree principle.

The spine: FY26 capital plan 74.0M, which is 41.5M in service plus 27.3M in flight plus 5.2M of unapproved requests, with 6.8M of new-asset depreciation flowing to the plan P&L. The rollforward report reads those three states across time.

One design rule joins these two processes to Workforce: cubes share dimensions, and shared dimensions must agree. If Projects plans labor by employee, the employee hierarchy in the Projects cube and the Workforce cube must be the same tree, maintained once. Divergent copies of a shared hierarchy are a documented pattern of field pain, and the fix is structural, not a rule: one source for each dimension, pushed to every cube that uses it.

THE USE CASE, SIMPLIFIED

The problem: The capital plan and the fixed-asset register drift apart until quarter end exposes it.

What we build: Plan rows land beside the register extract in your warehouse, on the shared entity tree.

What you get: The drift is a standing query with asset names on it, read any morning, not discovered at quarter end.

Capital plan and fixed-asset register drifting apart?

We land the plan rows beside the register extract, keyed on the same entity tree, and the drift becomes a query with names on it.

Talk to us

Terms on this page

in service / in flight / requested: The three asset states the rollforward reads.
Contract project: The only type that plans revenue. Three pricing subtypes.
OPF_: The Projects rule family prefix. Approve copies plan to forecast.
one tree: Each shared hierarchy maintained once, pushed everywhere.