A deep dive into openBoM properties: Public, Private, BOM (link), Items

At openBoM we are always thinking how to make complex things simple. One of those things is data management. In that context I want to talk about the openBoM property mechanism. In a nutshell: it is very simple; it’s similar to Excel where you add columns, name them and viola, you have a way to add data.

Properties: public and private

In open BOM we created structured properties that can be added to a BOM in much the same way you add columns to spreadsheet. There are seven supported property types you can choose from when creating a new property in openBoM: Number, Text, List, Multi-Selection list, Reference, Image, Checkbox

Moreover, we have a way to define and reuse these properties. A property can be defined as “Public” such that everyone has access to the “definition” of that property and you can re-use it and add to other BOMs. From that moment on, the property stops being public and access to that particular property definition and information is controlled by the specific BOM it’s in.

A property can be defined as “Private”. In that case, it is defined separately in a property table and can be shared with others. The new property dialog can clone public properties into private for reuse in BOMs.

You can share private property tables with other team members and by doing so re-use properties defined by someone else in the team.

Properties: BOM (instance) and Item

BOM Instance properties and Items properties are a simple mechanism. However, as I’ve learned over the years, they can be confusing. I will explain these using a simple example.

Imagine a CPU and PCB board. When I place a CPU part in the board (BOM), I can specify attributes such as Quantity, Reference Designators, etc. These attributes will be specific for this BOM. At the same time, a CPU Item (defined in part catalog) can have properties that remain the same regardless on the PCB board when this CPU is used.

The first property is a BOM instance properties (some engineers called them “BOM link” properties). The second property in example above is item (part) property. A change of a BOM instance property is reflected ONLY in the specific BOM where it appears. However, a change of an item property will be reflected in all the BOMs where the item is used.

All properties added to a BOM are instance properties. More details, here. To define an Item properties in openBoM, you need to create an Inventory (part catalog) and then add item properties starting with a specific Part Number. You can continue to add more item properties as required.

In addition, you can add Item properties to BOM via ‘Tool -> Add Inventory property’ in a BOM view. A change made in the parts catalog will automatically be reflected in all the BOMs containing those properties.

One final yet important point: inventory properties are optional. If your Bill of Materials is a simple part list, it’s sufficient, i.e., good enough to work with a simple Bill of Materials entity without having define all the item properties. This will save you time and effort. However, if you need to manage Items, then the examples in the videos is how you go about to getting it done via a combination of BOMs and Item properties.

Conclusion. openBOM has a robust yet simple data management mechanism based on property definitions that can be shared and reused by multiple organizations and users. The definition of property tables help to standardize around a specific set of properties that can be shared between teams. In a future property table enhancement, we plan to include a mechanisms to build classifications. I will talk more about that in an upcoming blog post.

Best, Oleg @ openbom.com

PS. We should know each other better. If you live in a Greater Boston, please let’s have a meeting (coffee is on me). If you’re located in other places, let’s have a virtual coffee session — I will figure out how to send you a real coffee for our virtual coffee session.