Dynamics GP Receivables: Resolving Payment Unapplication Issues After History Transfer

Table of Contents

This article addresses a common challenge encountered by users of Microsoft Dynamics GP, specifically within the Receivables Management module. The issue arises when attempting to unapply a payment that has already been transferred to the history tables. Understanding the limitations and available workarounds is crucial for maintaining accurate financial records and efficient operations within Dynamics GP.

This document will outline the symptoms of this issue and provide practical, step-by-step solutions to resolve it, ensuring you can effectively manage your receivables even after transactions have been moved to history. Whether you are a seasoned Dynamics GP user or relatively new to the system, this guide aims to provide clarity and actionable steps to overcome this particular obstacle.

Symptoms¶

The primary symptom of this issue is the inability to unapply a payment within Receivables Management after it has been transferred to the history tables in Microsoft Dynamics GP. This means that once a payment record has been moved to history, the standard functionality within Dynamics GP to unapply that payment becomes unavailable.

This situation can be problematic for several reasons. For instance, you might need to unapply a payment due to:

• Incorrect Application: The payment was initially applied to the wrong invoice or customer account.
• Payment Reversal: A customer needs to reverse a payment for various reasons, such as insufficient funds or a billing dispute.
• Data Correction: Errors were made during the payment application process, and unapplication is necessary to rectify these mistakes.

When you attempt to unapply a historical payment, the system will typically not allow the action, often without providing a clear error message explaining the limitation. This can lead to confusion and frustration as users try to resolve discrepancies or make necessary corrections in their receivables data. Recognizing this symptom is the first step towards implementing the appropriate workaround to address the issue effectively.

Workaround 1: Remove the Payment and the Applied Documents from the History Tables¶

One effective method to address the inability to unapply payments in history is to remove the payment and the associated applied documents directly from the history tables. This approach essentially reverses the history transfer for the specific transactions in question, allowing you to then unapply the payment and make necessary adjustments. This workaround involves using the “Remove Receivables Transaction History” window within Dynamics GP.

Here’s a detailed breakdown of the steps involved in using this workaround:

1. Access the “Remove Receivables Transaction History” Window: The navigation path to this window varies slightly depending on your version of Microsoft Dynamics GP.

   • For Microsoft Dynamics GP 10.0: Navigate to the Microsoft Dynamics GP menu, then point to Tools, then Tools, then Sales, and finally click Remove Transaction History.
   • For Microsoft Dynamics GP 9.0 and Microsoft Business Solutions - Great Plains 8.0: Go to the Tools menu, then point to Utilities, then Sales, and click Remove Transaction History.

   

   Upon accessing this window, you will be presented with options to specify the range of history to be removed. It is crucial to use this window with caution, as removing history data is a permanent action and can impact your audit trail and historical reporting.

2. Specify the Transactions to Remove: Within the “Remove Receivables Transaction History” window, you will need to define the criteria for the transactions you wish to remove. This typically involves specifying a date range, document numbers, or customer ranges. It is absolutely critical to carefully and precisely define this range to ensure you are only removing the specific payment and applied documents that you need to unapply. Removing incorrect transactions can lead to significant data integrity issues.

   • Document Number Range: This is often the most effective method for targeted removal. If you know the document numbers of the payment and the invoices it was applied to, you can enter these specific document numbers to ensure only those transactions are removed.
   • Date Range: You can also use a date range, but this is less precise and carries a higher risk of removing unintended transactions if you are not careful. If using a date range, make it as narrow as possible to encompass only the transactions in question.
   • Customer Range: In certain scenarios, you might need to remove history for a specific customer. However, similar to date ranges, using customer ranges requires extra caution to avoid removing more data than intended.

   Before proceeding with the removal, always double-check the criteria you have entered to verify that it accurately targets only the intended payment and applied documents. Consider running a test in a non-production environment if you are unsure about the outcome.

3. Execute the Removal Process: Once you have carefully defined the transaction range, click the “Process” button within the “Remove Receivables Transaction History” window to initiate the removal. The system will then delete the specified transactions from the history tables. This process is irreversible, so ensure you have backups in place and are absolutely certain about the transactions you are removing.

4. Re-enter the Payment and Applied Documents: After successfully removing the transactions from history, you will need to re-enter the payment and the applied documents into the open Receivables Management tables. This will essentially recreate the transactions as if they were newly entered, allowing you to then unapply the payment as needed.

   • Re-enter Invoices (if necessary): If the applied documents were invoices that were also moved to history and need adjustment, you will need to re-enter these invoices as well using the Receivables Transaction Entry window. To access this window, navigate to Transactions on the Sales menu, and then click Transaction Entry. Enter all the details of the original invoice accurately.

     

   • Re-enter the Payment: Re-enter the payment using the Cash Receipts Entry window. To open this window, go to Sales on the Transactions menu, and then click Cash Receipts. Enter all the payment details exactly as they were originally recorded.

     

5. Unapply the Payment: With the payment and applied documents re-entered into the open tables, you can now proceed to unapply the payment using the standard unapply functionality within Dynamics GP. Navigate to the appropriate window (e.g., Cash Receipts Entry or Customer Maintenance) and unapply the payment from the incorrect document.

6. Address General Ledger Impact (Important Note): Removing and re-entering transactions can have implications for your General Ledger. When you re-enter the transactions, Dynamics GP will typically create new General Ledger batches. If you do not want these re-entered transactions to update your General Ledger (especially if you are correcting historical data), you must take additional steps.

   • Delete the General Ledger Batch: After re-entering the transactions, check for newly created batches in General Ledger (Navigation: Transactions -> Financial -> Batches). Identify the batch(es) created by your re-entered transactions and delete them before posting. This will prevent the re-entered transactions from affecting your General Ledger balances.

   • Post Reversing Transactions: Alternatively, instead of deleting the batch, you could post reversing transactions in General Ledger to offset the impact of the re-entered transactions. This method is more complex but might be preferred in situations where you need a record of the re-entry process in your General Ledger audit trail. Consult with your accounting team to determine the most appropriate approach for your specific needs.

Cautionary Considerations for Workaround 1:

• Data Loss Risk: Removing history is a destructive process. Incorrectly removing transactions can lead to permanent data loss. Always back up your Dynamics GP database before performing history removal.
• Audit Trail Impact: Removing historical transactions will affect your audit trail. It is important to document the reason for removing history and the steps taken to rectify the issue for audit purposes.
• General Ledger Reconciliation: Carefully manage the General Ledger implications of this workaround. Deleting batches or posting reversing entries requires accounting expertise to ensure accurate financial reporting.
• Complexity: This workaround involves multiple steps and requires a good understanding of Dynamics GP navigation and transaction entry processes.

Despite these considerations, Workaround 1 can be a viable solution when you need to unapply historical payments, particularly if you are comfortable with the process and take the necessary precautions.

Workaround 2: Use the Transaction Unapply Tool¶

A more streamlined and often preferred method for unapplying payments in history is to utilize the Transaction Unapply tool found within the Professional Services Tools Library (PSTL) for Microsoft Dynamics GP. PSTL is a collection of valuable tools designed to enhance the functionality of Dynamics GP and provide solutions to common challenges. The Transaction Unapply tool specifically addresses the issue of unapplying historical transactions by automatically moving records from the history tables back to the open tables.

Here’s how to leverage the Transaction Unapply tool:

1. Install and Access the Professional Services Tools Library (PSTL): PSTL is not installed by default with Dynamics GP. You will need to download and install it separately. Typically, PSTL is available for download from Microsoft or your Dynamics GP partner. Consult your Dynamics GP partner or Microsoft documentation for the correct download source and installation instructions for your specific Dynamics GP version.

   Once installed, PSTL is usually accessed through the Dynamics GP menu (e.g., Microsoft Dynamics GP menu -> Tools -> Professional Services Tools Library).

   

2. Open the Transaction Unapply Tool: Within the PSTL window, locate and select the Transaction Unapply tool. Double-click on it to open the Transaction Unapply window.

   

3. Specify Transaction Criteria: The Transaction Unapply window will typically provide options to specify the transactions you want to unapply. This might involve selecting transaction types (e.g., Payments, Invoices), document numbers, customer ranges, or date ranges.

   • Document Number: The most precise method is to enter the specific document number of the payment you want to unapply. This ensures you are targeting the correct transaction.
   • Customer and Date Range: You can also use customer and date ranges to narrow down the selection if you don’t have the exact document number. However, using ranges requires careful consideration to avoid unintentionally unapplying other transactions.

4. Process the Unapplication: After specifying the transaction criteria, click the “Process” or “Unapply” button within the Transaction Unapply tool. The tool will then automatically:

   • Move Records to Open Tables: The Transaction Unapply tool intelligently moves the selected payment and related applied documents from the history tables back to the corresponding open transaction tables in Receivables Management.
   • Maintain Data Integrity: PSTL is designed to maintain data integrity during this process. It ensures that the relationships between the payment and applied documents are preserved when moving the records back to open tables.

5. Verify Transactions in Open Tables: After the Transaction Unapply tool completes its process, it is essential to verify that the payment and related documents have been successfully moved back to the open Receivables Management tables. You can do this by:

   • Checking Customer Inquiry: Navigate to Customer Inquiry and search for the customer associated with the unapplied payment. Verify that the payment and the applied documents are now visible as open transactions.
   • Reviewing Open Transaction Windows: Check the Cash Receipts Entry window or Receivables Transaction Entry window to confirm the presence of the moved transactions in the open tables.

6. Unapply the Payment (Standard Dynamics GP Functionality): Once the payment is back in the open tables, you can now use the standard Dynamics GP unapply functionality to unapply the payment as needed. Navigate to the appropriate window (e.g., Cash Receipts Entry or Customer Maintenance) and proceed with the unapplication process.

Advantages of Using the Transaction Unapply Tool (PSTL):

• Simplicity and Efficiency: PSTL simplifies the process of unapplying historical payments, making it much faster and less error-prone than manually removing and re-entering transactions.
• Data Integrity: PSTL is designed to maintain data integrity during the move from history to open tables, reducing the risk of data corruption or inconsistencies.
• Reduced Risk: Using PSTL is generally less risky than manual history removal, as it automates the process and minimizes the chances of human error.
• Reversibility: While PSTL moves transactions, it is generally easier to manage and reverse the process if needed compared to completely removing history data.

Considerations for Using the Transaction Unapply Tool (PSTL):

• PSTL Availability: PSTL is not a standard component of Dynamics GP and needs to be downloaded and installed separately. Ensure you have access to PSTL and that it is compatible with your Dynamics GP version.
• PSTL Licensing (Potentially): In some cases, PSTL or certain PSTL tools might require a separate license. Check the licensing requirements for PSTL and the Transaction Unapply tool with your Dynamics GP partner or Microsoft.
• Testing Recommended: Even with PSTL, it is always recommended to test the Transaction Unapply tool in a non-production environment first to understand its behavior and ensure it meets your specific needs.

Overall, the Transaction Unapply tool in PSTL provides a significantly more user-friendly and efficient solution for unapplying historical payments in Dynamics GP Receivables Management compared to manually removing history data. It is generally the recommended approach if PSTL is available and accessible in your Dynamics GP environment.

---

Both Workaround 1 and Workaround 2 offer solutions to the challenge of unapplying payments after history transfer in Dynamics GP. The choice between these methods often depends on factors such as the availability of PSTL, your comfort level with manual data manipulation, and the criticality of maintaining a detailed audit trail. Carefully evaluate the pros and cons of each approach in the context of your specific business requirements and Dynamics GP environment to determine the most suitable solution for your needs.

We encourage you to share your experiences and questions regarding unapplying payments in Dynamics GP Receivables Management in the comments below. Your insights can be valuable to other users facing similar challenges.