Uom Conversion Inter category on product

[sergyo (Sergio Morillo)]

@albert

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.

In that same way we implemented hard weight uom as information measure for customer/supplier in invoice, sale and purchase [1].
Note that standard UOM’s invoice line is increased automatically along its category in order to preserve amount precision (weight amount == uom amount).

[1] https://bitbucket.org/datalife_sco/trytond-account_invoice_weight

[lukio (Luciano Rossi)]

@albert

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).

I developed sale_information_uom based on purchase_information_uom some time ago. You can check it out.

• https://bitbucket.org/lukio/trytond-sale_information_uom

[ced (Cédric Krier)]

I started to work on this topic: Issue 8238: Allow conversion between UoM of different categories - Tryton issue tracker
But now, I’m wondering how to name modules and how much modules to create. The main issue is that the second UoM is mainly needed on sale and purchase but both will create stock moves and invoices to which a second UoM will be filled. But on the last documents, the same field could be used by sale and purchase.
So if I create two modules sale_second_uom and purchase_second_uom, I will need to create at least one or two modules account_invoice_second_uom and stock_second_uom. But those modules will be useful only if at least one of the first module is activated.
Another option is to create a single module product_second_uom which will depend on stock on account_invoice and extra_depends on purchase and sale to add the second uom conditionally.

[maxx (Maxime Richez)]

My vote is for single module option “product_second_uom”. It is not needed to create multiple modules if there’s extra_depends.

[pokoli (Sergi Almacellas Abellana)]

@ced

Another option is to create a single module product_second_uom which will depend on stock on account_invoice and extra_depends on purchase and sale to add the second uom conditionally.

I think this is the cleaner solution as it will avoid the need to create additional dependencies which will only be useful if one of the first is activated.

Do you think it’s possible to make the product_second_uom module depend only on product and add account_invoice and stock dependency as extra depends?

[ced (Cédric Krier)]

@pokoli

I think this is the cleaner solution as it will avoid the need to create additional dependencies which will only be useful if one of the first is activated.

On a second thought, this module may still lead to the same state as with a account_invoice_second_currency if any purchase or sale is activated.

@pokoli

Do you think it’s possible to make the product_second_uom module depend only on product and add account_invoice and stock dependency as extra depends?

Maybe but I’m wondering if it will not be too much complex for the benefit of reduce from 4 modules to 1.

Also we already have the analytic_* case with similar design.

[ced (Cédric Krier)]

@ced

So if I create two modules sale_second_uom and purchase_second_uom , I will need to create at least one or two modules account_invoice_second_uom and stock_second_uom . But those modules will be useful only if at least one of the first module is activated.

But it has the advantage that for example some setup may need only of sale_second_uom but still use purchase.

[albert (Albert Cervera i Areny)]

@ced

So if I create two modules sale_second_uom and purchase_second_uom , I will need to create at least one or two modules account_invoice_second_uom and stock_second_uom . But those modules will be useful only if at least one of the first module is activated.

But it has the advantage that for example some setup may need only of sale_second_uom but still use purchase .

That’s the reason why we created a separate module. However, maybe it could be a single module and make it configurable. After all, invoices will need those fields anyway.

[pokoli (Sergi Almacellas Abellana)]

@albert

That’s the reason why we created a separate module. However, maybe it could be a single module and make it configurable. After all, invoices will need those fields anyway.

But does it really hurt to have the second UoM fileds on purchase but only use when needed?
For me it’s not a big problem to have the fields available but do not use.

Indeed we have the same issue for companies selling services only, that they have the stock module activated but they do not use.

For me it’s important to reduce the number of modules so we keep the system simple and reduce the maintenance costs.

[sergyo (Sergio Morillo)]

I prefer one module with extras_depend and a good set of tests for each scope (product, sale, purchase and invoice).

[ced (Cédric Krier)]

@pokoli

For me it’s important to reduce the number of modules so we keep the system simple and reduce the maintenance costs.

I think having a single module will increase the complexity because you will need to have a test to detect if purchase or sale in activated.

Also I think it will be good to be able to choose to display secondary unit on stock or not (idem from invoice).
So for me, the 4 modules could not depend on each others.

[ced (Cédric Krier)]

I created Issue 8239: Add secondary unit - Tryton issue tracker with for now sale_secondary_unit and account_invoice_secondary_unit.
As you can see they are not depending on each other which provides a good flexibility of configuration. So for me, it is the right grain of modularity.