Re: Dev - UoM Conversion Enhancement

Posted by David E. Jones on
URL: http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167107.html


I wouldn't say clumsy... very simple though, certainly.

The UomConversion stuff could use some extensions. The offset (to  
handle things like y=ax+b) wouldn't be pretty easy to model with  
another field on the UomConversion entity.

For the conversions between different types of units of measure, that  
certainly does get interesting...

The algorithm you included Carl would probably be best to split into  
2 pieces: one for generic UOM stuff (including going between  
different types with various dimensions and such), and one specific  
to the Product entity that could be built on top of the general stuff.

A lot of the general UOM stuff would probably need to take the form  
of methods specific to certain things. For example: it would be hard  
to create a method (perhaps a service could be done though...) to  
convert from multiple lengths to an area or volume, or from a length  
and area to a volume, or vice versa and such.

Of course, if a library for such things that is of the appropriate  
license and such could be found, that would be great. On the other  
hand, making it configurable (especially from a database) can be a  
little tricky as we've found with other things...

-David


On Mar 8, 2006, at 7:24 PM, Leon Torres wrote:

> 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
>>
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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