Posted by
Carl Sopchak on
Apr 27, 2006; 1:20am
URL: http://ofbiz.116.s1.nabble.com/Re-Dev-OFBiz-JIRA-Commented-OFBIZ-826-Order-Unit-of-Measure-tp167770p167775.html
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