Dynamics 365 Business Central: Posting a Sales Refund and applying to a Credit Memo

Introduction

I come from a Dynamics GP background and I’ve always found the process for refunding in Dynamics GP to be rather long winded and not very intuitive. The main issue is there’s no specific option for creating a refund, so I was very interested to test out the option in Dynamics 365 Business Central.

In this article I’ll first explain a potential scenario when a refund would need raising and applying to a credit note, then briefly explain how I’d do this in Dynamics GP, before finally going through the refund process in Dynamics 365 Business Central.

The Scenario

The scenario is as follows:

A customer buys some goods so we issue an invoice. The customer sends us payment which we apply to the invoice however they subsequently send the goods back so a credit note is issued. Finally some time later the customer requests their money back as they aren’t planning on doing business with us anymore.

Therefore, prior to issuing the refund, the account would have an Invoice applied to a Payment and a unapplied Credit Memo as per below

To complete the process we now need to issue the customer with a refund and apply this to the credit memo.

Dynamics GP

In Dynamics GP its not possible to post a “Refund” type cash receipt and apply it to the credit memo. One solution would be to void the credit memo and post a “Return with cash” similar to below:

Alternatively you could post a debit type document, apply this to the credit memo and then create the customer in payables and post a payment, however both cases aren’t ideal. (you can also use “Refund Cheques”, but again this involves having the customer setup in payables which again isn’t ideal)

Dynamics 365 Business Central

In Dynamics 365 Business Central you can post a “Refund” and apply it to the “Credit Memo” using the “Cash Receipts Journal”. Below are the steps to achieve this:

First go to the “Cash Receipt Journal” page:

Enter the refund as per below:

Next apply this to the credit memo we are refunding:

And then post the Cash Receipt Journal.

If we now review the account we can see the refund has been successfully applied to the Credit Memo.

Conclusion

I do like this functionality in Dynamics 365 Business Central. Its intuitive and doesn’t require lots of different steps. Although I’m a firm fan of Dynamics GP I do find this an improvement when compared to the current functionality available in Dynamics GP.

Thanks for reading.

Dynamics GP – Error “Install Microsoft Word” when emailing a large number of Customer Statements

A client was experiencing the error “Install Microsoft Word” on the exception report for lots of statements when emailing a high volume of customer statements when running Dynamics GP 2013.

After searching online I found the following thread in the community forum https://community.dynamics.com/gp/f/32/t/137272

This mentioned the exact same issue and a user named Pam Robertson posted to advise of a fix in later versions of Dynamics GP.

I was curious to find this in the Microsoft documentation so I tracked down the fix list for Dynamics GP 2013 and a fix is indeed listed as per below for version 12.00.1920

I’ve since installed this at the client and can confirm it fixed the issue!

Therefore if you are on Dynamics GP 2013 (version 12.00.1920) or earlier and running into this issue applying this service will fix the issue.

A very quick post but I thought it worth putting out there in case anyone else encounters this issue and needs the evidence to show this is fixed in a later version of Dynamics GP.

Thanks for reading.

Dynamics GP – Error “This transaction contains multi – currency errors and can’t be posted” when posting Multi Currency Transactions

A client reported the following error on the posting journals when trying to post both Receivables and Payables Transactions. “This transaction contains multi-currency error(s)”

This transaction contains multicurrency errors

This was followed by a message informing them that the batch had gone to recovery.

I checked the usual things like exchange rate expiration dates however everything seemed fine.

The client then explained they had overwritten some exchange rates accidentally but had since changed these back however the error persisted.

I delved a little deeper using SQL and noticed that although the dates and rates were the same the TIME1 value in the MC020102 table for the transactions differed slightly from the TIME1 value in the DYNAMICS..MC00101 for the exchange rate in question.

Affected transaction showing differing TIME1 value from setup

As a test I changed one of the transactions by updating the TIME1 value in the MC020102 table to match the relevant TIME1 row in MC00100 using the script below.

UPDATE MCTRX 
SET    MCtrx.time1 = MC.time1 
FROM   mc020102 MCTRX 
       INNER JOIN dyn2018r2..mc00100 mc 
               ON mc.exgtblid = MCTRX.exgtblid 
                  AND mc.xchgrate = MCTRX.xchgrate 
                  AND mc.exchdate = MCTRX.exchdate 
WHERE  MCTRX.docnumbr = 'SALES00000001004'   

I then printed an edit list of the batch and the error had gone.

Now I knew how to fix the issue I realised I could also resolve this by just opening the transactions in the entry window and re-selecting the exchange rate however there were 1000’s of affected transactions so I used the script below. (this was affecting all multi currency transactions in WORK batches so I just had to filter on DCSTATUS)

UPDATE MCTRX 
SET    MCtrx.time1 = MC.time1 
FROM   mc020102 MCTRX 
       INNER JOIN dyn2018r2..mc00100 mc 
               ON mc.exgtblid = MCTRX.exgtblid 
                  AND mc.xchgrate = MCTRX.xchgrate 
                  AND mc.exchdate = MCTRX.exchdate 
WHERE  mc.time1 <> MCTRX.time1 
       AND DCSTATUS = 1   --add this so only WORK trx are affected

After running this script all sales transactions posted fine.

Next I turned to the payables transactions which just involved a small tweak to the original script and also an update to a different table to correct currencies for the multi currency payables payment batch header.

--First fix Payables multi currency trx

UPDATE MCTRX 
SET    MCtrx.time1 = MC.time1 
FROM   mc020103 MCTRX --Changed to MC020103 for payables trx 
       INNER JOIN dyn2018r2..mc00100 mc 
               ON mc.exgtblid = MCTRX.exgtblid 
                  AND mc.xchgrate = MCTRX.xchgrate 
                  AND mc.exchdate = MCTRX.exchdate 
WHERE  mc.time1 <> MCTRX.time1 
       AND DCSTATUS = 1 

--Also fix the batch header currency values for payment batches 

UPDATE batch 
SET    batch.time1 = mc.time1 
FROM   mc00500 batch --batch header multi currency table 
       INNER JOIN dynamics..mc00100 mc 
               ON mc.exgtblid = batch.exgtblid 
                  AND mc.xchgrate = batch.xchgrate 
                  AND mc.exchdate = batch.exchdate 
WHERE  mc.time1 <> batch.time1   

Once I’d ran through all this the transactions posted fine.

Hopefully this will help someone in the future who may face a similar issue however always remember to have a good backup of your data before running any SQL scripts and test whenever possible.

Thanks for reading