Category: GP (Great Plains)

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

This post is part of the series on Implementing Post Master Enterprise for Microsoft Dynamics GP from Envisage Software.

The Audot-Detect rules covered in the last post are sufficient for those cases when workflow is not being used or when the auto-detect rule can be configured using the Batch Number. I’ve worked with a few clients to implement Post Master Enterprise now and there usually comes a point when the in-built rules are not sufficient.

However, Post Master Enterprise can be extended to allow more complex auto-detect rules including selecting only batches approved in workflow (as a side note, I’ve discussed this with Envisage and for workflow batches they are looking at including this as a standard feature in the Auto-Detect window). Post Master Enterprise has been developed to call pro and post SQL stored procedures which can be used to insert batches in the pending table.

The pre/post stored procedures are deployed by Post Master Enterprise during the installation, but don’t include any functionality. The first time we did this, Envisage supplied some standard code to submit a batch into the pending tables and I extended that with my SQL function to return Workflow Status to pick up only those batches at a status of Final Approval.

This approach could be taken to select batches based on any criteria (such as user who posted, posting date or even specific GL accounts).

This post is part of the series on Implementing Post Master Enterprise for Microsoft Dynamics GP from Envisage Software.

From the settings menu select Auto-Detect.

Rules are created separately for each batch source and require four settings:

1. Company allows you to choose the company in which the rule is to be applied.
2. Batch Source is the type of transaction, which, in this example, is General Entry.
3. Filter I have set to Contains.
4. Value is the value in the batch id to check for; I have opted to set this to AUTO so only batches containing this will be auto posted.

I have also enabled the Schedule Auto-Detected Batches for weekdays between 0800 and 1800.

Continue reading “Implementing Post Master Enterprise: Create Auto-Posting Rules”

This post is part of the series on Implementing Post Master Enterprise for Microsoft Dynamics GP from Envisage Software.

With the Windows service configured we can move onto running Post Master Enterprise for the first time.

The first thing you need to do is configure it to run as administrator. Do this by right-clicking on the shortcut, selecting the Compatibility tab and mark the Run this program as an administrator:

Continue reading “Implementing Post Master Enterprise: First Run”

This post is part of the series on Implementing Post Master Enterprise for Microsoft Dynamics GP from Envisage Software.

With Post Master Enterprise installed, the next step is to configure the Windows service as Automatic (Delayed Start); this will ensure that SQL Server is running before Post Master itself starts; this does, of course, assume that Post Master is being installed on the SQL Server which is not a requirement.

Launch the Services control panel applet and open the properties for the Post Master Enterprise for Dynamics GP service.

Change the Startup Type to Automatic (Delayed Start):

Continue reading “Implementing Post Master Enterprise: Configure Windows Service”

This post is part of the series on Implementing Post Master Enterprise for Microsoft Dynamics GP from Envisage Software.

Once you have the prerequisites sorted out, launch the Post master setup utility. On the Welcome step, click Next::

Continue reading “Implementing Post Master Enterprise: Installation”

This post is part of the series on Implementing Post Master Enterprise for Microsoft Dynamics GP from Envisage Software.

The prerequisites for Post master Enterprise are fairly straightforward.

Firstly, a client install of Microsoft Dynamics GP is required; this can be used by users, but you’ll need a launch file which doesn’t include the products on the incompatible list and if there are any .NET add-ins from the list, a separate install, rather than a separate launch file, will be required.

Secondly, a dedicated Microsoft Dynamics GP user account with permissions to post the batches required. In their documentation, Envisage recommend using an account with the POWERUSER* role, but I would not recommend using an account with those permissions; a role containing only the batch posting for the types you will be posted, is a far more secure option.

Thirdly, a Domain account to use to run the Windows service.