SAP Business One Production Orders: From BOM to Finished Goods

Start with the BOM: the planned recipe

A bill of materials lists the components required to make a product. For a small pump assembly, for example, the BOM might specify one housing, two bearings, one motor, and the other required parts for each finished unit.

Those quantities are the starting point, not proof of what happened on the floor. The BOM needs to reflect the product the team actually builds, including the right item numbers and quantities. If the recipe is stale, the order carries stale expectations forward.

In SAP Business One, a production order can be created from a production BOM. The planned finished quantity scales the component quantities on the order, giving the team a job-level view of the expected material needs. The order can also include resources where they’re used in the company’s production process.

Think of the BOM as the recipe and the production order as the work ticket. A dependable recipe makes the ticket more useful.

Move from planned work to released work

A production order begins in Planned status. That’s the point to review the product, quantity, dates, and components before work is authorized to proceed. The order can be adjusted while it’s being prepared, but material issues and completion reporting aren’t available yet.

When the order is changed to Released, it can move into production. The team can then record the relevant component issues, receive finished goods, and report completion. That distinction matters: a planned quantity is a plan. It should not be mistaken for material already consumed or finished goods already on the shelf.

A practical review before release can catch basic errors:

• Is this the right finished item and order quantity?
• Does the BOM show the components the team expects to use?
• Are the component warehouses correct?
• Are dates and other order details useful for the people doing the work?

SAP’s overview of the production process in SAP Business One describes the production order as the document that tracks progress, material transactions, and costs through the job.

Record material as it moves

Once an order is released, the team records components going to production. The right timing depends on how the work is run and how the BOM lines are configured.

With manual issue, components are issued separately using an Issue for Production transaction. This gives the team a way to record materials when they’re actually needed and to issue quantities in stages. It can be a good fit when the shop floor wants to capture consumption as work progresses.

With backflush, eligible components are issued automatically when production completion is reported. This can reduce separate data entry for a repeatable process, but it depends on accurate BOMs and timely completion reporting. Backflush isn’t available for serial- or batch-managed items, so the team should confirm the right method for its products and tracking requirements.

The important point is not that one method is universally better. It’s that the recorded transaction should match what the team actually does. If the system says a component was issued but the material is still sitting in the wrong place, or the physical issue never gets recorded, inventory visibility can drift.

Report what was built

When the job is complete, or when the team is recording completed output, it reports completion and receives finished goods into inventory through a Receipt from Production. This is the production-specific receipt for the finished item. Component consumption and finished-goods receipt are related parts of the job, but they are distinct production transactions.

The record becomes more useful when the posted transactions reflect the shop floor:

• How many finished units were received?
• Which components were issued, and in what quantities?
• Were components issued manually or through backflush?
• Does the order still represent work in progress, or is it ready to close?

That trail helps operations and inventory teams understand the difference between the expected build and the transactions recorded against it. It also gives management a better basis for reviewing production costs and investigating a mismatch.

The system can’t record a substitution, shortage, or process change that nobody enters. Production visibility is a team habit supported by software, not a magic setting.

Common trouble spots, and a sensible first step

A few small checks can prevent confusion later:

• The BOM is outdated. Review item numbers and quantities against the current build.
• The order quantity is wrong. Confirm the planned output before release.
• Issue method and shop-floor practice don’t match. Decide when components should be recorded, then configure the process accordingly.
• Completion gets posted late. Agree on who records finished output and when.
• A job is closed before its transactions are reviewed. Reconcile the order before closing it.

Start with one repeatable product. Walk its BOM with the people who build it. Run a production order, record the components the way the team actually issues them, then receive the finished quantity. Review the result together and adjust the process before rolling it out more broadly.

For a practical walkthrough of native production features, see Quaint’s SAP Business One out-of-the-box manufacturing session.