http://ofbiz.116.s1.nabble.com/Dev-Ordering-Units-of-Measure-tp167406p167410.html
with OFBiz philosophy. Both myself and my client understand the benefits of
keeping changes within OFBiz when it's not a proprietary business process.
world's problems on his dime. ;-> I will always make the change extensible
As for where to put the code, maybe I goofed up on that in the UoM change. I
a "common" function. Are you saying that the product-based portion of the
big of a change (but please let me know if it's required/desireable)... BTW,
I suppose. Just wonderin'.
switch" (customer ordering UoMs? Yes/No). Is there a place within OFBiz
On Wednesday, April 05, 2006 19:43, David E. Jones wrote:
> Carl,
>
> On the do it separately versus a part of OFBiz: there are a lot of benefits
> for you as well as others to doing it as part of the main project. The
> downside is that you may get more feedback and review that you want.
> Sometimes this brings up issues that need to be resolved but that you don't
> care about, though what often happens is that it turns out that they are
> issues you really do need to work over.
>
> Whenever doing something based on OFBiz, and especially something that will
> go back into the project, the most important part is basically what you are
> doing now: reviewing what exists and deciding how to meet your requirements
> with existing and/or new features. If it's going back into the project then
> the duplicated functionality issue is an even bigger one.
>
> =============
>
> For this particular issue I agree that they shouldn't be different products
> for different UOMs. The general approach is to configure the size in one
> UOM (preferably consistent across similar products) and convert it in the
> user interface layer (and perhaps higher level services) to/from what to
> user prefers.
>
> The UOM stuff you are talking about should, as I mentioned before, be split
> into 2 sets. The core UOM stuff that does not deal with products (including
> conversion between varying dimensions, extended UOMs that are industry
> specific, etc) would go in the "common" component. The extensions to those
> for dealing with Product specific stuff should go in the "product"
> component.
>
> In general as much as can be shared should go into lower level components
> like common, but those can't depend on higher level things in other
> components like product.
>
> -David
>
> Carl Sopchak wrote:
> > OK, I finally got my Data Model Resource Books on Saturday, and I see
> > that the author suggests that different ordering UoM's are either
> > different features, or even different products. I'm not sure I agree
> > with the different products view, but I was wondering if anyone has tried
> > implementing multiple ordering UoM's as product features. If so, I was
> > wondering how well it worked for you, and how, specifically, they would
> > get set up. (Admittedly, I haven't spent a LOT of time on trying to
> > figure this out yet, but I'd rather spend my time changing the order
> > entry screens if needed...)
> >
> > The product my client sells is wood: 2x4's, 4x8's, plywood, etc. You
> > know, the stuff you build houses with. In our view, a 2x4x8, is a 2x4x8,
> > is a 2x4x8! We'll be shipping the same pieces, whether they order 200
> > pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge
> > "packages" you see stacked in your local home improvement store).
> > Further, if they order 1000 board feet, we may very well ship the 1067 BF
> > in a unit. (Other rounding-type issues may apply as well.) If we have
> > only one full unit, and a customer orders 100 pieces, we break the unit.
> > In other words, there's nothing special with the UoM's, except
> > convenience (or habit of the customer) in ordering.
> >
> > So, for us, different UoM's are DEFINITELY NOT different products. (Even
> > the ream of paper example in the book doesn't fly well with me - thinking
> > about boxes and pallets of reams of paper, but I'll let that slide for
> > now...) I'm not too sure how well ordering will work (particularly
> > during the busy summer months) with UoM as a feature.
> >
> > One last question: If we decide to do the order entry mod described in
> > the original email, should we do it as part of OFBiz and submit a patch,
> > or should we keep it as a local mod (since it seems against the data
> > model apparently employed by OFBiz)?
> >
> > Any comments or suggestions would be most welcome.
> >
> > Thanks,
> >
> > Carl
> >
> > On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
> >> Much to my surprise, OFBiz does not seem to "do" order quantities in
> >> units of measure other than the stock keeping unit. (I.e., you can't
> >> order a "Box" of something when stock is kept in "Eaches".) Someone,
> >> please let me know if I'm wrong here! Or, if anyone has made the mod on
> >> a "custom" basis, please contact me off-list.
> >>
> >> Assuming I need to make this change, here is what I propose:
> >>
> >> 1) Add attributes to the Product entity: skuUom (stock keeping unit
> >> UoM), and customerOrderUom (default customer order quantity UoM; I
> >> forsee a supplierOrderUom in my future, too, but I'm not sure yet).
> >> 2) Add the above fields to the Product Entry screen. Validate that
> >> either the two UoM's are equal, or that there are UomConversion records
> >> to go between the two.
> >> 3) Add attributes to the OrderItem entity: quantityAsOrdered and
> >> quantityAsOrderedUom.
> >> 4) Change the entry of order line items so that the quantity that is
> >> entered on the screen is saved in the quantityAsOrdered attribute, and
> >> add a drop-down of units of measure, showing only those units of measure
> >> which have a UomConversion record on file where the uomIdTo =
> >> product.skuUom, with the default value being the
> >> product.customerOrderUom, and the selection being saved in
> >> quantityAsOrderedUom. The quantityAsOrdered would be converted from the
> >> quantityAsOrderedUom to the product.skuUom, and the result stored in
> >> OrderItem.quantity. (There may be a rounding issue here that convertUom
> >> will have to address...)
> >> 5) Change the display of order lines to show the quantityAsOrdered and
> >> quantityAsOrderedUom instead of (or in addition to?) quantity and
> >> skuUom.
> >>
> >> Here are my questions:
> >>
> >> - Overall, does this make sense? Comments / suggestions / etc.
> >> welcome... - I haven't received my Data Modeling Resource Books yet (on
> >> order...), so I'm assuming the entities mentioned above are the right
> >> place to put the additional attributes. Please correct me if I'm wrong.
> >> - As for the "drop-down of UoMs" based on the product entered, this may
> >> be a bit difficult on a web page due to the way web browsing works
> >> (although I've seen "dynamic" pages that do similar things). Is there a
> >> standard way to handle such things in OFBiz? Should I just display the
> >> customerOrderUom, and supply a pop-up to pick from (based on the
> >> productId)? This does seems a bit awkward though, particularly for
> >> "high volume" order entry.
> >> - Although I'm sure I could find where everything needs to go, if anyone
> >> would like to point me to specific things that would need changing
> >> (particularly if I missed something), it would be most appreciated.
> >>
> >> Thanks in advance for the help and comments.
> >>
> >> 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