Date Effective Tax Rates allows you to record various different rates for a Tax Detail, and the date range that these rates are effective. This overrides the default Tax Rate entered in the Tax Detail set up window. For European Dynamics GP users this is a god send with the various EU wide changes in VAT rates.

Date Effective Tax Rates works with the SOP, POP, RM and PM modules in Dynamics GP. Once it is installed (it’s an option available from the Additional Products / Features menu when you install GP 2010 R2) it can be accessed through Tools >> Setup >> Company >> Company >> Options >> Additional >> Date Effective Tax Rates Setup. In this window you can enable the feature for a specific company.

Once enabled a user can set up various rates for each Tax Detail ID, and specify from and to dates for each rate. (Tools >> Setup >> Company >> Tax Details >> Additional >> Date Effective Tax). Remember, rates entered here take precedence over the rate entered in the Tax Detail set up window.

A cool part of this functionality is that you can update all saved transactions after you have set up date sensitive rates. (Tools >> Routines >> Company >> Regenerate Taxes). So once set up, all those unposted invoices etc. can be mass updated based on their dates.

One small issue is when you need to seperately report standard rate VAT at different percentages. Shouldn’t be an issue with rate changes effective from 1st January – since the change is at the start of a fiscal year. But if the rates changed mid reporting cycle and your local VAT authority required transactions at the old and new rates reported seperately, it would probably be best to create a new Tax Detail for the new rate.

Its VAT Rate change time again. Irish Standard Rate VAT is increasing from 21% to 23% on 1st January 2012.  (Hungary is also increasing 2% to 27%, and there will be others).

So, what’s the best approach to cater for these changes in GP, and what should you look out for? The good news is that the change takes effect at the start of a fiscal year – so there will be no need to report at the different rates as there was the last time Irish VAT increased.

At its simplest, changing the %age rate in your standard rate tax detail (Tools >> Setup >> Company >>Tax Details) after you have entered all 2011 transactions and before you enter any 2012 transactions, will suffice for those users using just Dynamics GP Financials (RM, PM and GL).

Slightly more complicated, but best for POP and SOP users – set up two new tax details, one for sales at 23% and one for purchases at 23%. Then set up two new Tax Schedules (Tools >> Setup >> Company >> Tax Schedules) – again one for sales and one for purchases at 23%…and assign one of the two new tax details above to each (Remember to tick Auto Calculate in each if the ‘Auto Calculate’ box is visible).

For most Irish users – you will have Tax Schedules already created called ‘SALL’ and ‘PALL’ (or some derivative). Add the relevant new tax detail into these as well.

Depending on how your system is set up and how it calculates the VAT payable / receivable…you will now need to update your master records. Look at your Item set up – if your inventory items are set to ‘Use Customer’ and ‘Use Vendor’ for their default tax schedules – then you will need to update your customer and supplier records. Any customer or supplier who is set to the current Standard Rate Tax Schedule, will need to be updated to use the new Standard Rate Tax Schedule (the 23% ones you just set up).

If your Inventory Items use their own Tax Schedule (i.e. they are not calculating VAT by reference to the customer or vendor ones) then you will need to update your Inventory records.

If you are lucky – updates can be rolled down by class ID. Or you could run a SQL query to update your master files (Update XXX set Tax Schedule ID = ‘new’ where Tax Schedule ID = ‘old’…something like that!).

You need to be aware of a few things.

• Sales Orders entered in December 2011 will have defaulted to the old rate (21%). When these orders get transferred to Invoice – this rate will follow through. If they are transferred to Invoice in January 2012 – you will need to manually update the Tax Schedules on each.
• If you process a return in 2012 for a sale that happened in 2011 – the return will default to the new 23% rate. You may have to manually change it back to the 21% rate.
• You will need to edit your VAT Dayooks to include the new tax schedule in the standard rate box. (Leave the old rate there as well – since you may enter sales returns etc. at the old rate in 2012.)
• The above will apply to Purchase Order transactions as well.

Two bug bears of mine are finally set to be resolved in Dynamics GP version 12…

• Selecting the Printer at print run time.
• Being able to enquire against GL Journals that are in historical years.

A word of warning – they may be on the feature list, but when release time comes they may have made it onto the cutting room floor. But hey, at least they are on the list!!

The first ‘selecting the printer’ allows a user to select the printer they want to use…at run time.  Previously the printer had to be selected prior to run time. Usually fine, but in those very large reports that take a while to build, it can be a real pain. If you forgot to change the default printer within GP, you have to wait for the report to finish, then change the default printer, and then re-run the report. Small but significant pain, and one that baffles users.

The second issue – enquiring against only open year GL journals is one of those ‘features’ that never really made sense. At least with GP 12, we will now be able to enquire against historical ones as well.

There are more ‘significant’ features billed for Dynamics GP 12 and we”ll look at them soon.

The additem.cnk available on Customersource / Partnersource works fine with GP2010 R2 and GP10. In the download page the compatible versions are listed as GP 8 and GP 9, but it works with later versions.

This.cnk forces the ‘Add Item’ functionality to be ‘on’ when a user opens the Purchase Order Entry window. This is important where users want to know if the Item they have added to a line on the PO is an Inventoried or Non Inventoried item in GP. With the Add Item flag switched on, the user is presented with a message asking if they want to set up a new item, when they enter a Non Inventoried line item.

Unusual one. The exact error message was a get/change next operation on table ‘GL_Account_Master’ is for an invalid key.

Unusual because it related to just one GP user ID, and only when they logged into one particular company. Tried all the usuals like running the Grant.sql against the company database, making sure DYNSA was the Database owner, checking was the database in single user mode, checking / resetting that users window and file access for that one company etc. It manifested itself in two ways:

1. Whenever the user opened the General Ledger Account look up window, for example when they opened the Enquiry >> Financial >> Summary window and clicked the Lookup button to show a list of financial accounts to select from. This list was blank.
2. In any window keyed off the Financial account, if they clicked the Next Record button at the bottom, they got the error message above.

The resolution was to take away access to the company database from that user, save, and then grant access back again. (Tools >> Setup >> System >> User Access)  I can only guess that database / table security was screwey in some way.

Product was Microsoft Business Solutions Great Plains version 8.

When you get an unexpected error in GP, right before you email your Partner, or log onto the Dynamics Community, its probably a good idea to do a bit of digging first. The very first questions you’re likely to be asked are ‘Is it the same for all users?…Does it happen if you log in as ‘sa?’, so a bit of preparation will shorten the resolution time and maybe even allow you to resolve the issue yourself. 

Some things you can try to narrow down the source of the problem:

1. The first thing is to be able to re-creat the error!! And when you do, take a screen shot of the error message (remember to scroll down through the message and get a screen shot of the rest of the message, and a shot of the data in the ‘Additional info.’ window if there is one). Gererally there is a clue in the error message (though not always) – Primary Key constraint, Violation of etc. all point to data corruption. Error in Equation is usually related to a calculated field on a modified report.

2. Log into a different company and see if the error occurs. This will narrow the issue down to a specific Company database, or if it is in all companies, its most likely a DYNAMICS database problem. If its a specific company, try running a Check Links against the relevant series /  table groups and see if this resolves the issue.

3. Log in as ‘sa’ and test for the error. If all is fine with the ‘sa’ login, then run the Grant.sql (located in the SQL sub folder of the GP application directory) – It may just be a table permissions issue within MSSQL.

4. If GP is installed on the Server, log into the server and repeat the test. Does it occur here? If not, then it could be an ODBC set up issue.  Also worth comparing the Server Dynamics.set file to that on the workstation at this stage. Is the server pointing to different locations for shared dictionaries? Or are there differences in the products listed between the two .set files?

5. Are all users receiving the same error? If not then it could be a GP User Security issue specific to the problem user. To debug, you need to find out whats different between the problem user and a good user. Start by ensuring that the problem user ID has the same access rights as the good user ID. First check the Modfied Forms and Reports ID that the good user has assigned (Tools >> Set Up >> System >> User), and compare this to the problem user. Check modified forms and reports for all products installed to ensure the correct access rights are assigned. If you can’t spot any differences that could be causing the error, set up a new user and go through your usual set up routines – adding security access  to companies and modified forms and reports etc. Does this new user get the same errors? If not, its definately a problem with the existing users security settings. You can try and trawl through SQL and GP Security, or take the ‘guaranteed to work’ option…delete and reset up the user.

6. Modified reports…If you are getting strange errors trying to print reports, the first thing to check is if the report has been modified. If it has, grant the user access back to the original version and try again. If the error disappears then its an issue with the modifictations. If it doesn’t then it could be an issue with the output (test printing to screen or file) or corrption in the underlying data.

One of our customers is upgrading from version 9 to 10. This also involves a move to a new server and some eConnect developments. Means that we set everything up on the new server, get the eConnect integrations tested and when all is ready, do the live upgrade and detach and re-attach the databases So, to allow users test the new enviornment, GP 10 was installed on som workstations alongside the current Live GP9. Not an issue, both will co-exist perfectly happily, each with their own ODBC to connect to their relevant server.

However, a day or so after installing GP10 (and having tested that both versions launched and worked OK), a user reports getting the following error message when logging into GP9:

You are using an earlier version of the Dynamics.dic than the one that is currently installed on the network.

Logging into GP10 was fine, so worked our way through all the usual suspects on the 9 install, and went back over the sequence of events since installing GP10 and the error appearing to see what could be the cause. Different Dynamics.dic version? OK – so lets look in the DB_Upgrade table in the Dynamics database – nothing wrong there, all product versions as they should be. Then we looked in the Versions table – DU000020. Aha!! in here the Dynamics Product major Version is set to 10. (The Product ID for Dynamics is ’0′). This clearly isn’t correct. We manually edited the table to reset the major and minor version numbers to what they should be, and viola, all back to normal. Users logging into 9 without issue.

But what was the cause? We tested in our own test enviornment and failed to re-create the issue…until…we changed the ODBC name when logging into Version 10 and hey presto, the error message re-appears.

It seems that the simple act of launching GP10 and selecting the ODBC that connects to the 9 database…actually causes an update to the DU000020 table. Now, when you do this, of course GP recognises that the data is in version 9 format and tells you to run utilities to update it. This is as you would expect…but even if you close out of GP, the DU000020 table is updated.

Simple fix, but could have been one of those all nighter issues!!

Note:

When looking at the DU000020 table, and you have no idea what the major and minor version numbers should be, look for one of the other products that are in synch with the Dynamics.dic version numbers. We used Field Service – product ID ’949′ – setting the Product ’0′ version numbers to equal the ’949′ version numbers.

Microsoft’s Office 365 offering is well documented on line. By now, most people are aware of it as Microsoft’s foray into the Cloud with their flagship office productivity tools.

But, if you’re a Dynamics GP user and are using the many MS Office integration points within GP to manage and project your business beyond GP, what are your options? If you switch to the Cloud, how will this affect current processes? Is this something you need to worry about?

Not according to the folks in Redmond. Their pronouncements on this are cut and dry. If you use GP and Office now, then if you switch to Office 365 there will be no change in experience usage. What you do now, you will be able to do in Office 365. Expect quite a bit of blogging on this topic over the coming months as more details emerge

And thats the skinny on Dynamics GP and Office 365!