Posted by
Jacques Le Roux on
URL: http://ofbiz.116.s1.nabble.com/Dev-Ordering-Units-of-Measure-tp167406p167422.html
From: "Carl Sopchak" <
[hidden email]>
> 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
Carl,
I'm not a specialist and sure this is something questionable. Besides Len
Silverston wrote in p. 80 (2d edition) "Most organisations will conclude that
if the same type of product is sold in different units of measure, then it
really is a different product". So he wrote "Most" but not "All". For example in
*most* shops you can pick a bottle out of a pack, but not in *all*. And even in
some shops you may pick a bottle out of some packs (water) but not of all
(beer), at least it's like that here in France.
OK, it was just a rewriting of what you said. My question is (for everybody) :
is there a way to merge this 2 models in one (Mmm if we look at the pack of
bottles example seems hard ;o). Because this seems to come back again and again.
Thanks
Jacques
Jacques
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev