Dynamics GP Receivables Aging is Too BIG, long, many pages...

I was recently working with a new customer on an upgrade. As part of the upgrade process, I have clients print various reports for comparison (before and after) the upgrade process. Typically I advise clients to print these reports to PDF, or similar file format. Some print outs can be quite large.

In this instance, the Receivables Aging report was more than 1500 plus pages long. So, I asked, "what's up with that?" Turns out, their previous partner had told them, "that was just how GP worked." Rarely do the words , "that's just wrong"  escape my mouth when criticizing my predecessors. I usually say things like that's not the approach I typically recommend, or something similar, acknowledging the possibility users were presented alternatives and may have selected the alternative of their own accord.

In this case, it is safe to say, the partner providing this information was wrong. If you have assumed the Receivables Aging report perpetually grows, or have been told this by someone, allow me to disabuse you of this notion.  There is a mechanism in GP, which can be used to shrink the aging by moving fully applied payments to history.

This tool, which can be misunderstood by users and consultants, is called Paid Transaction Removal...  Sales > Routines > Paid Transaction Removal

I believe the thing that puts people off about this feature is the use of the word Removal. In reality the routine moves transactions to history, which occurred before the specified cutoff dates. 

This process, when run, will “set in stone” cash applications for past documents, and prevent NSF transactions from being processed on payments within the Cut Off date. My recommendation to clients is leave enough cushion within the cutoff date to allow normal processing of NSF transactions, and changes in Cash Application.  

Some clients, do this at the end of every month (i.e. publicly traded companies), and others leave a full year open by processing at year end with a cutoff date of the year before (i.e. 12/31/2013 when closing 2014).  This makes a lot of sense, because closing a year, actually hard closes the prior year, and adjustments can be made to the last closed year in GP. 

As with any major update to the database, you should have a backup handy, should things not go exactly to plan.  It is also possible/recommended to update your test database, so you can run this process there to get an idea of the impact.  

When this process was run by a client who had not done it, ever, it took some time to run, so if you are in a similar situation, I would recommend you run this process when you have exclusive access to GP, and no one is going to need to use it for the duration of this process.