Planning / Capacity Planning is where ERP discipline either begins or breaks.
Capacity Planning & Finite Scheduling looks operational from far away. In a real finance team, it is a chain of assertions: the right actor started the work, the required records existed, the control policy was applied, the state change was preserved, and the outcome can be explained later without rebuilding the transaction from emails and spreadsheets.
The expected business outcome is specific: Overloads are identified and resolved before they become late orders; scheduling decisions are based on actual capacity rather than infinite assumption; on-time delivery improves through realistic promise dates.
The control flow a finance team actually needs.
Step 1
Infinite And Finite Scheduling Modes
Step 2
Work Center Calendar With Shifts,...
Step 3
Routing Operation Times
Step 4
Alternate Work Center With Efficiency...
Step 5
Drag-And-Drop Gantt Rescheduling
The ERP surface involved.
Module
Planning / Capacity Planning
Actors
Production Scheduler, Plant Manager, ERP System
Tier
Tier 2
Finance area
Manufacturing & Production
Region lens
US and UK finance teams
Publication date
May 9, 2026
Infinite and finite scheduling modes; work center calendar with shifts, holidays, and efficiency factors; routing operation times (setup, run per piece, queue, move, wait); alternate work center with efficiency factor adjustment; drag-and-drop Gantt rescheduling; overtime calendar entry; capacity loading report by work center by period; bottleneck identification; what-if capacity simulation; operation splitting across work centers; integration with shop floor actual times for remaining-to-complete calculation; CRP re-run triggered on work order change.
US and UK teams have different compliance hooks, but the same control problem.
US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.
The control matrix.
| Control area | Requirement | Acceptance proof |
|---|---|---|
| Control 1 | Infinite and finite scheduling modes | Given firm planned work orders and work center shift calendars |
| Control 2 | work center calendar with shifts, holidays, and efficiency factors | when a scheduler runs CRP in finite mode |
| Control 3 | routing operation times (setup, run per piece, queue, move, wait | then the system returns a Gantt schedule with each operation assigned to a specific time slot on the required work center respecting capacity limits |
| Control 4 | alternate work center with efficiency factor adjustment | overloaded periods are flagged |
| Control 5 | drag-and-drop Gantt rescheduling | negative) when a work order is scheduled to a work center whose shift calendar shows no available hours in the required window then 422 NO_CAPACITY_AVAILABLE. |
| Control 6 | overtime calendar entry | Overloads are identified and resolved before they become late orders; scheduling decisions are based on actual capacity rather than infinite assumption; on-time delivery improves through realistic promise dates. |
Audit evidence is a chain, not a folder.
| Evidence layer | What should be preserved |
|---|---|
| Business event | After MRP generates firm planned orders, the scheduler opens the capacity requirements planning (CRP) workbench, which loads all work orders onto work centers using routing operation times, scheduling forward or backward from due dates. The system identifies overloaded work centers (capacity exceeded) and underloaded centers. The scheduler uses the drag-and-drop Gantt chart to reschedule operations, shift to alternate work centers, or authorize overtime. The system enforces finite scheduling rules, preventing assignment of more hours than the work center's available capacity in a shift. Rescheduled operations update work order dates and regenerate component need dates for the next MRP net-change run. |
| Control rules | Infinite and finite scheduling modes; work center calendar with shifts, holidays, and efficiency factors; routing operation times (setup, run per piece, queue, move, wait); alternate work center with efficiency factor adjustment; drag-and-drop Gantt rescheduling; overtime calendar entry; capacity loading report by work center by period; bottleneck identification; what-if capacity simulation; operation splitting across work centers; integration with shop floor actual times for remaining-to-complete calculation; CRP re-run triggered on work order change. |
| Acceptance proof | Given firm planned work orders and work center shift calendars; when a scheduler runs CRP in finite mode; then the system returns a Gantt schedule with each operation assigned to a specific time slot on the required work center respecting capacity limits; overloaded periods are flagged; (negative) when a work order is scheduled to a work center whose shift calendar shows no available hours in the required window then 422 NO_CAPACITY_AVAILABLE. |
| Data record | |
| System event | |
| Lifecycle state | |
The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.
Implementation contracts.
Reference data model
`capacity_plans` { plan_id: string, work_center_id: string, period_start: timestamp, period_end: timestamp, loaded_hours: numeric, available_hours: numeric, overload_flag: boolean }; `scheduled_operations` { sched_op_id: string, op_id: string, work_center_id: string, scheduled_start: timestamp, scheduled_end: timestamp, external_id: string }; (reference, product may differ).API and events
`POST /v1/capacity/crp-runs` { mode: FINITE|INFINITE, horizon_days: int } -> 202 { crp_run_id }; `GET /v1/capacity/crp-runs/{id}/schedule` returns Gantt data; `PATCH /v1/scheduled-operations/{id}` { scheduled_start, work_center_id } -> 200 for drag-and-drop reschedule; emits `capacity.overload_detected` event; idempotent via `external_id`.State transitions
CRP run: `PENDING -> RUNNING -> COMPLETED`; scheduled operations: `TENTATIVE -> PUBLISHED -> LOCKED`; guard: LOCKED operations block capacity re-assignment without explicit override.Common implementation traps.
Treating the workflow as data entry
If the ERP only stores the final record, the team loses the decision trail that explains how the record became valid.
Hiding exception logic
Exceptions need owners, reason codes, and time stamps. A vague pending state is not a control.
Posting without recovery design
Retries, duplicate submissions, and partial failures must be explicit so the system does not create inconsistent records.
Skipping evidence design
A workflow that cannot produce evidence on demand will eventually push finance teams back into manual screenshots and spreadsheets.
Where Rivane fits.
Rivane is built for finance workflows where automation must stay tied to source documents, approvals, state transitions, ledger impact, reporting, and audit evidence. Use this guide as a checklist for evaluating whether an ERP workflow is merely digitized or actually controlled.
References and source basis.
These sources provide the standards, regulatory, or government context around the flow. They are included so the guide is useful to finance operators, auditors, and implementation teams, not only buyers reading software copy.