If you sum the CR Amt’s, they equal the sum of the DB Amt’s.
So it looks like an inventory transaction somehow generated different tran dates for the DB and the CR sides.
The offending transaction appears to be a STK-PLT transaction.
Turns out only half of a STK-PLT is getting pulled in on 8/22, and only half of a PLT-STK on 8/28.
When I run the WIP Recon report for just 8/22, I see a STK-PLT tran with a credit of $281.22 to our INV acct, but no matching DB
When I run the WIP Recon report for just 8/28, I see a PLT-STK tran with a DB of $281.22 to the destinations INV acct, but no matching CR
Normally a STK-PLT uses Accts 1151-00 (Inv-Plant A) and 1165-18 (InTransit-Plant F). With the PLT-STK vice-versa - 1165-18 (InTransit-Plant F) to 1151-18 (Inv-Plant F)
Site F was recently added, but it has all the GL accts and GL Controls required.
Any way to figure out what other account is trying to be used for the STK-PLT and PLT-STK trans?
All of those accts are valid
We’ve been doing Transfer Orders for a couple of years now.
Combining the following with your first picture,
Shows that the more complicated side (the CR side) is happening, but the DB side isnt.
The In-Transit account is setup - one for every site. We’re using Division GL Control to substitute the division segment, and its been working for years.
If it were possible to “un-receive” a TO Rcpt, I would. And then “un-ship” the TO Shipment. But you can’t un-receive a TO.
I am having the same situation of an unbalanced transaction on a STK-CUS transaction. One packing slip somehow created an unbalanced transaction and is holding up the entire day’s posting. I am going to ask Epicor support for help as there is no way I can fix this. The packing slip is already invoiced.
That’s what it was. I had setup the all Plant Transfer GL Controls on this new site (as xfers from this new site TO each of the existing sites). But failed to set them up as xfers from the existing sites to the new site.