• 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.
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.
I do not think it is wanted. The conversion may evolve over time. I’m thinking about better measurement tools or error corrections.
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.
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.
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.
It is simpler to keep existing field.
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).
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).
I think invoice should be like sale or purchase. It should have both units.
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.
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.
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).
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.
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).
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…
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.
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.
No because packaging is part of the product itself if the different “packages” variation are not equivalent. Otherwise the packaging information is pointless.
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].