New April Hotfix and more changes for VAT
Check out the latest updates to Microsoft Dynamics GP 2016 and 2018.
Dynamics 365 2019 release wave 2 plan Discover the latest updates to Dynamics 365.Release Plan | Weekly Deployment Notes
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants.Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements.
ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
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.
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.
Select * from SY00500 where bachnumb like '%RMPM%'
Scenario 2: The refund correctly posted and updated RM but the PM Side was interrupted.
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!
Business Applications communities