Posted by
Jacopo Cappellato on
Apr 26, 2006; 9:39am
URL: http://ofbiz.116.s1.nabble.com/Re-Dev-OFBiz-JIRA-Commented-OFBIZ-826-Order-Unit-of-Measure-tp167770p167777.html
Carl,
Please, see my comments inline:
Carl Sopchak (JIRA) wrote:
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).
I agree.
> 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.
>
I'm not an expert here... maybe Si Chen (that has recently refactored
the 'return' processes) could suggest the better approach to follow
(also considering the accounting issues).
> 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!
That's great.
> 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.
Hmmm... I don't think that it is a good idea to add another field to the
InventoryItem entity to store the qty in a different uom; the Inventory*
data model and processes (including reservations, issuances etc) are
rather complex and I wouldn't touch them unless it is absolutely needed;
however in the InventoryItem entity we already have a field to store the
uom for the qty of the InventoryItem, so we can virtually have the same
product stored in warehouse in different uoms; however the reservation,
picking, packing processes don't cosider this at the moment.
I think that the best thing we can do is to start to populate the
InventoryItem.uomId field with the default uom for the product
(Product.inventoryQtyUomId) and then review the processes at a later time.
> 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.
>
Yes, I think that the work you have contributed will satisfy all the
conversions needed.
> 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, > 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.
>
I agree.
> 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)...
>
There is no work in progress (or planned) in this area that I'm aware
of, so I think that yours is the only *official* effort in this area at
the moment :-)
> And I still need to look at
http://jira.undersunconsulting.com/browse/OFBIZ-369 ...
Yes, have a look at it but consider that the approach followed in that
contribution is rather different from the one you are following.
Jacopo
>
> Carl
>
>> Order Unit of Measure
>> ---------------------
>>
>> Key: OFBIZ-826
>> URL:
http://jira.undersunconsulting.com/browse/OFBIZ-826>> Project: [OFBiz] Open For Business
>> Type: Improvement
>> Components: order, product
>> Environment: all
>> Reporter: Carl Sopchak
>> Assignee: Jira Administrator
>
>> Original Estimate: 1 week
>> Remaining: 1 week
>>
>> 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)...
>
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev