I was doing some work for a client recently where we were loading lists of new creditors into Microsoft Dynamics GP from CSV files via Integration Manager. There is, however, a bug in IM 10 where it adds extra zeros to the phone and fax number fields of both creditors and debtors. These extra characters are, rather bizarrely, not always at the end but can be interspersed in the phone number.
The easiest work around was to put together a SQL script for loading the phone and fax numbers from CSV file which I did while on site which updated only a single address on the PM Creditor Master (PM00200) and PM Address Master (PM00300) tables.
After a slight mid-week diversion, here is another script I produced a while ago which updates the Item’s Default Purchasing Unit of Measure. It was produced when a client wanted to bulk update a large number of records which would have taken a long time manually but by script only minutes to write and run.
This is a script I’ve had a few months now and, like the one I posted yesterday, thought it might be useful to others.
This script was created for a client who changed some of their account codes on some Item Classes and had rolled them down to the Items themselves but there were many Sales Transactions already on the system which had the old code on and needed to be updated to the new one.
This script was produced for a client who wanted to bulk update the accounts defined against selected Inventory Items in Microsoft Dynamics GP 2010 R2. This particular client did not have Integration Manager so I needed an alternative approach to doing the update.
I could have used a GP Macro to do the job (doing one while recording the macro to create a template to be populated from a CSV using Mail Merge) but it was easier to create a SQL script to do the job directly from the CSV (this is the same view I took for updating the Account Segment Master).
I periodically have problems when trying to restore a GP company database over the Test database as SQL reports that the database is currently in use.
One way of resolving is to restart the SQL Server but this is only possible on a stand alone test system which is not being used by other people but this approach is overkill.
The better solution is to change the database to single user, restore the database and change the database back to multiple user. This can be done manually through SQL Server Management Studio but is far easier done via a SQL script.
On the Microsoft Dynamics GP Community site a question from Lisa Sorenson in October last year asking if it was possible to use the Table Import ( ) feature in Microsoft Dynamics GP to update some Segment descriptions has risen to the top with Steve Cummings linking to a post where the suggestion is to use a CSV file and Word template to generate a mailmerge.
This solution will work, but can be accomplished in much less time and effort by using the SQL command BULK INSERT to load the CSV (formatted as Segment ID, Segment Number and Description) Continue reading
I’ve recently been doing some work for a client where we’ve upgraded them from Microsoft Dynamics GP 10 to 2010 R2. Alongside this, we also migrated them from FRx to Management Reporter.
All looked fine after the upgrade until I opened one of the rows for editing and got the following warning message;
Backing up the a Microsoft Dynamics GP company to test is, unfortunately, not as simple as backing up one database and restoring it to the Test one. There are two scripts which need to be run after doing so; the first changed the INTERID and Company Name and the second changes the database owner to dynsa.
At my last company, we decided to make this process as easy as possible for clients, so we started creating a SQL Agent Job which would do the backup, restore and run the scripts with minimal effort or could even run on a scheduled basis. The basic purpose was to give the client a test or training system which was always, or could very quickly be, up to date. Continue reading
A colleague is currently working on some development for Microsoft Dynamics GP and needs to create a journal.
I did some digging around the company database looking for the correct way to get the next Journal Entry number and found a function called glGetNextJournalEntry.
A little work and I was able to supply the following to the developer for him to wrap into a stored procedure to get the Journal Entry number and make sure there were no issues in GP;
DECLARE @l_tINCheckWORKFiles tinyint = 1
DECLARE @I_iSQLSessionID int = USER_SID()
DECLARE @O_tOUTOK tinyint
DECLARE @IO_iOUTJournalEntry int = 1
DECLARE @O_iErrorState int
SELECT @IO_iOUTJournalEntry AS 'NJRNLENT', @O_tOUTOK AS 'OUTOK', @O_iErrorState AS 'ERROR'
In two previous posts I discussed testing Microsoft Dynamics GP 2010′s new Email Remittance functionality; first, by setting up creditors with an internal email address and, then, by transferring the email address from the INET1 field to the new EmailToAddress field.
The other script which I used, and forgot to post, was the one which configures all of the creditors, who are not currently configured for email remittances Continue reading