Month: February 2021

A recent project required a report of serial numbers received into Microsoft Dynamics GP on purchase orders and to which sales transaction they’d been allocated. I had a hunt around in my scripts folder and found an old script I’d written which only required some small changes to add the required fields.

The script uses INNER JOIN clauses as only assigned serial numbers were wanted, but this could easily be changed to LEFT JOIN to return serial numbered items which had been received but not yet allocated.

-- drop view if it exists
IF OBJECT_ID(N'uv_AZRCRV_POPSOPSerialNumbers', N'V') IS NOT NULL
	DROP VIEW uv_AZRCRV_POPSOPSerialNumbers
GO
-- create view
CREATE VIEW uv_AZRCRV_POPSOPSerialNumbers AS
SELECT
	['Purchasing Receipt Line Quantities'].PONUMBER
	,['Purchasing Receipt Line Quantities'].POPRCTNM
	,['Purchasing Receipt Line Quantities'].VENDORID
	,['Purchasing Receipt Line Quantities'].TRXLOCTN
	,['Sales Serial/Lot Work AND History'].ITEMNMBR
	,[Purchasing Serial Lot History'].SERLTNUM
	,['Sales Serial/Lot Work AND History'].SOPTYPE
	,CASE ['Sales Serial/Lot Work AND History'].SOPTYPE
		WHEN 1 THEN 'Quote'
		WHEN 2 THEN 'Order'
		WHEN 3 THEN 'Invoice'
		WHEN 5 THEN 'Back Order'
		ELSE ''
	END AS 'Type'
	,['Sales Serial/Lot Work AND History'].SOPNUMBE
	,['Sales Transactions'].DOCDATE
	,['Sales Transactions'].CUSTNMBR
FROM
	POP30330 AS [Purchasing Serial Lot History'] -- Purchasing Serial Lot History (POP30330)
INNER JOIN
	POP10500 AS ['Purchasing Receipt Line Quantities'] -- Purchasing Receipt Line Quantities (POP10500)
		ON
			['Purchasing Receipt Line Quantities'].POPRCTNM = [Purchasing Serial Lot History'].POPRCTNM
		AND
			['Purchasing Receipt Line Quantities'].RCPTLNNM = [Purchasing Serial Lot History'].RCPTLNNM
INNER JOIN
	SOP10201 AS ['Sales Serial/Lot Work AND History'] -- Sales Serial/Lot Work and History (SOP10201)
		ON
			['Sales Serial/Lot Work AND History'].SERLTNUM = [Purchasing Serial Lot History'].SERLTNUM
INNER JOIN
	(
		SELECT
			SOPNUMBE
			,SOPTYPE
			,DOCID
			,DOCDATE
			,CUSTNMBR
			,CUSTNAME
		FROM
			SOP10100 AS ['Sales Transaction Work'] -- Sales Transaction Work (SOP10100)
		UNION ALL
			SELECT
				SOPNUMBE
				,SOPTYPE
				,DOCID
				,DOCDATE
				,CUSTNMBR
				,CUSTNAME
			FROM
				SOP30200 AS ['Sales Transaction History'] -- Sales Transaction History (SOP30200)
	) AS ['Sales Transactions']
		ON
			['Sales Transactions'].SOPNUMBE = ['Sales Serial/Lot Work AND History'].SOPNUMBE
		AND
			['Sales Transactions'].SOPTYPE = ['Sales Serial/Lot Work AND History'].SOPTYPE
GO

GRANT SELECT ON uv_AZRCRV_POPSOPSerialNumbers TO DYNGRP
GO

This script will create a SQL view to select the last restore date for every database on a Microsoft SQL Server along with the user who performed the restore.

It has included a couple of other use columns in the returned data such as the collation_name and compatibility_level:

-- drop view if it exists
IF OBJECT_ID(N'uv_AZRCRV_GetLastDatabaseRestoreDate', N'V') IS NOT NULL
	DROP VIEW uv_AZRCRV_GetLastDatabaseRestoreDate
GO
-- create view
CREATE VIEW uv_AZRCRV_GetLastDatabaseRestoreDate AS
WITH LastRestores AS
	(
		SELECT
			d.name AS DatabaseName
			,d.create_date
			,d.compatibility_level
			,d.collation_name
			,r.restore_date
			,r.user_name
			,ROW_NUMBER() OVER (PARTITION BY d.Name ORDER BY r.[restore_date] DESC) AS RowNumber
		FROM
			master.sys.databases AS d
		LEFT JOIN
			msdb.dbo.[restorehistory] AS r
				ON
					r.[destination_database_name] = d.Name
	)

SELECT
	DatabaseName
	,create_date
	,compatibility_level
	,collation_name
	,restore_date
	,user_name
FROM
	LastRestores
WHERE
	RowNumber = 1
GO

GRANT SELECT ON uv_AZRCRV_GetLastDatabaseRestoreDate TO DYNGRP
GO

I created this as a view so that it could easily be included in a SmartList using either SmartList Designer or SmartList Builder to allow finance users to see how up-to-date their test system is.

I recently did a Microsoft Dynamics GP and Management reporter upgrade for a client which incuded migrating the databases to a new server. After performing the upgrade, users were unable, in some companies, to see the reports in Management Reporter. When we looked into it, some of the companies had reverted to the Default building block group.

To easily identify the companies which had reverted, I created the below script which coud be rn on both the original and upgraded Management reporter databases; it lists all the companies and the assigned building block group:

/*
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).
*/
SELECT
	['Case Control'].Code AS 'Company ID'
	,['Case Control'].Name AS 'Company Name'
	,['Control Specification Set'].Name AS 'Building Block ID'
	,['Control Specification Set'].Description AS 'Building Block Name'
FROM
	Reporting.ControlCompany AS ['Case Control']
INNER JOIN
	Reporting.ControlSpecificationSet AS ['Control Specification Set']
		ON
			['Control Specification Set'].ID = ['Case Control'].SpecificationSetID
ORDER BY
	['Case Control'].Code

This is a script I wrote years ago and thought I’d posted it here, but it seems it had never been posted, although I have posted a script to insert test emails against all customers. This script can be used to insert or update email addresses on vendors, customers or items in Microsoft Dynamics GP.

The insert doesn’t validate against the records against which the email addresses will be connected, so care does need to be taken to ensure data integrity and the script should be tested first before being run on a live company.

/*
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 #SY01200_IMPORT
	(
		Master_Type VARCHAR(3) -- VEN = Vendor / CUS = Customer / ITM = Item
		,Master_ID VARCHAR(100)
		,ADRSCODE VARCHAR(100)
		,EmailToAddress VARCHAR(1000)
		,EmailCcAddress VARCHAR(1000)
		,EmailBccAddress VARCHAR(1000)
	)
GO

BULK INSERT
	#SY01200_IMPORT
FROM
	'c:\temp\email.txt'
WITH
	(FIELDTERMINATOR = '\t'
	,ROWTERMINATOR = '\n'
	,FIRSTROW = 2
)
GO

-- UPDATE if Email Details present
UPDATE
	SY
SET
	SY.EmailToAddress = SY_I.EmailToAddress
	,SY.EmailCcAddress = SY_I.EmailCcAddress
	,SY.EmailBccAddress = SY_I.EmailBccAddress
FROM
	SY01200 SY
INNER JOIN
	#SY01200_IMPORT AS SY_I
		ON
			SY_I.Master_ID = SY.Master_ID
		AND
			SY.Master_Type = SY_I.Master_Type
		AND
			SY.ADRSCODE = SY_I.ADRSCODE
GO

-- Insert if no Email Details
INSERT INTO SY01200
	(
		Master_Type
		,Master_ID
		,ADRSCODE
		,EmailToAddress
		,EmailCcAddress
		,EmailBccAddress
	)

	(
		SELECT
			Master_Type
			,Master_ID
			,ADRSCODE
			,EmailToAddress
			,EmailCcAddress
			,EmailBccAddress
		FROM
			#SY01200_IMPORT 
		WHERE
			(SELECT
				COUNT(Master_ID)
			FROM
				SY01200
			WHERE
				Master_Type = #SY01200_IMPORT.Master_Type
			AND
				Master_ID = #SY01200_IMPORT.Master_ID
			AND
				ADRSCODE = #SY01200_IMPORT.ADRSCODE) = 0
			)
GO

DROP TABLE #SY01200_IMPORT
GO

As I mentioned in my last post, I’m in the process of doing upgrades for a couple of clients to the Dynamics GP Fall 2020 Release. Before I started on a clients system, I thought I would upgrade my own demo/test system to the latest version. The upgrade started fine, but then in one of the companies, the upgrade crashed with two errors:

Needing some more information on the error, I enabled a Dex SQL log and ran the upgrade again.

The problem it identified was in the Workflow Template Fields (WF40202) table into which I had added some extra rows for the fields to be included on the Workflow notification emails.

Once I removed these fields, I was able to run the upgrade without further problems; after the upgrade was complete, I ran the script to recreate the rows.

It’s a while since I did an upgrade of Microsoft Dynamics GP, as they are usually assigned to other consultants, but I’ve taken on a couple recently. One of them has 20+ companies and another coming up soon has well above 100+, so I decided I needed a way of seeing how far the upgrade had progressed.

The below SQL script creates a view on the upgrade tables showing when the upgrade of a company started and when it ended; the highlighted section should be changed to the include any of the products which should not be checked (I included the Dynamics Online Services product as it has been retired).

Continue reading “SQL View to Check Dynamics GP Utilities Upgrade Progress”

I was helping a client implement Microsoft Dynamics GP last year and advised them to review the posting report setup and decide which ones they wanted to keep. To assist them with this, I ran the below script to change all reports which were set to print the report, to output the report to screen instead.

The users can then review the report and determine if they want to keep it or not.

/*
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_Statement VARCHAR(1000) 
DECLARE
   cursor_InterID Cursor
FOR
   SELECT INTERID FROM DYNAMICS..SY01500
   
   OPEN cursor_InterID
   DECLARE @INTERID VARCHAR(100)
   FETCH NEXT FROM
      cursor_InterID
   INTO
      @INTERID
   WHILE (@@FETCH_STATUS <> -1)
      BEGIN
      IF (@@FETCH_STATUS <> -2)
            SET @SQL_Statement = 'UPDATE ' + RTRIM(@INTERID) + '.dbo.SY02200 SET PRTOSCNT = 1, PRTOPRNT = 0 WHERE PRTOPRNT = 1'
            EXEC (@SQL_Statement)
         FETCH NEXT FROM
            cursor_InterID
         INTO
            @INTERID
      END
   CLOSE cursor_InterID
DEALLOCATE cursor_InterID

This script updates the posting report output in every Dynamics GP company, so run it with care and after taking a good backup or all companies. I’d also recommend running it on a test system first, before running it on a live system to make sure you understand the impact it will have.

I’ve created other scripts to manipulate the posting reports previously:

• Copy Posting Report Configuration Between Companies
• Deactivate All Reports (Except PM EFT Payment Register) In All Companies