Item Transaction Inquiry not reconciling to On Hand Qty

[Luvsql]

Item A in the Inquiry > Inventory > Item Transaction for Site A yields the following:

Receipt 12/11/2003 Qty 12
Variance 17/7/2004 Qty (12)
Receipt 1/9/2004 Qty 8
Receipt 1/9/2004 Qty 3
Receipt 1/22/2004 Qty 5
Receipt 1/22/2004 Qty 6
Adj 1/22/2004 Qty(1)
Adj 1/22/2004 Qty(2)
Tranfer 1/23/04 Qty 1

According to this, I would have a total of 20. However, the Transfer on 1/23/2004 is transferring FROM Site A TO Site B. Why is this not a negative? As well, this does not show in the purchase receipts. At the very end, if I add up the quantities from this report, using (1) as the qty for Site A, I should have On Hand 4. GP says 6.

If I look at the transactions for Site B, the transfer does not show at all. The total qty is 2, which matches the On Hand, but where is the increase of the 1 from the transfer?

From what I calculate, Site A should be 4 instead of 6 and Site B should be 3 instead of 2. When this item has a cost of over $2000, you can see my issue.

We have over 10,000 items. I can't check every single one. How are we supposed to reconcile if the transactions are not showing correctly, the purchase receipts is different from the transaction inquiry, stock status is wrong because it pulls from the incorrect purchase receipts.

Are we not supposed to be able to count the quantities from the Item Transaction Inquiry correctly then match that to our On Hand??

 

[stef315]

Did you try reconciling the item? Utilities-Inventory-Reconcile

 

[Luvsql]

Yes, but inventory reconcile only reconciles what's in the IV00102 (quantity master) to the IV10200 (purchase receipts table). It doesn't go through every transaction detail for each item, update the purchase receipts, then update the IV00102. If the purchase receipts in incorrect, reconcile won't fix anything. This is what the stock status uses also.

 

[jazgeek]

This is probably one of the reasons why the historical stock status report doesn't work sometimes.

I have a crystal report that summarizes to a point in time from the IV10200 table and I can see direct errors in the table due to posting screwups and crashes.



-----------
and they wonder why they call it Great Pains!

jaz