It turns out that SQL Server has a report you can run which will show which features are installed.
The report is run from the SQL Server Installation Center which is available from the Windows Start menu. Click on Tools and then on Installed SQL Server features discovery report:
We’ve been doing a number of upgrades recently and I encountered an old error when trying to deploy the SQL Server Reporting Services (SSRS) and Excel Reports through the Reporting Tools Setup window ( ).
This particular client is being upgraded from Microsoft Dynamics GP 2013 SP2 to 2016 R2.
The problem is that some of the companies are showing as Not implemented. The companies showing this way are the oldest; TEST2016… is actually the main company renamed for testing.
Mark Polino has a set of Historical Excel Reports available for sale. The reports available are as follows:
- Receivables Management Historical Aged Trial Balance
- Payables Management Historical Aged Trial Balance
- Historical Inventory Trial Balance
- Historic Stock Status Report
Now is the ideal time to buy them, as the price is increasing on 1st April 2017.
I’ve just found a page on CustomerSource called the Microsoft Dynamics GP Directory and it looks like it has been in existence for quite a while as it has links to information on Microsoft Dynamics GP 2010 through to 2016 R2.
The links include Top Reasons to Buy Microsoft Dynamics GP, Top Reasons to Upgrade as well as links to the Feature Blog Series, System Requirements, Service Pack, Hotfix and Compliance Update Patch Releases and much more.
I got to the page from the Dynamics GP Support and Services Blog post on the which I got to through David Musgraves post on Microsoft Dynamics GP 2016 R2 New Features .
Just shows it is worth reading around the blogs on Dynamics GP.
I’ve seen the below error message a few times when trying to import VBA customisations and have had to do an investigation each time as to what the problem was, before realising it was exactly the same problem again:
Microsoft Dynamics GP
VBA cannot be initialized. Cannot import this package because it contains VBA components.
This post, is in an attempt to remind myself of what the error is without having to investigate.
The issue each time has been that the registration keys for Microsoft Dynamics GP have not been entered; VBA customisations cannot be imported if the Customisation Site Licence is not registered.
Once the keys are entered, the error goes away and the VBA customisations can be imported without further issue.
This is an update to the original Workflow 2.0 book I wrote a couple of years ago. This edition includes coverage of the new functionality introduced in Microsoft Dynamics GP 2016, a new chapter on adding table joins to workflow to allow additional conditions to be created, and some chapters and sections have been rewritten to either expand or make clearer the topics being covered.
Dynamics GP includes a variety of tools and modules to assist in controlling processes and data; one of the major modules for this was the Dynamics Workflow module. However, this module had major flaws which very much limited its usefulness; it was slow, clunky and difficult to install, configure and maintain.
If the checkbox is marked then the warning message is not displayed for that user anymore and there is no way to restore the message through the front end of the system.
The below script, allows the message to be restored for a named user (change the highlighted text to the required user):
/* Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (http://www.azurecurve.co.uk) This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK). */ DECLARE @USERID VARCHAR(20) SET @USERID = 'userid' DELETE FROM SY01401 WHERE coDefaultType = 13 AND USERID = @USERID GO
The solution Microsoft have supplied is an option which activates horizontal scroll arrows in the Account field:
This is activated, on a per user basis, via the User Preferences window () by marking the Horizontal Scroll Arrows:
However, if you have a lot of users, this can sometimes be a difficult message to disseminate.
An alternative I came up with for a client a wile ago was to create a trigger on the Users Master (SY01400) table which updates the field after a new user is created:
/* Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (http://www.azurecurve.co.uk) This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0 Int). */ CREATE TRIGGER utr_AZRCRV_UpdateSY01400ActivateHorizontalScrollArrows ON SY01400 AFTER INSERT AS UPDATE ['Users Master'] SET HSCRLARW = 1 FROM SY01400 AS ['Users Master'] INNER JOIN inserted AS INS ON INS.USERID = ['Users Master'].USERID GO
If users have already been created, then the following script can be used to activate the horizontal scroll arrows for them:
/* Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (http://www.azurecurve.co.uk) This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0 Int). */ UPDATE SY01400 SET HSCRLARW = 1 WHERE HSCRLARW = 0 GO
We actually decided to remove the trigger and apply the update script via a SQL Server Agent scheduled job which runs on a period basis (if I recall correctly, it was configured to run each evening at 2100 (avoiding backup jobs).
Everything had been fine until this point, but after creating a simple example approval workflow, I clicked the Submit button on the Purchase Requisition Entry window and nothing happened; I tried again through the navigation list, again without success.
I promised to figure out the issue in the next break and moved onto discussing other ways of interacting and then called the break.
It occurred to me that this might be another manifestation of an issue I have encountered previously, but without the visible error message.
I ran the script against the system database which redeploys the .NET Assemblies used by Workflow:
It took a few minutes to run through, but I was then able to approve the requisition without further problem.
Pretty much every client we have of Microsoft Dynamics GP uses the EFT Payment Register Report; a number of the save the file instead of printing it as the report has been customised to generate the EFT payment file for upload to the bank.
The clients who do this are either those whose installations of Microsoft Dynamics GP predate version 10 when the EFT for Payables Management module was made available to the UK market or they implemented before the EFT File Format was enhanced to allow a CSV output.
While some clients have created or amended a file format since the above, not all of them have been willing to spend the time (or money) to make the change.
As such, when they copy live to test they need to amend the path to which the report is being output, to ensure that a live file is not accidentally overwritten.
To faciliate this for users who have automated the live to test restore I created a script they could build into the process:
/* Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (http://www.azurecurve.co.uk) This code is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0 Int). */ UPDATE SY02200 SET FILEXPNM = 'C:\BACS OUTPUT\BACS.TXT' WHERE PTGRPTNM = 'EFT Payment Register'
The highlighted section is the path name which needs to be changed depending on where the test file is to be output.