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

     | 1234567**X** | (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.