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:
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.
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.
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.
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.