Dynamics GP – What are the P/L Source Document entries on the year end journal?

When you run the year end routine on the General Ledger in Dynamics GP the system automatically creates a journal to bring forward the balances for the Balance Sheet codes and it also closes all the profit and loss codes to the retained earnings account.

When you look at the header of the year end journal that’s created it shows a source document of BBF (Balance Brought Forward)

However if you take a closer look at the year end journal in smartlist you can see that some of the lines have a source document of “P/L”.

So why the mixture of BBF and P/L source documents for the year end journal?

The BBF entries are created to bring forward the balances of the “Balance Sheet” accounts and the “P/L” entries are created by closing the profit and loss accounts to the retained earnings account. As my demo data has multi currency postings to various profit and loss codes I get one entry per currency.

To confirm the correct amounts have been posted to the retained earnings account I can run the query below in SQL that sums all the amounts posted to the profit and loss accounts for the year 2024, and this reconciles back to the amounts posted to the retained earnings account on the year end journal:

The BBF entries are quite well known but I couldn’t find much information on the P/L source document which is why I created this post.

Thanks for reading!

Dynamics GP – Error message “Unhandled script exception: SCRIPTS – data area” opening the Payables Enquiry window

I’m come across this error a few times so thought I’d document on my blog.

The user is presented with the below error when opening the “Enquiry > Purchasing > Transaction by Document” window in Dynamics GP

When the window does open there’s a blank record showing in the scrolling window:

When you expand the window and attempt to select it you are prompted with the message “The selected record has been deleted by another user” and it disappears from the window

In this particular instance the issue is being caused by an incorrect PM Keys Record in the PM00400 table.

If I search for an incomplete record in the PM00400 table using the SQL query below this returns one record:

SELECT * FROM PM00400 
WHERE VENDORID='' AND DCSTATUS=3 AND DOCNUMBR='' AND DOCTYPE=0

If I then remove this record using the DELETE statement below the error no longer occurs when I open the window

* Always ensure you have adequate backups prior to deleting data from SQL

DELETE FROM PM00400 
WHERE VENDORID='' AND DCSTATUS=3 AND DOCNUMBR='' AND DOCTYPE=0

Please note you could also delete the entire contents of the PM00400 table and have the system recreate it using checklinks however this isn’t practical in my case.

I hope this helps anyone who encounters this issue in future.

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!