"Unhandled Script Exception: Set Precision.." when selecting item in Item Maintenance window

Background

The user was attempting to select an item in the Item Maintenance window and received the error:

Unhandled script exception:
set precision passed bad precision value -1.

EXCEPTION_CLASS_SCRIPT_OUT_OF_RANGE
SCRIPT_CMD_SETPRECISION

The error only happened for a handful of items in a catalog of a few thousands.

Solution

Dynamics will attempt to set the decimal precision for the currency and quantity fields on the Item Maintenance window based on the number of decimal places for the functional currency (this is the default) or based on the number of decimal places used to define the item list price under the Item Currency Maintenance window; and in the case of the quantities, the number of decimal places for the quantities. To fix the issue, you will want to look at the columns DECPLQTY and DECPLCUR for any values at or below zero which would sure render an incorrect precision value when Dynamics GP attempts to set the value of the drop-down list on the screen. In this case, a zero value in any of these columns will result in a precision value of -1, when the system attempts to set the drop-down list value.

The following query will identify any suspect records causing the problem:

SELECT * FROM IV00101 WHERE (DECPLQTY <= 0) OR (DECPLCUR <= 0);

SELECT * FROM IV00105 WHERE (DECPLCUR <= 0);

To fix, you will want to at least set them to the values of your functional currency, for example:

UPDATE IV00101 SET DECPLQTY = 3 — 2 decimals
WHERE (DECPLQTY <= 0);

UPDATE IV00101 SET DECPLCUR = 3 — 2 decimals
WHERE (DECPLCUR <= 0);

UPDATE IV00105 SET DECPLCUR = 3 — 2 decimals
WHERE (DECPLCUR <= 0);

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

Inside multi-platform integrations with Integration Manager

I have been working on a very challenging systems conversion project, from JD Edwards on AS/400 and DB2 to Microsoft Dynamics GP v9. Part of the challenge stems from the fact that certain processes, mainly in-house applications developed for the AS/400 will continue to support existing business processes pass the “go-live” date.

I am tasked with developing multiplatform integrations to support application processes in place and by doing so, I’ve had to dust off my DB2 – AS/400 skills. Per the client’s request, the integrations need to be easy to use, extremely flexible and adaptable, and low maintenance (as in little to no programming required). Many of you may think that due to the nature of the systems involved, this could very well be an eConnect implementation. However, Integration Manager was chosen because of the characteristics previously described.

As I work through implementing the first integration to manage expense reimbursements from Lotus Notes, my integration needs to read data from some interface tables in a DB2 catalog. As such, we deployed the IBM Client Access ODBC driver. Working through the configuration was fairly simple, but due to the driver features I was afraid Integration Manager was not going to be able to store the DSN configuration.

One thing I discovered while working with IM v9 SP4 (9.00.0054) is that due to it’s underlaying implementation of the almost outdated use of ADO technology, it cannot perform a preview of the source queries, with the following error message:

Upon further research, it seems this error is generated because server-side cursors are not supported with ISAM (Indexed Sequential Access Method) files. As it turns out, ISAM was originally developed by IBM and later replaced with a storage file system called methodology called VSAM (Virtual Storage Access Method). VSAM is the physical access method used in DB2.
What does this have to do with IM? Well, IM — version 9 specifically — uses ADO to connect and retrieve data. The problem with ADO and VSAM file systems is that the cursor location needs to be set to AdUseClient and the cursor type needs to be checked for bookmark support:

oRecordSet.Supports(adBookmark)

Apparently, this is not being done in IM v9’s internal ADO implementation. The good news is, I checked this against IM v10 and I have to say it works just fine, since, IM v10 was developed from the ground up with ADO.NET.

Given there was no preview available, testing began with a small dataset.

Integration Manager began importing expense vouchers and in the process neglected randomly to import the distributions. I executed the same integration a few times and obtained random results: transactions that previously imported fine along with their distributions did not import and failed the second time around. I verified the RecordSource Rule and Source properties to make sure they were set to Default Non-Imported and the source query for the distributions, respectively.

Upon adding some VBScript to write the records that were being read and attempted during the integration, I noticed that the header records were being read in order while the distribution records were shifting randomly. In some cases IM would match the header record with the distribution record, but in some cases it would skip a valid set of distributions for an expense voucher. By changing the UseOptimizedFiltering flag in IM to False the imports began to work as expected.

Integration Manager is a very useful tool and should not be overlooked when considering multiplatform systems integrations, especially if the customer insists on easy of use. All the integrations will be scheduled on a server and will run unattended, which only validates IM’s flexibility.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Applying Microsoft Dynamics GP v10 service pack 4: Tales from the trench

It’s a gloomy and rainy day in Atlanta, so I figured I could do something productive while under lockdown. I currently run Microsoft Dynamics GP build number is 10.00.1193 — service pack 3, which was installed using the Feature Pack 1 DVD image available on CustomerSource and PartnerSource under the Product Release section. This build installs the Dexterity dictionary 10.0.320.

Before beginning the installation of SP4, I created a backup copy of my current GP installation folder just in case I needed to revert to it, and of course, backed up all forms, reports, and VBA projects, and my DYNAMICS and company databases. I also backed up the registry key corresponding to the GP installation, HKLM > Software > Microsoft > Business Solutions > Great Plains.

The upgrade operation began by launching the Service Pack 4 msp installation file.

After 5 minutes of the “10.0 is being configured on your computer” process, the installation script began “Gatherting required information” to calculate the installation steps required to deal with my environment’s configuration.

That went fairly fast, until the progress bar reached 90%. This is when things slowed down again for approximately another 2 minutes.

Once planning phase was up, another progress bar began letting me know that “10.0 is being configured” on my computer, presenting a progress bar with the time remaining.

Approximately 1 second before the “Time remaining” phase was up, I got an error saying “DEX.DIC version 10.0.320 is not compatible with executable version 10.0.324.0“.The error showed up one more time and I clicked the OK button to continue. No other indications, except for the message that anything was wrong.

The process went along and completed “successfully” with all service pack files copied into the GP installation folder. All the Dexterity Shared components were replaced.

I then lauched Dynamics Utilities…remember that DEX.DIC error? There it was again! At this point, the only safe recovery option to protect my data’s integrity was restoring all previous backups: databases, reports, forms, registry entries, and application folders.

I then downloaded the latest hotfix prior to SP4, 10.00.1328 (KB971014), and repeated the installation process. Everything went fine. I did not receive the pesky Dexterity dictionary version check error, all system and company tables upgraded without a hitch. All my reports and forms upgraded successfully. I noticed the Dexterity dictionary version for this hotfix was 10.0.320. The question now was, would I receive the same error attempting to install SP4?

I repeated all the installation steps I previously described. The good news this time, the installation of the Service Pack 4 components completed without a hitch.

I onced again launched Utilities, this time to upgrade all system and company tables as required. The product validation went on successfully. SP4 rightfully detected the existance of a previous version. I clicked Next to continue with the system database upgrade. This operation completed successfully with the account framework synchronization.

Next was the company update process…this also went substantially smooth and fast. As to the error, I cannot say for sure whether the installation steps call to be on a specific Microsoft Dynamics GP hotfix build prior to beginning the installation of Service Pack 4, or if this is something that is unique to my environment configuration, but at least the word is out. If you find yourself in this situation, you may be forced to upgrade to the latest hotfix prior to the release of SP4 to correct this situation.

There is also another issue with the original Service Pack 4 installation, with SmartList Builder and Excel Report Builder. If you attempt to save a calculation, you will receive the error “Wrong number of arguments to ‘Replace_Text’”.

Fortunately, all you need to do is download a chunk file and apply to solve this problem. You will find a link to the chunk download by clicking on a link under the Current Release Downloads secition of the Service Pack, Hotfix, and Compliance page.

You are now directed to the error page, where you can download a zip file with the fix, under the Hot Topics area.

Applying the chunk was very simple, but is always recommended that you backup your data.

[Updated 09/02/2009]
Chad A., a user on the Dynamics GP newgroup reported having the same problem. This was his reply:

Found the issue! Looks like Microsoft changed the name of the dictionary from dex.dic to dex_us.dic (there is also a dex_int.dic) back in the day. My GP 10 SP3 install had both files (dex.dic and dex_us.dic) at the same version (10.0.320). SP4 upgraded dex_us.dic but didn’t upgrade dex.dic. I checked the dynamic.set, dynutils.set, and dex.ini file but didn’t see it listed anywhere so I just renamed dex_us.dic to dex.dic. That stoped the error message.

We started on GP 7.5 way back in the day. I wonder if that name change got
stuck in the system because we upgrade each time.

Microsoft should probably look into this. I will wait a little bit to see if they catch it, otherwise I may have to send an email to some internal Microsoft GP people I know.

Hope you find this response useful.

Until next post!

MG.-
Mariano Gomez, MIS, MCP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Microsoft Dynamics GP v10 Service Pack 4 now available

The highly anticipated Microsoft Dynamics GP v10 Service Pack 4 is hot out of the oven! Service Pack 4 had been expected by the end of this week, but the development and tesing teams worked around the clock to beat the deadline.

Service Pack 4 addresses a number of issues and delivers new features, such as International ACH Transactions (IAT) and Extender enhancement capabilities for forms and detail forms.

Extender Forms Enhancements

• Create new data entry forms for master files and transactions
• Create SmartLists for each new form
• Add Note windows and Note List windows
• Create conditional and calculated fields
• Use lookups to link to any Microsoft Dynamics GP or third party table
• Generate the next master ID numbers automatically
• Add up to 50 extra windows for each form
• Open associated applications from files
• Use templates to default fields and increase data entry speed
• Create multicurrency forms
• Create views
• Import data into forms

Extender Detail Forms Enhancements

• Create scrolling windows with up to ten user defined fields
• Import data into detail forms
• Add detail forms as quick links on the Home Page

SP4 will bring the Dynamics dictionary build number to 10.00.1368, but be sure to read the Installation Guide topics. There is an issue with Service Pack 4 that changes the OLEPath in the Dex.ini to the default local path. If you use OLE Notes and have a path to a network share, make sure to review the Dex.ini at each client workstation following the hotfix installation to ensure the path is correct. This issue is currently under review for a fix release. The default location for the Dex.ini is C:\Program Files\Microsoft Dynamics\GP\Data.

You can download Microsoft Dynamics GP v10 Service Pack 4 from:

CustomerSource – Click here
PartnerSource – Click here

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

US Payroll Tax Update Rounds

Having a tough time correlating the Last Tax Update date with the actual Payroll Tax Round number released by Microsoft?

Setup > System > Payroll > Payroll Tax
Sweat it no more! The following is a list of payroll tax round numbers with their corresponding dates:

Round 7 – Last Tax Update 7/3/2009
Round 6 – Last Tax Update 6/22/2009
Round 5 – Last Tax Update 4/27/2009
Round 4 – Last Tax Update 3/23/2009
Round 3 – Last Tax update 2/26/2009
Round 2 – Last Tax Update 1/21/2009
Round 1 – Last Tax Update 12/19/2008

Remember, you can always use the automated tax update feature in Microsoft Dynamics GP to get the latest tax updates.

1) Go to MSDGP > Maintenance > US Payroll Updates > Check for Tax Updates, and choose the Automatic update mode from the wizard.

2) Enter your company Authorization Number (usually your main phone number) to continue.

Click on the Log in button to continue. Dynamics GP will then download the latest tax update and apply the latest fixes required to fix bugs found in processing of payroll taxes.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

Fixing Microsoft Dynamics GP Toolbar erratic behavior

A few months aback, I blogged about a case where the Microsoft Dynamics GP toolbar menu would reorganized itself erratically even with the Lock Toolbar option activated. Back then, I alluded to the Script Debugging Tool being activated via the DEX.INI. Since then, I have also found that this may (or may not) be the case when returning from Modifier or Report Writer.

If you do happen to experience this issue and do not use the Script Debugging Tool, you can run the following T-SQL script in SQL Server Management Studio to correct the problem:

USE DYNAMICS;GO

UPDATE SY07121 SET Visible = 0, ROWNMBR = 1, RowSequence = 1 WHERE CmdBarDictID = 3830   AND CmdBarFormID = 22006   AND CmdBarWindowID = 22003   AND USERID  ''

UPDATE SY07121  SET Visible = 1, ROWNMBR = 1, RowSequence = 4  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 294    AND USERID  ''

UPDATE SY07121  SET Visible = 1, ROWNMBR = 1, RowSequence = 3  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 295    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 231    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 223    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 230    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 228    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 225    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 224    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 226    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 227    AND USERID  ''

UPDATE SY07121  SET Visible = 0, ROWNMBR = 99, RowSequence = 0  WHERE CmdBarDictID = 0    AND CmdBarFormID = 1568    AND CmdBarWindowID = 192    AND USERID  ''GO

The above script is applicable ONLY to Microsoft Dynamics GP v10. Make a backup of your DYNAMICS database before executing this script.

If the above fails to correct the issue, then you will need to remove the records for the user in question:

USE DYNAMICS;GODELETE FROM SY07121 WHERE USERID = 'theUserID';

The scripts were originally provided by Sarah Purdy on the Dynamics GP Partner Technical Community and must be executed without any users in the system.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Support Debugging Tool FAQs

I get asked almost on a daily basis what is Support Debugging Tool and how to get a hold of it. In addition, many partners have not ventured into using the tool at their customers, because they are unsure of the installation process, the footprint, or unaware that it’s a free tool.

Now, David Musgrave over at Developing for Dynamics GP has channeled all those inquiries into a Frequently Asked Questions (FAQ) article. If you are a customer and want to take advantage of Support Debugging Tool, but you are unsure how to obtain it, this article is just right for you. If you are a partner trying to become familiar with the tool and the installation process, this article is also right for you.

If you are not using Support Debugging Tool, you are definitely making your support and troubleshooting efforts much more difficult than they should be.

Related Articles

For all Support Debugging Tool articles over at Developing for Dynamics GP, click here. For all SDT related articles on this site, click here.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com

User date rollover message not displaying after mid night

Just recently on the Dynamics GP Partner forum, my friend Japheth Nolt reported that some workstations at one of his clients would not display the warning dialog “It’s 12:00 a.m. Would you like the user date to change to …?” after the system clock crossed the 11:59:59 PM barrier, and that this issue would cause some users to enter transactions with the wrong date. After all, transaction windows in GP default with the user date, not the system date.

Japheth had already inspected the DEX.INI looking for the SuppressChangeDateDialog, making sure the key was not set to True. This setting prevents the user date rollover message from being displayed and was designed to prevent integrations running around mid night from failing in response to the warning dialog.

In addition, there were no macros running around the mid night timeframe either. When a macro fires up, all timed events crossing paths with the executing macro are re-queued by the runtime engine.

The first step towards solving the problem was replicating the problem experienced by the users. So, this implies changing my system’s date and time to 11:59 PM., and check the Process Monitor to verify the status of the smChangeDateTimedEvent script timed event.

I noticed that past mid night, the smChangeDateTimedEvent script would move to the bottom of the queue, just as it would if a macro was executing when the timed event needed to be fired.

Something else was happening. I realized the date of the Fabrikam company is set to April 12, 2017, a far cry from my system date. Following, I changed the system date to April 12, 2017, 11:59 PM. Once the system date was changed, I waited patiently until the clock hit mid night… Bingo! The warning showed up!

As it turns out, the Dexterity Sanscript code checks that the system date matches the user date plus 1 day, before the user date is changed. Why? Since the Dynamics GP user date is managed by the user, the development team had to assume that if the user changed the user date, then the user wanted the date to remain in place regardless of any mid night change of date.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

User date rollover message not displaying after mid night

Just recently on the Dynamics GP Partner forum, my friend Japheth Nolt reported that some workstations at one of his clients would not display the warning dialog “It’s 12:00 a.m. Would you like the user date to change to …?” after the system clock crossed the 11:59:59 PM barrier, and that this issue would cause some users to enter transactions with the wrong date. After all, transaction windows in GP default with the user date, not the system date.

Japheth had already inspected the DEX.INI looking for the SuppressChangeDateDialog, making sure the key was not set to True. This setting prevents the user date rollover message from being displayed and was designed to prevent integrations running around mid night from failing in response to the warning dialog.

In addition, there were no macros running around the mid night timeframe either. When a macro fires up, all timed events crossing paths with the executing macro are re-queued by the runtime engine.

The first step towards solving the problem was replicating the problem experienced by the users. So, this implies changing my system’s date and time to 11:59 PM., and check the Process Monitor to verify the status of the smChangeDateTimedEvent script timed event.

I noticed that past mid night, the smChangeDateTimedEvent script would move to the bottom of the queue, just as it would if a macro was executing when the timed event needed to be fired.

Something else was happening. I realized the date of the Fabrikam company is set to April 12, 2017, a far cry from my system date. Following, I changed the system date to April 12, 2017, 11:59 PM. Once the system date was changed, I waited patiently until the clock hit mid night… Bingo! The warning showed up!

As it turns out, the Dexterity Sanscript code checks that the system date matches the user date plus 1 day, before the user date is changed. Why? Since the Dynamics GP user date is managed by the user, the development team had to assume that if the user changed the user date, then the user wanted the date to remain in place regardless of any mid night change of date.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Microsoft Dynamics GP Database Maintenance Utility

How many times have you performed an upgrade just to realize with the first posting that some stored procedure is missing or did not — for some misterious reason — get created, yet the upgrade completed with no errors? This is especially true when upgrading from several versions aback, when the upgrade path is not too clear, or you have forgotten to apply that critical service pack that would avoided some of the missing objects issues you are now experiencing.

I recently came across a user who wanted to recreate all SmartList Builder objects because they suspected something was wrong with the installation, however, they did not want to have to use the backend to recreate all the stored procs used by SLB, because of the “fair of missing something or endup damaging something else“… you know what they say… the client is always right! (not always, but that’s the topic of another article).

After scratching my head for a few moments, the answer came in the form of the new Microsoft Dynamics GP Database Maintenance Utility, but first some history…

Before there was the SQL Maintenance utility, back in the old days, the former Great Plains Software provided reams of text files containing scripts to recreate any missing or damaged system and/or company database object. These scripts could be found on the installation CDs and could be accessed via the old SQL Server Query Analyzer tool. All you needed to do was to open one of script files, do a search for the desired stored procedure, copy and paste into Query Analyzer, and execute the script against the appropriate database. This sounded simple enough until system administrators (we will not call them users for fear of retaliation ) began corrupting the script files and introducing their own code… It was funny, because Great Plains Support used to asked as part of their support script if you had modified X or Y stored procedure for the problem you were calling for. When Microsoft took over, came the MSIs and the script files were no longer provided. Now what? There comes SQL Maintenance, however, the set of utilities provided with SQL Maintenance did not allow you to recreate stored procedures, functions, or table triggers. These still had to be obtained from Microsoft. I guess, in the end they figured out it wasn’t worth the hazzle and delivered Database Maintenance Utility.

So, lets take a look.

To recreate database objects, you will need to:

1) Launch Database Maintenance Utility. Go to Start > Programs > Microsoft Dynamics > GP 10.0 > Database Maintenance.

Select your server and select an authentication method. Fortunately, Database Maintenance can use Windows Trusted Authentication. Click Next to continue.

2) Choose the company you are going to perform the updates on. My personal preference is to choose ALL databases if you suspect a damage on a stored procedure, function or trigger. Why? Chances are, the stored procedure may be damaged across the board.

Click Next to continue.

3) Select the product for which you will like to rebuild its objects. For this example, I will use SmartList Builder.

Click Next to continue.

4) Mark the objects you would like to recreate. You have the choice of Stored Procedures (includes UDFs too), table Triggers, and Views.

Note that for Tables and table Auto Stored procedures you must use the SQL Maintenance option available within Microsoft Dynamics GP. Click Next to continue.

5) Confirm your selection.

Click on Next to continue.

6) The Utility will run through a progress bar and will return a status of the operations when completed.

If recreating stored procedures, the Database Maintenance Utility will re-grant permissions to all database users in the DYNGRP role, so no need to run the GRANT.SQL utility script.

Hopefully, you use this powerful tool as a first option in recreating any missing or damaged database object, before you call Microsoft or open that support case.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com