The first of the security SQL views I am posting in this series shows all of the users and the companies to which they have been granted access.

CREATE VIEW [dbo].[uv_AZRCRV_UserAccessAndGranted] AS
/*
Created by Ian Grieve of azurecurve|Ramblings of a Dynamics GP Consultant (https://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).
*/
SELECT
	['User Master'].USERID AS 'User ID'
	,['User Master'].USERNAME AS 'Username'
	,['User Master'].USRCLASS AS 'User Class'
	,ISNULL(['Class Master'].DSCRIPTN, '') AS 'User Class Description'
	,ISNULL(['Company Master'].INTERID, '') AS 'Intercompany ID'
	,ISNULL(['Company Master'].CMPNYNAM, '') AS 'Company Name'
FROM
	SY01400 AS ['User Master']
LEFT JOIN
	SY40400 AS ['Class Master']
		ON ['Class Master'].USRCLASS = ['User Master'].USRCLASS
LEFT JOIN
	SY60100 AS ['User-Company Access']
		ON ['User-Company Access'].USERID = ['User Master'].USERID
LEFT JOIN	SY01500 AS ['Company Master']
		ON ['Company Master'].CMPANYID = ['User-Company Access'].CMPANYID
GO

GRANT SELECT ON uv_AZRCRV_UserAccessAndGranted TO DYNGRP
GO

Back in November I posted a SQL View which could be used in SmartList Designer to return the users, company and role assignments. This view is now accompanied by several others which allow for reporting on the Dynamics GP security setup at several different levels.

These have been done as SQL views so they can easily be plugged into SmartList Designer which does not have an import/export function, but they can also be used in SmartList Builder, should the client be licensed for this add-on, or any other reporting tool.

I had a client report a problem with a couple of purchase orders which were showing in the PO Entry window, but which they could not open. While looking into the problem we found three things:

1. The problem was down to corruption where the PO was on both the work and open tables;
2. There was more than just two POs;
3. The problem also affected receipts.

Rather than trying to identify the problems manually, I wrote a SQL script which would identify all POs and Receipts which were on both the Work and Open tables:

CREATE TABLE #POCHECK(
	PONUMBER VARCHAR(20)
	,POPRCTNM VARCHAR(20)
	,CHCKDGIT INT
	,DCSTATUS INT
)
GO

INSERT INTO #POCHECK
	(PONUMBER,POPRCTNM,CHCKDGIT,DCSTATUS)
--VALUES
	(SELECT PONUMBER,'',1,1 FROM POP10100)
GO

INSERT INTO #POCHECK
	(PONUMBER,POPRCTNM,CHCKDGIT,DCSTATUS)
--VALUES
	(SELECT PONUMBER,'',1,3 FROM POP30100)
GO

INSERT INTO #POCHECK
	(PONUMBER,POPRCTNM,CHCKDGIT,DCSTATUS)
--VALUES
	(SELECT '',POPRCTNM,1,1 FROM POP10300)
GO

INSERT INTO #POCHECK
	(PONUMBER,POPRCTNM,CHCKDGIT,DCSTATUS)
--VALUES
	(SELECT '',POPRCTNM,1,3 FROM POP30300)
GO

SELECT
	PONUMBER
	,POPRCTNM
	,SUM(CHCKDGIT) AS DCCOUNT
FROM
	#POCHECK
GROUP BY
	PONUMBER,POPRCTNM
HAVING
	SUM(CHCKDGIT) > 1
GO

DROP TABLE #POCHECK
GO

After we used the script to identify the corrupt orders, it was a case of going through the returned records and correcting errors.

In the learn something new everyday category, the first Dexterity game was written back in 1999 by David Musgrave of Winthrop Development Consultants.

David has full details of the game and a link to the download on his new blog