Dynamics 365 Business Central – Posting a Payables invoice to multiple GL codes using a Purchase Journal

Introduction

As I learn and familiarise myself with Dynamics 365 Business Central I often post something in Dynamics GP and then wonder how this same task could be achieved in Dynamics 365 Business Central.

Today’s pondering was looking for the equivalent to the “Payables Transaction Entry” window that we have in Dynamics GP.

I know you can post to G/L accounts via the “Purchase Invoice” page in Dynamics 365 Business Central but to me this is primarily a “Purchase Order Processing” type window. I wanted to post a sundry payables invoice, onto a vendor, to multiple GL codes, without the need to touch the “Purchase Invoice” window.

As usual there is more than one way to do this however I focus on the “Purchase Journal” page. I also elude to why I think you can achieve the same using other “journal” pages, although you might not necessarily want to use those anyway 🙂

Dynamics GP – Payables Transaction Entry

In Dynamics GP you can post a sundry payables invoice in a very straight forward and easy to understand window called “Payables Transaction Entry”.

This window has no link to Purchase Order Processing. We tend to advise users to use this window for posting invoices for sundry items and things you wouldn’t necessarily have a Purchase Order for. You can click “Distributions” and record multiple GL codes for this one invoice. Its also handy to import transactions into very quickly and users seem to prefer this window for speed of entry.

Dynamics 365 Business Central – Purchase Journal

There are various “journal” pages in Dynamics 365 Business Central so I turned to the “Purchase Journal” page to achieve my goal.

The first thing I found I had to select was the option “Show more columns” as per below.

Crucially this adds the “Account Type” option which gives the user the ability to add “G/L Account” when keying in the Payables document:

Now I had the “Account Type” field available for entry I found as long as you keep the Document Number, External Document No and Posting Date the same you are able to add a payables document with multiple lines.

First you add the “Account Type” of “Vendor” and key in the first line with the total amount of the document. On the subsequent lines you can choose “G/L Account” as the account type and enter the G/L distribution breakdown. Also, if you wish to analyse tax to any of the distributions you must populate the “Gen. Posting Type” with “Purchases” and then populate the “VAT Prod. Posting Group”.

In the end you should have something like this and the document will post successfully

Other takeaways

As with any investigation you usually find some interesting things along the way.

The major takeaway I found is that you can post the same purchase invoice using the “General Journal” page. After looking more closely it seems this is possible as both pages are based on the “Gen. Journal Line” table. Therefore all the fields (and business logic) you need are available on the “General Journal” page as well.

See below. The “Purchase Journal” and “General Journal” pages are based on the same table:

Purchase Journal
General Journal

However, as a word of caution, if you were to post the same purchase invoice from the “General Journal” page the transaction is given a “Source Document” of “GENJNL” in the “G/L Register” rather than “PURCHJNL”.

See below. The top G/L Register was posted using the “General Journal” page and the other using the “Purchase Journal” page.

Therefore I’d suspect its best to use the specific “Purchase Journal” for these postings.

Thanks for reading!

Dynamics GP – Select Cheques routine looping because of duplicate key error in DEX_LOCK

A quick one but hopefully it will help someone else in the future.

We had an issue raised last week with a client running the “Select Cheques” routine in payables and although it appeared to be running normally it was taking much longer than usual and never seemingly completing.

As usual my first port of call is to run a SQL Profile Trace of the process (should probably be using extended events by now) to monitor exactly what’s happening.

When I setup an SQL trace I generally start with RPC:Completed and SQL:BatchCompleted as per below:

This image has an empty alt attribute; its file name is image-17.png

After running this trace I could see that the process seems to be showing a loop where’s its SELECTing data and them attempting to INSERT into the DEX_LOCK table over and over again for the same document:

To investigate further I stopped the trace and added “Errors and Warning” and restarted the trace again

The trace now shows the issue. The system is producing a duplicate key error when trying to INSERT into the DEX_LOCK table.

Because of this it seems to loop back and then try the INSERT again. The error isn’t being reported to the end user so they just think the process is running but taking longer than usual.

As expected when i query the DEX_LOCK table the row_id (42468782 – yes this client posts LOTS and LOTS of payables data) relates to the DEX_ROW_ID in the PM20000 for the document mentioned in the SELECT in the trace:

To fix the issue I deleted the offending row in the DEX_LOCK table as per below and the “Select Cheques” process continued as normal. (I didn’t even have to stop the “Select Cheques” process, I just deleted the row and it went through fine)

I hope this helps anyone else facing a similar issue.

Thanks for reading!

Dynamics GP – Error Message Invalid length parameter passed to LEFT or SUBSTRING function in Edit Payables Check Window

I encountered this error when a client was trying to select a vendor in the “Edit Payables Cheque Batch” window. A screen shot of the error is below

The error occurred when trying to select a vendor from the list in the left hand pane of the window.

To troubleshoot this I created a SQL trace to capture all the SQL statements and also any error messages when the error occurred. This highlighted the exact error and offending SQL statement as per below:

Next I copied the offending SQL statement to SQL management studio and ran it in a query window. (I do have to tweak it a little and I also checked it wasn’t going to do any updates or inserts that could cause data issues). This gave me the same error being returned by Dynamics GP

Now it was a question of finding all the LEFT or SUBSTRING statements, commenting them out, and re-running the query until it worked. After some trial and error I found when commenting out the highlighted portion of the SQL statement below it executed without error

Therefore I now know the issue is with the A.KEYSOURC field. At this point I suspected it was blank and therefore the LEN calculation is producing a 0. The alias A has been given to the PM20100 table so I queried this table for the vendor in question and as suspected there is a blank KEYSOURC for this vendor.

I therefore deleted this blank record using a simple SQL script

DELETE PM20100 WHERE VENDORID='<InsertVendorid>' AND KEYSOURC=''

And now I can successfully select the vendor in the “Edit Payables Cheque Batch” window.

I hope this helps explain the issue and also how it can be fixed if anyone else encounters this in the future.

Thanks for reading!

Dynamics GP – The remittance reprint is including a remittance for a different vendor

A client reported that when reprinting a remittance via the “Recreate Check Stub” option it was correctly reprinting the remittance however another remittance for a totally different vendor was also printing at the same time?

The option being used for the remittance reprint is below

To troubleshoot I looked at the main table used on the “Reprint Check Remittance” layout in report writer.

As you can see from the image above this is the “PM Remittance Temp” table which on investigation is the PM80950 table.

When I queried this table in SQL I found a single row and the Vendor ID matched that of the remittance that was being tagged onto the reprint.

I therefore removed this row from the table by running a DELETE statement in SQL and now when I reprint the remittance it prints correctly.

I hope this helps someone else in the future if they come across the same issue.

Thanks for reading

Dynamics 365 Business Central – A quick walk through a Payables Payment Run using Payment Journals

Introduction

Over the last few days I’ve been working through a vendor payment run in Dynamics 365 Business Central and thought it useful to document my journey.

In this step by step post I’ll be generating payments using the “Suggest Vendor Payments” feature and then also going through the process of removing an invoice from a payment as you would in real life.

Setup

To keep things simple before I started I created two vendors, V00080 and V00090, and posted a couple of documents on each vendor. I’ll use these as the basis for my walk through.

On the vendor I set the “Payment Method” as “Cheque” as per below (I’ll likely look at another post for EFT\BACS in the future)

Setup of one of the Vendors I created for my walk through

The documents I posted onto the vendors created the following vendor ledger entries which I’ll be working with:

As you can see I have two invoices on vendor V00080 with a total of £180.00 and two invoices and one credit note on V00090 giving a total of £240.00.

Payment Journal

In order to pay these documents I’ll be using the “Payment Journal” which can be found by clicking the search option and typing “Payment Journal”

Once in the “Payment Journal” page the first thing to select is the batch. As you can see I’ve selected one called PAYMENTRUN


If we drill down on the batch you can see it determines the balancing account and also the number series to use. I’ve select “Bank Account” as the balancing account so the system will create “Bank Account Ledger Entries” that I can later reconcile via the bank reconciliation.

Once we have decided on the batch we can turn to creating the payments.

Suggested Vendor Payments

The process that completes the initial swoop looking for transactions to pay based on a set of criteria is “Suggest Vendor Payments”

On clicking “Suggest Vendor Payments” you are presented with the following options

I’ll focus on the ones I’ll be using as part of my payment run for vendors V00080 and V00090

Last Payment Date:- This is the due date cut off. I’m going to set this to 31/07/19 as I don’t want to pay any invoices after this date.

Find Payment Discounts:- I’m going to switch this on because if there are any payment discounts, I want the payments that are created to reflect them.

Summarise per Vendor:- I’m going to switch this on because I only want to create one payment journal entry per vendor rather than one entry per invoice I’m paying.

Posting Date:- I’m going to set this to 14/08/19 as this is the date I’ll be paying the invoices.

Balance Account Type:- I’m going to set this to “Bank Account” as I want the system to create bank account ledger entries so I can reconcile the payment via bank reconciliation.

Bal Account No:- I’m selecting “CHECKING” as this is the bank I’ll be paying from.

Payment Type:- I’m selecting “Computer Cheque” as on this occasion I’ll be printing cheques.

Vendor No:- I’ll be entering a range of V00080..V00090 as I only want to pay those two vendors

Therefore my options are:

When i click OK I get the following payments generated for me.

Now the system has generated the payments we can go ahead and tweak them for what we actually want to pay.

Editing the Payments

As you can see the system has generated a Payment for Vendor V00080 of £60.00 and a Payment for Vendor V00090 of £240.00

To view the invoices that have been applied on the payment you click “Process > Apply Entries”

If I select this option on the payment of £60.00 on Vendor V00080 you can see the invoices applied:

As you can see above the system has applied INV00002 but hasn’t applied INV0001. This is because INV0001 has a due date of 01/08/19 which falls outside of the due date cut off I entered into the “Last Payment Date” field in the “Suggest Vendor Payments” window. I’m happy with this so I’ll click ok and move to the next payment.

If I highlight the payment for Vendor V00090 and click “Process > Applied Entries” I get the following screen:

The first thing to note is the system has included the credit memo on the payment run. This is great and exactly what I’d expected.

Next I’m going to remove INV90001 from the payment run as I’m not ready to pay this Invoice just yet. To do this I’ll highlight the line and click “Process > Set Applies-to-ID”. Doing this blanks out the “APPLIES-TO-ID” field and also sets the “AMOUNT TO APPLY” and “APPLN. AMOUNT TO APPLY” to £0.00 on the invoice as per below

This all seems fine however when you click OK it would appear the payment amount hasn’t been updated on the Payment Journal to reflect the change I made?

It would seem I have to manually update this or the system would still post a payment for £240.00 onto the account. i.e. the posted payment would remain open and there would be an amount remaining of £30.00 on it.

I therefore edit the payment amount on the header to £210.00 to reflect the new payment amount:

Printing the Cheques

To print the cheques you just need to select “Cheque > Print Cheques”

On clicking this option you are presented with the following options:

I’m going to leave all the defaults and click “Print” and select my printer.

After doing this the flag “Cheques Printed” is checked.

Posting the Payments

Once you have printed the cheques and are ready to post you can just click “Post\Print> Post” as per below

This will create the Vendor Ledger Entries and also Bank Account Ledger Entries as our “Balancing Account Type” is set to “Bank Account”.

If I now view the “Vendor Ledger Entries” I can see the payments have been posted and applied to the invoices.

Conclusion

I hope you have found this write up on the payment run useful. I’m sure I’ve left out some options that can be used and being new to the Dynamics 365 Business Central \ NAV world I’d be very interested to hear of other peoples experiences.

Thanks or 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