Renaming "Unit of Sale"

This change is a little controversial, please read the discussion on bug #400702.

To sum it up, Fabien would like to see UoS renamed to 'Seconda Unit of Measure', but some think it's too vague and confusing.

Numérigraphe 2010-02-10:
My personal opinion is that "unit of sale" is clearer than "secondary unit". It would be useful if users of other ERPs could share their knowledge.
Either way, the shortened terms "UoM" and "UoS" must be removed, because too few people understand them.
Lionel

NaN 2010-02-10:
I know that Raphaël did a new module that adds a REAL secondary unit everywhere. That means being able to add another UoM in stock moves, inventories purchases, sales, etc. So secondary doesn't seem like a good term because that is already implemented in another module. I also personally like UoS better.

Jan Verlaan 2010-02-10
In APICS and other proprietary ERP's always "Unit of Measure" or "Uom" is used. If one wants to differentiate where the Uom is used, put it in front of it like Sales Uom, Purchase Uom, Packaging Uom or Pkg Uom.
In a ERP one would need a Base Unit of Measure that will serve as the base for the whole system. All other Uom's are conversions from the Base Uom. Normally stored in a conversion table, not like we have now in OpenERP in the product file.
You may have a look at the following link http://wiki.sdn.sap.com/wiki/display/SI/Unit+of+Measure+related+settings+in+SAP

ana juaristi 2010-02-10
I totally agree with NAN and mantain my opinion that UoS, on standard OpenERP by now is right like it is. For me is Unit of Sale.
@Jan: You are also right. But... in some ERP I know, just all that fields are specified on form product. Conversion factor between different measure units apply for each product in some cases.
There is unit conversion that could be made by a math formula (fixed) where conversion factor can be specified on a field. But it happens not only in sales but also in purchases and manufacturing (taking materials and producing final product)
This is the case of metals where a piece of known dimensions gives you always a weight, f.e. You could by kg or units, discount units or dm3 ... and so on but rates between measure units are always proportional and defined by a factor, nevermind wherever you use the unit.

But there is another conversions where math formula does not exist (variable)

Imaging simply a taylor.
You need buying a bobbin of fabric. Your supplier gives prices in meters but he send bobins so you define unit of purchase in Bobbins or meters?. Bobbin has got so many meters, but bobbin could haver more or less metters each time. You want to stock on meters, the only way to control exactly variable conversion factor, quantities received and stocked is filling manually both units on receiving and sending (This is exactly what is doing Raphaël's module product_second_uom).

So... For not complexing more... lets say that factor from bobbins to meters is not variable but fixed. Define that you buy in bobbins and stock in meters. You need a secondary measure unit on purchase and conversion factor from bobbin to meters. On Manufacturing. You need making material movement from stock to production. You need defining the discount unit (in this case probably would be meters). Finished product dress would be measured in Units and sold in Units so no UoS required on this case. BOM is making conversion for final product 1 unit dress = Xmeters fabric.

Maybe solution would be many to many field products-factors including type of measure unit so you could buy, sale, stock move and so on on whatever unit defined for that product. Not only fixed to sales, or purchases but having possibility of using different measure unit wherever you need.
Additionally, there should be also possibility of consulting stock in different selected measure unit for each product (Maybe a new combo on product search form, same way you added tarif and location on trunk branch. Let me say that this is a GREAT functionality added on trunk!!! )
Thank you all!!

Raphaël Valyi 2010-02-11:
Guys, that's true, the second unit feature seems all broken in OpenERP 5.x. Actually we and Ana Juaristi never figure out how to reproduce some example from the documentation explaining how to sale with 2 units in the official documentation (look for the word "ham" in the OpenERP book here http://www.scribd.com/doc/17852385/Openerp-Book )
This would be worth a long thread and a bug report, but basically I think this is because the on_change in the sale order/invoice are doing wrong things and as for purchase it was not even implemented properly apparently.
That's why indeed, pressed by the time and because we didn't figured it out right at the beginning it was actually a broken feature, we made that 2nd unit module
https://code.launchpad.net/~akretion-team/+junk/product_second_uom
the spec was from Ana Juaristi here: https://blueprints.launchpad.net/openobject-addons/+spec/stock-movements-in-2-measure-units
(this is actually largely the work of my associate Renato Lima; some people are happy using it in production)
Now, we didn't promote the module at all because aside from lacking of time, we think that a shame we had to do such a hack. Indeed, instead OpenERP should just get fixed so that the existing 2nd unit field be used at least as stated in the doc. Eventually our module just add useful reporting to it as it does, that could be an addons once OpenERP get fixed.
Unfortunately, as you know there are tons of things that are way have a higher priority for 5.2 (like basic accounting, wizards, code cleanup, taxes, rounding, multi-comp) so I didn't want to put yet such an other challenge to Tiny for now...
Also, I had no trust at all this could be fixed in 5.0 without breaking tons of other features. When you see that only minor workflow tweaks at some place result into such awkward changes/bugs side effects https://bugs.launchpad.net/bugs/519034 that's pretty easy to imagine what would be the critical regressions if they try to fix that in 5.0...
So for me, let it be for 5.0, people could eventually use our module as a temporary solution.
As for 5.2 I hope Tiny could tackle it, but again, there are tons of merge with a higher priority already waiting for a bare evaluation so not too sure we can bother Tiny with that at the risk it descopes more important stuff...