http://ofbiz.116.s1.nabble.com/Dev-UoM-Conversion-Enhancement-tp167105p167118.html
Just thought I'd let the list know that I have modified my UoM Conversion
UomConversion and UomConversionDated. These attributes take the same values
program. decimalScale is the number of decimal places to round to, and
BigDecimal javadoc for details). The rounding only takes place if
> 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