Posted by
Jacopo Cappellato on
Apr 26, 2006; 9:38am
URL: http://ofbiz.116.s1.nabble.com/Re-Dev-OFBiz-JIRA-Commented-OFBIZ-826-Order-Unit-of-Measure-tp167770.html
Carl,
I've moved this conversation to the dev list to make it easier to
comment on specific issues and let others jump in (if they want to do so).
Please, see my comments inline:
Carl Sopchak (JIRA) wrote:
> [
http://jira.undersunconsulting.com/browse/OFBIZ-826?page=comments#action_13055
]
> Carl Sopchak commented on OFBIZ-826:
> ------------------------------------
>
> 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...)
>
Yes, see my comments on the other message but keep in mind that it was
only a discussion (useful to get ideas) but nothing concrete has been
developed and contributed from it.
> 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...
>
Ok, so if the prices will be expressed for the units in the sku uom id
then everything will be a little easier (no conversion needed when you
calculate the order item amount); as a consequence, the new field that
will store the sku uom id could be named Product.internalQtyUomId
instead of Product.inventoryQtyUomId.
The biggest issue I see is that OrderItem.quantity field should be an
integer value (even if the db field allows for decimal values, the
system expects it to contain integer values): so you'll have to manage
this... I'm not sure about the best approach here; comments from others?
> 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"...
>
Well, I'm not so sure that it will be necessary to conditionally run the
order uom stuff based on the property product.order.use.uom... let's see
what other think about this; by the way it is a minor issue.
> Thanks again for the comments. They are much appreciated!
>
Thanks to you for sharing your ideas, plans and work,
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