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.