Why does this need to be done manually? Is there a valid reason that a user might not want an AR document to move to history when it's paid or is this just one of those quirky legacy issues from when man carved notes with a chisel?
*This post is locked for comments
I would just like to add we tell our clients to advance the date on checks one month into the future. This is usually enough to accommodate any NSF checks. So if we are running PTR for June the dates for the invoices will be June and the dates for the checks will be July.
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.
Thanks Redbeard - I knew you'd have the answer :)
However, what about the company who wants to look up Open Invoices by Customer (with the customer on the phone) without running an aged trial balance? That scenario requires running Paid Transaction Removal daily. Would it be possible to fire off a macro that would run the PTR automagically when the user logs in to GP?
Frank,
Once you pull the trigger on this one, you can no longer handle an NSF transaction or reapply a payment to another invoice (in the case someone applied it to the wrong one).
The only companies I know who must run Paid Transaction removal at Month-End are publicly traded ones who should have their published financial statements frozen in carbonite.
I actually had one customer settle on making it part of the year-end process to perform Paid Transaction Removal for the prior year - a lot like how when you close a year in GP Financials, you are actually hard closing the prior year (Last year +1).
I believe users can un-check the Fully Paid Documents option in Receivables Aged Trial Balance with Options report, which suppresses all the documents that show up on the aging when PTR has not been run.
I wish I had an explanation, if I had one ... I would have been more convincing when a debate emerges with clients regarding this unusual process which comes against the general standard and consistent behavior of the other modules.
I do believe that there are many other similar points which have no proper justification, at least for me, such as:
My list could go on and on which could give a bad impression. Although, I should keep the credit that this is a very small portion that would never go beyond 1% of the system processes. So my answer is simply, it is a quirky legacy that we have to deal with.
Still, just like you Mr. Frank, wishing to hear a proper justification derived from a consistent financial or business process standard as we have always used with Dynamics GP.
André Arnaud de Cal...
291,969
Super User 2025 Season 1
Martin Dráb
230,842
Most Valuable Professional
nmaenpaa
101,156