I think you're right, Jacopo. Reserve inventory routines should skip
items with QOH <= 0. What do you think, David?
With respect to the "cool service," I think we'd want to have some
way to make and adjustment inventory reservations manually down the
road. What David mentioned should definitely be a part of it.
Si
On Jul 9, 2006, at 8:04 AM, Jacopo Cappellato wrote:
This is a very interesting subject.
In theory, in the life of an inventory item, its quantity on hand
(qoh) can only decrease: the maximum qoh is the quantity of the
inventory item when it is created (by an inventory receipt, a
production run, or by a reservation if no inventory item for the
given product exist in the warehouse); in its life, the atp
quantity can decrease & increase many times (reservations are moved
very quickly), while the qoh can only decrease (for item issuances
for shipments).
(The only remarkable exception is the manual inventory variance.)
So, when the qoh goes to zero, the inventory item can be considered
'old' (or dead, and I think that this is a nice way to define an
old inventory item): no other issuances for shipments will ever
come from it.
(However it's important to keep them for material tracking and
history).
In order to speed up the reservation routine (when there are many
inventory items), we could exclude from it all the inventory items
with qoh = 0.
We could also hide for the facility->inventory item screen all the
those ii.
Ok, maybe I'm off topic, but I wanted to write this notes down
because I think there is something metaphotically sad in this :-)
Jacopo
David E. Jones wrote:
It would be cool to have a service (with a link somewhere in the
UI) to delete an InventoryItem and re-allocate its reservations
onto other InventoryItems.
-David
Si Chen wrote:
Well, either a status or date would work. Basically I have some
old inventoryitems which I no longer want inventory reservations
to be made against. Not exactly a "business process" per se.
Maybe it's better if I just delete those inventory items and
their OISGIR and inventory_item_detail that'd work better for
me. Yeah, maybe that's what I should do, now that I think about
it. ;)
Si
On Jul 7, 2006, at 1:26 PM, David E. Jones wrote:
Having a separate set of statuses for the non-serialized inv
items would be best.
Would this sort of status fit into the business process you are
trying to address, or is something like a date more natural?
-David
Si Chen wrote:
So should we create a new "INV_CANCELLED" or "INV_UNAVAIL"
status which basically means that this item is no longer
available? And show it be of the INV_SERIALIZED_STTS
type as well, or a new "INV_NONSERIAL_STTS"? Which would you
prefer semantically--to call them "cancelled" or
"unavailable" (which is what they are, but then other status
items may imply they are unavailable as well.)
Si
On Jul 7, 2006, at 12:07 PM, David E. Jones wrote:
Not that I'm aware of, but it is an interesting idea... For a
serialized type inventory item you can set the status so the
II is not available for reservation.
For non-serialized type items the status is not used, but I
suppose we could introduce something there...
-David
Si Chen wrote:
Is there any other way to mark an inventory item as "off
limits" for inventory reservations? I had thought an
expiration date might be what I'm looking for, but it didn't
work the way I thought, and I'm not sure I have time to do
all of this right now.
Si
On Jul 7, 2006, at 9:59 AM, David E. Jones wrote:
Christian Geisert wrote:
Si Chen schrieb:
Hi.
Just noticed that if inventory items with
InventoryItem.expireDate in the past are still being
reserved against order items. Is this a bug?
I'd say yes. As an example companies producing food or
drugs will be in
trouble if they are selling stuff with an exceeded expire
date but I
could imagine there are companies who sell stuff even if
the expire date
has been reached.
So I think the default should be that inventory with an
expire date in
the past shouldn't get reserved but maybe add an option
(global, store
or product) to allow this.
I agree, for some products it may be important to still be
able to sell it after expiration. Perhaps there are a few
options that could be configured with an enum on the Product
entity:
1. Ignore Expiration Date
2. Don't Sell After Expiration
3. Sell At A Discount After Expiration
4. ...
On the other hand, maybe a true/false for allow sale after
expiration is sufficient because the inventory can be re-
assigned to another Product that represents the expired
inventory and is sold in a special store or at a special
discount.
Either way, I'd say we shouldn't add a rule that makes it
impossible to sell expired inventory unless it is
configurable with a per-Product option (and like Christian
said, perhaps with per-Store or other defaults).
-David
