Production Order Statuses in BC: What Each One Means
A Microsoft Dynamics 365 Business Central production order carries one of five statuses — Simulated, Planned, Firm Planned, Released, or Finished — and the status isn’t just a label. It changes what the order actually is: what you can edit on it, whether it’s counted in planning, whether it can consume real material and post real output, and even, in one detail worth knowing, what “the same order” even means as it moves through its life. This page walks the five statuses and what changes at each transition, with a focus on what actually matters if you’re the one deciding what to schedule.
You can’t change a production order’s status directly by editing a field — it moves forward through the Change Status action (or the Change Production Order Status page for handling several at once), which runs the right logic for that specific transition rather than just flipping a value.
Simulated: a what-if, invisible to planning
A simulated production order exists for costing and quoting — Research and Development wants an estimate for a proposed item, a salesperson wants a rough cost before committing to a price. It behaves like a production order in every structural sense (it has a routing, a BOM, computed dates) but it carries no weight anywhere else: MRP and MPS don’t see it, it places no load on any work center’s capacity, and it can’t even serve as a reusable template, because changing its status makes it disappear. If you’re looking at capacity or trying to understand what’s actually committed in the shop, simulated orders are correctly invisible — they were never real demand in the first place.
Planned: the planning engine’s current best guess
A planned production order is what the Planning Worksheet generates automatically when it calculates a suggestion for manufactured demand, as covered in The Planning Worksheet Plans. It Doesn’t Schedule.. It’s scheduled the same way any order is — real routing, real calendar-respecting dates — and it does count toward work center load, showing planning’s best current estimate of future demand on each resource. But it’s explicitly disposable: the next planning run deletes and regenerates planned orders wholesale, which is exactly why hand-editing one or treating it as a firm commitment doesn’t hold up. If you need it to survive the next planning run, it has to become firm planned first.
Firm Planned: a placeholder that survives
Firm planned is where a suggestion becomes an intention. You get here either by carrying out an action message from the Planning Worksheet, by creating the order manually, or by generating it directly from a sales order — and unlike a planned order, a firm planned order isn’t erased by the next planning run. It holds its place in the schedule as a real, if not yet authorized-to-execute, commitment. Firm planned orders still contribute to work center load the same way planned and released orders do, which matters for anyone reading a load report: a work center can show as overloaded from firm planned demand alone, well before anything is actually released to the floor.
Released: work can actually start
Releasing an order is the step that makes it real in the sense that matters to the shop floor: it’s now authorized for materials to be picked and consumed and for work to actually begin. This is also where the item’s flushing method — manual, forward, or backward — takes effect: automatic posting of material consumption and production output only happens against released orders. Whether or not materials are physically picked the moment an order releases is a separate operational decision, but structurally, released is the status where the order stops being a plan and starts being trackable, real-world work in progress.
This is also the status where an order’s operations can genuinely be in flight — an operation partway through its run time, with some quantity already reported as output and some still to go. A released order that’s actively being worked deserves real caution before its dates get casually recalculated: refreshing or rescheduling an order with in-process operations can move time that, on the shop floor, has already happened. This is exactly why “released” is the status where a scheduling layer needs to know not just an order’s dates, but which of its operations are already underway and shouldn’t be treated as freely movable.
Finished: closed, and mostly locked
Finishing an order is a costing milestone as much as a production one — it’s the step that lets Business Central adjust and reconcile the item’s actual cost against what was expected. A finished order can’t be edited, and it becomes the historical anchor for traceability: tracing a shipped item back through what was consumed to produce it runs through its finished production order. There’s a narrow escape hatch — a finished order can be reopened once, to correct a genuine mistake like missing consumption, but not if its cost was already written off, and not a second time. Finished orders are history, not a scheduling surface; nothing about them should be competing for capacity going forward.
Which statuses actually matter for scheduling
Put the five together and only two of them are the right surface for a scheduler to actually work against. Simulated orders were never real demand and shouldn’t appear anywhere near a capacity plan. Planned orders are too volatile to sequence against with any confidence — they can vanish the next time someone runs MRP, so building a careful, hand-tuned sequence around one is building on ground that might not be there tomorrow. Finished orders are done; including them in a forward-looking load calculation would double-count work that already happened. That leaves Firm Planned and Released as the durable, real orders a scheduling layer should actually be sequencing — firm planned because it’s committed enough to plan around, released because it’s the order actually consuming capacity right now, including whatever’s already in progress and shouldn’t be casually rescheduled out from under the floor.
One identity detail worth knowing
Business Central’s production order records are keyed by status and number together, not by number alone — which means an order number by itself isn’t a unique reference the way it feels like it should be. It’s normal, not a data error, to find a Firm Planned order and a Released order both showing the same number: as an order moves from one status to the next, Business Central doesn’t just flip a field on one continuous record, it creates a new record at the new status. History (and, depending on setup, older statuses) can genuinely leave more than one record answering to the same order number, distinguished only by which status each one is. Order “3001” as a Firm Planned record and order “3001” as a Released record are two separate rows of data — related, telling the story of the same job at two different moments in its life, but not the same record with one field changed.
This rarely matters for someone working one order at a time in the UI — the page you’re looking at only ever shows one status at a time, so the ambiguity never surfaces. It matters a great deal for any report, integration, or scheduling tool built against production order data underneath the UI, because “give me order 3001” isn’t a complete question until you also say which status you mean. A query or an integration that filters by order number alone, without also filtering by status, risks silently summing quantities or capacity demand from two genuinely different records that happen to share a number — a subtle source of double-counted load that won’t look wrong on inspection unless someone knows to check for it.
For the mechanics of how each status’s routing lines actually get their dates, see How Business Central Schedules a Production Order, Step by Step. For Microsoft’s own detailed reference on each status and the consumption/output posting methods available at each stage, see About production orders.