Well it has happened 3 times in two weeks – people asking why paid transactions are appearing on their monthly Customer Statements. It seems like an opportune time to get reacquainted with my old friend, the Paid Transaction Removal routine.
What does it do?
- Move fully paid/applied transactions from the “open” status to the “history” status (if system is configured to maintain history for sales/receivables)
- Consolidates all balance forward transaction amounts.
Why should I run it?
- It can speed up various receivables routines and processes.
- Customer Transaction inquiries are faster/more efficient as you can now distinguish between “open” and “history” documents using the checkbox options on the screen.
- SmartLists can be faster and more flexible as you can filter by open vs. history
- Statements can run faster and more accurately…if you define “accurately” as a statement with only open/unpaid invoices
Why wouldn’t I run it?
- Older versions of GP had issues with transactions that had been moved to history and users realizing later a mistake had been made in the receipt application. This has largely been addressed with the RM Transaction Unapply tool in the PSTL (a tool discussion for a different day). PSTL is currently available for free on GP 10 (yes I said GP 10) and later, but it will need to be installed.
- The RM Transaction Unapply tool doesn’t work with documents where a gain/loss or discount was posted at the same time as the original document. This means many multicurrency documents don’t work with RM Transaction Unapply due to the exchange gain/loss.
Please note the following as well:
- If this is the first time the routine is being run, it could take a long time to run (depending on volume of data), and it may create a noticeable lag in the system for users. It is recommended to complete the initial running when other users are not logged into the system. Subsequent running of the routine should be quicker depending on frequency and volume of transactions.
- If the system is NOT configured to maintain history for Sales/Receivables, this routine with DELETE those transactions that would normally move to history if you were maintaining history. To set history settings go to Tools>>Setup>>Sales>>Receivables>>Options and Tools>>Setup>>Sales>>Sales Order Processing.
- If you are sending monthly customer accounts receivables statements and you want paid transactions to show on statements, you should run paid transaction removal AFTER running monthly statements. If you want to show only invoices with balances (i.e. nothing that’s been paid), you should run the routine BEFORE printing monthly statements.
To complete the Paid Transaction Removal routine, please do the following:
- Log into GP and Select Company (if multiple companies or you don’t have a default company login set)
- Navigate to Sales>>Routines>>Paid Transaction Removal
- This will open the Paid Transaction Removal window. Here you can choose a variety of options related to how the Paid Transaction Removal routine will function.
- Determine if you want to run the routine for ALL customers (default setting) or if you want to toggle from “All” to “From”/ “To” and identify a range of customers.
- Determine if you want to run the routine for ALL Customer Class ID’s or if you want to toggle from “All” to “From”/ “To” and limit the class ID’s the routine runs for.
- Identify which document types you want the routine to run against by checking the boxes next to the document types under the “Remove” heading.
- In the first Cut Off Date field, identify a cutoff date for all documents except checks (cash receipts). Documents must meet all criteria established in steps 4-7 to be removed/transferred to history.
- Enter a cutoff date for checks (this is the second cutoff date).NOTE: Checks have a separate cutoff date because those that are transferred to history or removed from the system can’t be marked as NSF. Because of this, Microsoft recommends that you enter a check cutoff date that is one month prior to the transaction cutoff date to avoid moving any potential NSF checks to history too soon. If NSF are not an issue (or are rarely an issue) for your company, you may set the check cut off date to the same date as the transaction cutoff date.
- Mark whether to consolidate balance forward customer accounts. If you mark this option, all documents for the balance forward customer are summarized and moved from the current aging period to the noncurrent aging period. A Customer is either “Open Item” or “Balance Forward” customer.
- Open Item – Individual transaction information is saved and detailed on customer statements until the transaction is removed through paid transaction removal.
- Balance Forward – Transaction information is retained only for the current period and is then consolidated into an account total that is brought forward at the beginning of each subsequent period.
- Mark Print Register to print a Removed Transaction Register. After the transactions are removed, the report is printed, and all the removed transactions are displayed if this option is selected.
- Choose Process to remove the selected transactions. The report is printed if you chose to print it. If not, the screen will revert to the original default or blank fields as a signal it is complete.
This routine certainly isn’t new, but the number of times I hear clients ask about paid invoices on statements or see users here on GPUG pose similar questions just highlights that it’s a function worth talking about!
If you have any questions about whether running the Paid Transaction Removal Routine is the right move, don’t hesitate to ask!
