Feature to exclude/include consumable price in BOM price range - FR #7603

[rocheparadox]

• A checkbox is added in the BOM panel in parts section to decide if the consumables' price have to be added to the BOM pricing
• A listener is attached to the checkbox to refresh the BOM table data when a change in the checkbox is detected.

[netlify[bot]]

✅ Deploy Preview for inventree-web-pui-preview canceled.

Name	Link
🔨 Latest commit	ac3b2b4afb772d898e28a28bd95a0ab13935b221
🔍 Latest deploy log	https://app.netlify.com/sites/inventree-web-pui-preview/deploys/66ca21ce0be5520008d280da

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.42%. Comparing base (d68d52b) to head (ac3b2b4). Report is 77 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7787      +/-   ##
==========================================
- Coverage   83.48%   77.42%   -6.07%     
==========================================
  Files        1127     1113      -14     
  Lines       50225    58622    +8397     
  Branches     1718     1440     -278     
==========================================
+ Hits        41932    45387    +3455     
- Misses       7855    12858    +5003     
+ Partials      438      377      -61     

Flag	Coverage Δ
backend	85.38% <ø> (+0.14%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[rocheparadox]

@SchrodingersGat , Is there something else to be done from my side to get these changes merged? Thanks.

[SchrodingersGat]

Hi @rocheparadox sorry I have not had a chance to review this yet.

This approach is only going to impact the front-end representation, not the actual calculation (and storing) of BOM pricing. I think that you should:

1. Add new global setting

https://github.com/inventree/InvenTree/blob/e0a878467bb0fe6766ea410a89c9cff8d052faec/src/backend/InvenTree/common/models.py#L1636

Add a new setting to determine if consumable items should be included in pricing

2. Update Calculation

Update the get_bom_price_range method, to optionally include or exclude consumable parts:

https://github.com/inventree/InvenTree/blob/e0a878467bb0fe6766ea410a89c9cff8d052faec/src/backend/InvenTree/part/models.py#L2021

[rocheparadox]

@SchrodingersGat , I will look into it. Thanks for the detailed explanation.

[wolflu05]

maybe it would be also good to get this feature to PUI, because when CUI is dropped, this will be no longer available.

[matmair]

@SchrodingersGat should this target 0.16.0 or can we move it to 0.17.x?

[rocheparadox]

@SchrodingersGat, Would it not be better, from a design standpoint, to provide this option as a part specific local decision? Doesn't adding this as a global setting restrict the users, to the selected option, throughout all BOM calculations? What if the users need to include the consumbale as part of their BOM pricing for one part and want to exclude in another?

[SchrodingersGat]

@rocheparadox maybe - but at the moment our pricing management system does have provision for a "per part" option like this.

We could certainly extend the pricing system, but, it will quickly become complex and everyone will want a slightly different approach...

This is where I think handing such decisions off to a custom pricing plugin system would make more sense.

If you have any ideas or input on how this should go, I'd be interested to hear them!

[rocheparadox]

@SchrodingersGat , I believe that you are mentioning Part.models.PartPricing as the existing pricing management system for the Part.

https://github.com/inventree/InvenTree/blob/70a52c938500f41c817bec8052e35e224b7eea16/src/backend/InvenTree/part/models.py#L2508

Nevertheless, I was thinking about adding a field called include_consumbales to that class and factoring that field in the BOM pricing calculations. However, as you mentioned, pricing itself would vary according to different users and it might be better left as a plugin development option. I am open to implementing either the global setting or this. I think, you know the user requirement better.