We had some PLT-STK transactions that were duplicated with no matching STK-PLT transacations, and now these duplicates got captured and are throwing off our Inventory/WIP in-transit account. I was able to at least reverse the duplicate transactions using the part tran BO to get our QOH correct, but how can I reverse these if they are hitting our in-transit account?
This was corrected (at least in part tran) to only have 1 PLT-STK transaction.
But were are seeing in Inventory/WIP that only 2 of these were properly deleted.
Are you 100% sure these are duplicates and not a problem with a BAQ?
If they are duplicates, then are there BPMs interfering with your data?
As for removing them, I don’t think there is a way out of the box to delete PartTran data.
Yes I’m 100% sure. Somehow the business object let us receive in a tf shipment multiple times. We have no customizations or BPMs that would affect this. We simply call the business objects we identify in a trace.
I’m not too concerned about the part Tran table transactions at this point, as I successfully negated the duplicates. I’m just more concerned about the financial aspect of this and where to start looking. Our INV/WIP report is off because it thinks some of these transactions are still in transit
Got it. So you have custom code that is doing this work for you. Bummer that you caught it in LIVE instead of testing.
It sounds like you need to review the resultant transaction as they process through. Unfortunately, its very hard to diagnose error in the GL comparative to correcting the transaction prior to posting, but in your case you have multiple partial transactions. I would hope that the Posting Engine would at least be able to continue balancing it, but you will have to write some correction Journals to bring your GL back into alignment.
Thanks Jason, im also coming to the conclusion as well that we need to just manually write-off/ correct the gl instead of backing these transactions out normally. The associated pack (when pulled up in TF shipment entry or receipt) doesn’t even show these lines anymore for these skus.
My first guess would be that the TO receipt was done (rcv’g 24), then “undone” 6 times (-4 each), and then received as just 4.
Check the systime and tran num for each of the part trans. If the system is doubling them up you’ll usually see nearly identical systimes and sequential tran nums…
We’ve reported a similar bug with PLT-STK transactions when an Inventory Transfer occurs for a part or lot that exists in another site from the one the user is currently in. When this occurs the Inventory Transfer BO creates a one sided PLT-STK PartTran record. Since this is a one sided transaction, the Posting Engine will not let you post a journal that is out of balance.
I do not know of a way to delete a PartTran record but you can change the GLTrans flag to false and the Posting Engine will ignore the PartTran record.
Thanks for the feedback everyone! I’m working on restoring a copy of our db from this time frame to see how we can best clean up this mess first before mucking up live even more. I’ll look into correcting journal entries, as well as that GLTrans flag setting, that seems like an interesting route as well.
Calvin,
I manually using the bl tester on the part tran BO flipped the signs to negative, they were all positive before, and to make matters worse we ran a data fix from epicor that fixed ones with matching stk-plt transactions but made the one sided transactions even worse. LOL my head hurts.
Because all of the transactions were posted we ended up doing a manual journal entry to correct the GL, at the advice of here and Epicor support. Thank you! This was a one time problem back in May and has not occured since.
All those trans use the same PackSlip number, and if you take the sum of the tran Qty’s it nets out to receiving 4 (from +26 - 4 - 4 - 4 - 4 - 4 - 4 + 4 = 4).
Go back and ensure that the TO Shipment of Pack slip 22357 was for a qty of 24. If it was, then there is still $229.40 in the Intransit account (20 x $11.47), and QOH of that part is off by 20.
If the TO shipment was originally for just 4, then you didn’t need to do anything. The 6 individual trans of qty (-4) each, would have reversed the receipt of 24. And the final receipt for 4, would have made everything square.
