ERPNext Production Plan Not Creating Work Orders: Fix Ladder (2026)

The Create Work Order button on a submitted Production Plan either produces a green toast with the WO count, a red toast with a specific error, or, in the worst case, a green toast that lies and creates fewer WOs than plan lines. The ladder below tells the three apart. I am Manoj, ERPNext and Frappe implementation lead at MithTech in Bengaluru, a 35-person practice that designs, customises, and operates business-critical software on ERPNext for manufacturers and distributors across India, and this is the diagnostic order we run on manufacturing client tickets.

The five causes at a glance

Skimmable summary: cheapest check first. Half of "Production Plan not creating work orders" tickets close at row 1 or 2.

Is the Item set up as a manufactured stock item?

Skimmable summary: three item flags gate everything downstream.

Open the Item form for the FG on the plan line and confirm all three:

• Is Stock Item — must be ticked. Non-stock items cannot be produced through Work Orders because there is nothing to receive into inventory.
• Include Item In Manufacturing — must be ticked. This is the master switch for whether ERPNext considers the item a manufacturing candidate at all. If it is off, the item is invisible to Production Plan → Work Order creation, even with a valid BOM.
• Default BOM — must reference an active BOM. If the field is empty, Create Work Order has nothing to instantiate from and skips the row.

If any of these is off, fix it on the Item form, then re-open the Production Plan and try Create Work Order again. You do not need to re-submit the plan — the button re-reads the item state each click.

Is the BOM Default AND Active?

Skimmable summary: an Item can have many BOMs; Production Plan uses only the Default one that is also Active.

Every WO needs a specific BOM version. ERPNext picks the one that satisfies both: Is Active = 1 AND Is Default = 1. The common failure modes:

• No Default BOM at all. The Item has three BOMs, none marked Default. Fix: open the intended BOM, tick Is Default, save. ERPNext auto-unmarks the other BOMs of the same item.
• The Default BOM is Inactive. Someone deactivated it after a rate change or a supersession. Fix: either re-activate it (if the deactivation was a mistake), or mark the new active BOM as Default.
• A newer BOM version was published but not made Default. Common on second-year manufacturing rollouts. Fix: on the intended BOM, tick both Is Active and Is Default.

To confirm quickly, open the BOM list, filter Item = <your FG>, and check the two boolean columns. You want exactly one row with both green.

Does the company on the plan match the warehouse company?

Skimmable summary: multi-company setups fail silently on this — no error toast, just a lower WO count than expected.

Every warehouse in ERPNext belongs to exactly one Company. When Production Plan tries to create a Work Order, it validates that the row's For Warehouse (target FG warehouse) and the source warehouses for raw materials all belong to the same Company as the plan itself. If any warehouse is in a different Company, that row is skipped in the WO create loop — the toast still reports a WO count, just a lower one than the plan lines.

To debug:

1. Open the Production Plan; note the value of Company at the top.
2. For each row in Assembly Items, click through to the referenced Warehouse.
3. On each Warehouse form, confirm Company equals the plan's Company.
4. If any row is on a warehouse in a different Company, either move production to a warehouse of the correct Company, or create the plan under the Company that owns the warehouse.

This is common in setups where a parent company holds the master warehouses and a subsidiary is trying to plan production against them — the reference will not work; produce from a warehouse the plan's Company actually owns.

Does the user have permission to create Work Orders?

Skimmable summary: Production Plan uses the current user's permissions when creating WOs — plan perms alone are not enough.

If the operator can submit a Production Plan but the WO create button errors with Not permitted to create Work Order (or, more subtly, produces zero WOs with no error on some ERPNext builds), their role is missing Create on Work Order. The plan itself only needs Submit; the WO create step runs as the same user and needs Create on the target doctype.

Two clean fixes:

1. Grant the role Create on Work Order via Role Permissions Manager. Usually the "Manufacturing User" role already has this — verify.
2. If the operator legitimately should not have Create, have a Manufacturing Manager click Create Work Order on their behalf; the plan can stay under the operator's ownership.

The v16 select-only permission regression noted in ERPNext v16 bulk edit not working can also cause this to fail if the operator has Select but not Read on Work Order — grant Read.

Are Semi-Finished Goods raw materials being ignored on v16?

Skimmable summary: an open v16 bug — untagged raw materials on Track-SFG BOMs are silently dropped from the WO's material picture.

If your BOM has Track Semi-Finished Goods enabled with multiple operations, and one or more raw materials are not tagged to a specific operation, Issue #51172 applies. Symptom: the Work Order is created successfully, but when you go to raise a Material Request against it or open the Job Cards, the untagged raw material is not listed. No error, no warning — the row just isn't there.

The workaround while the fix is pending upstream:

• Open the BOM in question.
• For every raw material row, populate the Operation field with one of the BOM's operations — even if the material is generic and used by more than one operation, pick the earliest.
• Save and re-submit the BOM (make new Version if needed).
• Re-run Create Work Order on the Production Plan.

This is not a permanent architecture change — once the upstream PR lands and you upgrade to the point release, untagged raw materials will work correctly again. In the meantime, tag every row.

What is the correct end-to-end setup order?

Adjacent problems that look like this

Three failure modes that look like "Production Plan not creating work orders" but need different fixes:

• Production Plan creates WOs but marks itself "Completed" while WOs are still open. That is Issue #27480 — a status-tracking issue, not a create-time issue.
• Production Plan tags and attachments not carrying to the WO. Issue #46619 — cosmetic, not blocking.
• A partial Production Plan won't produce the remaining quantity. That is a different diagnostic path — see Production Plan partial completion.

FAQ

The four questions this ticket generates most often.

Why does Create Work Order create fewer WOs than my plan has lines?

Usually one of two things. First, one or more plan lines reference a warehouse in a different Company than the plan itself — those rows are silently skipped. Second, one or more Items on the plan is missing Include Item In Manufacturing or has no Default BOM — those rows are also silently skipped. Compare the toast's WO count against your plan's row count; the difference is the number of rows to audit.

Do I need to un-submit the Production Plan to fix the Item or BOM flags?

No. Production Plan reads the current Item and BOM state each time you click Create Work Order — no re-submit required. Fix the flags, re-click, and the WOs create against the corrected setup.

The button greys out entirely. What does that mean?

The plan is already fully produced (every row has WOs created for its full quantity) or the plan is in a state that prevents WO creation (draft, cancelled). Check the plan's Status field. If it says Completed or Cancelled, no more WOs can come out of it.

Is there a way to force Production Plan to skip permission checks?

No, and you should not want one — WO permissions gate who can commit inventory to production, which is a real control. If a specific user must be able to create WOs from plans they submit, grant that user's role Create on Work Order via Role Permissions Manager. Skipping the check would defeat the audit trail on why a WO exists.