Additional Options for Joint Production Cost Allocation

started a topic about 2 years ago

Currently the only way to evaluate the cost of joint production items is to already know what you're going to sell it for, as both costing methods require you pick a Price Tier in order to calculate its weight distribution. This seems unrealistic for items that are priced based entirely off of production cost. Some more realistic ways of costing many processes in manufacturing are the Quantitative Unit method or the Weighted Average method. They are described in some detail here:

For DEAR, you're already 80% of the way to a happy medium between both of these methods.
It would be really nice if you added a weighted average method to DEAR that allows you to select which processes to apply the weighted average to. That way, by selecting only certain processes to be part of the weighted average, you'd have effectively created the Quantitative Unit method as well.
I'd image it would work by replacing the Sales Value field in the Finished Output section of the Production BOM with a Weight field per output when the new method is selected. Then, each Resources, Component, or Input would have a check box next to it on whether to apply the weight or not. If the weight is not applied to a specific line item, then it's cost would be calculated based on Quantities Produced instead.

As an example, we have Production BoMs in which two products share 90% of their production process and only the last step is different between the two parts. They are always made in tandem, so it doesn't make sense to split the Production BoM at all.

The Production BOM produces 60 of Part A and 12 of Part B. We start with a base component of a metal rod 4.6 inches in length. It is then machined into 5 parts each about .6 inches in length and 1 part that is about 1.6 inches in length. the 5 .6 inch parts will be turned into part A and the 1.6 inch part will be turned into part B. All 6 intermediate parts undergo the next step together.
Up to this point, operation costs from resources should be split 5:1 between parts A and B since for each cycle, those are the ratios of parts produced.

The material costs should be allocated in a more detailed way, namely 3:1.6 (the ratio of material used for each part).
For the final step, the process is different for each part and is represented by a split path in the Production BOM. Each path should be costed to its appropriate part only.
At the end of the day, this math is very similar to the NRV method already implemented in DEAR, but it is costed entirely independent of sales value AND it allows more precise control of variables.

Currently, I work around the issue by manually doing the above costing calculation myself and then entering the result in as a price tier for each resulting product which I then choose as my NRV method Sales Value. It is a very tedious process where I'm doing what DEAR is supposed to do so DEAR can do what it's supposed to do.

  • For those interested in the equation I use to manually calculate, I'll look at my example from above to demonstrate:
    We are producing 5 of Part A for every 1 of Part B. Part A uses .6 inches of base material per part while Part B uses 1.6 inches of base material per part.
    This means for every 4.6 inches of base material, 3 inches should be costed to Part A and 1.6 inches should be costed to Part B.
    Our weights are then 3 for Part A and 1.6 for Part B. I chose to make my weight off of base material used per part because that's what makes the most sense for this. You might choose to weigh it in other ways instead.
    I consider only the base material to be weighted, so everything else will be calculated based on quantity produced.

    I then create two variables for each Part.

    Part A:
    Fractional Quantity A = Quantity Produced A / (Quantity Produced A + Quantity Produced B) = 60 / (60 + 12) = 5/6 = 0.8333

    Fractional Weight A = Weight A / (Weight A + Weight B) = 3 / (3 + 1.6) = 3/4.6 = 0.6522

    Part B:

    Fractional Quantity B = Quantity Produced B / (Quantity Produced A + Quantity Produced B) = 12 / (60 + 12) = 1/6 = 0.1667

    Fractional Weight B = Weight B / (Weight A + Weight B) = 1.6 / (3 + 1.6) = 1.6/4.6 = 0.3478

    I can then use these variables to calculate total cost for each part along with Joint and Separated Costs as explained in this article from DEAR systems under the Net Realizable Value section:

    Part A:

    Total Cost A = Separated Costs A +  (Joint Costs - Raw Material Cost) * FQA + Raw Material Cost * FWA

    Part B:

    Total Cost B = Separated Costs B + (Joint Costs - Raw Material Cost) * FQB + Raw Material Cost * FWB

    Quite simply, you scale the quantity based costs by the Fractional Quantity and the weighted costs by the Fractional Weight and then add any Separated Costs appropriate for the given Part.

    If not only my raw material was weighted as 3:1.6 but also one of my machine processes, then I could add it to the list of things to be multiplied by the Fractional Weight scalar.

    Then the equation might look like this:

    Total Cost = Separated Costs + (Joint Costs - Raw Material Cost - Operation 1 Cost) * FQ + (Raw Material Cost + Operation 1 Cost) * FW

    You can further abstract this setup to follow more complex chains in the same fashion explained in the article above.

    You can also simplify the expression for Total Cost of a Part by creating two new variables and getting rid of Joint Costs:

    Quantitative Costs = (Any Cost not marked to be weighted for the appropriate branch)

    Weighted Costs = (Any Cost marked to be weighted for the appropriate branch)

    Then the final equation is simply:

    Total Cost = Separated Costs + Quantitative Costs * FQ + Weighted Costs * FW

    Again, abstract in whatever fashion you see fit.

    Then of course, the Cost Per Unit is just the Total Cost divided by the Quantity Produced.

    Once I get a cost per unit, I input it into DEAR as a Price Tier and then use the NRV method in the Production BOM and choose the Price Tier with my calculated value.

    The actual value costed by DEAR will often be a few cents lower than your calculated value, my suspicion is that this is due to decimal rounding on DEAR's part to keep the variables manageable (or perhaps the NRV method does some other bit of strange math that introduces the small error), but it's certainly a good enough fix for now.

    DEAR, feel free to use my equations to implement the feature faster. ;)

  • Hello Andrew,

    Thank you for your suggestions. We'll review it and add to our roadmap. 

    Best regards,


Login or Signup to post a comment
Log in or Sign up to post a comment