Fix: Dynamics GP 2010 modify word template, File Not Found

 

Template maintenance in Dynamics GP2010 fails

When in REPORTS>>Template Maintenance, after creating a new report from an original report, clicking on “Modify” caused a file not found exception on our install of GP.

"File Not Found: C:\DOCUME~1\USERXX\LOCAL~1\TEMP\file you were savingcreating.docx"

Solutions on the web GP community forums

  • Reinstalling Dexterity Shared Components
  • Upgrading to GP2010 SP2 or above

These solutions were not working for us. Between us we spent too much time running filemon and looking at debugger tool traces trying to track the problem down. The traces showed the template being created in the user profile temp directory with no error, but in reality it never got there.

Breakthrough

The server copy did work correctly. We spent some time between us trying to work out what the issue was and finally a colleague said something that made sense to me, so I checked out the theory.

I did a WinMerge check between the Add-in Directories (Addins subdirectory of GP application directory) on the working and failing machine and found the following missing files:

image

 

Copy the missing DLLs into the Adds folder

After copying all but the BusinessIntelligence dlls to the add-in folder of the previously broken install, the feature started working correctly again.

My guess is the managed storage dll is involved with the creating of the temp file… possibly.

Hence it would seem we’ve dropped these files as we have upgraded through the versions. We have our own Visual Studio Tools Addins in the add-ins folder. These are passed from version to version as we upgrade GP. My guess is these extra missing dlls got lost at some point causing the word template editing functionality to fail.

I hope this post has helped you get to the solution more quickly that we did.

Here is the working template in word

clip_image002

GP2010 SP3 Enhanced Intrastats VAT number format wrong IE (Ireland) and others…

07/11/2013 UPDATE: Partner has referred the matter to GP Fargo…

17/04/2015 UPDATE: New post with a fix

Tax registration numbers change

The Tax Registration number validation implementation looks to be flawed. Every EC country has VAT number formats they use, and regular expressions can be derived for most of them. Be aware that they are dynamic formats, regularly (well relatively) validation changes. As Microsoft Dynamics GP users this catches us out when it happens between releases as we need to wait for a hot fix.

At my company we have a SQL table of regular expressions against ISO country code, that we maintain for our website to validate the tax registration number formats entered by users. It is surprising how often we end up tweaking them, for new ISO country codes, a country changing a format, a country joining the EC etc. However when we get to GP this is very painful. I understand that in Dynamics AX, there is a user setup form where you can play with the the validator format for each country code. In GP we don’t seem to have this. From what I can tell whatever validation is occurring, the rules do not even reside in a table. It looks like it is complied into the app code!

I remember the same issue with valid Belgium VAT numbers not being accepted a while back, a hot fix followed to fix it that time.

Irish IE VAT number – Invalid Format

So today a customer presented, a newly created Irish company that uses the new Irish VAT number that now permits two letters at the end (e.g. 123456SH), this is a new format we’d not seen before and GP baulked at it with the familiar “Invalid Format” validation error on trying to enter it. First the sales staff checked with the VIES online checker see my GP implementation of this here, Dynamics GP real time EU tax registration number validation using VIESit validated fine.

Checking with the VAT number format on the  “.gov” website EU country codes, VAT numbers and VAT in other languages, it seems it is indeed valid. So we updated our website table, checked for any other country changes and then were left with no way to make GP take the number (other than direct to SQL). Time to raise a support ticket with our partner.

Valid Formats

1234567X

(8 or 9 characters)

1X23456X

 

1234567XX

 

I guess I’m saying that the country code setup window should have the ability to enter a regex (for advanced users), to allow us to intervene when these formats change, without the serious expense and time of having to test and deploy hot fixes. Obviously I’d expect the regex to come out in a table in SQL somewhere in that scenario.

Dynamics GP Add in “Cannot load file or assembly Microsoft.Lync.Utilities”

GP Add in raised exception

After applying GP2010 SP3 my GP add in started raising an exception on windows forms that used Entity Framework (EF). The error reported was

System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Lync.Utilities, Version=4.0.0.0…"

…but I don’t use Lync…

But I know Dynamics GP does have integration with Lync. It had me puzzled for a while as I wondered why my form was causing this assembly to be required and attempting to load it. Eventually the penny dropped after studying the stack trace. The stack trace was mentioning about System.Reflection and System.Data.Metadata.Edm.DefaultAssemblyResolver.GetAllDiscoverableAssemblies().  I guessed there was some dynamic loading going on and got mislead reading up on MEF, thinking perhaps GP implemented it under the covers. I then hit lucky on Google with Craig Suntz’s blog that explained my issue. It is down to Entity Framework connection strings.

Entity Framework Connection Strings

In my EF connection string I was building my connection string like this from the SQL connection string.

Dim entityBuilder As New EntityClient.EntityConnectionStringBuilder()
entityBuilder.Provider = "System.Data.SqlClient"
entityBuilder.ProviderConnectionString = sqlBuilder.ToString
entityBuilder.Metadata = _
"res://*/Inventory.DAL.InventoryModel.csdl|res://*/Inventory.DAL.InventoryModel.ssdl|res://*/Inventory.DAL.InventoryModel.msl"
Return entityBuilder.ToString()

Notice the “res://*” bit, the Metadata reference. The files are embedded into the assembly as resources and this Metadata property is the pointer to them. Specifying * instructs a reflective search through all assemblies (even if not yet loaded)  that are referenced by the application, looking for the resources.

I guess that as Lync SDK was referenced by GP 2010 my attempt to create the connection was causing the Lync assembly to be loaded in order to check it for the meta file resource. The consequence of this is that we got an application exception as that assembly does not exist on the machines in our organisation.

Solution

The solution is to explicitly specify the assembly name that holds the resource as shown in the next code snippet. Making this exact reference is more efficient by it preventing unnecessary loading of assemblies and thus preventing the error . This is interesting as I’d experienced a performance hit on these windows vs ones not using EF. I assume some of that was down to this attempt to load all the assemblies.

Dim entityBuilder As New EntityClient.EntityConnectionStringBuilder()
entityBuilder.Provider = "System.Data.SqlClient"
entityBuilder.ProviderConnectionString = sqlBuilder.ToString
entityBuilder.Metadata = "res://GP AddIn GUI Library/Inventory.DAL.InventoryModel.csdl|res://GP AddIn GUI Library/Inventory.DAL.InventoryModel.ssdl|res://GP AddIn GUI Library/Inventory.DAL.InventoryModel.msl"
Return entityBuilder.ToString()

Solved

After recompiling and then deploying to the GP add in folder, my problem went away. I suspect if I spent some more time on this that the Lync assemblies are stuffed into the Global Assembly Cache by the SP3 installer, as we do copy deployments to the client machines we will be missing those assemblies. Hence not everyone may suffer this issue when using add ins if you run the full installer. However this guesswork needs researching and I’ve not got time right now to investigate.

About MEF (Microsoft Extensibility Framework)

In my Google search of the issue, it looks like you can get issues around MEF with dynamically loading assemblies, so for those of you finding this post through Google and not using Dynamics GP, then that might be a term to try on Google for a solution in your scenario.

Below is the original error

Raised by by Add-in for those still with an interest…

clip_image002

Formatting notes using GP econnect

Note to self:

http://dynamicsgpland.blogspot.co.uk/2010/11/formatting-notes-using-econnect-2010.html

My solution is to run in a stored procedure after econnect,

-- fix formatting of the notes field that gets screwed up by econnect loosing line breaks     
UPDATE  sy03900
    SET txtfield = replace(CAST (txtfield AS VARCHAR (MAX)), CHAR(10), char(13))
WHERE   noteindx = (SELECT NOTEINDX
                    FROM   rm00101
                    WHERE  custnmbr = @CUSTNMBR);
UPDATE  sy03900
    SET txtfield = replace(CAST (txtfield AS VARCHAR (MAX)), CHAR(10), char(13))
WHERE   noteindx = (SELECT NOTEINDX
                    FROM   sop10100
                    WHERE  soptype = @SOPTYPE
                           AND sopnumbe = @SOPNUMBE);