Part Two: Configuring Microsoft Dynamics NAV for PST

Before getting into the details on handling British Columbia’s transition from HST to PST, here is a recap of the four main tables where the settings are managed.  Dynamics NAV offers a degree of flexibility in how the setup can be completed depending on the particular needs of a business and who is doing the setup.  The examples included in this blog post demonstrate one of many ways to configure Canadian sales taxes. For the purposes of this post, however, I’m going to focus on how this can help you configure NAV for PST.

The geographic area where a tax is applicable.  For Canada, this is typically a list of the provinces and territories where business is conducted, as shown in the example below.  For purchase documents in NAV, the tax area code will default first from the Location card, or if one is not used, from the Company Information card.  For sales documents, the tax area code will default from the Customer card.  In all cases, the code is normally editable by the user before posting the document.

The taxing authority, such as a government or other agency.  The tax jurisdiction codes are assigned to a tax area to specify which taxes should be applied.  In Canada there are sales taxes at both the federal (GST) and provincial (PST) levels.  Some provinces have combined their provincial tax with the federal tax into a single harmonized sales tax (HST).  In British Columbia’s case, HST was introduced in 2010, subsequently rejected by public referendum, and on April 1, 2013 the province returned to separate PST and GST.  The following table shows a typical setup for all Canadian federal and provincial tax jurisdictions.

The main fields in this table for defining the G/L integration and calculation method are:

• Tax Account (Sales) – The G/L account where sales taxes collected are posted.  This is normally a liability account.
• Tax Account (Purchases) – The G/L account where sales taxes paid are posted, if those taxes are recoverable or can be netted against taxes collected.  This is normally an asset account.  In Canada registered organizations are able to claim input tax credits for the Federal GST and Quebec Sales Tax (QST).
• Reverse Charge (Purchases) – The G/L account where self-assessed taxes are posted.  This topic will be covered in more detail in the next blog post in this series.
• Calculate Tax on Tax – This box is checked when the tax is calculated on a base that includes other taxes within the same tax area code.  In Canada this rule applied to QST up until January 1, 2013.  It also currently applies to PEI’s Revenue Tax (PST) until April 1, 2013 when that province converts to HST.  These taxes are/were calculated on a base which included GST.  The QST change is discussed below.

Tax groups are assigned to G/L accounts, items, and resources in NAV.  They define the different types of goods and services that a business purchases or sells.  They are used in conjunction with the tax jurisdictions to define the different rates that are applicable.  For example, the same tax may be applied to some goods at a rate of 10% but for others only 5% so these would be defined as two different tax groups.  The field can also be used as an additional way to categorize the data.  The various combinations and rates are managed in the Tax Details table.  At a minimum a typical setup in NAV would have codes for taxable and non-taxable goods and services.

This is the table where the tax groups and jurisdictions are combined to set the applicable rates.  If the same rate applies to everything, then the Tax Group Code field for the first entry for a given tax jurisdiction can be blank.  This means the system will apply that rate to all tax groups other than those specifically listed in the table.  The second entry would be for the non-taxable group, which has a rate of zero.  If different rates apply depending on the tax group, they would be listed individually with their respective rates.

The main fields in this table for defining the rates are:

• Tax Below Maximum – The applicable rate (%) is entered here.  Since Canadian sales tax rates do not vary by amount or quantity the related Maximum Amount/Qty. and Tax Above Maximum fields can remain blank/zero.
• Tax Type – Set to ‘Sales and Use Tax’.
• Effective Date – NAV compares this date to the Posting Date to determine which rate to apply when there are multiple table entries for the same Tax Jurisdiction and Tax Group combination.  This is shown in more detail in the examples below.
• Expense/Capitalize – For taxes which are not recoverable on purchases, meaning the purchaser absorbs the cost, check this box to have the system add the computed tax amount to the same expense G/L or fixed asset on the transaction line.  This applies to Manitoba, Saskatchewan, and (soon-to-be) British Columbia PST.

Although the main topic of this post is to look at BC’s PST transition, there was another sales tax change that took effect January 1, 2013 which is useful to include here.  Up until that date the Quebec sales tax (QST) was a ‘tax-on-tax’ applied at a rate of 9.5% to a base which included GST at 5%.  This gave the tax an effective rate of 9.975%.  At the beginning of the year the Quebec government changed things around, so that the QST is longer charged as a ‘tax-on-tax’ but to make up for the lost tax revenue the rate was increased to 9.975%.

At first glance, for NAV users it appears to be a matter of just adding an entry to the Tax Details table with an effective of January 1, 2013 at the new rate, which would look like this:

However, assuming the existing Quebec QST tax jurisdiction has the Calculate Tax on Tax box checked, this could pose potential challenges with managing the cutover because the setting is not date sensitive – it is tied to the jurisdiction code.

For smaller businesses with lower transactions volumes, handling this could be as simple as making sure the person doing the data entry switches the setting on and off depending on the posting date of the transaction.  For larger organizations with more staff entering data at different times, it may be easier to manage this by creating a separate tax jurisdiction code for the ‘new’ tax and adding it to the existing Quebec tax area setup.  By adding entries for both tax jurisdictions to the Tax Details table and using the Effective Date field, both the tax rate and calculation method can be controlled automatically without requiring user intervention per transaction.

The setup would look like this:

The shift from HST to PST plus GST is slightly more complicated than the QST example above.  And due to the flexible nature of the tax configuration in NAV there are different ways that it could be handled.  There are two options we’ll look at in this blog post for a typical setup where:

• Tax Area = BC
• Tax Jurisdiction = BC-HST
• BC-HST Taxable Rate = 12%

And what we need to get to after April 1, 2013 is:

• Tax Area = BC
• Tax Jurisdiction = BC-PST
• BC-PST Taxable Rate = 7%
• Tax Jurisdiction = FED-GST
• FED-GST Taxable Rate = 5%

If you are managing a cutover and do not want to manually switch out the old and new tax jurisdictions in the BC tax area, the Effective Date could be used to automate this.  However, the FED-GST tax jurisdiction may already be in use for other tax areas and so cannot be set to a rate of zero prior to April 1, which is needed to avoid double-counting of HST and GST.  Instead, a new BC-specific GST tax jurisdiction code could be added that would allow this approach to work.

And here is what an invoice for $1,000 would like before and after the cutover date:

Before

After

The second option is similar to the first, but instead of a new tax jurisdiction code we would create a new tax area code.  Since this could pose a problem if existing Customer cards are already assigned with the BC tax area code, there is a workaround that avoids the need to update all those records.

• Create a new tax area code called BC-OLD and assign the BC-HST tax jurisdiction to it.
• Create a new BC-PST tax jurisdiction code as shown above in Option 1.
• Open the existing BC tax area code, remove the BS-HST tax jurisdiction code and add the existing FED-GST and new BC-PST codes.

Now, when posting documents, the BC tax area code will still default based on the pre-existing setup on the Customer, Location, and Company Information cards.  If the posting date of the documents is before April 1st, simply change the tax area code to BC-OLD to compute the HST instead of the PST plus GST.  This would only need to be done until all the pre-April 1st transactions are processed and then that code can be retired.

There are pros and cons to both approaches and it really depends on how an organization’s system is currently configured, what the particular processes are which would be impacted by these changes, and who has to manage the data.  Hopefully these examples have given some general guidance on how to prepare for the transition.  In the next post in this series we’ll take a look at the features in NAV that support PST self-assessment, which is another process that businesses in BC will need to get ready for very soon.