Very simple. ERPNext is working the way it was designed. So there is nothing to worry about. I’m guessing you are updating the Valuation Rate in the item master as $1. Take that off. Or make the valuation rate as $100.00.
If you remove the valuation rate for the manufactured item in the item master, just open up the Stock Entry for item in the Stock Entry manufactured and put in a value of $100.00 and you will be okay.
More detailed explanation:
In any entry, you have to balance both sides. You are consuming up raw material worth $500 to manufacture items worth $500. However you are putting in the valuation rate of the item as $5.
So your total incoming (consumed) material is worth $500. But your total outgoing (manufactured) material is worth $5. So the difference account (default is Stock Adjustment Account) is getting charged $495.00 to balance the books.
I agree. It used to do that automatically before but with some change in perpetual accounting (or maybe I’m mixing up terms here), you have to do this now. The big problem is the first time you manufacture an item, so there is no valuation rate in the stock balance/ledger. That’s when it looks for the valuation rate in the item master.
So in this particular case it takes, Total Incoming Rate: $500, total out going rate: $5 so difference account gets charged for $495.00.
But let’s say the outgoing rate is changed manually to $100, so the Incoming and Outgoing rates are balanced out and the difference account is not charged. And a history of valuation rate of $100.00 is built for this item.
Now next time, let’s say you manage to source the raw material at $480 (it was $500 for 5 items before) the total outgoing material rate is $480, the total incoming material rate is $500 and $20 gets charged to the stock adjustment account.
So the stock adjustment account entries give you an indication whether you are consistently going above or below cost, if you handle it well.
I’m sure with a bit of custom scripting, we can restore the balance where the valuation rate of the manufactured item is the derived value of the rates of the input item.
Maybe we should re-look the manufacturing entry and build the functionality to manufacture multiple items (could be by-products, scrap, optimization approaches - think nesting) from a given set of raw materials and define the valuation rate for each item. This will mean changes to the BOM and the Stock Entry.
You guys game? I’m happy to get involved and provide Business/System Analyst contributions, testing contributions and maybe 25% of the development contributions.
I just get the feeling this is headed off on a tangent that is not really the source of the problem.
Don’t get me wrong. I do believe that Manufacturing is due for a major revamping, but I see this particular approach as only adding to the mess that is the Manufacturing module. When in reality this appears to be an accounting function gone wrong.
For example. An Item should be able to be created in the Items list as a ‘manufactured’ item and without a set value (because none should exist before the first manufacturing production order). Instead of a value in the field, there should be a check box that is set to hold the item value as blank (not 0.00, but really blank) until the completion of the first production order and transfer to stock. At that point the stock transfer from the manufacturing location should trigger the updating of the valuation rate of the item in the Item record and the accounting ledger.
Subsequent production runs would then update that number as normally should happen.
The original problem is not one of the manufacturing module, it belongs firmly in the Accounting module related to how items are valued. Most of this function already works when dealing with purchasing items that go up and down in price with each purchase. It just has to be expanded to allow for manufacturing items as well.
I would much prefer to place blame where it belongs so that we do not waste effort on further messing up manufacturing.
Having manufacturing item valuation rate go up and down is not a good idea. The right costing method erpnext should follow is standard costing (SAP use this method by default). If any developer have plan to revamp the manufacturing module, I and my boss are willingly provide feedback on this.
If you manufacture a BOM. The cost should always = cost of raw materials (unless your company is running Standard Cost valuation method)
You should not have to enter a valuation on the FG. Why would you do that? You should not have to tell the erp the value.
It should calculate the value of the FG, based on the cost of materials.
Or…if you’re using Standard Cost, it should fetch the standard cost price from the Item record.
You should not have to perform a Stock Entry, or Stock Reconciliation, or perform any manual effort. Again, the FG value should be calculated automatically.
If ERPNext is working as designed? Then it’s an unusable design, in my opinion.
I don’t have any manufacturing customers. Yet. But if I ever expect to have one? This will have to be fixed. Because they won’t use ERPNext if it works this way. Manufacturing in the USA is already very challenging, even when there is a great manufacturing module.
I understand the point @bkm makes. We cannot further mess up manufacturing.
So. At this point, my suggestion is we write a brand-new manufacturing App from scratch. Don’t even touch the current one. Write a standalone replacement. And when it’s mature enough, we can try to convince the community to replace the current one in the Core.
That is exactly what I am saying in my post above.
The only way for the cost of the finished goods to equal the cost of raw materials, is for it to get updated with each production run. Your raw materials are already brought in each time you do a production order.
So, as long as you can create an item in the Item database without a cost value and mark is as a manufactured item, then the existing calculations will already work like they do for items you purchase.
The problem is that you cannot create an Item with a blank valuation field. There needs to be a way to do that and then mark the Item to get is new value each time it is manufactured. But until you make your first production order it should remain blank. Currently when you make zero, Then it doesn’t get updated by the production order because there is no mechanism to do so.
In my opinions, since the problem here is accounting entry, we can try avoid messing manufacturing module by making a stand alone Manufacturing Stock Entry doctype that is not related to the current Stock Entry. Then End User can have option to whether using this new doctype or not?
Actually, @bkm has done quite a bit of Manufacturing flogging in previous months/years. He’s not the only one. @jayram has been actively interested in manufacturing changes for a long time.
The challenge? The same with many other ERPNext initiatives, such as Documentation. Accounting improvements. Intercompany. Email capabilities.
We need volunteers to write detailed specifications on how a Manufacturing module should work. Including mock-ups of screens, GL postings, configurations, etc.
There is no point in writing even 1 line of code, until there’s a design. Otherwise, you’re just making stuff up as you go.
We need volunteers to develop the replacement code and/or changes.
This is normally where we get stuck. There is a shortage of ERPNext developers. This is not an ERPNext-only phenomena. During the early days of my previous ERP platform, we also experienced a huge shortage of developers.
We need volunteers to perform robust testing, including regression testing of all the modules.
This is just as important as the development. There’s no way the developers will get everything correct on the 1st, 2nd, or even 3rd revisions. It’s critical that testers try to make/break everything that was built.
Once we can figure out how to actually do Steps 1, 2, and 3, instead of just talking about them?
Manufacturing might not be everyones cup of tea, but I assume the 4/5 people here are interested.
@bkm@JayRam@mkhoa94@brian_pond do you think we are enough to give this a go? Am a chartered accountant with pretty good knowledge of cost accounting and I have access to a programmer (who insists on getting paid, the devil).