http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167111.html
That's similar to the approach I was suggesting. I added an additional layer
though. Your suggestion would be simpler and easier to implement.
We have to convert LF to BF just like you. My suggestion was intended to
> 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>