inventree
[Feature] Support physical units for BOM lines
Now that we support physical units, this could be included for BOM items also.
If the internal unit for a wire is "metres", the BOM could specify inches / mm / etc
This issue seems stale. Please react to show this is still important.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue seems stale. Please react to show this is still important.
This issue seems stale. Please react to show this is still important.
This issue seems stale. Please react to show this is still important.
Where does this issue stand? This seems like a required/standard feature.
@CWatson-Tactile you are very welcome to fund the issue to push it along :) Developer resources are pretty constrained, there are a lot of open issues. I would certainly like to see this one implemented, and happy to implement it, just it's not at the top of the pile.
Ok, how does funding projects work?
Connor Watson Supply Chain Manager - Tactile Engineering
From: Oliver @.> Sent: Monday, September 23, 2024 8:14:24 PM To: inventree/InvenTree @.> Cc: Connor Watson @.>; Mention @.> Subject: Re: [inventree/InvenTree] [Feature] Support physical units for BOM lines (Issue #4922)
@CWatson-Tactilehttps://github.com/CWatson-Tactile you are very welcome to fund the issue to push it along :) Developer resources are pretty constrained, there are a lot of open issues. I would certainly like to see this one implemented, and happy to implement it, just it's not at the top of the pile.
— Reply to this email directly, view it on GitHubhttps://github.com/inventree/InvenTree/issues/4922#issuecomment-2369822834, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVNU5FB5ZCDDVAW7BTZWJLLZYCVGBAVCNFSM6AAAAAAYSVMKC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRZHAZDEOBTGQ. You are receiving this because you were mentioned.Message ID: @.***>
@CWatson-Tactile we use polar.sh as our funding platform. You can either make a donation against that link, or via the "fund this issue" button (at the top of this page).
@CWatson-Tactile we use polar.sh as our funding platform. You can either make a donation against that link, or via the "fund this issue" button (at the top of this page).
the "Fund this Issue" Butten links to a 404 ERROR Page. i used the link in your reply. the webpage is: polar.sh/inventree/issues
we could realy use this feature. thx for your time
the "Fund this Issue" Butten links to a 404 ERROR Page.
Unfortunately @polarsource removed the "fund this issue" feature (which was very handy!)
We would still welcome support against this issue, either with code or financial support - https://inventree.org/contribute.html
Does the PINT library handle conversions between different units of measurement?
The major categories of measurement include length (meters), mass (grams), volume (cups, fluid ounces, liters), other (counts/qty)...
If sugar is measured in mass (pounds) then would the pint library help with the conversions between different units? For example, if a purchase order shows that an item of sugar is purchased in 4 lb quantities, then the purchase order can display the units in pounds. If the part/stock item is tracked in Kilos (as configured when setting up the part) then the part/item can reference units in Kilos when showing current stock. If a BOM tracks a recipe based on grams of sugar used, then the BOM can use grams as its display unit. As the stock is used to make assemblies (cookies?) the stock page will show the current stock in Kilos.
I don't mind looking deeper into this, but there is potential for large ramifications to how stock is tracked and I'm reluctant to get too deep into this without more discussion first.
In my opinion, it seems like the best course would be to settle on a base unit for each category of measurement for internal use. Each display point would need to track the "display units" for conversion.
Display units would need to be tracked for:
- Each BOM line
- Each purchase order line
- Stock tracking
Would probably also need to figure out how to handle the fractions that would occur. If I have 8lbs of smokeless powder and I use 15 grains worth of powder to assemble a rifle cartridge, I don't want to see my stock of powder displayed as "7.99785714285714..." lbs. (1 lb is 7000 grains).
This method should also handle #10274. Similarly, if a pipe is purchased in a length of 3 meters and I only use 1 inch of it... we need to figure out how we would like to display the remaining qty in the stock page.
Most of these questions have already been solved/answered during past development: we have pretty well-rounded support for UoM for parameters. I think that implementation should serve as the blueprint for this feature.
I would be careful to touch too many mechanisms in one PR, #10274 is a huge undertaking in of itself and has major unsolved challenges. Not sure there is broad enough consensus on the mechanics to develop that one.
Does the PINT library handle conversions between different units of measurement?
Yes, this is already supported for "supplier parts" which are provided in a different (but compatible) UoM from the base part.
Your suggestions above would be best split into multiple feature PRs
One of the changes would be to add a unit of measure attribute to the BomItem model.
The migration here needs to be carefully implemented.
Other models likely affected include but not limited to Part, PartPricing, PartStocktake ... well, basically any part and stock model where quantity is an attribute.
Comparatively, 10274 seems minor compared to this. Ref my recent comment there.
However, this seems more useful to a wider audience in the long run than implementing 10274.