Approval status, read exactly

Sixty entities each carry a plan through a documented workflow, and the question every forecast week is the same: who is holding what, and since when. The states, the built-in report, and the REST route are all documented. The history is not kept, and that is the gap this page closes.

Note: In Planning, Oracle's module where budgets and forecasts are built, every entity's plan moves through an approval workflow before it counts. This page is how to read that workflow's status, what the built-in report gives you, and what it cannot remember.

The whole module is mapped on the Planning index.

RuleRead status by the seven documented states, use sub-status to explain failed actions, pull the population by REST on a schedule, and keep the history yourself.

Nevercall the Reject state Rejected in any spec or report. The state is Not Signed Off, and precision here is how implementers know you have read the documentation.

◆ The states, footed, seven states, the Tuesday counts summing to 60, and the two behaviors that surprise people.

Each approval unit, an entity in a scenario and version, sits in exactly one of seven documented states, per Oracle's reference. The sample world's Tuesday of forecast week:

State	Meaning	Tuesday count
Not Started	Initial state of every unit, before Start.	1
1st Pass	No owner yet; anyone with write access can work and promote. Start produces this state in the free-form template only.	6
Under Review	After Promote or Submit; the current owner holds the pen. In bottom-up, Start lands here at the first stop of the promotional path; in distribute, at the last. First and last are locations on the path, not states.	12
Not Signed Off	The state Reject produces. There is no state named Rejected.	0 today; 1010-CL, the Chilean subsidiary, passed through it last week and is back Under Review.
Approved	Approve was selected.	41
Signed Off / Frozen	Signoff recorded; Frozen locks descendant data read-only.	counted within the 41 approved above

The counts foot: 41 approved plus 12 under review plus 6 in first pass plus 1 not started is the full 60 units. Two documented behaviors worth respecting: a parent's status change cascades to children unless a child was excluded or already approved, and excluding a unit discards its annotations and history, per the approvals tutorial.

◆ The three routes, the built-in report column by column, the REST read, and the missing history.

Route	What it gives, and where it stops
The built-in report	System Reports, then Approval Unit, then Approval Status, per the report doc: filter by status, scenario, version, hierarchy, generation, or approval group, and get unit, parent, status, sub-status, the previous, current, and next owner, current location, total value, and last status change date, in XLSX, PDF, HTML, or XML. Sub-status is the underrated column: it records why an action failed, security, validation rules, or system errors. It is security-trimmed to units you can write to, run by hand, and it holds exactly one timestamp.
REST	Oracle's REST reference lists List All Planning Units for reading and Change Planning Unit Status for acting, and a practitioner write-up shows the actions route driven from a Groovy rule, including gating a Promote with a validation before it lands. Reading status on a schedule is therefore supported, documented, and scriptable.
What neither holds	History. Last Status Change Date is one date; nothing records how long each owner held each unit, when the reject happened, or how this cycle compares to last. That history is a nightly snapshot away, and it is what the owned model keeps.

THE USE CASE, SIMPLIFIED

The problem: The approval report is a point-in-time snapshot, run by hand, and it cannot say when anything changed or how long each owner held it.

What we build: A nightly snapshot of every approval unit's state lands in your warehouse, built from the documented REST read.

What you get: Cycle times per owner, the day each unit moved, and last cycle against this one, all as queries.

Forecast week status still collected by walking the floor?

We wire the nightly REST snapshot into your warehouse, and every morning of forecast week opens with who holds what, since when, and how that compares to last cycle.

Talk to us

Terms on this page

sub-status: Why an action failed: security, validation rules, system. The underrated column.
Not Signed Off: What Reject produces. No state is named Rejected.
locations: First and last in the promotional path describe where, not what state.
the missing history: Owner hold times and change dates. Kept only if you keep them.