[FR] Assembly pricing calculation without consumables

[dieselburner]

Please verify that this feature request has NOT been suggested before.

• [X] I checked and didn't find a similar feature request

Problem statement

I love assembly pricing calculation feature as it precisely shows absolute minimum and maximum of overall assembly cost, depending on component purchase quantities and their price breaks.

However, when looking at assembly price range, it is calculated with consumables. Now, if I add to assembly, let's say, PCB stencil or solder paste, which are consumables, these will be not tracked in build order, which is also a great feature, but the assembly itself will not reflect the right cost anymore. 500g of solder paste I use cost around 150$. And if before a tiny board assembly was 5$ at a minimum and 20$ at a maximum, if I add this solder paste to BOM as consumable, board pricing will show 155$ at a minimum and 170$ at a maximum.

Suggested solution

I would love to see an option to turn on assembly pricing calculation without consumables.

Describe alternatives you've considered

Do not place consumables into BOM?

Examples of other systems

No response

Do you want to develop this?

• [ ] I want to develop this.

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[SchrodingersGat]

We could add a global option to exclude consumable items from BOM pricing calculation, I think this would provide the flexibility you are looking for?

[dieselburner]

We could add a global option to exclude consumable items from BOM pricing calculation, I think this would provide the flexibility you are looking for?

Yes! Thanks!

[SchrodingersGat]

@dieselburner ok, I'll look into it. Currently there's a lot of the developer pile - if you want to support this feature request via the "fund this issue" button above - that would be greatly appreciated :)

[rocheparadox]

@SchrodingersGat shall I take this up?

[SchrodingersGat]

@rocheparadox happy for you to tackle it! An extra setting, allowing "consumable" items to be excluded when performing BOM pricing calculation :)

[rocheparadox]

Based on the suggestions provided by @SchrodingersGat I added a global setting to include/exclude consumables in bom pricing calculation. While working on it, I came across, two different sources for the calculation. I can see that @matmair implemented PartPricing model to hold the pricing related data of a part which contains fields such as bom_cost_min and bom_cost_max.

However, the Part model has a method to calculate the bom price range.

https://github.com/inventree/InvenTree/blob/d1c835485982650dfa4a9c6b51142ab9660584d4/src/backend/InvenTree/part/models.py#L2044

@matmair , Shall I convert this method into a delegator which returns the values of PartPricing.bom_cost_min and PartPricing.bom_cost_max with no deliberate calculation in it?. Also, the global setting that I have implemented affects all the rows of PartPricing model, if changed. So, do we have a hook that gets triggered when a global setting is changed?

[github-actions[bot]]

This issue seems stale. Please react to show this is still important.

[dieselburner]

Closed why? There's a person who looked into this and wanted to implement it, asked a question, no replies, and this FR got closed? Or is this automatic?

[SchrodingersGat]

Issues without activity (and not attached to any milestone) get automatically closed after a period. I guess this one dropped off the radar (apologies @rocheparadox )

[SchrodingersGat]

@rocheparadox if I understand your question correctly, the difference with the get_bom_price_range method is that it attempts to take quantity pricing into account. The idea is that it may be more cost efficient to produce or purchase a part at a higher quantity.

However, this does add another level of complexity to pricing - which is already quite complex and does not capture everyone's (varying) requirements. I have been considering how pricing calculations could potentially be offloaded (or augmented) by plugins to allow greater flexibility. But, I have not had time or inspiration to work this out yet. Input welcome!