Production Steps in an App: A Planned Start Time Is Not Permission to Begin

A production step may have a scheduled start and still be waiting for another operation to finish. Your app should make that distinction visible. Decide which predecessor must be completed, what completion means in your process and whether any required waiting period remains before the next operation can begin.

This is not the same as checking whether a machine has an empty slot. It is about the relationship between operations, even when they use different resources. Technical and safety conditions must be defined by competent people, not inferred from a calendar arrow.

Describe the prerequisite, not just the row order

Use an invented example: prepare a component, then assemble it. Specify whether assembly depends on completion of preparation or whether a reviewed partial handover is permitted. Do not infer the answer from which row appears first on a screen.

Odoo 19 documents a Blocked By relationship between bill-of-materials operations. In its work-order list, a blocked operation shows Blocked; after the blocking work orders are completed, its tag changes to To Do. That is a product-specific dependency example, not proof that your custom app enforces your actual production conditions.

If your first version only warns about an out-of-order start, say so. A warning that can be ignored must not be described as an enforced prohibition or a safety interlock.

Keep the estimated time separate from reported completion

The same Odoo guide describes planning a dependent work order after the expected duration of its predecessor. An estimated end time is therefore useful for planning, while the completion state is a different fact.

For your brief, ask what staff see when the predicted end passes but the earlier operation remains unfinished. The following operation should not appear operationally cleared merely because its appointment has arrived. Where the system blocks starting, demonstrate the block; where it only displays a warning, demonstrate that limitation clearly.

Completion itself needs a definition. Is it a staff report, an accepted output quantity or a separately reviewed check? Those are process choices, not alternative meanings the app may select silently. This article does not establish any required inspection or permission to bypass one.

Distinguish movable slack from a required waiting gap

Odoo documents rescheduling modes that keep a buffer or use it, and cautions about compressing gaps. Your implementation needs to know why a gap exists before it can move work into it.

A convenient scheduling cushion is different from a technically required wait. For example, a fictional process may require a specialist-defined waiting interval after an operation. State the event from which it is measured, the applicable duration and who can revise that rule. Do not let a target delivery date turn such a requirement into spare calendar space.

The source's buffer feature is a planning mechanism. It does not certify physical readiness, a curing result or a safety condition in your process.

Removing a warning must not silently remove the rule

The Odoo documentation explains that cancelling a dependency link in the planning view breaks that relationship because the product assumes an exception. That is materially different from replanning work while preserving the link.

Specify who may remove a dependency in your application and how the reason remains visible. Ask the demonstration to show the relationship before and after the change. A planner trying to tidy a red arrow should understand whether they are changing a date or deleting a prerequisite.

Accept the sequence through difficult cases

Use invented jobs in the acceptance walkthrough: a late predecessor, a completed predecessor with a required wait still running, a moved operation and an attempted dependency removal by an unauthorised user. Include parallel work that has no prerequisite so the system does not force every operation into one chain.

Verify the planned time, actual completion, blocking reason and remaining wait separately. Ask what happens if a completion report is corrected after the successor starts; that needs an explicit exception path rather than a silent rewrite of history.

Bring the agreed operation relationships to a production-app discussion. The useful deliverable is an explainable sequence with honest enforcement limits, not merely connected blocks on a timeline.

Source

Odoo 19: Work order dependencies, read 26 October 2026. Product behaviour above is documentation-based; proposed acceptance cases are not a completed implementation test.