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

MartinHBramwell · January 7, 2021, 2:52pm

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

Questions:

Is this expected behaviour?
If so, why does it make sense?
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

WarehousesBefore

Warehouses After

WarehousesAfter

Inventory Before

CofA_InventoryBefore

Inventory After

CofA_InventoryAfter

Costs Before

CofA_CostsBefore

Costs After

CofA_CostsAfter

General Ledger

Guide:

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

Sorry to dump so many images.

peterg · January 7, 2021, 4:29pm

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:

github.com

frappe/erpnext/blob/dbb994238e39252794a0a1a37d68014c32d6d30a/erpnext/stock/doctype/stock_entry/stock_entry.py#L450


		self.update_valuation_rate()
		self.set_total_incoming_outgoing_value()
		self.set_total_amount()


	def set_basic_rate(self, reset_outgoing_rate=True, raise_error_if_no_rate=True):
		"""
			Set rate for outgoing, scrapped and finished items
		"""
		# Set rate for outgoing items
		outgoing_items_cost = self.set_rate_for_outgoing_items(reset_outgoing_rate)
		finished_item_qty = sum([d.transfer_qty for d in self.items if d.is_finished_item])


		# Set basic rate for incoming items
		for d in self.get('items'):
			if d.s_warehouse or d.set_basic_rate_manually: continue


			if d.allow_zero_valuation_rate:
				d.basic_rate = 0.0
			elif d.is_finished_item:
				if self.purpose == "Manufacture":
					d.basic_rate = self.get_basic_rate_for_manufactured_item(finished_item_qty, outgoing_items_cost)

edit: updated link

MartinHBramwell · January 7, 2021, 3:57pm

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?

peterg · January 7, 2021, 4:27pm

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.

JayRam · January 7, 2021, 6:14pm

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.

Thanks

Jay

peterg · January 8, 2021, 3:33am

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.

MartinHBramwell · January 13, 2021, 10:02pm

@peterg, @JayRam

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

I am grateful for the hints so far.

MartinHBramwell · January 16, 2021, 8:56pm

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
-------------------------------------------------------------
                              $10.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?

JayRam · January 17, 2021, 5:26am

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.

Thanks

Jay

peterg · January 17, 2021, 5:43am

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.

JayRam · January 17, 2021, 5:46am

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

Thanks

Jay

JayRam · January 17, 2021, 9:21am

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.

Thanks

Jay

MartinHBramwell · January 18, 2021, 7:04pm

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/stock_entry.py >> 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 …

https://github.com/frappe/erpnext/issues/24385#issuecomment-762235101

MartinHBramwell · January 20, 2021, 3:58pm

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

I was running beta.7 at the time.

JayRam · January 20, 2021, 4:29pm

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

Thanks

Jay

MartinHBramwell · January 20, 2021, 4:31pm

Yup.

I’ll have to pay more attention to that.

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

Questions:

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