Copies that drift apart
Someone duplicates the file to try a change, and from then on there are two truths.
BOM management
A BOM in Excel works fine until there are three of them, with similar names, and none says which revision of which board it belongs to. In XKEMA the bill of materials hangs off the thing it describes, and every line points at a component entered in the library.
| Ref | MPN | Manufacturer | Qty |
|---|---|---|---|
| U1 | STM32F407VGT6 | STMicroelectronics | 1 |
| U4 | TPS62130RGTR | Texas Instruments | 2 |
| U7 | SN65HVD230DR | Texas Instruments | 1 |
| C12–C18 | GRM188R71H104KA93D | Murata | 7 |
| L2 | 744314220 | Würth Elektronik | 1 |
Sample data.
Someone duplicates the file to try a change, and from then on there are two truths.
The same MPN turns up with different spaces, hyphens or suffixes, and stops matching anything.
The list doesn't say which revision it belongs to, so you infer it from the file date.
How XKEMA handles it
It is created inside the board, the PCB or whichever element it describes. You don't have to put the product name in the filename to know what it belongs to, because it is already inside it.
Each line links to a record in the central library: manufacturer, part number, properties, datasheet. It stops being text that everyone types their own way.
Uploading a new BOM doesn't delete the old one — it stores it linked to it. When someone asks which one was bought for the 2021 run, the answer is in the system.
Sample data.
XKEMA doesn't check distributor prices or stock, doesn't warn about obsolescence and doesn't diff two BOMs line by line. It manages the list and its relationship with the product and the components; we don't promise the rest, because it doesn't do it.