RE: Receivables - Paid Transaction Removal
Thanks Frank!
My typical advice to companies who are not publicly held is to run Paid Transaction removal for the prior month (Cutoff of June 30 when running PTR on July 31) as part of their Month-End Close Checklist.
This normally minimizes the white noise created by fully applied transactions. The problem with running this anytime sooner, is you run the risk of encountering an NSF transaction, or the need to reapply a payment, after you've removed the option.
I agree wholeheartedly it would be a better approach to move the transactions to history without manual intervention of PTR, and provide the capacity to process NSF/reapply a transaction if necessary, like voiding or correcting a journal entry, instead of entering its inverse transaction.
Final thought - one of the things that makes Dynamics GP an Enterprise system, is architecture. There are Work, Open and History tables and overt actions move transactions from one table to another. Paid Transaction Removal moves cash applications to history tables, improving the performance of related windows and reports.
Any "half-measure" like flipping a flag or updating a status field value, might ultimately negatively impact performance, as the cash applications table filled up what are effectively open transactions, because running the PTR process would no longer be a necessity. Think of the future forum posts - Why is cash application so slow? Why does my aging report take forever to run? LOL.