Users - UoM Conversion Enhancement

[Carl Sopchak]

Hi,

I am helping a Wholesale Lumber company implement OFBiz.  We are both very new
to OFBiz (a month or two since first finding it), and we have UoM conversion
requirements that OFBiz does not seem to handle.  Specifically, we need to
convert between lengths (LF), area, volume (Board Feet = Cu. Ft. * 12), and
weight.

OFBiz can only do simple conversions: to get from A to B, multiply by Z.  But
for wood, the conversion is based on the product:  For example, Lineal Feet
(LF) to Board Feet (BF) for a 2"x4"x6' will be different than for a
2"x6"x10', and it doesn't make sense to set up different UoM's to make the
OFBiz conversions work as we need.  (Customers would wonder what a BF2610 UoM
would be, and there'd be a WHOLE LOT of combinations, I think...)

So, I'm planning on extending the convertUom function as follows (in
pseudo-code):

function convertUom(valueToConvert, fromUomId, toUomId, optional productId) {
  if productId == null {
    productFactor = 1
  } else {
    fromUomTypeId = Uom(fromUomId).uomTypeId
    toUomTypeId = Uom(toUomId).uomTypeId
    if fromUomTypeId == toUomTypeId {
      productFactor = 1
    } else {
      using product(productId) { // save typing
        pLen = .productDepth
        pHt = .productHeight
        pWid = .productWidth
        pWt = .productWeight
      }
      case fromUomTypeId of {
        'LENGTH_MEASURE': fromVal = pLen
        'AREA_MEASURE': fromVal = pLen * pWid
        'VOLUME_MEASURE': fromVal = pLen * pWid * pHt
        'WEIGHT_MEASURE': fromVal = pWt
        *: fromVal = 1  // for Each, primarily
      }
      case toUomTypeId of {
        'LENGTH_MEASURE': toVal = pLen
        'AREA_MEASURE': toVal = pLen * pWid
        'VOLUME_MEASURE': toVal = pLen * pWid * pHt
        'WEIGHT_MEASURE': toVal = pWt
        *: fromVal = 1
      }
      productFactor = toVal / fromVal
  } }

  if found(UomConversion(fromUoM, toUoM)) {
    returnValue = valueToConvert * productFactor *
            UomConversion(fromUoM, toUoM).conversionFactor
  } else {
    if found(UomConversion(toUoM, fromUoM)) {
      returnValue = valueToConvert / productFactor /
              UomConversion(toUoM, fromUoM).conversionFactor
    } else {
      <conversion error>
      returnValue = valueToConvert
  } }
  return returnValue
}

I realize the following points:
- The above function does not take dated conversions into account.  I will be
able to add that logic as well, but didn't want to confuse the issue here.
- Ideally, I should be worrying about the UoM's of the length, width, height,
and weight of the product, and the UoM conversion factor's expectations.  
However, in our case, these will be pretty much standardized (I think - still
working on that), so I hope to get away with not worrying about it.  By doing
so, I can use the standard UomConversion entity, instead of building a new
one.  If I have to, though, I'll add the expected uomId's to the conversion
factor table (new: uomProductConversion, probably) and convert between the
product's UoM and the conversion's expected UoM before calculating the
productFactor.
- I have chosen to only use Length for LENGTH_MEASURE, and only Length times
Width for AREA_MEASURE.  I don't see this as a terribly limiting constraint.  
But, if I have to create the UomProductConversion entity, I may add fields to
define which dimension(s) to use for these.  (Or, I may add a
uomProductConversionTypeId to the Product entity and the new
UomProductConversion (as a key to the later).)
- I will need to find all calls to convertUom and change them to include a
productId, if one is available.  (Suggestions welcome, but find/grep will
probably be what I use to ensure I don't miss anything...)

And now for my questions:
- First and foremost, is my statement about OFBiz not handling these types of
conversion correct?
- Does this function seem reasonable?
- Does the Each UoM (which, from what I can gather, is blank) have a uomTypeId
associated?  I definitely want to be able to convert between individual
pieces and the other UoM's.
- Are there other product-based conversions that others would like to see
(that would be trivial to add to the above <g>)?  I'd be happy to add them...
- And a question on form:  I sent this to both the Users and Dev mailing
lists.  Would have one sufficed?  (Which would have been better?)

Since this will be my first forray into modifying OFBiz, any and all hints /
help / suggestions / comments / words of wisdom / etc. / etc. / etc. would be
MOST appreciated!

Thanks,

Carl
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Leon Torres-2]

That's an interesting idea.

However, I'd like to point out the whole idea of doing conversion with the
UomConversion entity is very clumsy. Right now, all the system can handle is,

   y = ax

Where a is the conversion factor. What about the offset? I can't convert
Fahrenheit to Celsius with this. What about custom conversions like in your
case? There could be weird polynomial conversions, and so on.

Are there any libraries that could help us do the actual conversion so we don't
have to reinvent the wheel here? We really don't need to be doing conversion by
hand in OFBiz.

- Leon


Carl Sopchak wrote:

> Hi,
>
> I am helping a Wholesale Lumber company implement OFBiz.  We are both very new
> to OFBiz (a month or two since first finding it), and we have UoM conversion
> requirements that OFBiz does not seem to handle.  Specifically, we need to
> convert between lengths (LF), area, volume (Board Feet = Cu. Ft. * 12), and
> weight.
>
> OFBiz can only do simple conversions: to get from A to B, multiply by Z.  But
> for wood, the conversion is based on the product:  For example, Lineal Feet
> (LF) to Board Feet (BF) for a 2"x4"x6' will be different than for a
> 2"x6"x10', and it doesn't make sense to set up different UoM's to make the
> OFBiz conversions work as we need.  (Customers would wonder what a BF2610 UoM
> would be, and there'd be a WHOLE LOT of combinations, I think...)
>
> So, I'm planning on extending the convertUom function as follows (in
> pseudo-code):
>
> function convertUom(valueToConvert, fromUomId, toUomId, optional productId) {
>   if productId == null {
>     productFactor = 1
>   } else {
>     fromUomTypeId = Uom(fromUomId).uomTypeId
>     toUomTypeId = Uom(toUomId).uomTypeId
>     if fromUomTypeId == toUomTypeId {
>       productFactor = 1
>     } else {
>       using product(productId) { // save typing
>         pLen = .productDepth
>         pHt = .productHeight
>         pWid = .productWidth
>         pWt = .productWeight
>       }
>       case fromUomTypeId of {
>         'LENGTH_MEASURE': fromVal = pLen
>         'AREA_MEASURE': fromVal = pLen * pWid
>         'VOLUME_MEASURE': fromVal = pLen * pWid * pHt
>         'WEIGHT_MEASURE': fromVal = pWt
>         *: fromVal = 1  // for Each, primarily
>       }
>       case toUomTypeId of {
>         'LENGTH_MEASURE': toVal = pLen
>         'AREA_MEASURE': toVal = pLen * pWid
>         'VOLUME_MEASURE': toVal = pLen * pWid * pHt
>         'WEIGHT_MEASURE': toVal = pWt
>         *: fromVal = 1
>       }
>       productFactor = toVal / fromVal
>   } }
>
>   if found(UomConversion(fromUoM, toUoM)) {
>     returnValue = valueToConvert * productFactor *
>             UomConversion(fromUoM, toUoM).conversionFactor
>   } else {
>     if found(UomConversion(toUoM, fromUoM)) {
>       returnValue = valueToConvert / productFactor /
>               UomConversion(toUoM, fromUoM).conversionFactor
>     } else {
>       <conversion error>
>       returnValue = valueToConvert
>   } }
>   return returnValue
> }
>
> I realize the following points:
> - The above function does not take dated conversions into account.  I will be
> able to add that logic as well, but didn't want to confuse the issue here.
> - Ideally, I should be worrying about the UoM's of the length, width, height,
> and weight of the product, and the UoM conversion factor's expectations.  
> However, in our case, these will be pretty much standardized (I think - still
> working on that), so I hope to get away with not worrying about it.  By doing
> so, I can use the standard UomConversion entity, instead of building a new
> one.  If I have to, though, I'll add the expected uomId's to the conversion
> factor table (new: uomProductConversion, probably) and convert between the
> product's UoM and the conversion's expected UoM before calculating the
> productFactor.
> - I have chosen to only use Length for LENGTH_MEASURE, and only Length times
> Width for AREA_MEASURE.  I don't see this as a terribly limiting constraint.  
> But, if I have to create the UomProductConversion entity, I may add fields to
> define which dimension(s) to use for these.  (Or, I may add a
> uomProductConversionTypeId to the Product entity and the new
> UomProductConversion (as a key to the later).)
> - I will need to find all calls to convertUom and change them to include a
> productId, if one is available.  (Suggestions welcome, but find/grep will
> probably be what I use to ensure I don't miss anything...)
>
> And now for my questions:
> - First and foremost, is my statement about OFBiz not handling these types of
> conversion correct?
> - Does this function seem reasonable?
> - Does the Each UoM (which, from what I can gather, is blank) have a uomTypeId
> associated?  I definitely want to be able to convert between individual
> pieces and the other UoM's.
> - Are there other product-based conversions that others would like to see
> (that would be trivial to add to the above <g>)?  I'd be happy to add them...
> - And a question on form:  I sent this to both the Users and Dev mailing
> lists.  Would have one sufficed?  (Which would have been better?)
>
> Since this will be my first forray into modifying OFBiz, any and all hints /
> help / suggestions / comments / words of wisdom / etc. / etc. / etc. would be
> MOST appreciated!
>
> Thanks,
>
> Carl
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users