Production final valuations are the **square** of the # of items produced!?!?!

I have created a simple-as-possible manufacture scenario so as to understand stock and accounting consequences.

In a nutshell to produce 5 litres of finished product (Chemical D):

  • 5 each of 4 raw material items (Labelled bottle and Chemicals A, B & C)
  • Raw materials: $10.48 ($52.40 for 5)
  • Operating costs: $8 ($40.00 for 5)
  • Total: $18:48 ($92.40 for 5)

What I actually see in the Stock Entry generated from the finished Work Order is:

  • Total Incoming Value: $ 302.00
  • Total Outgoing Value: $ 52.40
  • Total Value Difference (Out - In): $ 249.60

The only way I can see to get $302 incoming is by squaring!! the number of items, multiplying by raw materials costs then adding operating costs:

  • 5 x $52.40 = $262
  • $262 + 40 = $302


  1. Is this expected behaviour?
  2. If so, why does it make sense?
  3. If not, what can I have done wrong (am I causing the squaring)?

Work Order Before

Bill of Materials

Stock Entry After

Stock Ledger

Warehouses Before


Warehouses After


Inventory Before


Inventory After


Costs Before


Costs After


General Ledger


  • 4 through 13 create initial stock
  • 14 through 17 create finished good.

Sorry to dump so many images.

More concretely, the incoming valuation is your incoming Qty (5) times your Basic Rate (52.40) plus your Additional Costs (40). In isolation, that’s how it’s supposed to work I think, but the question is why the Basic Rate got defaulted to 52.40 (instead of 10.80 or something else).

The code for setting that value appears to be the bit I’ve linked below:

edit: updated link

So … I’m unsure what your opinion is.
Are you suggesting that that code will help me see:

  • that I have something screwed up in earlier steps that cause the miscalculation OR
  • that there’s a bug in the ERPNext code?

I think the code is doing what it’s supposed to be doing for the most part, except the value it proposes for base_rate in row 5 of your Stock Entry doesn’t make sense to me. It appears to be suggesting a total rate when it should be using a per-item rate. I got the same seemingly-incorrect value when I tested on my system. You could edit it manually before submitting the stock entry, of course, but that’s annoying.

At first glance, the code looks correct, but the finished_item_qty doesn’t seem to be registering correctly for some reason.

1 Like

Please check if you’ve set the valuation rate for Chemical D at some value in the Item Master. If yes, remove the value, make it 0 and try again and things should go through nice and smooth.

You say your raw material cost for the ABC is $10.48 but ERPNext is seeing a valuation of $0.01, $0.02 and $0.03. You may want to fix that too by making revaluing the rate of these checmicals.

Hope this helps.



In my testing, that didn’t fix the issue. For both specified and zero valuation, incoming basic rate is being calculated as a total rate rather than as a per-item rate.

1 Like

@peterg, @JayRam

I have not dropped this, just interrupted by other things for a time.

I am grateful for the hints so far.

The Bill of Materials to create a single unit of Chemical D shows:

Chemical A   - 300ml @ $0.01 = $3.00
Chemical B   - 200ml @ $0.02 = $4.00
Chemical C   - 100ml @ $0.03 = $3.00
Chemical D Label - 1 @ $0.48 = $0.48

If this is incorrect, then I suffer from a fundamental misunderstanding of how a Bill of Materials is meant to be calculated. In what way should I revalue the rate for the chemicals?

No, you are doing great. It was more my understanding of your situation in reading the data you provided.

Now, let’s say you make ItemX 1 Nos (or Bottle), this item has to inherit the valuation of $10.48 And it does unless you have set a valuation rate for ItemX in the Item Master. Or you are loading up deemed Labour, Utilities, Rental or other costs through the Workstation and Operations feature. I’m guessing you must have entered $10.48 someplace else and ERPNext is faithfully taking the $10.48 (valuation of raw materials) and multiplying it by another 10.48 and ergo you see the square.

This part works very predictably on ERPNext, so it’s possible that you’ve not configured it appropriately.

Hope this helps.



I think this is incorrect. I tested on a 100% brand new system, v13-development, and I’m seeing exactly what @MartinHBramwell is describing. The stock entries I generated from a BOM workflow generated a basic_rate equal to total cost (per-unit cost * qty), not per-unit cost. That does not seem correct to me.

Okay, I am yet to test Ver 13. Seems like a bug then. :slight_smile:



Please check if there is different UOMs involved and if the conversion factor in the UOM is what’s resulting in this problem. I was just doing a transaction coincidentally and I almost ended up with this situation.

It’s most likely a bug, but please check if you can.



I created a bug report but forgot to mention it here, sorry,

I tried to compare master branch code with development branch (that I am on) for the /stock/doctype/stock_entry/ >> set_basic_rate() function.

It’s a complete rewrite.

I was wondering how it was possible that such a gross error could get through unit testing … then I looked at the tests …

1 Like

So yes. It is a bug, that was fixed 3 days before I posted this question. :roll_eyes:

I was running beta.7 at the time. :unamused:

1 Like

Cool! That’s why I like to stay one version behind the latest.




I’ll have to pay more attention to that.