IMINVBIN qtys not matching IMINVLOC qtys ??

[jaustill]

Macola Progression 7.6.400b running on a mssql server

I have had continuous daily problems with my IMINVBIN_SQL quantities getting out of synch with my IMINVLOC_SQL quantities. I believe what is happening is that an "I" type order is entered into the system with a qty ordered and a qty marked to ship and the invoice is not printed. Then a few days later that item that was marked to ship is deleted from the "I" type order.
The result is that the BIN "qty_on_hand" increases by the amount that was deleted when it should have stayed the same and the BIN "qty_allocated" qty stays the same as before the item was deleted when it should have decreased.

HOWEVER
If an "I" type order is entered into the system with a qty ordered and zero (0)qty marked to ship and the invoice is not printed. Then a few days later that item is deleted from the "I" type order.

The result is that the BIN "qty_on_hand" stays the same and the BIN "qty_allocated" qty decreases by the amount that was deleted. It should have stayed the same, because it was not allocated before.

Seems NOT to happen with "O" type orders.

Is anyone else seeing that type of problem??

Is anyone else using BIN's?

 

[kscheeler]

Are you set up for confirm ship?

Kevin Scheeler

 

[jaustill]

We are not setup for confirm ship

 

[dgillz]

A qty ordered, even if the qty to ship is zero, should still allocate the items. So deleting the order should reduce the allocations.

The Qty on Hand is another matter altogether, as Kevin points out if you are not using confirm pick or ship entering any type of order should never affect qty on hand.

Are you using hard allocation? I will try to recreate the error.

Software Sales, Training, Implementation and Support for Macola, eSynergy, and Crystal Reports

http://www.gainfocus.biz

"What version of URGENT!!! are you using?

 

[jaustill]

Yes, we are using hard allocation.

 

[jaustill]

Is anyone else using BIN's?
Is anyone using BIN's not having this problem?