Category: GP (Great Plains)

I have a few clients with many company in Microsoft Dynamics GP (and one with well over 100) so doing upgrades or live to test backups can require a fair few, potentially time consuming, changes to data. I’ve posted scripts to update email addresses on test in bulk before as well as a few other variations. One recent one which has come up a couple of times, is the web services server location.

In the Workflow Setup window (Administration area page » Setup » System » Workflow Setup) is a field for the Web Services Server Location; this is the server where the web services have been installed and will be different for a standalone test server to live. Rather than have to move between several dozen companies changing this setting one at a time, the following script can be run to make the change in all companies.

The first highlighted section is the new server location and the second the current one:

/*
Created by Ian Grieve of azurecurve | Ramblings of an IT Professional (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).
*/
DECLARE @SQL NVARCHAR(MAX)
SET @SQL = STUFF((
					SELECT 
						CHAR(13) 
							+ 'UPDATE
								WF
							SET
								Web_Service_Server = ''test.example.co.uk''
							FROM
								' + INTERID + '.dbo.WF00100 AS WF
							WHERE
								Web_Service_Server = ''live.example.co.uk'''
					FROM
						DYNAMICS.dbo.SY01500
					FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(MAX)'), 1, 1, '')

EXEC sys.sp_executesql @SQL

The second element is there to make sure the script is only run in companies in which the workflow setup has been completed.

There was a recent issue with the Report Writer reports printing a black box instead of an image. This problem was the result introduced by a Windows update and quickly acknowledged as an issue by Microsoft.

This is an example of how the standard report looks when the bug is present:

The Dynamics GP Support and Services Blog posted about the problem on the 12th March and have posted regular updates on the progress of the investigation.

The latest update on the 22nd was that a new update had been released which fixed the problem for legacy OS’s like Windows 8 and Windows Server 2012 which follows current versions having working updates available from the 19th.

We’ve just upgraded another client to Microsoft Dynamics GP Fall 2020 Release; everything during the upgrade went smoothly until we came to upgrading the web services. The test environment was created by replicating the live servers into a sandbox environment.

I was pretty much expecting to encounter the problem we did as we were moving from using a SQL Server security store to an Active Directory security store. The error received was:

As the error referred to a security object error, my thinking immediately went to the new security store as being the issue. Due to the change in method I opted to remove the web services and do a reinstall; I tried using the built-in removal process in the Web Services Configuration Wizard, but this took a very long time to run and then crashed, so I used a couple of Microsoft supplied scripts to remove all of the web services objects from the company databases first and then from the system.

Once the web services had been completely removed, I re-ran the Configuration Wizard and deployed the web services again. The deployment ran through without any issues and we were able to test web services without encountering any further issues.

The lesson, which confirmed what I expected, is that if you change the security store type, you need to remove the web services from all companies and do a redeploy.

This post is part of a series on creating a simple audit for Microsoft Dynamics GP.

As I’ve shown over the last few posts, it is relatively easy to create a simple audit on a table in Dynamics GP, but this approach is not very scalable and requires someone to manually create the SQL triggers. For a client on a shoestring budget and who wanted to audit one table, this approach sufficed.

However, for a larger client who would want to audit more tables in more than one company and who would want to have non-technical users maintaining the audited information, I would recommend a solution like Assure Suite from Fastpath which I have implemented with a umber of clients previously.

What brought this approach to mind was a client had an issue with some incorrect data and we could not determine who or what was changing some data, so I amended this custom audit for the tables we needed to record for that issue. In this instance, there was no need for a full audit solution as it will only be in place temporarily while investigating a specific issue.

This post is part of a series on creating a simple audit for Microsoft Dynamics GP.

Once the audit table and triggers have been deployed, any changes made through the audit will be recorded and available for reviewing later to see who has been making changes and, more significantly, what was changed.

The easiest way of making this available to the client was to create a SmartList for them using SmartList Designer to select data from the new custom audit table. SmartList Designer can see either Dexterity tables or SQL views, but not custom SQL tables, I created a SQL view on the custom audit table, joining it to the Users Master (SY01400) table in the DYNAMICS table to get the username:

/*
Created by Ian Grieve of azurecurve | Ramblings of an IT Professional (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 VIEW uv_AZRCRV_Audit AS
SELECT
	['Audit'].RecordType AS 'Record Type'
	,['Audit'].RecordID AS 'Record ID'
	,['Audit'].UpdateType AS 'Update Type'
	,['Audit'].USERID AS 'User ID'
	,['User Master'].Username AS 'Username'
	,FORMAT(['Audit'].ChangeDateTime, 'yyyy-MM-dd') AS 'Change Date'
	,FORMAT(['Audit'].ChangeDateTime, 'HH:ss') AS 'Change Time'
	,['Audit'].OldData AS 'Old Data'
	,['Audit'].NewData AS 'New Data'
FROM
	ut_AZRCRV_Audit ['Audit']
LEFT JOIN
	DYNAMICS..SY01400 AS ['User Master']
		ON
		 	['User Master'].USERID = ['Audit'].USERID
GO

GRANT SELECT ON uv_AZRCRV_Audit TO DYNGRP
GO

This post is part of a series on creating a simple audit for Microsoft Dynamics GP.

With the table created to store the audited information, the second step is to create the required triggers on the Address Electronic Funds Transfer Master (SY06000) table. For an Vendor EFT audit there are three triggers required:

1. INSERT
2. UPDATE
3. DELETE

These triggers will record all new Vendor EFT information added as well as that which is amended or deleted. The client for which this audit was created only dealt with vendors in the UK and only ever set three fields in the EFT Bank window:

1. Bank Name
2. EFT Bank Code
3. EFT Bank Account

Additional fields can be added to the audit if other fields need to be stored.

As the Address Electronic Funds Transfer Master (SY06000) table holds EFT Bank information for customers as well as vendors, the Record ID has been set to include the Series. Strictly speaking, this was not necessary as the client did not store bank details for their customers in Dynamics GP as none were making direct debit payments.

The audited data is being trimmed and cast as varchar so the extra whitespace held by Dynamics GP due to the columns being chars are removed.

The first trigger creates the trigger which runs when data is inserted:

/*
Created by Ian Grieve of azurecurve | Ramblings of an IT Professional (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_SY06000_AuditInsert ON SY06000 AFTER INSERT AS
INSERT INTO
	ut_AZRCRV_Audit
--VALUES
	SELECT
		'Vendor EFT'
		,CAST(i.SERIES AS VARCHAR(100)) + ' | ' + CAST(RTRIM(i.CustomerVendor_ID) AS VARCHAR(100)) + ' | '  + CAST(RTRIM(i.ADRSCODE) AS VARCHAR(100))
		,'Insert'
		,SYSTEM_USER
		,GETDATE_USER()
		,''
		,'BANKNAME = ' + CAST(RTRIM(i.BANKNAME) AS VARCHAR(100)) + ' | ' + 'EFTBankCode = ' + CAST(RTRIM(i.EFTBankCode) AS VARCHAR(100)) + ' | ' + 'EFTBankAcct = ' + CAST(RTRIM(i.EFTBankAcct) AS VARCHAR(100))
	FROM
		inserted i
GO

Continue reading “Simple Audit for Microsoft Dynamics GP: Create Triggers”

This post is part of a series on creating a simple audit for Microsoft Dynamics GP.

The first step in creating the audit is to create a table in the company database to hold the audited information. From the user point of view there was five pieces of information required:

1. Key for the vendor EFT being amended
2. User ID
3. Date/Time
4. Old Data
5. New Data

To make reporting easier and to add an element of future proofing, I also added two other pieces of information:

1. Record Type to record the type of information being audit; in this case Vendor EFT.
2. UpdateType to explicitly record whether the change was an INSERT, UPDATE or DELETE

The following SQL will create a table with the table with the seven columns mentioned above:

/*
Created by Ian Grieve of azurecurve | Ramblings of an IT Professional (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 TABLE ut_AZRCRV_Audit
	(
		RecordType VARCHAR(100)
		,RecordID VARCHAR(100)
		,UpdateType VARCHAR(10)
		,USERID VARCHAR(150)
		,ChangeDateTime DATETIME
		,OldData NVARCHAR(MAX)
		,NewData NVARCHAR(MAX)
	)
GO