search

inventree / InvenTree

Open Source Inventory Management System
https://docs.inventree.org
MIT License
4.27k stars 772 forks source link

[FR] Assembly pricing calculation without consumables #7603

Open dieselburner opened 3 months ago

dieselburner commented 3 months ago

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

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?

Upvote & Fund

Fund with Polar

SchrodingersGat commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

@SchrodingersGat shall I take this up?

SchrodingersGat commented 3 months ago

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

rocheparadox commented 2 months ago

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] commented 1 week ago

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

dieselburner commented 1 day ago

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 commented 1 day ago

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 commented 1 day ago

@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!