http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167108.html
I would like to be involved in this work, since our industry is related to
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
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