Re: Dev - Ordering Units of Measure

Posted by Carl Sopchak on
URL: http://ofbiz.116.s1.nabble.com/Dev-Ordering-Units-of-Measure-tp167406p167408.html

I've decided that we need this mod.  Please see
http://jira.undersunconsulting.com/browse/OFBIZ-826 for the full details.  
(The biggest change from what was originally described is that this is going
to be based on a parameter in catalog.properties.)

Comments and suggestions welcome...

Carl

On Monday, April 03, 2006 19:45, 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