Re: Dev - [OFBiz] [JIRA] Commented: (OFBIZ-826) Order Unit of Measure

[Jacopo Cappellato]

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

[Jacopo Cappellato]

Carl,

Please, see my comments inline:

Carl Sopchak (JIRA) wrote:

>      [ http://jira.undersunconsulting.com/browse/OFBIZ-826?page=comments#action_13056 ]
>      
> Carl Sopchak commented on OFBIZ-826:
> ------------------------------------
>
> 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).

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

[David E. Jones]

Jacopo Cappellato wrote:

> 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?

As I've mentioned before in order to push the quantity to a whole number we introduced the amount field which is meant to be a decimal. For many packaged goods no amount is needed as it is always 1.0, but for something like rope or boards that are custom cut or other things like that, the amount would be used along with a UOM to specify exactly what is being ordered.

-David


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

yes I know that the amount field can store decimal values. However I
think that there could be problems when inventory operations are
considered because I'm not sure that the amount field is currently
treated correctly there:

1) are reservations and issuances handled correctly? I think that
reservations/issuances are done considering the quantity field, instead
of the amount field

2) what happens when a purchase order is received? I'm rather sure that
the amount field is ignored

Jacopo

David E Jones wrote:

> Jacopo Cappellato wrote:
>
>> 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?
>
> As I've mentioned before in order to push the quantity to a whole number we introduced the amount field which is meant to be a decimal. For many packaged goods no amount is needed as it is always 1.0, but for something like rope or boards that are custom cut or other things like that, the amount would be used along with a UOM to specify exactly what is being ordered.
>
> -David
>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[David E. Jones]

Jacopo,

Yes, that's a good (and scary) point...

I don't know if any back-end support was ever added when amount field was added. In fact, I don't think even the stuff I recommended when it was discussed was ever finished.

What should probably happen with inventory is to keep a total "quantity" that is the ordered quantity multiplied by the ordered amount (iff an amount is specified). For sales orders the same thing should happen when deducting from inventory for reservation (ATP) and for issue (QOH), ie use quantity * amount, and again iff an amount is specified. Also in both cases the amount UOM should match the inventory UOM or be converted...

So yeah, I imagine some work is needed in this area as given the progression of some of these things chances are the state of things is not all that great...

-David


Jacopo Cappellato wrote:

> David,
>
> yes I know that the amount field can store decimal values. However I
> think that there could be problems when inventory operations are
> considered because I'm not sure that the amount field is currently
> treated correctly there:
>
> 1) are reservations and issuances handled correctly? I think that
> reservations/issuances are done considering the quantity field, instead
> of the amount field
>
> 2) what happens when a purchase order is received? I'm rather sure that
> the amount field is ignored
>
> Jacopo
>
> David E Jones wrote:
>> Jacopo Cappellato wrote:
>>
>>> 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?
>> As I've mentioned before in order to push the quantity to a whole number we introduced the amount field which is meant to be a decimal. For many packaged goods no amount is needed as it is always 1.0, but for something like rope or boards that are custom cut or other things like that, the amount would be used along with a UOM to specify exactly what is being ordered.
>>
>> -David
>>
>>
>>  
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>
>  
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Carl Sopchak]

Some comments on recent posts:

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

Works for me.  I'm looking for as many comments as people care to offer.  But
this did start on the Dev list, and I added it to the JIRA, which seemed to
get more comments...  Oh, well...  I'm easy...

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

Make sense.  That sounds best to me, too.

>
> 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?

That's why I added the rounding options to UomConversion :-)  In our case, we
will always be selling integral pieces of wood.  (We don't cut a 2x4x8 in
half.)  If a customer orders 700 Board Feet, and that converts to 131.25
pieces, we'll ship 132.  (Customers expect this.)

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

Comments welcome, but if you don't really need UoM conversion, why bother show
it?  True, it's minor, and I may not spend the extra time on it...

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

I would like to hear Si's comments.  (Ya out there, Si?)  But I think the
flexibility of selecting the UoM for a return adds a lot.  But then again, I
haven't really looked at the returns process yet.

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

Fair enough.  For my client's purposes, I don't think we'll be worrying about
multiple UoMs for inventory - at least not for a while.

And that would be Product.internalQtyUomId, right?  :->

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

Nice to hear!  Hope so...

> 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 :-)

Good - in that I'm not duplicating effort and wasting bandwidth on the mailing
list.  Bad - in that now I have work to do! ;-)

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

Yes, I know.  I did look at it some, and I know I just can't use it as is, but
it might still help me determine where changes might be needed.  I will very
most likely continue to follow the approach that I have outlined.

> As I've mentioned before in order to push the quantity to a whole number we
> introduced the amount field which is meant to be a decimal. For many
> packaged goods no amount is needed as it is always 1.0, but for something
> like rope or boards that are custom cut or other things like that, the
> amount would be used along with a UOM to specify exactly what is being
> ordered.

I've seen the Amount field, but I'm unsure on scenarios that would use it.  
(I'm fairly certain my client will not be needing it.)  I can understand 3
pieces of rope at 10 feet each, or 4 buckets of paint at 5 gallons each.  But
I question how a (web) user might enter a UoM for these scenarios, and what
the UoM for the inventory quantity would be.  Technically, each numeric value
would have a UoM, the quantities would be multiplied, and a new UoM would be
used for the result (hopefully easily converted to the internal UoM).

Also, it sounds like it's not used throughout OFBiz.  Is this something I
should worry about??

> What should probably happen with inventory is to keep a total "quantity"
> that is the ordered quantity multiplied by the ordered amount (iff an
> amount is specified). For sales orders the same thing should happen when
> deducting from inventory for reservation (ATP) and for issue (QOH), ie use
> quantity * amount, and again iff an amount is specified. Also in both cases
> the amount UOM should match the inventory UOM or be converted...

Even so, I think I'll leave whatever usage of the Amount field is there.  If
someone else would like to tackle it, tho...

Further comments, suggestions, insights welcome...

Carl
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

Hi Carl,

just a few minor comments:

Carl Sopchak wrote:
> Some comments on recent posts:
>
>> 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).
>
> Works for me.  I'm looking for as many comments as people care to offer.  But
> this did start on the Dev list, and I added it to the JIRA, which seemed to
> get more comments...  Oh, well...  I'm easy...
>

Well, so now we can collect comments from the mailing list and the issue
tracker ;-)

  >> 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?
>
> That's why I added the rounding options to UomConversion :-)  In our case, we
> will always be selling integral pieces of wood.  (We don't cut a 2x4x8 in
> half.)  If a customer orders 700 Board Feet, and that converts to 131.25
> pieces, we'll ship 132.  (Customers expect this.)
>

That's fine for me.

>> 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.
>
> Comments welcome, but if you don't really need UoM conversion, why bother show
> it?  True, it's minor, and I may not spend the extra time on it...
>

Well, this is probably a matter of taste :-)

>
> Fair enough.  For my client's purposes, I don't think we'll be worrying about
> multiple UoMs for inventory - at least not for a while.
>
> And that would be Product.internalQtyUomId, right?  :->
>

Exactly.

>
> Carl
>  

Jacopo
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Jacopo Cappellato]

David,

I'm rather sure you've already explained to me the reasons/advantages of
treating the OrderItem.quantity field as an integer... but I cannot
remember it, sorry.
Could you please, quickly (re-)explain?

Thanks,

Jacopo

David E Jones wrote:

> Jacopo,
>
> Yes, that's a good (and scary) point...
>
> I don't know if any back-end support was ever added when amount field was added. In fact, I don't think even the stuff I recommended when it was discussed was ever finished.
>
> What should probably happen with inventory is to keep a total "quantity" that is the ordered quantity multiplied by the ordered amount (iff an amount is specified). For sales orders the same thing should happen when deducting from inventory for reservation (ATP) and for issue (QOH), ie use quantity * amount, and again iff an amount is specified. Also in both cases the amount UOM should match the inventory UOM or be converted...
>
> So yeah, I imagine some work is needed in this area as given the progression of some of these things chances are the state of things is not all that great...
>
> -David
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev