OpenBOM Getting Started 2026: Managing Inventory, RFQs, and Purchase Orders

When people talk about inventory management or purchase orders, the conversation usually starts in accounting or ERP systems. That is where numbers live, where transactions are recorded, and where compliance matters. But in practice, inventory problems almost never start there. They start much earlier, when product structure, quantities, and supplier decisions are unclear, fragmented, or disconnected from engineering data.

This is why OpenBOM approaches inventory and purchasing from the product side first. Instead of treating inventory and POs as purely financial transactions, OpenBOM connects them to the same product data that engineers, buyers, and manufacturing teams already depend on. The result is a continuous flow that starts with items and bills of materials and ends with production and finished goods, without forcing companies to replace their existing financial or ERP systems.

In this article, we walk through that flow step by step. The goal is not to describe every feature or configuration option, but to show how inventory, RFQs, and purchase orders naturally emerge from product data when everything is connected.

The Big Picture: One Flow from Design to Production

Before diving into individual steps, it helps to step back and look at the entire flow as a single system.

What OpenBOM enables is not a collection of disconnected tools for catalogs, BOMs, purchasing, or inventory. Instead, it provides a continuous thread that connects product definition, planning, sourcing, and production into one coherent picture.

At the left side of that picture is product intent. Items come from catalogs. BOMs describe how products are structured. Engineering data flows in from CAD systems or manual definitions. None of this is transactional yet. It is descriptive. It answers a fundamental question: what is the product, and what does it consist of?

In the middle of the picture, intent becomes demand. Planning orders translate a product structure into quantities. Inventory availability is evaluated. Gaps are identified. This is the decision-making zone, where engineering, purchasing, and operations meet. The goal here is clarity, not execution.

On the right side of the picture, decisions turn into actions. RFQs are sent. Purchase orders are created. Inventory is received. Parts are consumed. Assemblies are built. Finished SKUs appear in stock. Financial and ERP systems are updated where needed.

The important thing to notice is that nothing is recreated along the way. Each step builds on the previous one using the same underlying data. That continuity is what allows teams to move quickly without losing control.

This single-picture view becomes especially important as products grow more complex and teams become more distributed. When everyone is working from the same data model, even if they interact with it differently, coordination becomes much easier.

Start with a Catalog of Items and Vendors

Every downstream process depends on a simple question: what are we actually buying, making, or assembling?

In OpenBOM, the answer starts with item catalogs. An item is not just a row in a table. It represents a real thing in your product structure: a purchased component, a manufactured part, a subassembly, or a finished SKU. Each item can carry the information needed by different teams, including descriptions, internal identifiers, purchasing attributes, and lifecycle state.

Vendors are modeled just as explicitly. Instead of embedding supplier names and part numbers inside free-text fields, OpenBOM allows vendors to be defined as connected objects. An item can be linked to one or multiple vendors, each with its own supplier part number, pricing, lead time, and availability assumptions.

This matters because supplier choice is rarely static. Teams often need alternates, substitutions, or different vendors depending on region, volume, or availability. By separating items from vendors while keeping them connected, OpenBOM preserves flexibility without losing traceability.

Catalogs can be created manually, imported from spreadsheets, or synchronized from ERP systems. Some companies start with a rough catalog and refine it over time. Others bring in a clean dataset from an existing system. The important part is not how the catalog is created, but that it becomes a shared foundation used consistently across engineering, purchasing, and planning.

Build the Bill of Materials

Once items exist, the next step is assembling them into a product structure. This is where the bill of materials comes in.

In OpenBOM, BOMs can be created automatically from MCAD or ECAD systems using add-ins, or built manually when CAD data is incomplete, external, or simply not available. Both approaches lead to the same underlying structure: a revision-controlled, multi-level BOM that connects items, quantities, and intent.

This consistency is critical. Engineering teams often think of BOMs as design artifacts, while purchasing teams see them as inputs to sourcing decisions. OpenBOM treats them as both, without forcing one perspective to dominate the other.

At this stage, the BOM represents what the product is, not what will be ordered or built. Inventory is not consumed. No financial transactions are created. The BOM simply defines the structure and quantity relationships that everything else will depend on.

Create a Planning Order for a Specific Quantity

The transition from design to execution usually begins with a very practical question: how many are we going to build?

This is where planning orders come into play. A planning order takes a BOM and applies a specific build quantity to it. If the BOM defines what goes into one unit, the planning order defines what is needed for ten, one hundred, or one thousand units.

The planning order multiplies quantities, aggregates requirements across assemblies, and creates a clear picture of demand, without committing inventory or creating purchase orders yet. This separation is intentional. Planning and execution are different activities, and mixing them too early almost always leads to confusion.

Planning orders allow teams to explore scenarios. What happens if we increase volume? What if a component is substituted? What if lead times change? These questions can be answered before any commitments are made.

Validate Inventory Gaps and Create POs 

Once demand is visible, reality enters the picture. Some components are already in inventory. Others are partially available. Some may not exist at all.

OpenBOM compares planned demand against on-hand inventory, allocated quantities, and known incoming supply. From this comparison, it calculates gaps automatically. These gaps represent what needs to be sourced externally or produced internally.

This is where purchasing decisions begin to take shape. Instead of manually comparing spreadsheets or exporting BOMs into disconnected tools, the gap is visible directly in the context of the planning order. Buyers can see what is missing, in what quantity, and which assemblies are affected.

From here, teams can create RFQs or draft POs. Both can be sent to vendors already linked to the relevant items, preserving traceability between the request and the original product definition. As the purchase order is delivered the inventory will be updated. 

But before it happens it is a process. Engineering changes during this phase are common. Quantities shift. Parts change. Suppliers become unavailable. OpenBOM is designed to accommodate this reality, allowing changes to flow through planning and purchasing without restarting the entire process.

Create Purchase Orders (PO)

Once suppliers are selected and terms are agreed upon, RFQs are converted into purchase orders. At this point, execution begins.

What matters here is continuity. The PO is not an isolated document. It remains connected to the planning order, the BOM, and the items it was derived from. If questions arise later about why something was ordered or which product it supports, the answers are already linked.

OpenBOM does not attempt to replace financial systems. Instead, purchase orders can remain in OpenBOM for operational tracking or be synchronized with accounting and ERP systems when required. The level of integration depends on the organization, but the underlying data remains consistent.

Receive Purchase Orders, Fully or Partially

In the real world, parts rarely arrive exactly as planned. Partial shipments, backorders, and delays are normal.

OpenBOM supports partial and full PO receipts, updating inventory as parts arrive. Received quantities increase on-hand inventory, while remaining quantities stay visible and tracked. This allows planning and production teams to adapt as reality unfolds rather than relying on outdated assumptions.

Because receipts are connected to the original PO and planning order, the impact of delays or shortages becomes immediately visible. Teams can respond by adjusting schedules, reallocating inventory, or sourcing alternatives.

Move into Production and Assembly

With parts available and we validated zero gaps, the focus shifts to production.

In OpenBOM, production activities consume components from inventory and create assemblies or finished goods. When parts are used, inventory is decremented. When assemblies are built, inventory is incremented at the appropriate level.

This step closes the loop that began with the BOM. The same structure that defined the product now drives how inventory moves and how finished SKUs are created. Nothing is disconnected or duplicated.

For organizations that use MES or ERP systems for shop floor execution, OpenBOM integrates at the appropriate boundary. The goal is not to centralize everything in one system, but to ensure that product data remains consistent wherever execution happens.

Integration with Financial Systems and ERP

A common concern is whether OpenBOM replaces ERP or accounting software. It does not.

OpenBOM focuses on product structure, quantities, and collaboration across engineering, purchasing, and manufacturing. Financial systems such as QuickBooks or Xero handle accounting, invoicing, and compliance. ERP and MRP systems manage broader operational planning and execution.

OpenBOM integrates with these systems when needed, passing clean, structured data rather than forcing teams to re-enter information manually. This reduces errors and shortens the time between engineering decisions and operational execution.

Video Walkthrough

Watch how OpenBOM supports inventory planning, RFQs, purchase orders, and production — starting from a BOM and ending with finished goods.

Conclusion

Inventory management and purchasing are often treated as downstream problems, something to clean up after design decisions are already locked in. In reality, they are deeply connected to how product data is created, structured, and shared from the very beginning.

What OpenBOM provides is a way to manage that connection explicitly. By starting with structured item catalogs and BOMs, translating them into planning orders, validating inventory gaps, and carrying the same data through RFQs, purchase orders, and production, teams avoid the handoffs and rework that slow everything down.

Just as importantly, OpenBOM does this without forcing companies into a single monolithic system. Financial tools continue to do what they do best. Financial,  ERP or MRP systems remain in place where they make sense. OpenBOM acts as the product-centric backbone that keeps engineering, purchasing, and manufacturing aligned. If you have an ERP or financial system (eg. Quickbooks), OpenBOM integrates directly with them. Otherwise, OpenBOM provides you a backbone for product development. 

For teams getting started in 2026, this approach offers a practical path forward. You do not need to redesign every process on day one. You can start with catalogs and BOMs, add planning when you are ready, and integrate purchasing and inventory step by step, all while keeping your data consistent.

REGISTER FOR FREE to check OpenBOM – you can start with a simple seat and grow up with our new 2026 pricing model. 

Best, Oleg