[FR] Support Actual Cost of Build Outputs based on Cost of Parts

[cjdet]

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

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

Problem statement

When creating a build order to assemble parts with purchase cost data, the cost of the assembled output is not the sum of the cost of the parts. Instead a BOM range is used in the "stock value" for the output. This does not allow accurate tracking of the value of inventory we have, which fundamentally breaks the ability to use InvenTree as part of the accounting side of inventory management.

Here is a simple example to show how this can cause significant errors in the calculated "stock value" versions the actual value in stock:

Let’s say we just have two parts:

• C1: is a component that we purchase from a vendor
• A1: is an assembly that is just composed of one C1
  Purchase 10x C1 at $10 each
• We have paid $100 and our stock value accurately reflects this at $100
  Build 5x A1s
• We now have 5x C1s and 5x A1s and our stock value accurately reflects our overall inventory of $100
  Buy another C1 at $100 (say we needed a part real fast, so high cost)
• Now we have $200 in inventory
• The original 5 C1s that remain are still priced at $10 each ($50 total)
• The new 1 C1 is priced at $100 ($100 total)
• However, the A1s we built from the $10 C1s no longer say they are just $10 each, instead their stock value is listed as $10-$100 each.
  So our overall inventory is:
• $50 from original C1s
• $100 from new C1
• $50-$500 from old A1s
  Total: $200-$650

With this very simple example you could just say take the low end, but that doesn’t work in more complex examples. Using stock item pricing age can help in some cases, but not others.

My company would likely be willing to support some of this development since right now this is creating significant overhead in accounting for what the value of our stock is.

Suggested solution

When build outputs are created from a build order, the cost of the assembled stock items should be the sum of all the stock items used.

Describe alternatives you've considered

Using "Stock Item Pricing Age" can help in some cases, but does not work well overall to solve this problem since some parts we have get turned over quickly, while others only transition slowly and can have significant cost changes.

It makes sense that when looking at a part that the BOM price range will used to give a sense of the overall price of making a part. However, when a build order is completed the newly built part has a very specific cost based on the exact cost of the stock that was allocated to build the new part.

Right now the solution involves either a lot of additional spreadsheets or we have to manually assign costs to assemblies.

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.

[LavissaWoW]

I've been meeting similar questions from my own management.
I do think the pre-requisites are present for this to be easy to implement.

Sure, InvenTree isn't an accounting tool. And half-assing one is worse than not having one.
But I do agree that it wouldn't be a bad idea to populate the purchase_price field for a build Output, basing the cost on the actual costs of the stock items used.

Doing this will also yield more accurate tracking of increasing production costs, as the price range of a given part will be based on the actual production cost, not just the projected future cost.

[SchrodingersGat]

@cjdet your suggestion is a good one. There is another similar issue floating around which raises the same idea, however I can't find it right now (the curse of having > 200 open issues and only a handful of active developers).

I have been pondering on this one, I think it calls for an extension of the existing pricing system:

• Allow individual stock items (i.e. build outputs) to have a more generic "unit cost" field (which is sourced from a purchase order, or build order, or manual input)
• Allow unit cost to be generated from a build order by looking at the sum of component items which were consumed
• Expose pricing to the plugin system and allow plugins to augment these calculated values

Further ideas / discussions welcome. One additional consideration is for things like labour costs, and additional "costs to build" which are not part of the Bill of Materials

[cjdet]

Thanks for the consideration and feedback. I searched a whole bunch of FRs and Bugs and didn't find anything along these lines, but I'm sure there are other related ones. Here are some additional thoughts:

• I agree that a basic propagation to purchase_price would be straight forward, however, it does raise the question of what to do if one of the sub-components does not have a purchase_price.
  • It would be nice if there were a warning either when allocating stock or before completing the build output, which would require a bit more effort to implement this and adds complexity. This might be the ideal option as it makes the user think about what they want to do.
  • It could default to using "stock value" if purchase_price is unavailable, but then it does raise the question of which end of the range to select. So probably this just adds unneeded complexity.
  • The simplest would be to just use zero. I think this is reasonable at least as a first past.
• Adding "unit cost" would make a lot of sense.
  • In addition to adding labor costs, this would be an opportunity to add shipping costs as well. If this is the route, it would be great to be able to add line items for these things to purchase orders as well and have them automatically spread across the unit cost. We add shipping costs manually right now during purchase orders. This is related to #3928 which requests this as well.
  • While this is probably the best way to do it, if this revamp of the pricing system isn't going to happen soon, then I'd say it would be better to just use purchase_price for storing this for assemblies since it is still flagged as something assembled to differentiate from something just purchased.

While InvenTree certainly isn't an accounting system, it is tightly tied to accounting since at least in the US you can't deduct cost of goods sold until the inventory goes out the door. So knowing how much the parts of an assembly you just sold cost is very important. Regardless, InvenTree has really streamlined out inventory management and build proces, thanks!

[SchrodingersGat]

@cjdet given the vast quantity of outstanding issues, this concept (while important, and I support it) is getting added to a very big pile of things to do.. Our development team is very under resourced unfortunately.

If your comapny is willing to fund this issue, or even contribute code I'd be happy to discuss further!

[matmair]

I expect whoever adds this functionality to commit to maintaining it, I guarantee I will neither handle bug reports, fixes, reviews or code quality for it.
And I expect the person to write documentation that ensures InvenTree is not mistaken for an accounting system, driving some small businesses into the ground come tax time.

[cjdet]

@SchrodingersGat we would certainly be willing to talk about funding this or contributing code. Would you be open to just propagating purchase_price into the purchase_price of the assembly? If so that could be a straightforward PR that we could probably do. If it is revamping to add unit_cost, that would require a lot more in-depth knowledge.