An Unknown Error Occurred sending mail in Dynamics GP with Office 365

Attempting to send email from Dynamics GP using multi factor authentication (MFA) results in an error, after selecting a user in the Office authentication window.

An Unknown Error Occurred

An Unknown Error Ocurred - Dynamics GP Email

There is no explanation as to what the error actually was. In the case I was investigating some users could email and yet others could not. This is strange when the machines that they were using originate from the same base image.


After logging is turned on, it turns out the error underneath is that the following file does not exist:

c:\Users\{userID}\AppData\Roaming\Microsoft Business Solutions\Microsoft Dynamics GP\Microsoft.Dynamics.GP.BusinessIntelligence.TemplateProcessing.dll.msalcache.bin3


GP looks to be using the Microsoft Authentication Library (MSAL) to cache the Azure authentication tokens for the connection to Office 365 into this folder and file. However, if the folder does not exist then the library can not write the cache file . I looks like this folder will only be created if the user in GP has had the field auto complete feature in GP turned on, or has had it in use at some point in the past.

Details of Auto complete functionality is found here: Using AutoComplete functionality with Microsoft Dynamics GP

This feature also uses this folder to store the database files that drive the auto complete functionality.

It is controlled from the User Preference window.

Autocomplete setup window in GP

Comparing a user that can send email against one that can’t using SQL


We can see one has auto complete on the other has it off and also checking the existence of the folder shows that the user encountering the error does not have the folder.

So after creating the following folder,

c:\Users\{userID}\AppData\Roaming\Microsoft Business Solutions\Microsoft Dynamics GP\ was found that email functionality will work correctly. I assume the developer of the email feature, assumed that this folder will always exists on all systems. They were unaware it may not be created if autocomplete is turned off. My guess is that code will not create the folder when it does not exist and hence the error.


Creation of this directory has been added into group policy for GP users. 

Hope this helps someone else, comment if you found it helpful.

Another user is editing this item–Dynamics GP error

Another User Is Editing This Item

You can’t delete an item because another user is editing this item message pops up.

This is due to a lock in the SY_ResourceActivity table (DYNAMICS..SY00801).

Check the table for the item number in RSRCID field, you can list all the records locked in the system with following SQL statement…



To resolve, remove the rows that are for the item in question.

DELETE FROM DYNAMICS..SY00801 where rsrcid='{insert item number}'

You should of course check the user is not editing the item, in this support case, the user themselves could not delete the item due to a system crash during a previous edit.

Dynamics GP–The Document is in use and could not be deleted, when attaching a document

When using document attach in Dynamics GP from Version 2016, it is not possible to attach a document if it is open in another application.

If a user has a document open and then attempts to attach it, the error is:

The document is in use and could not be attached.


I think this is a positive change, although it can require users to change working practices, just a little, to accommodate it.

I have the feeling this is to prevent data loss. If user attaching a document, such as word or excel, that is both open and has unsaved changes in it, then they mistakenly may believe they have safely stored the document in the document attachment. Unfortunately they may not realise the outstanding changes in the open document will not have been in the version they captured to GP, from the file system. Those changes could get lost quite easily (machine restarts or user saves to file system not refreshing the attached version).

Whilst protecting users from themselves, it does pose the problem that if a user has preview pane of file explorer open, or PDF viewer open looking at a PDF, then the filesystem will know the file is locked, and prevent them attaching the documents. For end users this can seem odd and frustrating behaviour, although obvious to a IT professional why this is so. With a little change to workflows and practices (user training), this can be overcome.

A common example seems to be AP departments scanning and attaching AP invoice PDFs. The document scanner opens the PDF automatically, in PDF viewer immediately after scanning, blocking its ability to be attached in GP. Users just need to learn to close documents and turn off previewers to work effectively again.

Dynamics GP Payables - A unique document number could not be found Please check setup

Payment run failed after GP upgrade

On upgrading to GP: Version 18.4.1361 (2021) everything worked great except for making EFT payments.

On printing the EFT payments, the following error popped up.

A unique document number could not be found. Please check setup.

A Unique Document Number Could Not Be Found. Please check setup.

Although it could be clicked through the first time, attempting further subsequent EFT payments resulted in another message box.

An error occurred. Contact your system administrator to verify data.

An Error Occurred. Contact your system administrator to verify data.

This was annoying as this prevented any further EFT payments, although manual payments were absolutely fine.

Diagnosing the problem

I posted the issue on the community forum and lodged a ticked with our support partner, just in case this couldn’t be resolved ourselves… then time to dig in and investigate as not paying suppliers is a big issue…

This was a familiar message to me from other modules of GP, where the number sequence has gone so far out of range that GP fails to scan for a new number, or the number sequence has not been defined – this experience helped me later narrow in on the problem. I checked the purchasing setup window and the various GP tables to find that the next numbers for both that chequebook and the payables transactions. All were all looking correct.


It felt like something was wrong when GP was getting the next chequebook number (or perhaps payment transaction number, though it felt less likely), you get a gut feeling on these things when working with a product long enough!

Next action was to capture a SQL debug trace and a Dexterity Script debug trace around that operation. The SQL trace had nothing interesting in it. However the script trace did. This showed the error box was being called after function “GenerateNextEFTNumber” was executed.

'GenerateNextEFTNumber of form PM_Print_Computer_Checks', table 'CM_Checkbook_MSTR', "0000000000000001012343295", 0

           'PM_Number_Inc_Dec', "", 1

'SaveCurrentFormTrigger', 2567, 0, "SY_Error_Message"

EFT Number, what is that?? – I’m not that familiar with the EFT module in GP, so I went looking around the configuration for EFT, which hangs off the chequebook form.

I found in the EFT options here: Cards->Financial->Chequebook->EFT Bank->Payables Options

EFT Setup - Payable Optoins shiowing use cheque numbers and empty field for next number

In there it states option is to use the cheque number, but it looks like it is possible rather than use up cheque numbers, to use a unique EFT sequence number for EFT payments. This was the moment that I felt that I knew what was happening.  You may see from the screen shot that there is no EFT number in the Next EFT Payment Number field. On the test environment I seeded this value with EFT000000000001, having also set the option to “Use EFT Numbers”. This time the payment processed as expected and the “Next EFT Payment Number” incremented by the number of payments.

Aha! – I set the option back to “Use Cheque Numbers” but leaving the Next EFT Payment Number populated and it still allowed payments to be processed. It looks like the blank field was the problem.

Fix Production environment

I moved to production environment and ran

UPDATE CM00101 SET EFTPMNextNumber = 'EFT000000000001'

that will seed the Next EFT Payment Number for all the chequebooks (make sure this is ok in your environment and do for each company DB).

The setup options for EFT now looked like this below, with a value in the next number field but option still to use cheque numbers…

EFT Options with corrected setup

On attempting to do the payments run, it worked just as it did pre-upgrade. –yay!


Conclusion is that even if the option is set to “Use Cheque Numbers”, then GP will still attempt to generate EFT numbers, and thus needs the field for Next EFT Payment Number to be populated. It is not so much “used” but is “required”.

Also out of curiosity went and created a new chequebook. On opening the EFT options window of this new chequebook, the “Next EFT Payment Number” field is pre-populated by the application with “EFT000000000001” – thus on a current versions of GP this issue would not happen. There would always be a value in that field. I guess in the past versions of GP that this field was not auto populated by the application, thus our chequebooks ended up with blank fields, that only then became an issue after upgrading to this latest version of GP.

It was a stressful few hours but outcome was good.