http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167109.html
necessarily a bad way to go. And my client's checkbook agrees <GRIN>. I do
opposed to making the logic extendable, either. (I am a firm believer of the
K.I.S.S. principal, though!)
the convertUom function). The conversion uses values from the product that
is being converted, but the conversion process is not product-specific. (For
values to use (i.e., product related, or xxx related?). Also, on the
giving the mod back to the community. I'd be happy to take the lead on the
> 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