Standard UOM Conversion Factor Table

Ideas, ideas! I am implementing ERPNext in my business, and I think that the UOM table is fantastic. I like the fact that ERPNext supports PER ITEM conversion factors, however I consider that a great addition would be a generic, default table. This way, ERPNext could use the generic conversion factor as priority #1, and where a PER ITEM conversion exists, as is currently the case, use the PER ITEM conversion factor as priority #1. This would allow any conversion factor for a BOM, stock entry, or when entering a purchase receipt.
For example, two units of measure are defined in ERPNext.

  1. “Foot” referring to the English Foot measurement
  2. “Metre” referring to the SI unit.

The conversion table would thus store that a “Foot”, defined in terms of “Metre” is equivalent to 0.3048 Metre
Source: Foot (unit) - Wikipedia

Electrical wire is purchased from supplier, usually, by “Metre”. But the warehouse or field operator requires amount in “Foot” in Material Request (due to cultural and idiosincratyc behavioral habits that die hard, or is impractical to request change). When the purchase order is printed, the measurement is shown in “Metre”, and stated that amount originally was expressed in “Foot”.

The problem is that having a PER ITEM definition forces you to find the conversion factor each time, where some factors would be ideally pre-loaded into the system, with the SI and worldwide standards pre-loaded by ERPNext and the capability to define or customize the units.
The table should also house a URL to the source where the “standard” measure was referred to, for validation purposes.

Any development going on for this? Any ideas as to where to begin setting this up in ERPNext?

On Github, issue #5032

@Tropicalrambler
Currently ERPNext has UOM Conversion for purchase Item, We can Make it for Sales UOM Conversion and Common table for UOM Conversion.

If value does not present in Item Sales/Purchase UOM Conversion table, then we will fetch values from Common UOM Conversion Table.

Do you want to sponsor this feature?

@kolate_sambhaji Sure thing, let us do this. How much do you think it will take, time and moneywise?

Let me know!

1 Like

Hello,

It will take one week development time. $500
We will develop sales uom and this common conversion table.

Thanks,
Sambhaji

jumping on this discussion. Will the design be that you have 3 UOM with a conversion rate in between?

I mean like

(incoming/purchase) UoM x conv. rate = internal UoM x conv. rate = outgoing/sales UoM

by default both conversion rates are ‘1’ (resulting into all 3 UoM’s will be the same)

I furthermore would like to suggest to establish clearly separate terms like

  1. UoP (Unit of Puchase) for incoming UoM
  2. UoM (Unit of Measure) for internal UoM
  3. UoS (Unit of Sales) for outgoing products UoM

the concept of different Units of Measurement is a bit tricky to grasp (especial for people who haven’t dealt with such logic before) and a clear separation and usage of terminology helps immensely to ‘get it’

5 Likes

was this ever done? I’m doing a simple conversion of mm to meter for every chain/string item. Seems silly that this has to be done for every item when it’s a pretty standard conversion.

@Nathan, it never was!

However, I will have some extra cash on hand soon and I will sponsor this feature.

Just to chip in some ideas with a case study:

Company A manufactures mosquito spray aerosol. Below is an example:

  • Procurement dept: Purchases 8 different raw chemicals ingredients in drums (160kg each) to be stored in warehouse.
  • Production dept (chemical mixing): Takes 20kg from each raw chemical drums to mix. The final chemical mixture will be stored in drums (160kg each)
  • Production dept (packaging): Takes 1 drum (160kg) of the chemical mixture to produce 2400 mosquito spray aerosol cans. After these cans are produced, they will be packed into cartons (24 cans)
  • Warehouse: Sometimes when a carton’s packaging broke, the cans inside will be taken out to be stored in loose cans. They will be repacked with other loose cans of the same batch into cartons again.
  • Sales dept: Sells in cartons (24 cans each)

.
.

Department UOMs used
Sales Carton (24 cans)
Warehouse Carton (24 cans)
Loose Cans
Drum
Kg
Production (Packaging) Carton (24 cans)
Loose Cans
Production (Chemical Mixing) Can
Drum
Kg
Procurement Drum
.
.

Seeking advice for best practices in handling such complicated process. Below is a use-case example:

  1. Sales Dept:- receives a large order e.g. 10,000 cartons (equiv. 240,000 cans).

  2. Warehouse Dept:- then checks for any available cartons balance and cans balance.

  3. Warehouse Dept:- after checking, notifies Production Dept-Chemical Mixing to produce the outstanding cans needed.

  4. Production Dept-Chemical Mixing:- checks with Warehouse Dept if there’s any balance of chemical-mixture that are not yet packaged into cans. e.g. 5 drums and 10kg (1/16 of drum)

  5. Production Dept-Chemical Mixing:- If the chemical-mixture is not enough, then the production planning needs to calculate the balance of raw chemicals needed (in kg) for Procurement Dept to purchase raw chemicals.

  6. Procurement Dept:- needs to be able to convert the total no of kg provided by Production Dept-Chemical Mixing into drums to make PO.

The ability of the system to convert between these UOMs is very important especially in the Production Planning tool, BOM and Work Order. This will help in the communication between departments as

  • Sales Dept will only “speak” in cartons and cans,
  • Warehouse Dept “speaks” in cartons, cans, drums and kgs,
  • Procurement Dept speaks in drums only
  • while Production (Chemical Mixing) will be the most complicated one because they will need to be able to “speak” and plan in cartons, cans, drums and kgs.

In other words, when Sales Dept request for e.g. 10,000 cartons, the Production (Chemical Mixing) should already know how much raw chemicals in drums & kgs to produce XX drums of chemical-mixture for Production (Packaging) to package into 240,000 cans / 10,000 cartons.

Good day Raymond,

Have you found a solution to your problem?

Regards,