[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Order/Inventory Problem in all versions, proposed solution
- Subject: Re: Order/Inventory Problem in all versions, proposed solution
- From: Nigel Titley <..hidden..>
- Date: Sun, 10 Mar 2013 23:58:32 +0000
On 10/03/2013 08:55, Chris Travers wrote:
Well, it does break our workflows. However, changing the workflow will
be a moderate price to pay for not having to run stock checks so frequently.
I have discovered a corner case which leads to onhand numbers being
off. Here is my proposed solution along with the problem description.
In future versions we will want to think of how we categorize
inventory, but for now I think the proposed solution below is best.
The current approach is that if you "ship" or "receive" an order
inventory gets automatically added to or subtracted from the onhand
quantity for the parts. Similarly the ship column in the order is
filled in. When you go to convert the order to an invoice the program
detects whether the ship values are filled in and if they are, then
onhand numbers are not adjusted.
This works fine if orders are fully billed *or* if orders go through
the full shipping workflow, but if you enter ship numbers in the order
screen it does not adjust the inventory at all when this is converted
and this is a problem.
My proposed solution is to stop adjusting inventory on shipping and
receiving and only do so on invoice. This would provide a single
place where the inventory numbers are guaranteed to change, and this
would help. I would like to further verify that we have proper
accounting of goods shipped or received and not invoiced for inventory
counting purposes. We may need to do something regarding reporting
here, because this is a behavior change, but currently both approaches
have the capacity to create bad numbers, and I'd rather put in the
effort to make sure this is working and robust than decline to fix
something dangerously broken because it breaks workflows.
What does everyone think?