feat: add piece_count and piece_size fields to BomItem for cut-to-length parts - #12422
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✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #12422 +/- ##
==========================================
- Coverage 86.83% 86.81% -0.03%
==========================================
Files 1449 1450 +1
Lines 96884 96982 +98
Branches 11185 11271 +86
==========================================
+ Hits 84132 84195 +63
- Misses 12688 12723 +35
Partials 64 64
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 |
|
@amanjain57-gif you will need to address the conflict here due to API version updates |
…o-length-parts # Conflicts: # src/backend/InvenTree/InvenTree/api_version.py
|
@SchrodingersGat Conflict resolved — merged latest master. Upstream had taken |
|
Heads up on CI: the only red check is |
|
That pr is already in your branch; I am not sure how a rerun would help |
|
You're right — #12640 is already in the branch from the master merge, so a re-run wouldn't pull in anything new. My mistake referencing it; it also only touched What I actually meant is that the three failures ( I've pushed a fresh commit to trigger a clean run — let's see if they come back green. If you're seeing these as genuinely caused by this PR rather than environmental, I'd appreciate a pointer and I'll dig in; I can't reproduce Firefox E2E reliably locally. |
|
@amanjain57-gif please note that in future I have no interest in a discussion with your AI agent. |
3 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.