I’m increasingly coming around to the view that from a system perspective, there is only one UOM and one UOM only. All UOM from a system perspective according to me is Nos. Nothing else!! But from a user perspective, there could be a primary UOM and a secondary UOM, tertiary, etc. Etc.
Often times the system UOM (always Nos as I already said) has a deterministic relationship with the Primary UOM, but many times due to variabilities the primary UOM cannot have a deterministic relationship with the system UOM. Let’s say you are filling bags of wheat and your process has variability and fills anywhere from 4.75 - 5.25 KGS into each bag. But you want to charge not by the bag but by weight. So, the way ERPNext is built right now, you have to use Kgs as the UOM so that you can charge by the Kg. From a reporting perspective you may need to know how many bags you have and the total weight of wheat in those bags.
Textiles, BOPP films (a user has post expressing his challenges on this front), castings, Metals - a whole bunch of industries have these challenges. Some of these challenges may become more pronounced in precious metals industries. Let’s say you make gold earrings. Now you definitely need to track the weight of the earring in addition to the Nos. Else you could lose money.
So my question to the community is: Is it time to reconfigure ERPNext to add these flexibilities?
How many of you (or your clients) would benefit from this reconfiguration? I can think of 3.
Hi. I’m brand-new to ERPNext, but I’ve using and consulting on MS Dynamics AX for 10 years. So I’ll comment based on that experience.
This is both a familiar challenge, and also a familiar request. At least 3 of my clients also need this feature. It’s very common in the Chemical/Biochem industries. You may have Bottles, and these can contain different volumes of liquid. Without consuming a whole bottle/container, you might dispense only a portion of the liquid. Same situation for bags of salt or other loose materials. The lowest inventory UOM could be grams or liters, but the material is often bought, consumed, transferred, or shipped by containers.
This scenario is sometimes referred to as “catch weight”, depending on the industry and situation.
You can think of the containers as individual Lots/Batches, each having a different quantity on-hand. But the handling of this needs to be simple for the users. And you can have multiple containers per product.
Requires some good data modelling, but I’d vote for this as an important function/feature.
Could you please clarify a bit more what you propose as a solution? I think I agree with what you’re saying, but I am not sure I understand how the system would change.
Brian: Welcome to ERPNext. Hope you have a great experience using and implementing ERPNext. Would you please take a look at the manufacturing module enhancement on ERPNext that we are proposing and provide your (MS Dynamics) perspectives? Here’s the link to that post: Manufacturing Module Phase 1 - Signoff on Scope and Let's Execute!
Specific to UOM my other reply to Ben should cover how to implement multiple UOMs.
I’m sure there is another way of going about this, bit here’s what I propose. All items have a system UOM of Nos. We change the system to incorporate this. We also change so that Serial Numbers are tracked for all items by default. In case the user has checked Track Serial Numbers box, the user has the ability to assign serial numbers to the item. Else the system auto assigns serial numbers to the item. Then you have the primary UOM which the user decides. And maybe a Secondary UOM and a tertiary UOM. The user also has to say whether there is a deterministic relationship between the Primary UOM and the other UOMs - yes in some cases - like the weight of a component; No - in other cases - like the weight of a piece of fabric, even though all pieces are, say 1 Square meter, the weight varies because of process variabilities.
So as items are aggregated through transactions, like let’s say dropped into a warehouse, you have the ability to report on any of the UOMs. And because the system keeps a record at the System UOM level it knows that the 35 Nos of Fabric that’s in stock adds up to 18.75 KGS because it is keeping a separate record for the weight of each item, yet it is able to report simply on Primary, Secondary or Tertiary UOMs. Further if you want to pull a piece of fabric that is closest to 0.492 Kg, the system will be able to indicate the serial number of the piece that has that weight. To be able to pull that piece from the warehouse means, of course, that the user has checked track serial number and has pasted the serial number on the items.
So that you can support the Primary, Secondary, Tertiary UoM. I just don’t see how you can do that without the system tracking each item by serial number irrespective of whether the user has ticked the “Track Serial Number” box.
The Serial Number is visible to the user only if the user has checked the “Track Serial Number” box. IN such cases operators have to enter the Serial Number on all stock transactions.
Where the user has not checked “Track Serial Number” box, the system assigns the Serial Number automatically on some logic - Random or FIFO…
If not checked, i think the behavior has to be Not Traking Serial Number …otherwise you’ll be asked to choose a serial number for each can of coke or bottle of water sold …that’s quite a pain …
Agree. So where the user does not want to track serial numbers, the operators are not asked to enter serial numbers into transactions. Maybe there is another System Serial Number field that is completely hidden from the operators. Where the “Track Serial Numbers” box is NOT checked, the system manages in the background without any operator intervention.
The system only asks for the serial numbers, where the user has checked the “Track Serial Numbers” box.
Maybe this is too technical for now and frankly I don’t understand how it will work completely.
But yes, even with this new functionality (should we decide to do this, and find the sponsorships to fund it), the Operators interface with Serial Numbers will remain exactly as it is now.
ERPNext has purchase UOM conversion feature, At Purchase Order you can buy in KG, Gram, Metric Ton and at Purchase Receipt you can convert it into primary stock mom KG.
There are some feature request related to UOM on Github like change rate when UOM is changed.
I think the problem with this is that you would need to use the serial number at all times. If I buy two 10 meter rolls of fabric (and separate serial numbers are assigned), then use 2 meters, the system needs to know which roll I cut it from. Otherwise there is no way to know what each roll has at any given time (which I think is what you are proposing).
I don’t think this type of feature needs to be used in all situations, but I do think that being able to partly reduce the quantity of a serialized item is useful (having a roll of fabric and being able to keep track of how much is left on the roll as opposed to just what I have in stock).
Yeah Brian that’s what I’m getting at. Apologies if this is too confusing, but the fact that you are able to pass an entry means that, irrespective of the UOM of the item you are transacting, you are able to reduce it down to 1 Nos Stock Entry.
Lets say for a Textile application:
How does ERPNext toggle between what management needs (Total textile length in Meters) as against the Operators requirement to pull out the piece that’s closest to 45 Meters.
Right now you have to pick Meters as the UOM and when you do, the operator requires a manual system totally out of ERPNext to be able to ship the length of Fabric that’s closest to 45 meters.
What I’m proposing will help both the management and the operator.
I mean I somehow know instinctively that what I’m proposing makes sense, but I’m unable to articulate it in simpler terms.
Let me try simple again: How do we track two scenarios:
When a primary UOM has a deterministic relationship with a secondary UOM - like say the weight of a MS Bolt.
When a primary UOM does not have a deterministic relationship with the secondary UOM. Like say the weight of a calf (say in livestock trading)
If we can build a model to address both, I think we would have built a whole load of flexibility into ERPNext.
Never mind if this is too complicated. Let’s move on. I will try again, in a few months, to explain this in simpler terms.
I am working in Textile Information Systems for the last 18 years.
I have used a lot of home developed and ready made packages and a mix of them to run this business.
Few months ago , i have started to focus on ERPNext to be used in this industry.
I really great you , you have touched a very good point, which prevented me along the time from using ERPNext in this field.
As a brief of the problem ( and as you and others described)
We create Item (FabricItem_01) with serial enabled. and UoM is Roll (equivalent to Nos)
In production we are generating (or buying from supplier) variable length Rolls, for ex :
- Roll No 001 with total length 67.4 meters.
- Roll No 002 with total length 32.6 meters.
and so on…
Now we have in stock 100 meters and also we have 2 Rolls .
I should be able to sell any of the two Rolls to the customer and invoice him with meters.
Also i should be able to sell x meters out of specific Roll .
I hope i succeeded to clarify , and i am very interested in that point .
1- New Item with item code Fabric_01
- Primary UOM is Meters
- Secondary UOM is Roll or Unit or Nos …
2- Production Produced 500 Meters from Fabric_01
3- Packing (last step in production) will cut this 500 fabric into 4 rolls as below and deliver to warehouses :
- Roll No x with 150 Meters Length
- Roll No x+1 with 100 Meters Length
- Roll No x+2 with 50 Meters Length
- Roll No x+3 with 200 Meters Length
so now in stock we have 500 meters packaged in 4 rolls each roll has its own length.
