Dynamics GP VAT rate change and how to deal with it

8th July 2020 and the UK government have announced that temporary reduction of VAT rate from 20% to 5% for hospitality sector (on food, accommodation and attractions), from 15th July until 12 January 2021. This gives you only one week to get advice from your ERP support on how to set up your system for the new VAT rate and for some (depending on your services and product mix), this will involve for the first time having to deal with different rates of tax on the same documents. Some people are SO going to be regretting not originally setting up invoice reports etc to dynamically pull the tax rates at the line level! Consultants are going to be super busy this week just helping people through the basics of reconfiguring their system to work with the new temporary VAT rate. This is also for many going to involve some consultancy to put the rates back in January (depending on how self sufficient the GP site is).

What should you think about?

You must  check in your supporting systems and documents, such as excel, your GP reports and reporting services reports for places where VAT rates have been “hard coded” (written in rather than looked up from system). These will need addressing, by preferably doing the extra work to dynamically look them up at run time, or replace with more generic wording if appropriate (say in terms and conditions of sale where VAT rate may have be specified in words.) As time is short you may just have be less perfect and note where they all are and go change them and get ready to swap the old report for the new report/document on the day and back again in January, assuming the rate actually goes back then…

Next you have three issues

  • Ensure new transactions from 15th July get the new 5% rate
  • Dealing with existing transaction particularly SOP document that will be fulfilled/processed after the 15th July as they will retain the previous tax rate unless further work to recalc is performed.
  • Putting the rate back again in January 2021

 

You have some avenues to explore:

  • Introduce a totally new Tax Schedule and Tax Detail IDs for the new rates. On the night of the change, update all the records to point at the new tax detail ids.
  • Just add new Tax Detail ID then take old one out of existing schedule.
  • Change the value on the exiting Tax Detail ID (not recommended).
  • Turn on effective tax dates feature (version GP2010+) and configure the effective records for the date in question. If no effective date exists it will fall back to the base tax rate so this will work well.
  • Use the Regenerate Tax tool to update your existing transactions.
  • Use a macro to update each document (depending on your transaction volume, could be very painful)

Some of the above options, provide for a clearer picture than others when it comes to reporting your VAT particularly don’t just change the tax percentage of the exiting Tax Detail, this is bound to give you issues, so consider that too.

Dynamics GP may from version GP2010 (with extra product) use Date-effective Tax. This allows a date range to be stored against a different tax rates for tax details , the appropriate tax rate then being used by a transaction based on that date in respect of document/posting/tax date (as configured). This is extra module that needs installing prior to GP 2015 R2, but after that it should be waiting for you to enable in company settings, if you haven't already.

There is also the useful tool of “Regenerate Taxes” that allow existing transactions to have the tax values updated, once the detail id has been updated.

Andy in his blog goes through some of the options with older versions of GP: All Change on 20% Tax Again January 2011 this should be read together with  Changing SOP Tax Rates using the Support Debugging Tool.

 

The “Whats New In Dynamics GP2015r2 document” explains all this nicely as copied below:

Date effective tax

You can now enter the tax rates in advance for transactions, and calculate the taxes based on the rates specified for a date range. You can also recalculate the taxes for the saved transactions by modifying the specified tax rates based on the latest tax rates specified by the tax authorities.

You can mass modify the tax rates, and regenerate the taxes for the saved transaction batches.

Follow these steps to set up a date effective tax:

1. Open the Company Setup Options window.

Company Setup Dynamics GP Effective Tax Dates

2. Microsoft Dynamics GP >> Tools >> Set up >> Company >> Company >> Options

3. In the Company Setup Options window, mark the Enable Tax Date checkbox, to allow you to use the tax date option for calculating the tax rate for the transaction based on a tax date.

4. Mark the Use Date-effective Tax checkbox. Select the option to calculate the tax. The option that you select here is used for updating the taxes for saved transactions within the tax effective date range. Transactions that are corrected will be based on the date you select here. You can select the Document date, Posting date or the Tax date to calculate the tax.

NOTE: Select posting date if you want to calculate tax based on the posting date that you specify. Select Tax date if you want to calculate tax based on the tax date that you specify. Select Document date if you want to calculate tax based on the document date that you specify.

You must set up the date range for the specified Tax ID to calculate the tax amount or percentage for the transaction. Follow these steps to create the date range for the tax ID.

1. Open the Date effective Tax Rates window.

DAte EFfective Tax Rates Window Dynamics GP

GP Tax Detail Window with Date Effective Tax Rates

2. Microsoft Dynamics GP >> Tools >> Set up >> Company >> Tax Details >> Select the tax ID in the Tax Detail ID field to set up the date range for >> Date effective Tax Rates.

3. Specify the date range for the specified tax amount or percentage. You can mass modify the tax percentage of multiple tax IDs.

You can choose to modify the tax percentage or amount for the taxes detail or the tax type based on date range, or for the tax without any specifying any date range, or both. Follow these steps to mass modify the tax percentage.

1. Open the Mass Modify Taxes window. Microsoft Dynamics GP >> Tools >> Utilities >> Company >> Mass Modify Tax Percentage

2. Select the option to modify the tax percentage.

You can choose:

• Date effective Tax – To update the dates specified in the date range, and the percentage that you have specified in the Date effective Tax rates window. What’s New in Microsoft Dynamics Page14
• Tax details – To update the tax percentage that you have specified in the Tax Detail Maintenance window.
• Both – To update the tax percentage that you have specified in the Date effective Tax rates window, and in the Tax Detail Maintenance window.

3. Click Insert to view the list of the tax IDs listed for the modification. NOTE: Within the specified Tax IDs, if you do not want to modify any Tax ID, you can select the Tax ID record, and click Remove.

4. Click Modify to modify the listed Tax IDs based on your specifications. You can also regenerate taxes for the transaction batches with the updated tax percentage. You can regenerate taxes for all the saved transactions of all the modules (except GL) or the selected module, only if you mark the use date effective tax in the Company Setup Options window.

You can specify the modules and the batches for which you want the taxes to be regenerated, or regenerate the taxes for all the batches in all the modules (except GL) at one time.

Follow these steps to regenerate the taxes for the saved batch transactions.

1. Open the Regenerate Taxes window. Microsoft Dynamics GP >> Tools >> Company >> Utilities >> Regenerate Taxes

2. Select the module to regenerate the updated tax for the batches. You can choose All to update the tax for the saved batch transactions in all the modules (except GL). Or, you can choose the module to update the tax for the saved batch transactions in the selected module.

3. If you choose a particular module to update the batch transactions, specify the batches in the batch range fields.

4. Click Insert to view the list of the batches that will be updated with the modified tax percentage. NOTE: You can select a batch ID record and click Remove, to prevent updating the transactions with the modified tax percentage.

5. Click Process to recalculate the tax for the transaction in the module and batch specified.

 Important:

1. The tax calculation of a transaction will be overridden if there is a date effective tax rate that exist for any tax detail.

2. If the tax calculation routine does not find the rate for a particular date range, then the percentage in the tax detail maintenance will be taken.

3. For the receiving transaction entry, only shipment/Invoice will be considered for date effective tax calculation.

4. For the returns transaction entry, only return with credit and inventory with credit type of transactions will be considered for date effective tax calculation.

5. You can regenerate taxes for transactions when workflow is active for the Receivables Management Batch Approval, Payables Management Transaction and Payables Management Batch Approval.

 

References:

How to handle VAT rate changes in Dynamics GP (perhaps dated now)

Changing Tax Rates and Date Effective Tax Rates in Dynamics GP

What’s New in Microsoft Dynamics GP (see 2015 R2 section)

Changing SOP Tax Rates using the Support Debugging Tool

All Change on 20% Tax Again January 2011

Dynamics GP will not remove hold or why timestamp format in GP matters

If Dynamics GP will not let a SOP module, transaction process hold be removed in the user interface, it may be due to formatting of time stamps. Check no integrating applications have created that hold incorrectly. 

The issue is that GP is real fussy about formats of timestamps, one place time stamps can cause problems is in use with the SOP Transaction Hold table, the following query illustrates what you need to know about this. 

SELECT [PRCHLDID], [HOLDDATE], [TIME1]
FROM SOP10104
WHERE SOPNUMBE='YourDocumentNumber' AND SOPTYPE=2

This query gives us some data to look at, that is if some holds exist for that document supplied to the SQL query...

The first thing to notice is that GP often splits/spreads the Time and the Date components of the point in time over two fields, in this case the point in time is represented by HOLDDATE and TIME1. These two fields are of the sql data type "datetime", something that can catch out people when new to GP databases as it may not be totally obvious what is going on. 

Lets look at the first row, it is for the hold type "CREDIT" and represents the point in time, 3rd of May 2020 at eleven minutes past three and 31 seconds

  • It is interesting and important to note that for the HOLDDATE field, it has a date but see how the date has zeros for all the time elements of that HOLDDATE datetime value. To fill up the unused time component, the time has been defaulted to midnight. A default time of zero (midnight) is used, as the unused half of the datetime sql data type may not be set to null (we need all those bytes). 
  • Now also note how the TIME1 field value has a time component, but the date has been defaulted to a "default" of the 1st of January 1900. This date by convention is used to fill the date component of the time, as the unused half of a datetime data type may not null. 
  • Further, it is vital to note that the milliseconds of the time has been zeroed too

Now if you disobey these format rules, the GP user interface will do weird things. More often than not, it just doesn't do anything, that can be really perplexing as a problem solve because the records to the untrained eye look fine and similar to other records right next to them. It may be as simple as including milliseconds (not zeroing them) that can prevent a user from removing a hold in the GP user interface!

These time stamps are used in this way for many tables, where the same rules apply. It is very important to provide a correctly formatted time and date field if integrating or manually scripting against the GP database. This is a really common rookie mistake for developers working with GP, its easy to get lazy or not notice the formatting to be wrong. It can also change behaviour and totals, as time span calculations may not result in the same outcome if time components are left in date fields etc. Imagine the impact when totalling values over time spans, urgh.  

So to save some head scratching, and to make a GP compatible timestamp for the current time field in .NET use the following code snippet:

DateTime now = new DateTime(1900, 1, 1).Add(DateTime.Now.TimeOfDay);
DateTime ForFieldUse= now - new TimeSpan(0, 0, 0, 0, now.TimeOfDay.Milliseconds);

Don't be tempted to simplify this and try to access the .now in two places on the same statement as you may find the times have shifted enough between calls to cause the milliseconds not to zero correctly as two different values would be returned and be subtracted, not resulting in zero! Date times are immutable so you can't simply zero the milliseconds component either.

To get the date only value for use in GP date fields, you may simply use the in build .NET method ".Today" as shown in this snippet;Snippet

DateTime.Today;

 

 Hopefully this will help get back up and running after Googling the problem you've just encountered! - If so do comment, it keeps me motivated to blog more.

Installing Remote Server Administration Tools for Windows 10

Note to self, run following where the add features option in windows doesn't work. 

DISM.exe /Online /add-capability /CapabilityName:Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 /CapabilityName:Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0 /CapabilityName:Rsat.CertificateServices.Tools~~~~0.0.1.0 /CapabilityName:Rsat.DHCP.Tools~~~~0.0.1.0 /CapabilityName:Rsat.Dns.Tools~~~~0.0.1.0 /CapabilityName:Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0 /CapabilityName:Rsat.FileServices.Tools~~~~0.0.1.0 /CapabilityName:Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0 /CapabilityName:Rsat.IPAM.Client.Tools~~~~0.0.1.0 /CapabilityName:Rsat.LLDP.Tools~~~~0.0.1.0 /CapabilityName:Rsat.NetworkController.Tools~~~~0.0.1.0 /CapabilityName:Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0 /CapabilityName:Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0 /CapabilityName:Rsat.RemoteDesktop.Services.Tools~~~~0.0.1.0 /CapabilityName:Rsat.ServerManager.Tools~~~~0.0.1.0 /CapabilityName:Rsat.Shielded.VM.Tools~~~~0.0.1.0 /CapabilityName:Rsat.StorageReplica.Tools~~~~0.0.1.0 /CapabilityName:Rsat.VolumeActivation.Tools~~~~0.0.1.0 /CapabilityName:Rsat.WSUS.Tools~~~~0.0.1.0 /CapabilityName:Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0 /CapabilityName:Rsat.SystemInsights.Management.Tools~~~~0.0.1.0



Office Interop Access is denied fix for .NET automation of Microsoft Office

Problem, Could not load file or assembly … or one of its dependencies. Access is denied

This is the solution to a perplexing issue around Office automation, that many people do not seem to be finding a solution for on forums.

The story, on a newly deployed set of PCs, a big issue arose where the Microsoft Office Interop for our .NET application would fail with errors of “Access is denied” when launching our integrating application. Solutions that were attempted proved only to be a temporary fix, with the problem reverting back again, often overnight.

Could not load file or assembly Microsoft.Office.Interop.Excel.dll or one of its dependencies. Access is denied.

Could not load file or assembly Microsoft.Office.Interop.Outlook.dll or one of its dependencies. Access is denied.

It turns out this is to do with permissions to the Interop assemblies that are put in the Global Assembly Cache (GAC) and the Centennial version of the Office App.

 

Solutions attempted

 

In an attempt to resolve the issue, the usual culprits were investigated including many more ideas that I’ve now forgotten about:

  • Changing the permissions within the COM, component services control panel for the access, launch and activation permissions etc
  • Taking control of the assembly cache permissions and granting access for directories and files including…
    "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Outlook\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Outlook.dll"
    "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Excel\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll"
    "C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Word\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll"
  • Uninstalling restarting, reinstalling Office
  • Uninstalling restarting, installing the Office interop via the Office installer options
  • Removing and replacing the local Office interop assemblies for the integrating application
  • Embedding the Interops in the application (difficult with Nuget packages tho?)
  • Using cacls.exe to update DCAL

Some of the above would work for the rest of that day, fixing the issue,  yet the problem would return the next morning (machines left on overnight).

 

Root cause

Finally, a hint of the issue was found from digging deeper and deeper in the forums, revealing the root cause.

“Office in the Windows Store” was released which is a different version of Office that is available through the windows store in Windows 10. This version of office is often referred to as Office Centennial version, as it utilises Project Centennial to allow office to be ported to an Office store app. Project Centennial is a bridging solution intended to make it easier for software developers to migrate existing applications to the store and app architecture in windows. This bridge was used to create the version of office in the store, which is distinct from the standard Office you would install from other media sources.

This store version of Office has been included in the Windows system image used by some OEM manufacturers of PCs, so new users have it ready to go on the machine when they get it to the Office or home. Being a store app, it gets refreshed by the auto updates of the Windows store… you can see where this is going?…

It would seem that this version of Centennial Office was installed on the disk image of these PCs and when full Office professional was installed on the machine, all is fine, until the (not in use) Centennial version of Office decides to repair itself overnight during the store update, corrupting the permissions on the Interop assemblies in the GAC, leaving them with only SYSTEM permissions, thus rendering them inaccessible to the end users.

Doing many of the aforementioned attempts to fix the issue, would overlay the correct permissions, but only until the Centennial version of Office went and undid the work overnight.

What is more annoying is that early on in the diagnostics for this issue I had a suspicion around this being the issue, but found no installer under, Start>>Apps and Features for  Microsoft Office Desktop Apps or Office, other than the pro copy. Also nothing in the programs and apps. Hence I’d assumed it can’t be the issue, wrongly as it turns out.

This seems to be an issue that has been hitting people from early 2019 through to 2020 when this blog post was written, although the OEMs were asked not the include the version of Office in the images anymore, so this should fade away over time.

It is a bit concerning that few people in forums seem to have found solutions, other than rebuilding the machine, but pushing on…

 

Removing Centennial Office

It seemed the obvious solution was to remove the store version of Office. It was not required and thus removing it should stop it overwriting the good install of Office. As noted before, there seemed to be no “uninstall” option anywhere in windows to get rid of the application. There were a few ways to remove this Office listed on internet forums, but the only one that worked for me was to launch power shell as an admin user. Then to run the following three commands, each in turn.

"(Get-AppxPackage -Name Microsoft.Office.Desktop).Dependencies | Remove-AppxPackage"
"Get-AppxPackage -Name Microsoft.Office.Desktop | Remove-AppxPackage"
"(Get-AppxPackage -Name Microsoft.Office.Desktop).Dependencies"

The final command should just confirm removal, by not returning anything.

Immediately it could be seen the assemblies had been removed from the “C:\Windows\assembly\GAC_MSIL\*” directories and after running the afflicted application, the issue would seem to be resolved. The professional office install was also repaired, via the Office Pro installer, for good measure.

A very annoying, obscure problem finally resolved!

 

References:

How do I uninstall Office 365 Windows Store version?

how to uninstall office 365 preloaded in windows 10

Why ‘Office in the Windows Store’ isn’t really Microsoft Office

Office.dll access denied to VSTO add-in