http://ofbiz.116.s1.nabble.com/Dev-Ordering-Units-of-Measure-tp167406p167409.html
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.
> 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