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

[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
>

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

[David E. Jones]

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

[Adrian Crum]

I would like to be involved in this work, since our industry is related to
Carl's and our UOM conversions are the same.

How about a field in the table (ie: UOM conversion type) that points to a UOM
conversion entry in an XML file. The conversion entry in the XML file lists
calculation services to be called for that particular conversion. The UOM
conversion service takes the UOM conversion type, looks it up in the XML file,
then calls each calculation service listed.


David E. Jones wrote:

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

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

[Carl Sopchak]

Thanks to all for the input.

I personally think that taking it a step at a time - as needed - is not
necessarily a bad way to go.  And my client's checkbook agrees <GRIN>.  I do
NOT want to get into all possible conversions that could pop up, but I'm not
opposed to making the logic extendable, either.  (I am a firm believer of the
K.I.S.S. principal, though!)

I should clarify that the conversion as I have proposed is not based on adding
productId as a key to the UomConversion file (or passing multiple values to
the convertUom function).  The conversion uses values from the product that
is being converted, but the conversion process is not product-specific.  (For
example LF to BF, regardless of product, is L x W x H / 12, but you need to
know which product to get L, W, and H.)  So, David, I am only proposing the
first part of your two-part change (if I'm reading your comments right).

I would need more detail on the "XML pointing to service(s)" idea that Adrian
describes, as it is not clear how it would work in my situation (same
calculations, but product-value related) or how the services would know what
values to use (i.e., product related, or xxx related?).  Also, on the
surface, it seems like a more intrusive mod than my simple replacement of the
convertUom function.

Adrian, does what I propose handle the conversions that you are looking for?  
Do some of my limitations pose a problem for you?  Do you have any questions
on how I envision this working?  Are there other issues that you have run
across in OFBiz pertaining to lumber that we can colaborate on?  Feel free to
email me directly if you would like to discuss OFBiz/Lumber.

Does anyone else have an IMMEDIATE need for UoM conversion extensions that we
should consider in designing our solution?  Like I said, I don't mind
designing in more flexibility, as long as it doesn't turn a relatively simple
mod into a 6 month project.

I should be getting more details from my client tomorrow, so I may have to
rethink some of this anyway.

Should I put this in the jira, to make it an "official" mod?  We do plan on
giving the mod back to the community.  I'd be happy to take the lead on the
change, and coordinate efforts with anyone else willing to help (Adrian,
others?).

Any and all feedback welcome.

Carl


On Thursday, March 09, 2006 11:31, Adrian Crum wrote:

> I would like to be involved in this work, since our industry is related to
> Carl's and our UOM conversions are the same.
>
> How about a field in the table (ie: UOM conversion type) that points to a
> UOM conversion entry in an XML file. The conversion entry in the XML file
> lists calculation services to be called for that particular conversion. The
> UOM conversion service takes the UOM conversion type, looks it up in the
> XML file, then calls each calculation service listed.
>
> David E. Jones wrote:
> > 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
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Si Chen-2]

JIRA's always a good tool.

Another suggestion I had was to make uom conversion "pluggable."  We can
expand the UomConversion or UomConversionDated field to have a
"serviceName"  If serviceName != null then put all the parameters in and
run that service and return its results.  Then you can write whatever
conversion you need.

Si

Carl Sopchak wrote:

>Thanks to all for the input.
>
>I personally think that taking it a step at a time - as needed - is not
>necessarily a bad way to go.  And my client's checkbook agrees <GRIN>.  I do
>NOT want to get into all possible conversions that could pop up, but I'm not
>opposed to making the logic extendable, either.  (I am a firm believer of the
>K.I.S.S. principal, though!)
>
>I should clarify that the conversion as I have proposed is not based on adding
>productId as a key to the UomConversion file (or passing multiple values to
>the convertUom function).  The conversion uses values from the product that
>is being converted, but the conversion process is not product-specific.  (For
>example LF to BF, regardless of product, is L x W x H / 12, but you need to
>know which product to get L, W, and H.)  So, David, I am only proposing the
>first part of your two-part change (if I'm reading your comments right).
>
>I would need more detail on the "XML pointing to service(s)" idea that Adrian
>describes, as it is not clear how it would work in my situation (same
>calculations, but product-value related) or how the services would know what
>values to use (i.e., product related, or xxx related?).  Also, on the
>surface, it seems like a more intrusive mod than my simple replacement of the
>convertUom function.
>
>Adrian, does what I propose handle the conversions that you are looking for?  
>Do some of my limitations pose a problem for you?  Do you have any questions
>on how I envision this working?  Are there other issues that you have run
>across in OFBiz pertaining to lumber that we can colaborate on?  Feel free to
>email me directly if you would like to discuss OFBiz/Lumber.
>
>Does anyone else have an IMMEDIATE need for UoM conversion extensions that we
>should consider in designing our solution?  Like I said, I don't mind
>designing in more flexibility, as long as it doesn't turn a relatively simple
>mod into a 6 month project.
>
>I should be getting more details from my client tomorrow, so I may have to
>rethink some of this anyway.
>
>Should I put this in the jira, to make it an "official" mod?  We do plan on
>giving the mod back to the community.  I'd be happy to take the lead on the
>change, and coordinate efforts with anyone else willing to help (Adrian,
>others?).
>
>Any and all feedback welcome.
>
>Carl
>
>
>On Thursday, March 09, 2006 11:31, Adrian Crum wrote:
>  
>
>>I would like to be involved in this work, since our industry is related to
>>Carl's and our UOM conversions are the same.
>>
>>How about a field in the table (ie: UOM conversion type) that points to a
>>UOM conversion entry in an XML file. The conversion entry in the XML file
>>lists calculation services to be called for that particular conversion. The
>>UOM conversion service takes the UOM conversion type, looks it up in the
>>XML file, then calls each calculation service listed.
>>
>>David E. Jones wrote:
>>    
>>
>>>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
>>>      
>>>
>>_______________________________________________
>>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

[Adrian Crum]

Si,

That's similar to the approach I was suggesting. I added an additional layer
though. Your suggestion would be simpler and easier to implement.

Carl,

We have to convert LF to BF just like you. My suggestion was intended to
accomodate additional UOM conversions down the road.


Si Chen wrote:

> JIRA's always a good tool.
>
> Another suggestion I had was to make uom conversion "pluggable."  We can
> expand the UomConversion or UomConversionDated field to have a
> "serviceName"  If serviceName != null then put all the parameters in and
> run that service and return its results.  Then you can write whatever
> conversion you need.
>
> Si
>
> Carl Sopchak wrote:
>
>
>>Thanks to all for the input.
>>
>>I personally think that taking it a step at a time - as needed - is not
>>necessarily a bad way to go.  And my client's checkbook agrees <GRIN>.  I do
>>NOT want to get into all possible conversions that could pop up, but I'm not
>>opposed to making the logic extendable, either.  (I am a firm believer of the
>>K.I.S.S. principal, though!)
>>
>>I should clarify that the conversion as I have proposed is not based on adding
>>productId as a key to the UomConversion file (or passing multiple values to
>>the convertUom function).  The conversion uses values from the product that
>>is being converted, but the conversion process is not product-specific.  (For
>>example LF to BF, regardless of product, is L x W x H / 12, but you need to
>>know which product to get L, W, and H.)  So, David, I am only proposing the
>>first part of your two-part change (if I'm reading your comments right).
>>
>>I would need more detail on the "XML pointing to service(s)" idea that Adrian
>>describes, as it is not clear how it would work in my situation (same
>>calculations, but product-value related) or how the services would know what
>>values to use (i.e., product related, or xxx related?).  Also, on the
>>surface, it seems like a more intrusive mod than my simple replacement of the
>>convertUom function.
>>
>>Adrian, does what I propose handle the conversions that you are looking for?  
>>Do some of my limitations pose a problem for you?  Do you have any questions
>>on how I envision this working?  Are there other issues that you have run
>>across in OFBiz pertaining to lumber that we can colaborate on?  Feel free to
>>email me directly if you would like to discuss OFBiz/Lumber.
>>
>>Does anyone else have an IMMEDIATE need for UoM conversion extensions that we
>>should consider in designing our solution?  Like I said, I don't mind
>>designing in more flexibility, as long as it doesn't turn a relatively simple
>>mod into a 6 month project.
>>
>>I should be getting more details from my client tomorrow, so I may have to
>>rethink some of this anyway.
>>
>>Should I put this in the jira, to make it an "official" mod?  We do plan on
>>giving the mod back to the community.  I'd be happy to take the lead on the
>>change, and coordinate efforts with anyone else willing to help (Adrian,
>>others?).
>>
>>Any and all feedback welcome.
>>
>>Carl
>>
>>
>>On Thursday, March 09, 2006 11:31, Adrian Crum wrote:
>>
>>
>>
>>>I would like to be involved in this work, since our industry is related to
>>>Carl's and our UOM conversions are the same.
>>>
>>>How about a field in the table (ie: UOM conversion type) that points to a
>>>UOM conversion entry in an XML file. The conversion entry in the XML file
>>>lists calculation services to be called for that particular conversion. The
>>>UOM conversion service takes the UOM conversion type, looks it up in the
>>>XML file, then calls each calculation service listed.
>>>
>>>David E. Jones wrote:
>>>  
>>>
>>>
>>>>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
>>>>    
>>>>
>>>
>>>_______________________________________________
>>>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
>

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

[Jacopo Cappellato]

Carl, Adrian, Si, others,

I'd suggest to have a look at the CustomMethod and CustomMethodType
entities (defined in the framework/common component). You could add a
"customMethodId" field to the UomConversion entity.
Then in the CustomMethod entity we simply map the logical name
(customMethodId) to the service name that implements the conversion
(customMethodName).
This pattern is already used to implement the manufacturing formulae for
bom and route calculations.

Jacopo

Adrian Crum wrote:

> Si,
>
> That's similar to the approach I was suggesting. I added an additional layer
> though. Your suggestion would be simpler and easier to implement.
>
> Carl,
>
> We have to convert LF to BF just like you. My suggestion was intended to
> accomodate additional UOM conversions down the road.
>
>

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

[Carl Sopchak]

Jacopo, thanks for pointing this out!  This should make the flexibility that
should be implemented must simpler to do (since the code is already there -
or close enough to copy and modify).

One of my hesitations with going for a more general solution is that this is
my first attempt at modifying OFBiz.  I know I can implement my first
suggestion, but things are still fuzzy with the CustomMethod approach.  I do
feel that this is the best way to go, though, so I'll invest some time in
designing a solution based on it and resubmit my plan.

Could someone point out an example of the usage of the CustomMethod logic?

Thanks,

Carl

On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:

> Carl, Adrian, Si, others,
>
> I'd suggest to have a look at the CustomMethod and CustomMethodType
> entities (defined in the framework/common component). You could add a
> "customMethodId" field to the UomConversion entity.
> Then in the CustomMethod entity we simply map the logical name
> (customMethodId) to the service name that implements the conversion
> (customMethodName).
> This pattern is already used to implement the manufacturing formulae for
> bom and route calculations.
>
> Jacopo
>
> Adrian Crum wrote:
> > Si,
> >
> > That's similar to the approach I was suggesting. I added an additional
> > layer though. Your suggestion would be simpler and easier to implement.
> >
> > Carl,
> >
> > We have to convert LF to BF just like you. My suggestion was intended to
> > accomodate additional UOM conversions down the road.
>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

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

[Carl Sopchak]

I've decided to pursue the use of services via the CustomMethod entity.  
(Thanks Jacopo for the help!)  Here's what I have in mind now:

1) Add the customMethodId to the UomConversion file, with a relation to
CustomMethod.
2) Add an optional parameter to convertUom: productId.
3) Add a check in the simple method convertUom (in CommonServices.xml), right
after the check for the UomConversion record being found:  If customMethodId
is not empty, call convertUomCustom and skip the rest of the logic in
convertUom.
4) Add method convertUomCustom to CommonServices.xml that looks up the
customMethodId in CustomMethod and calls the service, which in my case, I plan
on calling convertUomProduct.
5) Create a service_uom.xml file in framework/common/servicedef that defines
convertUomProduct.
6) Create a UomFormulas.xml in framework/common/script/org/ofbiz/common which
implements convertUomProduct.  This would basically do the logic (more or
less) of my original post.
7) Find all calls to convertUom and add the productId as a parameter, if one
is
available.

I think this is much more flexible than my original idea, and not very much
more work.

I will add this to jira.

Any other comments are welcome.

Adiran, if you'd like to help, how about working on the task #7 listed above:
adding productId to the convertUom calls.  I have already made the change to
framework/common/servicedef/services.xml to add the productId as an optional
parameter.  The diff is attached.  The I should have steps 1 through 4 done
today, 5 and 6 maybe as early as tomorrow.

Carl


On Friday, March 10, 2006 07:50, Carl Sopchak wrote:

> Jacopo, thanks for pointing this out!  This should make the flexibility
> that should be implemented must simpler to do (since the code is already
> there - or close enough to copy and modify).
>
> One of my hesitations with going for a more general solution is that this
> is my first attempt at modifying OFBiz.  I know I can implement my first
> suggestion, but things are still fuzzy with the CustomMethod approach.  I
> do feel that this is the best way to go, though, so I'll invest some time
> in designing a solution based on it and resubmit my plan.
>
> Could someone point out an example of the usage of the CustomMethod logic?
>
> Thanks,
>
> Carl
>
> On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:
> > Carl, Adrian, Si, others,
> >
> > I'd suggest to have a look at the CustomMethod and CustomMethodType
> > entities (defined in the framework/common component). You could add a
> > "customMethodId" field to the UomConversion entity.
> > Then in the CustomMethod entity we simply map the logical name
> > (customMethodId) to the service name that implements the conversion
> > (customMethodName).
> > This pattern is already used to implement the manufacturing formulae for
> > bom and route calculations.
> >
> > Jacopo
> >
> > Adrian Crum wrote:
> > > Si,
> > >
> > > That's similar to the approach I was suggesting. I added an additional
> > > layer though. Your suggestion would be simpler and easier to implement.
> > >
> > > Carl,
> > >
> > > We have to convert LF to BF just like you. My suggestion was intended
> > > to accomodate additional UOM conversions down the road.
> >
> > _______________________________________________
> > 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

[Adrian Crum]

I'll pitch in on this, but I'd like to wait a day or two for the other
developers to look over your proposal - to make sure everyone agrees this is the
way we should go.

I'm kinda swamped today and I won't be able to research this until tomorrow
(Saturday). I'll comment more then.


Carl Sopchak wrote:

> I've decided to pursue the use of services via the CustomMethod entity.  
> (Thanks Jacopo for the help!)  Here's what I have in mind now:
>
> 1) Add the customMethodId to the UomConversion file, with a relation to
> CustomMethod.
> 2) Add an optional parameter to convertUom: productId.
> 3) Add a check in the simple method convertUom (in CommonServices.xml), right
> after the check for the UomConversion record being found:  If customMethodId
> is not empty, call convertUomCustom and skip the rest of the logic in
> convertUom.
> 4) Add method convertUomCustom to CommonServices.xml that looks up the
> customMethodId in CustomMethod and calls the service, which in my case, I plan
> on calling convertUomProduct.
> 5) Create a service_uom.xml file in framework/common/servicedef that defines
> convertUomProduct.
> 6) Create a UomFormulas.xml in framework/common/script/org/ofbiz/common which
> implements convertUomProduct.  This would basically do the logic (more or
> less) of my original post.
> 7) Find all calls to convertUom and add the productId as a parameter, if one
> is
> available.
>
> I think this is much more flexible than my original idea, and not very much
> more work.
>
> I will add this to jira.
>
> Any other comments are welcome.
>
> Adiran, if you'd like to help, how about working on the task #7 listed above:
> adding productId to the convertUom calls.  I have already made the change to
> framework/common/servicedef/services.xml to add the productId as an optional
> parameter.  The diff is attached.  The I should have steps 1 through 4 done
> today, 5 and 6 maybe as early as tomorrow.
>
> Carl
>
>
> On Friday, March 10, 2006 07:50, Carl Sopchak wrote:
>
>>Jacopo, thanks for pointing this out!  This should make the flexibility
>>that should be implemented must simpler to do (since the code is already
>>there - or close enough to copy and modify).
>>
>>One of my hesitations with going for a more general solution is that this
>>is my first attempt at modifying OFBiz.  I know I can implement my first
>>suggestion, but things are still fuzzy with the CustomMethod approach.  I
>>do feel that this is the best way to go, though, so I'll invest some time
>>in designing a solution based on it and resubmit my plan.
>>
>>Could someone point out an example of the usage of the CustomMethod logic?
>>
>>Thanks,
>>
>>Carl
>>
>>On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:
>>
>>>Carl, Adrian, Si, others,
>>>
>>>I'd suggest to have a look at the CustomMethod and CustomMethodType
>>>entities (defined in the framework/common component). You could add a
>>>"customMethodId" field to the UomConversion entity.
>>>Then in the CustomMethod entity we simply map the logical name
>>>(customMethodId) to the service name that implements the conversion
>>>(customMethodName).
>>>This pattern is already used to implement the manufacturing formulae for
>>>bom and route calculations.
>>>
>>>Jacopo
>>>
>>>Adrian Crum wrote:
>>>
>>>>Si,
>>>>
>>>>That's similar to the approach I was suggesting. I added an additional
>>>>layer though. Your suggestion would be simpler and easier to implement.
>>>>
>>>>Carl,
>>>>
>>>>We have to convert LF to BF just like you. My suggestion was intended
>>>>to accomodate additional UOM conversions down the road.
>>>
>>>_______________________________________________
>>>Dev mailing list
>>>[hidden email]
>>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>>------------------------------------------------------------------------
>>
>>Index: services.xml
>>===================================================================
>>--- services.xml (revision 6966)
>>+++ services.xml (working copy)
>>@@ -248,5 +248,6 @@
>>         <auto-attributes include="pk" mode="IN" optional="false"/>
>>         <attribute name="originalValue" mode="IN" type="Double" optional="false"/>
>>         <attribute name="convertedValue" mode="OUT" type="Double" optional="false"/>
>>+        <attribute name="productId" mode="IN" type="String" optional="true"/>
>>     </service>
>> </services>
>>
>>
>>------------------------------------------------------------------------
>>
>>
>>_______________________________________________
>>Dev mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/dev

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

[Carl Sopchak]

Adrian, sounds good.  My gut tells me there'll be quite a few calls to
convertUom, so it'll probably take some time to hit them all.

It was pointed out to me that it would be more flexible if the new optional
parameter to convertUom was a Map, and I agree, so I have modified the parms
per the attached diff file.  

I plan on continuing this in the JIRA, which is here:
http://jira.undersunconsulting.com/browse/OFBIZ-782

I have the patch to the UomConversion entity there as well.  That's steps 1 &
2 down, 5 to go...

Carl

On Friday, March 10, 2006 11:58, Adrian Crum wrote:

> I'll pitch in on this, but I'd like to wait a day or two for the other
> developers to look over your proposal - to make sure everyone agrees this
> is the way we should go.
>
> I'm kinda swamped today and I won't be able to research this until tomorrow
> (Saturday). I'll comment more then.
>
> Carl Sopchak wrote:
> > I've decided to pursue the use of services via the CustomMethod entity.
> > (Thanks Jacopo for the help!)  Here's what I have in mind now:
> >
> > 1) Add the customMethodId to the UomConversion file, with a relation to
> > CustomMethod.
> > 2) Add an optional parameter to convertUom: productId.
> > 3) Add a check in the simple method convertUom (in CommonServices.xml),
> > right after the check for the UomConversion record being found:  If
> > customMethodId is not empty, call convertUomCustom and skip the rest of
> > the logic in convertUom.
> > 4) Add method convertUomCustom to CommonServices.xml that looks up the
> > customMethodId in CustomMethod and calls the service, which in my case, I
> > plan on calling convertUomProduct.
> > 5) Create a service_uom.xml file in framework/common/servicedef that
> > defines convertUomProduct.
> > 6) Create a UomFormulas.xml in framework/common/script/org/ofbiz/common
> > which implements convertUomProduct.  This would basically do the logic
> > (more or less) of my original post.
> > 7) Find all calls to convertUom and add the productId as a parameter, if
> > one is
> > available.
> >
> > I think this is much more flexible than my original idea, and not very
> > much more work.
> >
> > I will add this to jira.
> >
> > Any other comments are welcome.
> >
> > Adiran, if you'd like to help, how about working on the task #7 listed
> > above: adding productId to the convertUom calls.  I have already made the
> > change to framework/common/servicedef/services.xml to add the productId
> > as an optional parameter.  The diff is attached.  The I should have steps
> > 1 through 4 done today, 5 and 6 maybe as early as tomorrow.
> >
> > Carl
> >
> > On Friday, March 10, 2006 07:50, Carl Sopchak wrote:
> >>Jacopo, thanks for pointing this out!  This should make the flexibility
> >>that should be implemented must simpler to do (since the code is already
> >>there - or close enough to copy and modify).
> >>
> >>One of my hesitations with going for a more general solution is that this
> >>is my first attempt at modifying OFBiz.  I know I can implement my first
> >>suggestion, but things are still fuzzy with the CustomMethod approach.  I
> >>do feel that this is the best way to go, though, so I'll invest some time
> >>in designing a solution based on it and resubmit my plan.
> >>
> >>Could someone point out an example of the usage of the CustomMethod
> >> logic?
> >>
> >>Thanks,
> >>
> >>Carl
> >>
> >>On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:
> >>>Carl, Adrian, Si, others,
> >>>
> >>>I'd suggest to have a look at the CustomMethod and CustomMethodType
> >>>entities (defined in the framework/common component). You could add a
> >>>"customMethodId" field to the UomConversion entity.
> >>>Then in the CustomMethod entity we simply map the logical name
> >>>(customMethodId) to the service name that implements the conversion
> >>>(customMethodName).
> >>>This pattern is already used to implement the manufacturing formulae for
> >>>bom and route calculations.
> >>>
> >>>Jacopo
> >>>
> >>>Adrian Crum wrote:
> >>>>Si,
> >>>>
> >>>>That's similar to the approach I was suggesting. I added an additional
> >>>>layer though. Your suggestion would be simpler and easier to implement.
> >>>>
> >>>>Carl,
> >>>>
> >>>>We have to convert LF to BF just like you. My suggestion was intended
> >>>>to accomodate additional UOM conversions down the road.
> >>>
> >>>_______________________________________________
> >>>Dev mailing list
> >>>[hidden email]
> >>>http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >>_______________________________________________
> >>Dev mailing list
> >>[hidden email]
> >>http://lists.ofbiz.org/mailman/listinfo/dev
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>Index: services.xml
> >>===================================================================
> >>--- services.xml (revision 6966)
> >>+++ services.xml (working copy)
> >>@@ -248,5 +248,6 @@
> >>         <auto-attributes include="pk" mode="IN" optional="false"/>
> >>         <attribute name="originalValue" mode="IN" type="Double"
> >> optional="false"/> <attribute name="convertedValue" mode="OUT"
> >> type="Double" optional="false"/> +        <attribute name="productId"
> >> mode="IN" type="String" optional="true"/> </service>
> >> </services>
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>
> >>_______________________________________________
> >>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

[Carl Sopchak]

I have uploaded the patch files that implement the product-based unit of
measure conversion into the JIRA:
http://jira.undersunconsulting.com/browse/OFBIZ-782
Only the files dated today (25/Mar/06) are needed.  They implement all of the
changes needed to use convertUomProduct.  The existing calls to convertUom
have not been modified, but from what I found, no modifications are needed.

This surprises me - a LOT.  I figured there'd be a large number of calls to
convertUom, but only found a handful - for shipping services (for order
weight; DHL & USPS), and currency conversion in a few places.  Could someone
please confirm this?

It looks like my next mod will be adding UoM selection to the order entry
process.  Details to come...

Carl


On Friday, March 10, 2006 14:33, Carl Sopchak wrote:

> Adrian, sounds good.  My gut tells me there'll be quite a few calls to
> convertUom, so it'll probably take some time to hit them all.
>
> It was pointed out to me that it would be more flexible if the new optional
> parameter to convertUom was a Map, and I agree, so I have modified the
> parms per the attached diff file.
>
> I plan on continuing this in the JIRA, which is here:
> http://jira.undersunconsulting.com/browse/OFBIZ-782
>
> I have the patch to the UomConversion entity there as well.  That's steps 1
> & 2 down, 5 to go...
>
> Carl
>
> On Friday, March 10, 2006 11:58, Adrian Crum wrote:
> > I'll pitch in on this, but I'd like to wait a day or two for the other
> > developers to look over your proposal - to make sure everyone agrees this
> > is the way we should go.
> >
> > I'm kinda swamped today and I won't be able to research this until
> > tomorrow (Saturday). I'll comment more then.
> >
> > Carl Sopchak wrote:
> > > I've decided to pursue the use of services via the CustomMethod entity.
> > > (Thanks Jacopo for the help!)  Here's what I have in mind now:
> > >
> > > 1) Add the customMethodId to the UomConversion file, with a relation to
> > > CustomMethod.
> > > 2) Add an optional parameter to convertUom: productId.
> > > 3) Add a check in the simple method convertUom (in CommonServices.xml),
> > > right after the check for the UomConversion record being found:  If
> > > customMethodId is not empty, call convertUomCustom and skip the rest of
> > > the logic in convertUom.
> > > 4) Add method convertUomCustom to CommonServices.xml that looks up the
> > > customMethodId in CustomMethod and calls the service, which in my case,
> > > I plan on calling convertUomProduct.
> > > 5) Create a service_uom.xml file in framework/common/servicedef that
> > > defines convertUomProduct.
> > > 6) Create a UomFormulas.xml in framework/common/script/org/ofbiz/common
> > > which implements convertUomProduct.  This would basically do the logic
> > > (more or less) of my original post.
> > > 7) Find all calls to convertUom and add the productId as a parameter,
> > > if one is
> > > available.
> > >
> > > I think this is much more flexible than my original idea, and not very
> > > much more work.
> > >
> > > I will add this to jira.
> > >
> > > Any other comments are welcome.
> > >
> > > Adiran, if you'd like to help, how about working on the task #7 listed
> > > above: adding productId to the convertUom calls.  I have already made
> > > the change to framework/common/servicedef/services.xml to add the
> > > productId as an optional parameter.  The diff is attached.  The I
> > > should have steps 1 through 4 done today, 5 and 6 maybe as early as
> > > tomorrow.
> > >
> > > Carl
> > >
> > > On Friday, March 10, 2006 07:50, Carl Sopchak wrote:
> > >>Jacopo, thanks for pointing this out!  This should make the flexibility
> > >>that should be implemented must simpler to do (since the code is
> > >> already there - or close enough to copy and modify).
> > >>
> > >>One of my hesitations with going for a more general solution is that
> > >> this is my first attempt at modifying OFBiz.  I know I can implement
> > >> my first suggestion, but things are still fuzzy with the CustomMethod
> > >> approach.  I do feel that this is the best way to go, though, so I'll
> > >> invest some time in designing a solution based on it and resubmit my
> > >> plan.
> > >>
> > >>Could someone point out an example of the usage of the CustomMethod
> > >> logic?
> > >>
> > >>Thanks,
> > >>
> > >>Carl
> > >>
> > >>On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:
> > >>>Carl, Adrian, Si, others,
> > >>>
> > >>>I'd suggest to have a look at the CustomMethod and CustomMethodType
> > >>>entities (defined in the framework/common component). You could add a
> > >>>"customMethodId" field to the UomConversion entity.
> > >>>Then in the CustomMethod entity we simply map the logical name
> > >>>(customMethodId) to the service name that implements the conversion
> > >>>(customMethodName).
> > >>>This pattern is already used to implement the manufacturing formulae
> > >>> for bom and route calculations.
> > >>>
> > >>>Jacopo
> > >>>
> > >>>Adrian Crum wrote:
> > >>>>Si,
> > >>>>
> > >>>>That's similar to the approach I was suggesting. I added an
> > >>>> additional layer though. Your suggestion would be simpler and easier
> > >>>> to implement.
> > >>>>
> > >>>>Carl,
> > >>>>
> > >>>>We have to convert LF to BF just like you. My suggestion was intended
> > >>>>to accomodate additional UOM conversions down the road.
> > >>>
> > >>>_______________________________________________
> > >>>Dev mailing list
> > >>>[hidden email]
> > >>>http://lists.ofbiz.org/mailman/listinfo/dev
> > >>
> > >>_______________________________________________
> > >>Dev mailing list
> > >>[hidden email]
> > >>http://lists.ofbiz.org/mailman/listinfo/dev
> > >>
> > >>
> > >>-----------------------------------------------------------------------
> > >>-
> > >>
> > >>Index: services.xml
> > >>===================================================================
> > >>--- services.xml (revision 6966)
> > >>+++ services.xml (working copy)
> > >>@@ -248,5 +248,6 @@
> > >>         <auto-attributes include="pk" mode="IN" optional="false"/>
> > >>         <attribute name="originalValue" mode="IN" type="Double"
> > >> optional="false"/> <attribute name="convertedValue" mode="OUT"
> > >> type="Double" optional="false"/> +        <attribute name="productId"
> > >> mode="IN" type="String" optional="true"/> </service>
> > >> </services>
> > >>
> > >>
> > >>-----------------------------------------------------------------------
> > >>-
> > >>
> > >>
> > >>_______________________________________________
> > >>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

[Carl Sopchak]

Just thought I'd let the list know that I have modified my UoM Conversion
Enhancement that's in the JIRA at
http://jira.undersunconsulting.com/browse/OFBIZ-782 with the following
changes:

1) The convertUomProduct method (and related changes) have been moved to
applications/product from framework/common, per David's suggestion / request.

2) This version also adds customMethodId to the UomConversionDated entity, so
the custom method conversions will now work for conversions based on either
entity (UomConversion or UomConversionDated).

3) BIGGIE: I added attributes decimalScale and roundingMode to both
UomConversion and UomConversionDated. These attributes take the same values
as the similarly-named parameters to <calcop>, and are used to round the
conversion results prior to returning the converted value to the calling
program. decimalScale is the number of decimal places to round to, and
roundingMode can be any of Ceiling, Floor, Up, Down, HalfUp, HalfDown,
HalfEven, or Unnecessary, and determines how the rounding is performed (see
BigDecimal javadoc for details).  The rounding only takes place if
roundingMode is not empty.

Hope this is useful to others...

Carl

On Saturday, March 25, 2006 14:03, Carl Sopchak wrote:

> I have uploaded the patch files that implement the product-based unit of
> measure conversion into the JIRA:
> http://jira.undersunconsulting.com/browse/OFBIZ-782
> Only the files dated today (25/Mar/06) are needed.  They implement all of
> the changes needed to use convertUomProduct.  The existing calls to
> convertUom have not been modified, but from what I found, no modifications
> are needed.
>
> This surprises me - a LOT.  I figured there'd be a large number of calls to
> convertUom, but only found a handful - for shipping services (for order
> weight; DHL & USPS), and currency conversion in a few places.  Could
> someone please confirm this?
>
> It looks like my next mod will be adding UoM selection to the order entry
> process.  Details to come...
>
> Carl
>
> On Friday, March 10, 2006 14:33, Carl Sopchak wrote:
> > Adrian, sounds good.  My gut tells me there'll be quite a few calls to
> > convertUom, so it'll probably take some time to hit them all.
> >
> > It was pointed out to me that it would be more flexible if the new
> > optional parameter to convertUom was a Map, and I agree, so I have
> > modified the parms per the attached diff file.
> >
> > I plan on continuing this in the JIRA, which is here:
> > http://jira.undersunconsulting.com/browse/OFBIZ-782
> >
> > I have the patch to the UomConversion entity there as well.  That's steps
> > 1 & 2 down, 5 to go...
> >
> > Carl
> >
> > On Friday, March 10, 2006 11:58, Adrian Crum wrote:
> > > I'll pitch in on this, but I'd like to wait a day or two for the other
> > > developers to look over your proposal - to make sure everyone agrees
> > > this is the way we should go.
> > >
> > > I'm kinda swamped today and I won't be able to research this until
> > > tomorrow (Saturday). I'll comment more then.
> > >
> > > Carl Sopchak wrote:
> > > > I've decided to pursue the use of services via the CustomMethod
> > > > entity. (Thanks Jacopo for the help!)  Here's what I have in mind
> > > > now:
> > > >
> > > > 1) Add the customMethodId to the UomConversion file, with a relation
> > > > to CustomMethod.
> > > > 2) Add an optional parameter to convertUom: productId.
> > > > 3) Add a check in the simple method convertUom (in
> > > > CommonServices.xml), right after the check for the UomConversion
> > > > record being found:  If customMethodId is not empty, call
> > > > convertUomCustom and skip the rest of the logic in convertUom.
> > > > 4) Add method convertUomCustom to CommonServices.xml that looks up
> > > > the customMethodId in CustomMethod and calls the service, which in my
> > > > case, I plan on calling convertUomProduct.
> > > > 5) Create a service_uom.xml file in framework/common/servicedef that
> > > > defines convertUomProduct.
> > > > 6) Create a UomFormulas.xml in
> > > > framework/common/script/org/ofbiz/common which implements
> > > > convertUomProduct.  This would basically do the logic (more or less)
> > > > of my original post.
> > > > 7) Find all calls to convertUom and add the productId as a parameter,
> > > > if one is
> > > > available.
> > > >
> > > > I think this is much more flexible than my original idea, and not
> > > > very much more work.
> > > >
> > > > I will add this to jira.
> > > >
> > > > Any other comments are welcome.
> > > >
> > > > Adiran, if you'd like to help, how about working on the task #7
> > > > listed above: adding productId to the convertUom calls.  I have
> > > > already made the change to framework/common/servicedef/services.xml
> > > > to add the productId as an optional parameter.  The diff is attached.
> > > >  The I should have steps 1 through 4 done today, 5 and 6 maybe as
> > > > early as tomorrow.
> > > >
> > > > Carl
> > > >
> > > > On Friday, March 10, 2006 07:50, Carl Sopchak wrote:
> > > >>Jacopo, thanks for pointing this out!  This should make the
> > > >> flexibility that should be implemented must simpler to do (since the
> > > >> code is already there - or close enough to copy and modify).
> > > >>
> > > >>One of my hesitations with going for a more general solution is that
> > > >> this is my first attempt at modifying OFBiz.  I know I can implement
> > > >> my first suggestion, but things are still fuzzy with the
> > > >> CustomMethod approach.  I do feel that this is the best way to go,
> > > >> though, so I'll invest some time in designing a solution based on it
> > > >> and resubmit my plan.
> > > >>
> > > >>Could someone point out an example of the usage of the CustomMethod
> > > >> logic?
> > > >>
> > > >>Thanks,
> > > >>
> > > >>Carl
> > > >>
> > > >>On Friday, March 10, 2006 02:29, Jacopo Cappellato wrote:
> > > >>>Carl, Adrian, Si, others,
> > > >>>
> > > >>>I'd suggest to have a look at the CustomMethod and CustomMethodType
> > > >>>entities (defined in the framework/common component). You could add
> > > >>> a "customMethodId" field to the UomConversion entity.
> > > >>>Then in the CustomMethod entity we simply map the logical name
> > > >>>(customMethodId) to the service name that implements the conversion
> > > >>>(customMethodName).
> > > >>>This pattern is already used to implement the manufacturing formulae
> > > >>> for bom and route calculations.
> > > >>>
> > > >>>Jacopo
> > > >>>
> > > >>>Adrian Crum wrote:
> > > >>>>Si,
> > > >>>>
> > > >>>>That's similar to the approach I was suggesting. I added an
> > > >>>> additional layer though. Your suggestion would be simpler and
> > > >>>> easier to implement.
> > > >>>>
> > > >>>>Carl,
> > > >>>>
> > > >>>>We have to convert LF to BF just like you. My suggestion was
> > > >>>> intended to accomodate additional UOM conversions down the road.
> > > >>>
> > > >>>_______________________________________________
> > > >>>Dev mailing list
> > > >>>[hidden email]
> > > >>>http://lists.ofbiz.org/mailman/listinfo/dev
> > > >>
> > > >>_______________________________________________
> > > >>Dev mailing list
> > > >>[hidden email]
> > > >>http://lists.ofbiz.org/mailman/listinfo/dev
> > > >>
> > > >>
> > > >>---------------------------------------------------------------------
> > > >>-- -
> > > >>
> > > >>Index: services.xml
> > > >>===================================================================
> > > >>--- services.xml (revision 6966)
> > > >>+++ services.xml (working copy)
> > > >>@@ -248,5 +248,6 @@
> > > >>         <auto-attributes include="pk" mode="IN" optional="false"/>
> > > >>         <attribute name="originalValue" mode="IN" type="Double"
> > > >> optional="false"/> <attribute name="convertedValue" mode="OUT"
> > > >> type="Double" optional="false"/> +        <attribute
> > > >> name="productId" mode="IN" type="String" optional="true"/>
> > > >> </service>
> > > >> </services>
> > > >>
> > > >>
> > > >>---------------------------------------------------------------------
> > > >>-- -
> > > >>
> > > >>
> > > >>_______________________________________________
> > > >>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

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