# Uom Conversion Inter category on product
**URL:** https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219
**Category:** Feature
**Tags:** purchasing, sales
**Created:** [March 5, 2019, 10:46am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219 "2019-03-05T10:46:45Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@tbruyere](https://discuss.tryton.org/u/tbruyere)
#### Post date: [March 5, 2019, 10:46am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/1 "2019-03-05T10:46:45Z")
## Rational
**Currently Tryton offers :**
• a storage unit (Default UOM)
• a purchasing unit in the same category as the Purchase UOM
• a sales unit in the same category as the storage unit (Sales UOM)
• a unit price expressed in the storage unit
• a unit conversion mechanism in the same category (intra conversion category)
**Existing situation:**
We manage several hundred steel ball products.
We store the products in UNIT by default.
**On Purchase**
We have the option to use multiple suppliers for the same product.
Some suppliers deliver in KG and others in UNIT,
For suppliers who deliver to us in KG we will need to perform a unit conversion between 2 differents categories (WEIGHT → UNIT)
We therefore need to introduce a concept of inter-category conversion by product when buying (the WEIGHT → UNIT factor is different by product)
**On Sale**
We have the same situation as for the purchase. Customers order us products in UNIT and others in KG.
All moves must be performed in the product’s storage unit (Default UOM)
Purchase and sales invoices must be made in the unit defined with the supplier or the customer.
Note: The concept of inter-category unit conversion for a product should not to be confused with the concept of packaging a product for sale or purchase.
Example: selling a product in 10kg or 25kg bags for a product stored in the KG is not a unit conversion but a definition of a packaging for sale that may be part of the selling price. The concept of unit conversion does not change the price but only the quantity.
## Proposal
- ONETOMANY conversion factors at the product level for a different category unit than the storage unit and one unit per family for conversion.
example: Product A stored in UNIT → added conversion for KG, we can not add a conversion for GRAM. The conversion between KG and GRAM is already present in the WEIGHT category.
- Provide protection against changing conversion factors at the product level. To guarantee a constant conversion factor.
- provide protection against the removal of a conversion factor used in SALE LINE, PURCHASE LINE, MOVE LINE, INVOICE\_LINE
- Extend the unit category range that can be used on the SALE LINE, PURCHASE LINE, and INVOICE LINE models. Resume the category of the storage unit + the categories of the conversion unit of the article.
To avoid having to duplicate all the fields of the line in the different screens, we propose to use the existing fields with the different units. This value is added in the FORM view of the line for information.
What is important for the user is to view the information in the unit defined with the client or the provider (and not the storage unit).
- Create an additional field that represents the quantity of the product in its storage unit using the product conversion factor. This field will be the one used for creating the moves because it is in the storage unit.
- copy the conversion factor on the moves to facilitate the possible recalculation of the quantity or the price expressed in Default UOM
- On the MOVE duplicate the fields QUANTITY, UNIT. Synchronize these fields with an on\_change event.
The shipment must be allowed to express the value shipped to the secondary selling unit and recalculate the quantity in the stock unit.
The MOVE unit domain can not be changed to allow conversion units because it makes it difficult to calculate inventory and cost. Mainly for the treatment of BACKORDER.
example: a sale for 3kg of the product A (stored in UNIT), we can only ship 2KG. It must be possible to modify the shipping MOVE by directly indicating 2KG and recalculate the value in UNIT for the MOVE.
- When creating the INVOICE LINE (Purchase and Sale) take the unit from the PURCHASE or SALE line and use the shipped quantity expressed in this unit.
## Implementation
> **[Add secondary unit (#8239) · Issues · Tryton / Tryton · GitLab](https://foss.heptapod.net/tryton/tryton/-/issues/8239)**
>
> From https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219
---
### Author:  [@dave](https://discuss.tryton.org/u/dave)
#### Post date: [March 5, 2019, 12:14pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/2 "2019-03-05T12:14:15Z")
Is this a similar problem to [Product sold in multiple packagings](https://discuss.tryton.org/t/product-sold-in-multiple-packagings/227)?
---
### Author:  [@maxx](https://discuss.tryton.org/u/maxx)
#### Post date: [March 5, 2019, 12:30pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/3 "2019-03-05T12:30:44Z")
> [@dave](#):
>
> Is this a similar problem to [Product sold in multiple packagings](https://discuss.tryton.org/t/product-sold-in-multiple-packagings/227)?
No, i think it is different (uom category conversion vs packaging)
> [@tbruyere](#):
>
> Note: The concept of inter-category unit conversion for a product should not to be confused with the concept of packaging a product for sale or purchase.
> Example: selling a product in 10kg or 25kg bags for a product stored in the KG is not a unit conversion but a definition of a packaging for sale that may be part of the selling price. The concept of unit conversion does not change the price but only the quantity.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 6, 2019, 4:00pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/4 "2019-03-06T16:00:02Z")
> [@tbruyere](#):
>
> ONETOMANY conversion factors at the product level for a different category unit than the storage unit and one unit per family for conversion.
It will be difficult to manage the unique constraint because the category will not be stored in this model.
I’m wondering if the conversion should not be stored directly in a second unit field instead of a One2Many. I do not see much case where it will be needed to have more than 1 second unit for sale and for supplier.
> [@tbruyere](#):
>
> Provide protection against changing conversion factors at the product level. To guarantee a constant conversion factor.
I do not think it is wanted. The conversion may evolve over time. I’m thinking about better measurement tools or error corrections.
> [@tbruyere](#):
>
> provide protection against the removal of a conversion factor used in SALE LINE, PURCHASE LINE, MOVE LINE, INVOICE\_LINE
Again, I think referential data may evolve over time, it should not be blocked by operational data.
For example, it is possible to change the sale or purchase UoM even if there are orders using it.
> [@tbruyere](#):
>
> To avoid having to duplicate all the fields of the line in the different screens, we propose to use the existing fields with the different units. This value is added in the FORM view of the line for information.
I do not think it is doable. And even, I think it will create too much complex code. I prefer to store a second quantity in a second unit.
Also changing the meaning of the quantity field will make all reporting based on it invalid. It will no more be possible to aggregate the values without expensive unit conversion.
It will also break the unit price computation as it is based on the sale/purchase UoM.
> [@tbruyere](#):
>
> What is important for the user is to view the information in the unit defined with the client or the provider (and not the storage unit).
For me, it is not always the case. If the company choose a particular UoM, it is because it is the best for their business. The second unit is to please customer or supplier.
> [@tbruyere](#):
>
> Create an additional field that represents the quantity of the product in its storage unit using the product conversion factor. This field will be the one used for creating the moves because it is in the storage unit.
It is simpler to keep existing field.
> [@tbruyere](#):
>
> copy the conversion factor on the moves to facilitate the possible recalculation of the quantity or the price expressed in Default UOM
For me, the second unit should only be informational data for the stock. Stock should use the stock unit.
As it is only informational, I think it is better to compute it from it is origin (e.g. sale line or purchase line).
> [@tbruyere](#):
>
> The shipment must be allowed to express the value shipped to the secondary selling unit and recalculate the quantity in the stock unit.
I’m not sure it is desirable because storage unit is or should be the more precise unit for the product. So making the conversion from the second unit may generate imprecision due to rounding (or non-bijection between the two units).
> [@tbruyere](#):
>
> When creating the INVOICE LINE (Purchase and Sale) take the unit from the PURCHASE or SALE line and use the shipped quantity expressed in this unit.
I think invoice should be like sale or purchase. It should have both units.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 6, 2019, 4:08pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/5 "2019-03-06T16:08:15Z")
> [@ced](#):
>
> the conversion should not be stored directly in a second unit field
Also I think there should be a check that ensure the factor/rate and two UoM rounding does not loose precision.
---
### Author:  [@tbruyere](https://discuss.tryton.org/u/tbruyere)
#### Post date: [March 8, 2019, 9:37am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/6 "2019-03-08T09:37:12Z")
> [@ced](#):
>
> I’m wondering if the conversion should not be stored directly in a second unit field instead of a One2Many. I do not see much case where it will be needed to have more than 1 second unit for sale and for supplier.
Do you mean two separate secondary unit and factor/rate for Sale and Purchase or only one secondary Unit by product usable for Sale and Purchase ?
For me one secondary unit is sufficient.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 8, 2019, 9:47am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/7 "2019-03-08T09:47:43Z")
I mean having on the product a secondary sale unit and factor and having on product supplier a secondary purchase unit and factor.
---
### Author:  [@tbruyere](https://discuss.tryton.org/u/tbruyere)
#### Post date: [March 8, 2019, 10:05am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/8 "2019-03-08T10:05:34Z")
> [@ced](#):
>
> I do not think it is doable. And even, I think it will create too much complex code. I prefer to store a second quantity in a second unit.
You need also the unit price in the secondary unit. During the sale, price is negotiated in the unit asked by the customer. In the sale line, the user need to see the unit price in secondary unit. On the report we would like to see the price in the secondary unit.
---
### Author:  [@tbruyere](https://discuss.tryton.org/u/tbruyere)
#### Post date: [March 8, 2019, 10:18am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/9 "2019-03-08T10:18:21Z")
> [@ced](#):
>
> I mean having on the product a secondary sale unit and factor and having on product supplier a secondary purchase unit and factor.
> On product supplier
> Does it mean different secondary unit by supplier ?
We think having a factor/rate on sale and on purchase will be often redundant.
Anyway, how to check is the factor/rate is sync between sale and pruchase ?
Sample : the product is stored in Unit, but we purchase in KG and sell in KG too. The factor is the same for the two secondary unit in sale and purchase (KG in purchase and KG in sale).
---
### Author:  [@tbruyere](https://discuss.tryton.org/u/tbruyere)
#### Post date: [March 8, 2019, 10:22am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/10 "2019-03-08T10:22:30Z")
> [@ced](#):
>
> For me, the second unit should only be informational data for the stock. Stock should use the stock unit.
> As it is only informational, I think it is better to compute it from it is origin (e.g. sale line or purchase line).
Do you think to store the factor/rate on the sale line / purchase line when saving ?
Is factor/rate updated from the product when editing line ?
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 8, 2019, 10:38am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/11 "2019-03-08T10:38:54Z")
> [@tbruyere](#):
>
> You need also the unit price in the secondary unit.
No you do not need. It has the same factor as the unit conversion.
> [@tbruyere](#):
>
> The factor is the same for the two secondary unit in sale and purchase
Not necessary, it depends which factor the supplier uses.
But let’s say that on product supplier, we can leave the factor empty if the second unit is the same as the second unit on the product.
> [@tbruyere](#):
>
> Do you think to store the factor/rate on the sale line / purchase line when saving ?
Yes to avoid issue if the referential data is changed.
> [@tbruyere](#):
>
> Is factor/rate updated from the product when editing line ?
No, it is set only once at creation.
---
### Author:  [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [March 8, 2019, 11:00am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/12 "2019-03-08T11:00:06Z")
We developed the purchase\_information\_uom module [1], which depends on account\_invoice\_information\_uom [2]. The idea was to create the sale\_information\_uom if ever required (we had it in OpenERP).
The idea with these modules is that the new UoM is only necessary as a communication tool (information) with the other party (supplier in this case). So Tryton keeps its current behaviour and the information UoM simply helps encoding or telling the supplier how much amount in their unit we need.
If I understood correctly, I think that’s what Cédric was suggesting.
[1] [https://bitbucket.org/nantic/trytond-purchase\_information\_uom](https://bitbucket.org/nantic/trytond-purchase_information_uom)
[2] [https://bitbucket.org/nantic/trytond-account\_invoice\_information\_uom](https://bitbucket.org/nantic/trytond-account_invoice_information_uom)
---
### Author:  [@maxx](https://discuss.tryton.org/u/maxx)
#### Post date: [March 13, 2019, 1:17pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/13 "2019-03-13T13:17:56Z")
> [@albert](#):
>
> If I understood correctly, I think that’s what Cédric was suggesting.
>
> [1] [https://bitbucket.org/nantic/trytond-purchase\_information\_uom](https://bitbucket.org/nantic/trytond-purchase_information_uom)
> [2] [https://bitbucket.org/nantic/trytond-account\_invoice\_information\_uom](https://bitbucket.org/nantic/trytond-account_invoice_information_uom)
Indeed those modules are very similar to our needs, but we need to extend to sales too.
In this module, it is possible to input purchase unit\_price in the secondary uom (info\_uom) and updating unit\_price. We need this functionality in purchase, sale and invoice. (Purchaser or commercial always need to input negotiated price in the uom used with the customer/supplier).
Unit\_price in the secondary uom on the template product is calculated with the ratio.
Problem with your module is that you “force” to use a secondary uom. User has not the choice to use default uom or secondary uom for the same product. (i mean if you check on the template there is a secondary uom, this uom will always be used for purchase). We need to buy something to a supplier with our default uom or with the secondary uom.. it is the same for the sales and invoices.
So secondary uom should not be a function field but stored on the purchase\_line, sale\_line, invoice\_line (but how to keep always domain valid if we change the secondary unit on the template product).
---
### Author:  [@bala4901](https://discuss.tryton.org/u/bala4901)
#### Post date: [March 16, 2019, 1:10am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/14 "2019-03-16T01:10:39Z")
Hi @maxx,
I had a work around:
Product: steel ball.
Uom category: steel ball.
New uoms: unit, gram, kg
So each unique product for multiple different type of uom has own uom category.
And the price can be set on the pricelist.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 16, 2019, 9:29am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/15 "2019-03-16T09:29:22Z")
I do not think it is a solution that scales. You will have to manage a set of UoM per product as it is highly probable that any set can be reused. This compared to manage a single factor per product…
---
### Author:  [@bala4901](https://discuss.tryton.org/u/bala4901)
#### Post date: [March 17, 2019, 4:18am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/16 "2019-03-17T04:18:45Z")
Yes.. It is workaround but not solution. In fact, current uom method quite hard to maintain a set for reused.
Example:
Product 1: salmon fillet, storage uom: pcs, sale uom: pack = 3pcs
Product2: kitkat, storage uom: pcs, sale uom: pack = 12pcs.
As above example: uom pack, name is same code is same but conversion different. During making new product, the user need to carefully select the uom.
For some cases, my opinion. Uom should tie to product instead of uom category.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 17, 2019, 8:35am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/17 "2019-03-17T08:35:19Z")
> [@bala4901](#):
>
> Example:
> Product 1: salmon fillet, storage uom: pcs, sale uom: pack = 3pcs
>
> Product2: kitkat, storage uom: pcs, sale uom: pack = 12pcs.
If you create such unit, you are using them wrong. If 1 \* 12pcs != 4 \* 3pcs of Product1, it means that you are mixing UoM and packaging.
Normally you never have to create new UoM for unit category.
---
### Author:  [@bala4901](https://discuss.tryton.org/u/bala4901)
#### Post date: [March 17, 2019, 11:53am UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/18 "2019-03-17T11:53:59Z")
ok.. I get what you mean.
If we separated Uom & packaging,
Therefore, sale’s uom, & Purchase’s uom should be unit.
is it necesary, to have the master packaging for product which can extend for sale & purchase.
Such as:
Product 1: Salmon, sale uom: Unit, Sale Packagings: Pack, Box, Pcs
> > Pack = 12 Pcs/unit, Box=24 pcs/unit
currently the packaging in trytond\_packaging, the purpose is for shipment out to use for package tracking.
---
### Author:  [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [March 17, 2019, 12:26pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/19 "2019-03-17T12:26:34Z")
> [@bala4901](#):
>
> Therefore, sale’s uom, & Purchase’s uom should be unit.
> is it necesary, to have the master packaging for product which can extend for sale & purchase.
No because packaging is part of the product itself if the different “packages” variation are not equivalent. Otherwise the packaging information is pointless.
---
### Author:  [@bala4901](https://discuss.tryton.org/u/bala4901)
#### Post date: [March 17, 2019, 3:13pm UTC](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219/20 "2019-03-17T15:13:55Z")
Correct me if I get you wrong.
You mean, I need to create 2 product, as example below:
Product1: salmon, default\_uom: unit
Product2: salmon @12pcs/pack, default\_uom: unit
If this case, my storage unit in warehouse is “salmon”.
Whenever sale created for product2, and shipment out created. Before user can pick for product2, there is an internal move [production] to convert 12 unit product1 to product2[through bom].
[Next page](https://discuss.tryton.org/t/uom-conversion-inter-category-on-product/1219.md?page=2)