We have a Part that shows an incorrect Running total. It turns out the error is in the very first transaction (last displayed in the grid)
There were no PartTrans before 3/9/17, yet after a PUR-STK receipt of 4 on 3/9, the Running Total shows 19.
A query of the PartTran Table for this part shows:
Why does the Part Tran History show a running total of 19 after the first transaction that increased QOH by 4? Especially when the Begin Qty for that trans was 0.
Also, why would the BeginQty be zero prior to the STK-CUS tran (red arrow)?
After a little digging, it looks like the BeforeQty and AfterQty aren’t what you think. They have to do with costing, and aren’t meant to be a record of the QOH prior to, and after the transaction.
But still no idea why the Running total shows 19 after the first receipt of 4. (heck, 19 isn’t even a multiple of 4, like if the receipt processed several times.)
Yes you will see a PUR-STK with a negative transaction quantity. If there
were any ADJ-CST transactions associated with that receipt it will show
those as negatives as well
Yes, after created PackID, if u removing the line item…it creates a negative TranQty…but it is the mystery why its showing 19 OH qty on first transaction of PUR-STK 4 qty.
The transaction date is not necessarily when the transaction happened. It might be useful to sort the transactions by system date. Also I would compare this running total balance in Transaction History to the balance in Stock Status (PartBin table if you run the report as of today). The running total in Transaction History may need to be updated with a standard Epicor fix program but the key to your data integrity is the balance in Stock Status.
Which “standard” Epicor fix program are you referring to? Is it conversion program 6430? If so, are you manually running it or do you have it automatically set to run on a schedule?
I only run Epicor fixes under Epicor’s direction. I do not know the
number. I just believe that most fields that summarize other data will
eventually develop an error and Epicor probably has a fix for it.
I’m wondering if anyone has run a conversion program such as 6430 on an auto schedule? We run 6430 each month manually and looking for a way to automate it.
First off, the TranDate for some of the transactions were back dated (TranDate of 3/20, SysDate 4/10). Perhaps it was some combo of a receipt being created in one fiscal period, and being deleted in another, that caused the QOH - PartTran mismatch. Turns out there were about 6 parts that had this mismatch. All had deleted receipts as well.
Epicor support directed me to run “Refresh PartBin QOH from PartTran” and “Refresh Part Quantities and Allocations”. These are not conversion programs. They are right on the menu:
The fact that these are prominent (and not implemented as a conversion) makes me think that QOH and PartTran’s can get out of synch so easily, that this is program had to be provided.
FWIW…
While working on a Running Total in a PartTran BAQ,
I ended up using a subquery to set the “signs” of the tran qtys (e.g. 1,0 or -1)
Then a running total calc field in the main query that sorted records by TranDate and TranNum, both in descenging order & that (finally) started matching up with the PartTranHistTracker.
