[jira] Created: (OFBIZ-219) Discussion about quantity uom support in inventory and orders.

[Nicolas Malin (Jira)]

Discussion about quantity uom support in inventory and orders.
--------------------------------------------------------------

                 Key: OFBIZ-219
                 URL: http://issues.apache.org/jira/browse/OFBIZ-219
             Project: OFBiz (The Open for Business Project)
          Issue Type: Wish
          Components: order, product
            Reporter: Jacopo Cappellato
            Priority: Minor


This is taken from an issue created in the old server by Carl Sopchack:

OFBiz currently only allows orders to be placed for product in the product's stock keeping unit of measure. Add ability to use varying Units of Measure when placing an order. For example, if a product's stock keeping UoM is "each", allow orders to be in "each", "box" (of 12 or 24 or whatever), "case" (of 3, 4, 5... boxes), or "pallet" (of n cases).

THese are the changes that I foresee doing:

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 there 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 way to select units of measure, allowing 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 value 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.

I'm sure there will be more related changes down the road (e.g., on the pick ticket), but I'll enter a JIRA when I get to that point.

I'm starting on this work today (but only working part time)...


 All   Comments   Work Log   Change History      Sort Order: [navigator.ascending.order]
Comment by Carl Sopchak [01/Apr/06 11:54 AM]
[ Permlink ]
Well, my Data Model Resource Books were delivered about 30 minutes after I entered this, and see that the different UoM's - according to the book - are different features of a product. I need to study this a bit more, to see if it makes sense in my client's use case. But, in the mean time, I guess the change is "on hold"... (At first glance, this seems cumbersome, but I'll approach it with an open mind...)

Comment by Carl Sopchak [22/Apr/06 04:24 PM]
[ Permlink ]
Ok, after reading the Data Model Resource Book, and studying features in OFBiz, I couldn't figure out how we would implement different ordering Units of Measure with existing functionality. Our product is wood: 2x4's, 2x6's, 2x8's etc. A customer may say that they want 200 pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge "packages" you see stacked in your local home improvement store), but we'll be shipping the same physical pieces regardless. If they only want 800 lineal feet, we'll break a unit and ship them half of it...

So, it appears that this mod is needed for our implementation. I have started on it, as described above, with the following exceptions:

1) The field names above for Uom will have an "Id" at the end.

2) I am making the mod contingent on the setting of a property in a property file. Since this is primarily product related, I will be adding the property to file application/product/config/catalog.properties. The property is product.order.use.uom, which will be true or not. (I'll always compare to "true", so false or not found or not recognized all mean false.) If someone thinks there's a better place for this, please let me know.

3) The UoM fields have been put on the Product Update page unconditionally. However, the validation that the customer order UoM can be converted to the SKU UoM is done conditional on order.use.uom. (Is there a way for me to pass the value of product.order.use.uom to the form, so I can use <field use-when="product.order.use.uom=='true'">?)

Comments and suggestions welcome.

Carl

Comment by Jacopo Cappellato [24/Apr/06 04:05 AM]
[ Permlink ]
Carl,

I think that you'll find interesting the thread "Units of measure for quantities in sales/purchase/manufacturing orders and for inventory" happened in the user mailing list starting from 18/01/2006.

Jacopo

Comment by Jacopo Cappellato [24/Apr/06 05:00 AM]
[ Permlink ]
Carl,

here are some comments:

a) instead of Product.skuUomId, I'd suggest something closer to OFBiz's conventions, such as Product.inventoryQtyUomId

b) instead of Product.customerOrderUomId, I'd suggest something like Product.productPriceQtyUomId: this should store the uom for the unit price qty to which all the prices in the ProductPrice entity refer; this uom can also be used as the default uom for sales orders

c) I like the idea of adding a new field to store the quantity ordered in the non sku uom (quantityAsOrdered); this will minimize the mods needed for the order fulfillment process

d) you can pass a value from a properties file to a form adding the following code to the "action" section of the screen widget:

<property-to-field field="useUoms" resource="catalog" property="product.order.use.uom" default="false"/>

and then, in the form definition, you can test is in the following way:

<field use-when="${useUoms}=='true'">

(or something like this... please verify the syntax of the use-when attribute)

However I think that it's not necessary to hide these fields in the edit product form.




Comment by Carl Sopchak [25/Apr/06 04:56 PM]
[ Permlink ]
Jacopo,

Thanks for the pointer to the User list thread. I'll comment on it separately, after I read through it a few times, and read through the JIRA issue it pointed to (which was closed with status "won't fix", which gives me pause...)

As for your other comments:

a) Makes sense. Being new to OFBiz, it might take me a little bit to learn these kind of conventions. Please bear with me ;-) And please keep pointing these things out.

b) Actually, since I haven't spent a lot of time on this yet, I didn't think about prices - yet. (argh!) Anyway, I'm not too sure we want to have pricing in a UoM different from the inventoryQtyUomId, since we'll be using that UoM a whole lot, which would require a lot of calls to convertUom. By keeping everything in the same base UoM, things should be easier down the road (and allow the implementation of varying UoMs to be added piecemeal as needed). I'll have to think about this a bit more...

c) Thanks. I figured this would allow the functionality that we need without throwing a huge knot into everything. It will also allow varying UoMs to be implemented as needed, where needed, by whomever needs it...

d) Thanks for the tip. As far as not hiding the fields on the Edit Product form, I think if I don't, then people will see them and wonder why they "aren't working". On the other hand, seeing them might prompt them to look into it further. Maybe a message stating that they're "info only" if product.order.use.uom <> "true"...

Thanks again for the comments. They are much appreciated!

Carl

Comment by Carl Sopchak [25/Apr/06 06:49 PM]
[ Permlink ]
My comments on the thread starting at http://lists.ofbiz.org/pipermail/users/2006-January/009827.html :

IMHO, the unit of measure used for quotes, sales orders, purchase orders, customer requests, AND returns should ALL be SELECTABLE at the time the document is entered into the system, and carried forward (e.g., quote -> sales order) throught the ordering processing. I would not implement these as a product attribute that must be used (although a product attribute for a default UoM would certainly make sense). As for returning product in a UoM different than purchased - absolutely want to do. If I buy a case of paper, and when I open it up I find a ream stained or damaged, I want to return the ream, not the case. For all of these documents, I'd suggest following the idea presented above for customer orders.

As for warehousing - interesting idea. Having designed and developed systems for a public warehouse, I've probably seen just about every product handling scenario you can think of! There are two schools of thought here: One is to keep inventory all at one UoM. This certainly simplifies a lot of the system processing, and user data entry, because you don't have to deal with, for example, splitting pallets into boxes. On the other hand, keeping stock in the UoM that the product is actually handled in can help with processing and handling when it's done in those units (think computer-aided picking). Then again, maybe using both UoM's, as suggested above in my order UoM mod description, might be a good compromise. This ides is probably a few months away for my client, so I'll worry about it then ;-).

As for the conversion issue, hopefully my UoM converision enhancement (that made it into SVN this past weekend) will satisfy at least some of the conversions needed. The restrictions on what UoM's are valid should be based on the conversions available.

And, yes, I can see scenarios where you'd purchase by the truckload, warehouse by the pallet, and sell by the case...

As for using different products for different UoM's, I suggest this would depend highly on how the product is handled. If you're never going to break a case of paper to get a ream out, go ahead and use different products. But, if you expect to be breaking boxes to ship reams daily, I think different products is unworkable. In my client's case, we sell the same physical product regardless of the UoM they designate on the order.

The post in the thread at http://lists.ofbiz.org/pipermail/users/2006-January/009905.html suggests that work was started on adding UoMs to OFBiz. Has this work started, or is it still on a To Do list? Some of it should change, based on my UoM Conversion Enhancement (and, hopefully, on my comments above)...

And I still need to look at http://jira.undersunconsulting.com/browse/OFBIZ-369 ...

Carl

Comment by Carl Sopchak [02/Jun/06 06:37 AM]
[ Permlink ]
I'm sorry to report that my client has decided to persue another system, so it looks unlikely that I will be continuing work on this request.

Carl

Comment by Si Chen [02/Jun/06 04:55 PM]
[ Permlink ]
Jacopo,

I just looked through this.

I think this could be a good feature and may be better than OFBIZ-664, for us at least, and certainly better than our earlier attempt at the marketing package auto-explode.

My suggesions:

1. Keep a separate product UOM for each facility, so they can have different ones.

2. Use the termUomId in ProductPrice to set separate prices for each UOM. This would also allow different stores (by store group) to sell in different UOMs.

3. Use the uom field in SupplierProduct to control purchasing at different UOMs.

The tricky thing is what to do when there is no UOM specified in the data? Somehow I want to say assume 1.0, but 1.0 of what?

Maybe we should at OFBIZ-369 again. There was a lot of interesting stuff there, but some of it duplicated what was already in OFBiz (like the conversion service was a re-write of our convertUom). Sorry I was the dodo who closed the issue at the time.

Comment by Daniel Kunkel [02/Jun/06 07:12 PM]
[ Permlink ]
Hi Si

You said:

I think this could be a good feature and may be better than OFBIZ-664, for us at least, and certainly better than our earlier attempt at the marketing package auto-explode.

I'm really confused by your statement...

As I understand it, the Marketing Package auto-explode allows packages of different products and not only different quantities to be built or packed on the spot during shipping. It makes a lot more sense to me to only stock red widgets and white widgets even if we sell a package that contains both a red and white widget.

Comment by Si Chen [02/Jun/06 11:27 PM]
[ Permlink ]
Jacopo,

I thought through this again and think that I'm overspecifying it originally. We could set a "base" UOM in the Product entity, perhaps with a new baseUomId field. Then each ProductPrice and SupplierProduct could have its UOM converted to this base UOM or, if it doesn't have a uomId, be assumed that the conversion 1.0. For now receiving inventory in the base UOM would be fine--we can extend it later with ProductFacility if we need to.

This model allows us to specify purchase and sale prices at different UOMs in the ProductPrice and SupplierProduct entities. The only thing I can't work out is how to set a UOM for sale in a store, if we want to "hardcode" it so that in one store it is only available in sets of 10, in another in sets of 100 (typical wholesale vs. retail situation.) I'm thinking that perhaps a new entity, which we've implemented but haven't put into the OFBIZ SVN yet, called "ProductCatalogProduct" might be good for this purpose actually. We could add a UOM field to it to control the UOM for each catalog or leave it out so that the default UOM is used.

What do you think?

Si

Comment by Jacopo Cappellato [07/Jun/06 12:40 PM]
[ Permlink ]
Si,

I agree with what you say.
about selling products with different uoms in different stores: could the ProductPrice.productStoreGroupId help with this? It is a primary key field so we could set up one price (for uom "set of 10") for one store (group) and one price (for uom "set of 100") for other store (group).

However, should we add the new field ProductPrice.currencyUomId?

Jacopo

Comment by Si Chen [08/Jun/06 05:37 PM]
[ Permlink ]
Daniel,

You're right - if you had red & blue widgets in a marketing package, then uom would not work. I was just thinking of using uom for selling things in different quantity blocks.

Si

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira