http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167110.html
JIRA's always a good tool.
run that service and return its results. Then you can write whatever
>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>
>
>