[ 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.