1Features
- One canonical record per part: LTC6909HMS#PBF and ltc6909hms/pbf are the same part
- Parametric search typed the way engineers talk — “0402 100k”, “22uf 0805”, any word order
- Stock kept as an event ledger: balances are computed, never stored, so every change can be undone
- Board builds: preview what building N boards consumes, record it, roll it back
- File inventory by content hash — knows which BOMs were imported, changed or went missing
- The importer never drops a row: anything it can't resolve goes to a review queue with the reason
- 204 automated tests, one for every data trap found in real BOM files
2Specifications
- Language
- Python 3.11
- Storage
- SQLite · SQLAlchemy 2
- Import
- .xlsx / .xls
- Search
- Part no. + parametric + fuzzy
- Interface
- Desktop app + CLI
- Tests
- 204
3Figure 1 — Parametric search
4In use
5Description
Parts bought for a board end up spread across dozens of BOM spreadsheets, each spelling the same part a little differently. BUL reads those files into one catalogue, so the everyday questions — have we bought this before, how many are left, what can replace it, which projects used it — take one search.
It is built as a catalogue rather than a list of purchase rows. Every manufacturer part number collapses to one normalised record, and purchases, projects and distributor codes hang off it. Values are pulled out of free-text descriptions into SI units, so “0402 100nF” matches on capacitance and package rather than on spelling, and a part number and parameters can be mixed in one query.
It was built against real files and their traps: Excel turning part numbers into scientific notation or dropping leading zeros, manufacturer BOMs writing 4K7 and 13.3K, a quantity column that meant per-board in one file and per-order in another, a formula multiplied twice. Each trap is detected and flagged rather than guessed at, and each is locked in with a test.