I have extensive experience dealing with this while implementing Oracle e-Business R12. Interested to contribute on this feature but it may be too early as i am yet to fully learn the development in frappe/erpnext. In my experience its a big deal feature for any ERP to have and its been adopted in many of legacy ERP solutions as well. Especially in process manufacturing industries.
The feature has been requested so many times but without actual contributors (i am a frontend dev + a project / product manager), if you would like to contribute you can open a github issue and start from there
I have a client with very similar requirements and needs.
In a smaller project, I would agree with submitting a GitHub issue. However, ERPNext currently has over 2,600 open issues on GitHub. The oldest is from year 2013. I’m sure there’s already something in those talking about dual UOM. Assuming I’m wrong, would new issue #2601 be reviewed? Worked on?
Dual UOM isn’t extremely difficult. But it is rather intrusive:
It requires modifying many DocType tables. Purchase Order Items. Purchase Receipt Items. Sales Order Items. Sales Receipt Items. Stock Adjustments. Stock Levels. Lots more.
It requires modifying several DocType UI’s.
Many ERPNext users won’t want this modification, and the extra “clutter” on their screens. It’s already challenging to display relevant information in a clean, readable way. So ideally this Dual UOM feature should be something we can enable/disable.
There will need to be various Python functions for doing all the conversions and calculations.
In summary: a rather large quantity of code changes. A rather large Pull Request.
My impression is the current Maintainers would not feel comfortable merging something of this magnitude. How to convince them or collaborate with them? I do not know.
Until the project figures out how to collaborate at this scale, I’ve just been maintaining my own fork of various modifications. Whenever a new Major Version is released, I spend time upgrading and applying those modifications to the new code base.
I agree with what brian has said its very intrusive but not extremely difficult but without this feature we may hit the wall while implementing the system in process manufacturing industry. It is a must for example in textile industries (yarn , fabric etc.). So some effort is required on this aspect in near future. It can really lift ERPNext to another level if this feature is incorporated.
We need to show 2 columns everywhere.
(Item master, PO, SO, inventory, production order etc ).
They are 1. Secondary unit qty, 2. Secondary UOM. These 2 columns can be shown/hidden based on company/warehouse level settings.
Welcome to ERPNext. Hope you have a great experience with ERPNext and here on the community.
It’s possible to build this with a bit of scripting. However, that will mean that you will need to make the item a batched item and that has other overheads on the shopfloor - like users will need to key in the batch number for every stock transaction.
The Stock in each UOM can be built into the Batchwise Balance report.
Suppose i have purchased (Metal Sheet) in “Kgs” and i have to maintain its stock in “Nos”. I have put conversion factor and that is calculating my Stock UOM in fractions but i want this to be whole number.
Are you willing to turn on Serial Numbers or Batch Numbers for your Sheets? If yes, you can make the Primary UOM Sheet and make that a Whole Number and using a bit of scripting you can write the weight into a custom field in the Serial Number or Batch Number document.
Turning on Serial Numbers and Batch Numbers is a Huge Overhead and it is not always practical to do this.
The simplest solution is that you maintain the Primary UOM in Sheets and don’t add a secondary UOM into the Item Master but use Kgs in transactions and enter the Kgs that you are making the transactions for.
A even simpler solution is not to worry about the secondary UOM at all. Just add custom fields in each of the Stock Transaction documents at the Item level. Call it “Rate in Kgs” and “Weight in Kgs” and when your users enter those values, they get a rate that they can enter into the actual rate field of the document. Like a sheet is 30.5 Kgs and another Sheet is 29.8 Kgs and the rate is $1, then the rate of the First Sheet that is entered by the user is $30.5 and the second is $29.8 and the two together will be (30.5+29.8)/2 = 30.15 and 2 Sheets.
The Simple solutions means that you will need to weigh the sheets every time the sheets are outbound or inbound from/to your company to/from the outside world. Though you may not need to weigh every time you transfer internally.
With the Batch Number Tracking (You will have to have a separate batch for each Sheet) or Serial Number Tracking approach, you will need to weigh only when you receive the item and this weight can be reported in transactions whenever you want it reported and can be used to calculate the rate by using appropriate scripting.
Like I said it’s not easy managing these weight variability on a structured data system such as ERPNext, so you have to make appropriate investments and/or make appropriate compromises.
My use case is like this:
I have bought items in Kgs UoM, say i have bought (For Eg.- X-Sheet) in Kgs (say 15.83 Kg), in item master apart from Nos i have added one more UoM Kg and taken its value as (1/15.83 = 0.0631711939355).
Now in Purchase Order when i select X-Sheet and taken Quantity in Kgs and UoM also as Kgs,
Stock UoM is coming in fraction but i want to take this as a Whole Number.
I am following this way because it is required in Purchase Order Print Format.
I am not using Serial Number and Batch Number.
Try taking off the Kgs UOM in the Item Master and the conversion factor and in the transaction try use UOM Kgs, enter the quantity in Kg and then manually calculate and key in the conversion factor so that the quantity is an integer (1, 2, 3, etc.). If you end up having round off errors, you will have to replace the item with a new Item with UOM say Pieces and turn on Must be Whole Number in the UOM record. You will then have to manage the conversion factor as that it gets as close to an integer (or Whole Number) as possible.
I know this is not an elegant solution, but I still do think you should take off the UOM from the Item Master, add a custom field in the transaction to capture quantity in Kgs and manually calculate and key in the Rate per Piece to reflect the Cost of that sheet. Like I said, 1 Sheet - 30.5 Kgs $1/Kg - translates to $30.5 per Sheet for this sheet.