As a first step towards ERP functionality, part data needs to be stored. This should be done as two levels, which are as tightly integrated as possible to provide seamless view and editing in the simple case of a single supplier for a part. Additional levels (such as stock) will exist below the part.
- Meta-parts. This is the view that will be most commonly seen. A meta-part requirement may be satisfied by multiple supplier-specific parts. It contains top-level data, such as:
- Part category (RESISTOR, CAPACITOR, etc)
- Package (0603, SOIC-8, SOT-23, etc) <- which may need multiple entries or aliases
- Value
- Tolerance (optional?)
- Other non-core attributes that may be part-specific
- Preview image
- Parts. These are manufacturer-specific, and live under a meta-part. Data includes:
- Supplier part number
- Price (in breaks at different quantities)
- Packaging type (REEL, BULK, TUBE, etc)
- Order quantity multiples or mininums
- Lead time
- Stock. This is stored per part, so that it's possible to derive either a per-meta-part stock level by aggregating child parts, or seeing per-part stock. Should be kept historically and not a simple column in the parts table, to allow burndown projections and re-order dates. But we shouldn't update the stock level every time a part is used or the data will be unmanagable. Perhaps stock is pre-allocated when a production batch is defined, then marked as consumed when the batch is completed?
Outstanding questions:
- Do we need part categories? For example RESISTOR, CAPACITOR, etc. It feels like we should because this is how suppliers divide their product ranges (with sub-categories below those) and systems such as Inventree do it, but I'm not convinced it's necessary. This system won't be used for part selection purposes where you don't know the type of part you're going to use. It'll be used for assigning parts that have already been selected. Provided they can be found by matching on attributes such as package and value, that may be enough. Although part type is typically embedded in BOMs. Hmmmm.
- Do we need a third layer, with suppliers for each manufacturer part number? The same manufacturer SKU may be available from DigiKey, LCSC, Mouser, etc with different stock levels and price breaks.
- How do we store groups / collections of parts so we can track their location, such as reels, bags, etc? If we receive multiple reels of a part in one delivery, we should assign a ULID to each one so that we can determine later if that specific reel is in a machine, in a storage location, etc.
- When a production batch is created and parts are pre-assigned, how are they selected if there are multiple parts that can fulfil the requirement?
- Do we need additional filtering for more stringent requirements, for example a 10K 0603 1% resistor specific in a design could also be met by a 10K 0603 0.5%?
As a first step towards ERP functionality, part data needs to be stored. This should be done as two levels, which are as tightly integrated as possible to provide seamless view and editing in the simple case of a single supplier for a part. Additional levels (such as stock) will exist below the part.
Outstanding questions: