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.

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.

• 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.

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 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.

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.

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.

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!

Great Plains Dynamics

Yes it is!

Its 10 years since Microsoft acquired GP for about 1.1 Billion dollars plus change – or Great Plains Dynamics as it was back then. Based up in Fargo with Doug Burgum at the helm, running ‘Stampede’ every year. The highlight for the Irish contingent was the FRx Breakfast! (which ran from about 2am when the pubs closed, to the following morning). And it all started with the Burgum family developing a DOS based accounting package for themselves!! For GP back then, the partner channel really was the key that opened the door.

Some great milestones – remember eEnterprise? the 32 bit release? All the hoo hah over Y2K? (or as Morgan used to say ‘Y not?’), the Euro Conversion, Siebel Front Office, The acquisition of FRx? The Acquisition of Solomon (Dynamics SL), the first run of Multicurrency POP (Aaaaaghhh), The eCommerce module???? and all the while the lovely wav file welcoming you to dynamics every time you logged in.

According to Microsoft’s Steve Balmer at Convergence last week in Atlanta, GP had 30,000 customers world wide when Microsoft bought the company lock stock and barrell. Microsoft Dynamics now has 350,000 customers with over 5 Million users worldwide.