Bill of materials software should connect a finished item to its components, quantities and approved production structure. Choose it by testing a representative assembly and a controlled component change. A useful demonstration must distinguish material requirements, available stock and revision approval; an attractive product screen alone does not establish those controls.
Start with a product your business understands. List what goes into it, which parts arrive ready-made, which are assembled internally and who approves a changed specification. Then ask a shortlisted system to represent that structure. This gives the demonstration a concrete purpose and keeps a general inventory presentation from standing in for manufacturing evidence.
The comparison below uses current Odoo and ERPNext documentation as examples of different approaches. It is not a ranking, an implementation report or confirmation that a particular edition meets your requirements. The original acceptance worksheet later in the article is a proposed exercise for a separate test environment.
What must a bill of materials system represent?
A component list needs a clear relationship to its output. In Odoo’s BoM documentation, components have required quantities. Establish which finished item and output quantity the list represents before comparing totals. Otherwise, two valid-looking lists may describe different production quantities.
A flat list may be insufficient for an assembly with intermediate products. ERPNext documents multi-level BOMs, in which a sub-assembly can have its own component structure. Sketch that relationship before configuring it. Mark an intermediate item as purchased, manufactured or merely grouped for the demonstration, and ask how that choice affects the material view.
Keep the item record separate from the production instruction. Ask the demonstrator to show which screen owns the component specification and which record governs a particular production run. Record the answer using the product’s actual terminology. Do not assume that a familiar field label has the same effect in another platform.
How do variants, operations and revisions change the comparison?
A product variation can change only part of an assembly. Odoo documents variant-specific component applicability and requires its Work Orders feature for BoM operations. These are configuration details to check in the proposed installation, rather than capabilities to assume from the product name. Ask for a demonstration with one shared component and one variant-specific component.
A revision changes the controlled specification. It deserves a separate test from changing a product’s display name. Ask who can propose the change, who can approve it and what an operator sees afterwards. Distinguish a suggested approval process from a documented platform feature until the demonstrator provides evidence.
Odoo’s documentation associates visible BoM versions with its PLM app. ERPNext states that a submitted BOM cannot be edited directly. Those are different starting points for a change-control discussion; neither statement alone proves that an organisation’s complete approval process is implemented.
| Decision | Documented example | What to request in the test copy |
|---|---|---|
| Product variation | Odoo supports variant-specific components | Show the shared and changed component for each selected variant |
| Production operation | Odoo’s BoM operations require Work Orders | Identify the enabled feature and the relevant instruction record |
| Revision visibility | Odoo documents version visibility with PLM | Show how the approved version is identified for the operator |
| Submitted specification | ERPNext restricts direct editing after submission | Demonstrate the applicable replacement process without changing live records |
| Intermediate assembly | ERPNext supports multi-level structures | Explain whether the intermediate item is stocked or made for the exercise |
Retain the version, edition and enabled features alongside the demonstration notes. A screenshot without that context is a weak handover record. If a required action depends on an additional application or a custom change, put it in the proposed scope and request evidence before treating it as available.
What should an exploded materials test show?
An exploded view expands intermediate structures into underlying requirements. ERPNext documents both an exploded materials view and an item-level “Do Not Explode” option. Use those as prompts for a test: the desired treatment depends on what the intermediate item means in your own process.
Consider this explicitly fictional exercise. A display stand needs one base and two brackets. The base contains three panels and four fasteners. If two stands will be assembled and their bases must also be made, the base portion of the exercise needs six panels and eight fasteners. These figures are illustrative arithmetic, not a production recipe or a promise about a configured system.
Now change the scenario: the two bases are already available as approved stock. Ask how the system distinguishes the requirement for bases from an instruction to make more bases. Do not assume that a displayed component total is also a purchase recommendation. Request the explanation of stock treatment, planned production and any relevant configuration separately.
ERPNext distinguishes inventory-tracking warehouses from workstations used for costing and scheduling. Include both in the demonstration record so a workstation selection is not mistaken for a stock-location decision. This is a useful way to catch misunderstandings between the production team and the person configuring the software.
How should consumption exceptions be handled?
The approved specification and the quantity actually used are separate questions. Odoo documents consumption settings that can block deviations or permit them. Ask what the proposed setting means for your operator, supervisor and subsequent review. A permissive setting should not be described as approval of an unspecified substitution.
For the fictional stand, propose a component change and record its intended effective point. Ask whether the demonstration changes the specification, a single production record or both. Compare that answer with the requirement written by your business. If they differ, keep the issue open rather than accepting a plausible-looking total as a pass.
The same discipline applies to units. Write the intended unit next to every component quantity in the test card. Where a conversion is required, record the agreed conversion and independently calculate the illustrative result. Then inspect the software’s displayed unit and quantity together. Do not enter ambiguous quantities into production records to discover how the application interprets them.
Original assembly-and-revision acceptance worksheet
Use this original worksheet to organise a witnessed demonstration. It is a proposed review method, not evidence that Spout or a software vendor has performed the tests. Keep the exercise in an isolated test copy, use fictional or approved non-sensitive data and record observed behaviour.
Define the assembly. Draw the finished item, intermediate assemblies and underlying components. Note the output quantity and unit at each level. Identify which intermediate item is stocked and which must be manufactured for this particular exercise. Name the business owner who can confirm that this represents the intended process.
Establish the baseline. Enter the structure in the test copy and capture the resulting component view. Compare it with the hand calculation before introducing a revision. Record any configuration that affects the result. A mismatch needs an explanation; it should not be concealed by changing the example until the figures happen to agree.
Introduce a controlled change. Change one component requirement in the fictional specification. Ask the demonstrator to show the proposal and approval route that is actually available. Record who could make the change, what record changed and how the intended revision is recognised. Leave an unsupported approval requirement as an open scope item.
Compare material outcomes. Run the stocked-base and manufactured-base scenarios separately. Retain the input assumptions and the displayed requirements for each. Ask the production owner to explain the difference back in operational terms. This checks shared understanding as well as screen output.
Prepare a decision record. For every requirement, mark demonstrated, unresolved or outside the proposed scope. Attach the relevant configuration and screenshots. Keep acceptance of the demonstration separate from permission to modify live production. Agree a migration, backup, validation and recovery plan before any later rollout; this worksheet does not authorise an import or a production test.
Use the record to compare the shortlist on demonstrated fit, ownership and unresolved work. For wider context, see business systems and software development. To discuss the requirements, get started with the assembly sketch and the questions the demonstration still needs to answer.
By Spout Team. AI-assisted drafting and editorial revision by Codex using the linked primary documentation. No product implementation or customer outcome is claimed.