Cross UOM categories

Feature
1

Rational

Some uom are a combination of multiple uoms. Defining this combination would allow to calculate a variable depending of the uom categories implied in the combination.
Some examples: Speed = length /time (km/h), Density = weight/volume (Kg/m³) or even existing Tryton uom categories : Surface = length * length , Volume = Surface * length

Proposal

Defining a new model “cross_uom” that would define uom categories “linked” together. Considering uom_category_1 * uom_category_2 = uom_category_result * coefficient(1 by default).
Each uom_category will use by default the base uom.
Combination of the 3 uom_categories would be unique.

  • uom_category_1
  • uom_category_2
  • operation : * or / or …
  • uom_category_result
  • coefficient : default 1

Implementation

2

I think it will be good to define how the API to make conversion will look.

I think this can be achieved by storing in a column the ordered list of the three category ids.

3

I think we need to store which units are used to compute the base unit. For example, in density we use Kg/m3, which mixes Kg and m3.

So if we have a product of 100g, witha a volume of 0.1 liters it does not make sense to expres density as g/liter. We need to convert both units first to kg and m3 and then do the operation between them.

As there are combinations that use division and others multiplication I think we should also store the operation used to produce the combined unit.

4

It is not needed as we already the base unit defined as the unit with factor 1.

5

For “composed” uom, we will have to split to convert from base unit ?
I mean, i’ll create a new uom category “Density”, i’ll add an uom “gr/mm³” and define as base unit.(factor 1). To do calculations with cross uom, i’ll have to split “gr/mm³” in “gr” and "mm³) to apply factor on Weight and Volume following their base unit ?
Or by default, as Density is a cross unit, their will be a base uom which will be base uom from both uom composing cross uom… So Density is Weight/Volume . Default will be Kg/l ?

6

Split what?

No you do not need because the factor will be in the coefficient.

7

And what about rate and factor when defining uom ?
For Density, 1 Kg/l = 1gr/Cm³ … so in cross uom … coefficient will be 1 and i could have multiple uom as base unit in the same category ?
And if i prefer to have a default uom for Density in gr/mm³ , i define this uom with a factor/rate=1 to be the base unit and in cross-uom, coefficient will be 0,001 then.

So method to calculate would be:
def calculate (uom1, value1, uom2, value2):
((uom1.factor * value1) [operation (* or /) ] (uom2.factor * value2)) * coefficient = result in uom3.base
but this calculation should evolve following uom passed in arguments:
A/B = C is standard case, but we could have A,C to find B, so it will be A/C=B and third case with C and B as parameters : C * B = A (operation will be inversed)

8

Yes you can if they express the same quantity.

For me, the API should be:

def convert(value1, uom1, value2, uom2, to_uom):

So you will have the target uom from which you can apply the conversion factor against its base unit.

9

Can’t i use the Unique sql constraint on the three category ids instead of a column ?

10

Then it won’t check against different order.

11

Ok, so it would be:
unique_key = fields.Function(fields.Char(‘Unique Key’), ‘on_change_with_unique_key’)
unique_key_storage = fields.Char(“Unique Key”)

unique_key field would be a join of each uom category id… ex: id1, id2, id3
I add a unique constraint on unique_key_storage. And when saving i update unique_key_storage = unique_key
Is it the good way ? Or too complicated ?

12

I think you do not need to create a Function field unique_key but simply ensure that unique_key_storage is updated on each create and write calls.

1 Like