[
https://issues.apache.org/jira/browse/OFBIZ-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621288#action_12621288
]
Jacques Le Roux commented on OFBIZ-219:
---------------------------------------
Hi Jacopo,
Please, what is the status of this ? I just re-read the interesting thread
http://lists.ofbiz.org/pipermail/users/2006-January/009827.html and your
proposition at its end + Sebastien's.. It's a pity Carl was gone...
> Discussion about quantity uom support in inventory and orders.
> --------------------------------------------------------------
>
> Key: OFBIZ-219
> URL: https://issues.apache.org/jira/browse/OFBIZ-219
> Project: OFBiz
> 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.
-
You can reply to this email to add a comment to the issue online.
