Hello Everyone,

In support we often get calls regarding Refund Checks being interrupted or errors associated with Refund Checks.  I wanted to provide insight on what happens during the Refund Checks Process and how to approach correcting these.

There are two common scenarios that we see. The first scenario is the Refund Process stopped before the transfer to Payables. The second scenario is it gets transferred to Payables and fails during the check process.

To start, what is the Refund Process doing?

The process is taking a Receivables Balance and transfer it to Payables Management to have a check created to be sent to the Customer/Vendor for the Credit Balance of the Customer or Specific Documents. Overall, RM creates a Debit Memo to offset the RM Balance and creates a Payables Misc. document to pay.

First, we need to understand the process so we know what document will need to be looked at when an issue occurs with this process.

  • Open the Refund Checks window.
    • Sales >> Transactions >> Refund Checks
    • Next, we need to define the information for the Refund process.
      • Enter the Check Batch ID that will be used.
        • This is the batch that will get used during the check process in Payables.
  • Select the Customer that you want to process the Refund for.
  • Select to do the Specific Documents for the Customer or the Customers entire Credit Balance.
  • Click Insert to open the Edit Refund Checks window
    • Mark what documents you want to be included in the Refund.
  • Then select the Vendor that the Check will be created for.

 

  • Once this has been selected and you click the Process button, what happens?
    • GP will create a batch called RMPMXFR ‘User ID’ in the Receivables module
      • This posts the Debit Memo in Receivables that the Credit Document being refunded gets applied to.
      • This batch is also used to transfer the values to the Payables RMPMXFER batch.
  • GP will then create a RMPMFXER Batch in Payables which posts a Misc. Charge to allow a check to be created for the amount of the Refund.
    • As these are system generated batches based on the user ID, only one can exist in each module for that user. If one already exists due to an failed Refund process, this can cause errors for the User if they try to do the process again because the system cannot create the batch as it is already exists.

 

  • The process will then use the RMPMXFER batch to transfer the balances to Payables. This process creates a Misc. Charge in the Payables modules to allow you to create a Check and apply to the Misc. Charge.
  • After the Transfer process is complete, the Print Payables Check window opens with the Batch ID that was used in the Receivables Refund Checks window.
  • You are then able to print and post the check which moves the Check and Misc. Charge to history in payables.

Most issues we see come from the Transfer process being interrupted. When this happens, this can cause error when attempting to do another refund or logging in gives a message pertaining to the Previous Transaction Level posting did not complete.

There are two common scenario that we see and will provide guidance on how I approach these.

Scenario 1: The Refund process did not make it to the Payables.

  • First, we need to determine what and where are our RMPMXFER batches are. I use the following statement to locate these.

Select * from SY00500 where bachnumb like '%RMPM%'

  • Once I know where the batches are, I review each of the documents assigned to the batch to determine what tables have been updated. This will most time give us the Document selected to be refunded by looking at the apply record.
    • These documents are:
      • Original Document selected to be refunded.
      • Debit Memo created from the Refund Process.
      • In support, we have a script called the All RM. This will pull the entire transaction from all tables to allow for review. If you do not have this, the following tables will need to be looked at.
        • Original Document being refunded.
          • RM00401 (Keys).
          • RM10101 (Work/Open Distributions).
          • RM20101 (Transaction Open).
          • RM20201 (Work/Open apply).
  • Debit Memo created from the process.
    • RM00401 (Keys)
    • RM10101 (Work/Open Distributions
    • RM10301 (Transaction Work)
    • RM20101 (Transaction Open)
    • RM20201 (Work/Open Apply).
  • Almost always the Original Document being refunded is fine and the Debit Memo is broken. However, the RMPMXFER batch is not available in the front end.
    • To clean up this type of scenario after reviewing the data, we could do the following.
      • Use the All RM to review the record.
      • Remove the Debit Memo record from SQL.
        • If it is available in the front end, you can delete this from the Receivables Batch window.
          • Sales >> Transactions >> Receivables Batches
          • If this updated the General Ledger, delete the batch or backout the Journal Entry dependent if it posted.
            • Financial >> Transactions >> Financial >> Batches
            • Reconcile Outstanding Document Amounts for the Customer to reset the Current Amount.
              • Sales >> Utilities >> Reconcile
              • Re-process the Refund again.

Scenario 2: The refund correctly posted and updated RM but the PM Side was interrupted.

  • For this scenario, I would do the following.
    • Verify where the RMPMXFER batches are.

Select * from SY00500 where bachnumb like '%RMPM%'

    • Use the All RM to verify where the RM Transactions are and if posted correctly.
    • We have an All PM that we use in support as well. If you do not have this, you will need to look at the following tables.
      • PM00400 (Keys)
      • PM10000 (Transaction work)
      • PM10100 (Distributions work)
      • PM10200 (Open Apply)
      • PM10300 (PM Payment Work)
      • PM20000 (PM Transaction Open)
      • PM30200 (Transaction History)
      • PM30300 (History Apply)
      • PM30600 (Distribution History)
      • GL10000 (Transaction Work)
      • GL10001 (Transaction Amounts Work)
      • CM20100 (CM Transaction).
  • Depending on where the data sits.
    • If the Misc. Charge posted fine and the RMPMXFER batch does not exist.
      • You can delete the PM Check Batch and recreate the check batch to pay the Misc. Charge created from the Refund process.
      • If the RMPMXFER batch exists and the Misc. Charge did not post.
        • I would delete the RMPMXFER batch.
          • If it is present in GP, this can be done in the Batch Entry window.
            • Purchasing >> Transactions >> Batches
            • If the batch is not able to be seen in GP but can be seen in SQL, it will need to be deleted in SQL from the SY00500 table. This will contain the Misc. Charge document
              • If this is done, it will not remove the transactions. You will need to remove the transaction from the tables in SQL as well once you have reviewed and determined where these sit within the tables listed above.
              • Delete the Check Batch.
                • Keep in mind, the Batch ID that we enter in the Refund Checks window is the name of the check batch.
                  • This can most times be deleted from the Payables Batch Entry window.
                    • Purchasing >> Transactions >> Batches
                    • I would then un-apply the Credit Document from the Debit Memo on the RM side.
                      • Sales >> Transactions >> Apply Sales Documents
                      • Pull up the Customer.
                      • Pull up the Credit Document.
                      • Un-mark the Checkbox for the Debit Memo.
                      • Close the window.
                      • Next, void the Debit Memo. The reason I do this is so we can re-do the process and have all the documents linked for a clean end result.
                        • Sales >> Transactions >> Posted Transactions
                        • Select the Customer ID.
                        • Document Type = Debit Memo.
                        • Verify the information.
                        • Click Void.
                        • Close the window.
      • Now you should be back to the way it was before the Refund was processed and can re-do the refund process.
        • Sales >> Transactions >> Refund Checks

This information is very basic. We always want to do our due diligence and review the data before any troubleshooting is done so we can make an educated decision on our approach.

There are multiple different scenarios that can occur with Refund Checks. The two scenarios above are the most common.

The greatest piece of information that I can provide when you are troubleshooting Refund checks is to get into test and manually enter one so you can review how a correct one looks as well as the documents that are coming into play.

Thank you for taking a moment to review the information above!