Manufacturing issues in Version 11

Hi

I am using a self hosted copy of ERPnext and have some issues since Version 11 with manufacturing operations. To check whether this is limited to my own instance, I checked and found the same issues on the current cloud version at erpnext.com (ERPnext: v11.1.17 (master) Frappe Framework: v11.1.17 (master)):

(A) Material Consumption for Manufacture

This feature was introduced recently to “consume materials for manufacturing of a production order without booking a finished quantity” ( New Stock Entry Purpose: "Material Consumption for Manufacture" · Issue #13368 · frappe/erpnext · GitHub)

Issue (1):

The button “Material Consumption” (see example at Not Found) does not show up.

Issue (2):

When trying to “consume materials for manufacturing” with zero in the “For Quantity” field, an error shows up saying that “For Quantity” is mandatory. This sort of defies the purpose of this type of stock entry, which was created exactly for consumption of material without producing any finished goods.

(B) Manufacturing Settings: “Backflush Raw Materials Based On Material Transferred for Manufacture”

The manual explains: “When creating Manufacture Entry, raw-material items are back-flush based on BOM of production item. If you want raw-material items to be back-flushed based on Material Transfer entry made against that Work Order instead, then you should set Back-flush Raw Materials Based On Material Transferred for Manufacture

This setting does not work anymore since Version 11. Both stock entry types “Manufacture” and “Material Consumption for Manufacture” now always suggest the BOM quantities, and never “transferred quantities”, irrespective of above manufacturing settings.

I have pointed out the latter problem a while ago in December (Version 11 - Backflushing Raw Materials based on Material Transfer - Bug?), and was hoping it would get fixed in one of the regular updates. It really upsets our processes, as we literally have to copy the transferred quantities by pen and paper, and then manual add them to the “Manufacture” stock entry. We would also happily to pay for fixing this issue.

Cheers,

Oliver

1 Like

@OSchauf same issue we are also facing, this issue was resolved a before but again its arrived.

https://github.com/frappe/erpnext/issues/7864

We hope community will resolve this issue on urgent basis.

Not likely. They still have not done anything about Scrap Management for Manufacturing and that has been a reported issue for over 4 years.

Hope you have better luck.

BKM

I have found that if the “Skip Material Transfer to WIP Warehouse” in Works order, is not checked then the “Material Consumption” button does show up. If it is checked then it does not show up.

I have no idea if this is intentional or just an oversight.

Hi Everyone!

We’re using ERP Version 13 and we also have the same issue. how to solve this?

Hello Community,

I am following up on my own post from two years ago (also see my other post on the same issue: Version 11 - Backflushing Raw Materials based on Material Transfer - Bug?). Unfortunately, even three versions down the line, these issues are still not resolved, and we are still using version 10 where the “Backflush Raw Materials Based On Material Transferred for Manufacture” feature is working. However, there are lots of other bugs in that version (especially related to GST), and since it is not supported anymore, all these would never get fixed. On top, such an old version is likely a security risk.

So, now our options are either (a) changing the software or (b) getting this one fixed. As for an alternative software ERPAG supports all our required functionality, but as a new software would require a lot of staff training again.

I would greatly prefer the second (fix it) option, and it’s not that we didn’t try. We hired a Pune developer (which got recommended to us by the Frappe team). They fixed some other issues for us (like the “target warehouse” functionality in the Delivery Note, which would not function with product returns). But despite that was a condition of our order, they told us afterwards that they cannot publish these (rather small) fixes as a pull request and get them merged with the main software. However, that is a very unsatisfactory approach, as after patching ERPnext with our “custom fixes” our system becomes “non-updatable”. And hence we would need to use our own “custom fixes” for every issue coming up afterwards. But that seems just short of having to develop our own software;)

So, my question to the community: can someone recommend us a developer who can (a) fix the manufacturing bugs, and (b) get these fixes merged with the main software via pull request? Requirement (A) seems easy, but we haven’t found anyone yet committing to (B). You may answer here or PM me.

Cheers,

Oliver

I think I have found a work around (I am using v13)
Once the Works Order has been Submitted:

In the Connections section Click on Stock Entry

Choose Create a new Stock Entry in the next page

For Stock Entry Type select Manufacture and then change your selection to Material Consumption for Manufacture (If you select Material Consumption for Manufacture first then you have to manually select the Works Order Number)

Click on Get Items in the BOM section and this will pull in the Items

Once the Stock Entry is Submitted the Consumed Qty will be updated in the Works Order

I have submitted a bug report https://github.com/frappe/erpnext/issues/29006

This has been fixed in [v13.41.1] (Release v13.41.1 · frappe/erpnext · GitHub)

2 Likes

@OSchauf

The problem shows a deeper root cause than what you see at the surface.
ERPNext never intended to solve Process Manufacturing issues and was more interested in solving Discreet manufacturing issues.
But somewhere down the line they (in my opinion) “attempted” to find a work around.

Hence you see the obviously glaring errors where “For Quantity” needs to be entered, even though it doesn’t make sense.

Even in process manufacturing, the BOM quantity should relatively be fixed(but variable) and open to variations in production batch sizes, which here it is not. Such as 500L batch can produce 510 or 490 L with changes in input quantities. Attempts to use the work around is actually more confusing and more of a struggle.

We have been to working to fix this particularly and hopefully a better solution will be available.

J