feat: add piece_count and piece_size fields to BomItem for cut-to-length parts - #12422
feat: add piece_count and piece_size fields to BomItem for cut-to-length parts#12422amanjain57-gif wants to merge 8 commits into
Conversation
…gth parts Manufacturing BOMs frequently require multiple pieces of a specific size cut from continuous stock (cables, tubing, structural profiles). Currently the only way to express "10 pieces of 250mm cable" is to enter the total length (2.5m) as quantity, which loses the piece-count information that purchasing and production need. This adds two optional fields to BomItem: - piece_count: number of discrete pieces required (default: 1) - piece_size: size/length of each piece (e.g. "250 mm") When piece_size is specified, the total quantity is auto-calculated as piece_count × piece_size, maintaining full backward compatibility (existing items effectively have piece_count=1 and empty piece_size). Changes: - Backend: new model fields, migration, updated recalculate_quantity() logic, hash_fields for BOM validation - API: serializer exposes piece_count and piece_size - Frontend: BOM form includes the new fields, BOM table shows them as optional columns Addresses inventree#10274
✅ Deploy Preview for inventree-web-pui-preview canceled.
|
|
@amanjain57-gif an interesting idea here, thanks for submitting. I think that you can achieve this with a single additional field, not two. If you remove the "piece_size" field and just use quantity, then the additional "piece_count" field can be used to reflect multiple pieces. e.g. a BOM with multiple lengths of wire
Thus the total requirement is 2m of wire, but we can see it is in 10x pieces of 200mm |
SchrodingersGat
left a comment
SchrodingersGat
left a comment
There was a problem hiding this comment.
Reduce to a single additional field as discussed
Remove the piece_size field entirely. The existing quantity field already represents the per-piece size/length, so piece_count multiplied by quantity gives the total material requirement. Example: quantity=200mm, piece_count=10 → total 2m of wire in 10 pieces. Changes: - Remove piece_size model field, serializer field, and frontend column/form - Update migration to only add piece_count - Update get_required_quantity() to multiply by piece_count - Restore original recalculate_quantity() without piece_size logic
|
Thanks for the feedback! Simplified to a single |
|
@amanjain57-gif thanks for the updates. Can you please also add some unit tests here, for (at least) the following:
|
|
You will also need to add comprehensive documentation for the new extension |
|
@SchrodingersGat Working on both requests:
Will push shortly. |
|
Done — pushed unit tests and documentation: Tests added (11 total):
Documentation:
|
|
Fixed |
|
@amanjain57-gif looking good! Please fix:
|
- Bump INVENTREE_API_VERSION to 531 with entry for piece_count field - Add CHANGELOG.md entry under Unreleased > Added - Fix RUF001: replace ambiguous × with x in serializers.py help_text
|
@SchrodingersGat Thanks — all three addressed:
The API Schema check should also resolve now, since the version bump lets the paths filter pick up the API change. |
SchrodingersGat
added
enhancement
|
@amanjain57-gif nice, this is looking pretty clean now |
|
Still need to address outstanding CI failures |
The 0153 AddField recorded help_text with a Unicode multiplication sign (×), while the model field uses plain 'x' after the RUF001 fix. This mismatch made makemigrations --check flag an unstaged 0154_alter_bomitem_piece_count migration, failing the DB test CI jobs. Update the original migration's help_text (and docstring) to plain 'x' so the field definition matches the model, keeping a single clean migration instead of add-then-alter.
|
@SchrodingersGat Fixed the outstanding CI failure. The DB test jobs were failing on the unstaged-migration check: Root cause: migration Since |
Codecov Report❌ Patch coverage is ❌ Your project check has failed because the head coverage (76.67%) is below the target coverage (85.00%). You can increase the head coverage or adjust the target coverage.
Additional details and impacted files@@ Coverage Diff @@
## master #12422 +/- ##
==========================================
- Coverage 83.33% 76.67% -6.66%
==========================================
Files 1441 1446 +5
Lines 95938 108951 +13013
Branches 11165 11165
==========================================
+ Hits 79946 83543 +3597
- Misses 15925 25341 +9416
Partials 67 67
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
BomItem.quantity is a derived field, recalculated from raw_amount on every save() via recalculate_quantity(). Setting item.quantity directly was overwritten back to the fixture value on save, so the tests computed against quantity=3 and failed. Use set_quantity() (which sets raw_amount) to match how quantity is meant to be updated.
|
Fixed the 5 failing Switched them to |
2 participants
Summary
Addresses #10274
Manufacturing BOMs frequently require multiple pieces of a specific size cut from continuous stock (cables, tubing,
structural profiles). Currently the only way to express "10 pieces of 250mm cable" is to enter the total length (2.5m)
as quantity, which loses the piece-count information that purchasing and production need.
Changes
Adds two optional fields to BomItem:
When
piece_sizeis specified, the total quantity is auto-calculated aspiece_count × piece_size, maintaining fullbackward compatibility (existing items effectively have piece_count=1 and empty piece_size).
Backend
recalculate_quantity()to compute total from piece_count × piece_size when piece_size is setAPI
piece_countandpiece_sizefieldsFrontend
Example
A BOM line for "10 pieces of 250mm aluminum profile" (part units: m):
This preserves the per-piece information for production while correctly computing total material requirement for
purchasing.