I recently had cause to knock together a fairly simple SQL script to determine the quantity to order based on Sales transactions in the system taking into account the Order Point Quantity and Quantity To Order for the Item/Site combination in the Inventory module:
SOP10200.LOCNCODE AS 'Site'
,SOP10200.ITEMNMBR AS 'Item Number'
,SUM(SOP10200.QUANTITY) AS 'Quantity Required'
,IV00102.ORDRUPTOLVL - SUM(SOP10200.QTYTORDR) AS 'Quantity To Order'
LEFT OUTER JOIN
ON IV00102.ITEMNMBR = SOP10200.ITEMNMBR AND IV00102.LOCNCODE = SOP10200.LOCNCODE
SOP10200.QTYTORDR <= ORDRPNTQTY AND SOP10200.QTYTORDR <> 0
SOP10200.ITEMNMBR, SOP10200.LOCNCODE, IV00102.ORDRUPTOLVL
this is a simple script, but I’ve written it about four times now so I figured I’d post it so I can find it easily next time I lose my local copy.
Perfect Image are resellers of the Advanced Bank Reconciliation module from Nolan Business Solutions (along with the other add-ons they’ve written for Dynamics GP) and I often need to demo this replacement for the standard Bank Rec module.
One item I typically show is the auto-Propose function which matches transactions against statement lines in the Reconcile Bank Transactions window ( ).
To do this I need to be able to import statement lines which match the transactions in Dynamics GP; the easiest way of doing this is to extract the transactions.
This can be done with a very simple SQL script:
Once the data has been extracted it can be imported during the demo using the standard ABR Import Statement routine.
A while ago I posted about a problem with a collation conflict on a couple of columns in the Tax table. It seems I posted about how to fix the problem, but it seems I didn’t post how I found the problem columns.
I did this with a fairly simple SQL script:
DECLARE @Collation SYSNAME SET @Collation = 'SQL_Latin1_General_CP1_CI_AS'
TABLE_NAME AS 'Table'
,COLUMN_NAME AS 'Column'
,DATA_TYPE AS 'Data Type'
,COLLATION_NAME AS 'Collation Name'
DATA_TYPE IN ('varchar','char','nvarchar','nchar','text','ntext')
COLLATION_NAME <> @Collation
Microsoft Dynamics GP includes a large number of reports which will automatically print off when a transaction or batch is posted; and some postings produce many different reports.
When I implement a new client I typically leave them on during training with an instruction to identify which ones they want to use after go-live as I will switch off any I’m not told to leave on.
I used to do it the other way and tell people to let me know which ones they wanted switched off; however, this lead to all reports being left on and then it being mentioned a year or so down the line that they get all these reports printing that they don’t want.
So now, all get switched off unless I am specifically told to leave them on. As I’ve dealt with clients with many companies (I think the largest is 180 companies) this is not something I want to do manually.
Fortunately, the settings for whether the reports should print is stored in SQL table which means a SQL script can be written to switch them off in bulk.
A client reported a problem with Management Reporter returning incorrect figures when a link to the Financial Dimensions on the Row Definition had been entered in lower case.
The reports in question had been created in FRx which was rather more forgiving that Management Reporter is for these things. The client had quite a large number of reports which may, or may not, have had segments entered in lower case so the client didn;t want to have to check and update manually.
I again delved into the Management Reporter SQL database and updated the ControlRowCriteria table to capitalise the Low and High values of the link to financial dimensions using the script below:
Low = UPPER(Low)
High = UPPER(High)
LEN(High) > 0
Once the update had been run, the client checked their reports and confirmed that they were now returning the correct figures.
Management Reporter again, folks, after a short delay; I finally completed on a house purchase, in rural Northumberland, two years after I started work at Perfect Image.
I received another call that data on a report was not coming out correctly a short time ago (I’ve had the screenshots stored for a while until I had time to write this post); the numbers didn’t match those in Microsoft Dynamics GP or those on the old FRx report (which did match the numbers in GP.
I started by checking the Row Definition and the Link to Financial Dimension column to see what information was being brought through. The setup with ranges for the excludes struck me as a little odd with the ranges of 1:1, 10:10 and 100:100:
A client who upgraded to Microsoft Dynamics GP 2013 a few weeks ago began encountering a problem when switching between modules. In particular when they loaded the Purchasing area page they received the following message;
Value cannot be null. Parameter name: contentValue
Fortunately, there are two solutions to this problem outlined in the Microsoft Support KB Article 2843273. The first is to upgrade to Microsoft Dynamics GP 2013 which at very short notice isn’t really an option, or to use the script in the KB article to both remove the corrupt entry in SY07140 and add a trigger to the table to prevent another corrupt entry being created.
As we needed the client up and running without the error quickly, we opted for the second approach and will look to schedule in the upgrade from 2013 RTM to SP1.
I’ve recently been creating an HSBC Standard 18 BACs file format for a client in Microsoft Dynamics GP 2010 R2.
Unfortunately, once I released it to their system, they reported an error with the import where the Creditor’s Cheque Name wasn’t being output on the resulting file.
I did some testing and it turns out to be a bug in the export function of the EFT File Format (
) window in Microsoft Dynamics GP 2010 R2; I have subsequently tested on GP 2010 SP3 and GP 2013 and the import/export works fine. I realised something odd was going on when I looked at the template in the EFT File Format window ( ) and saw that while the Series was defined as Purchasing in the header, the scrolling window for the Data Field only had Receivables Management tables and fields available to it and not the Payables Management tables and fields I would expect;
In the last post I showed how the FRx menu can be renamed to show Management Reporter instead.
However, it is also a per user setting so would need to be done for each user created in Microsoft Dynamics GP who had access to Management Reporter.
To make the job a lot less onerous, I thought it might be useful to follow up with a SQL script to copy the FRx command customisations from one user to all others Continue reading
Earlier this week I posted about a bug in Integration Manager where it added extra zeros into the phone and fax number fields when importing creditors. Well, the same bug also affects debtors but a similar script to update debtors via a CSV is also possible.