TXSHANTY and Tax Sheltered Deductions

Whew! Back from vacation and a whirlwind week before and after!

I have been battling a bit of an odd issue for a client regarding FUTA and SUTA taxable wages.  Let me start by giving you some background:

1. Deduction configured as non-TSA, no tax sheltered boxes marked (Setup-Payroll-Deduction, Cards-Payroll-Deduction)

2. Activity posted using the deduction code

3.  Deduction setup changed to now be TSA, with three of the tax sheltered boxes marked (Setup-Payroll-Deduction) and change to set up rolled down

4.  Deduction maintenance not updated with new tax sheltered settings, as their was already activity on the code (Cards-Payroll-Deduction)

So, the bottom line is that the employee deduction maintenance (Cards-Payroll-Deduction) showed no tax sheltered checkboxes marked but the setup did (Setup-Payroll-Deduction).  Normally, this would not be a problem.  New employees would get the new settings while older employees would not.  But then the weirdness began :)

When printing the FUTA and SUTA summary reports, it was noticed that the wages were off by the amount of these deductions.  Both FUTA and SUTA were set  up (Setup-Payroll-Unemployment Tax) to NOT include any TSA deductions as wages.  But, in this case, the deduction in question was NOT sheltered.  So it should NOT have been excluded from wages. 

If we changed the FUTA and SUTA setup to include the deduction as wages, it fixed the employees who did NOT have tax sheltered flags marked.  But it created another problem, since it also now included the deduction as wages for employees who DID have the tax shelted flags marked.  Eek.  Fun.

So why was it sheltered the deductions that were NOT marked as tax sheltered?  All 'cuz of TXSHANTY.  Many thanks to Michelle Blaser at Microsoft, who asked the question and had us check this setting.  In the UPR00500 field there is a field called TXSHANTY.  This is a boolean field, with a zero if NONE of the tax sheltered checkboxes are marked (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX) or a 1 id any of the tax sheltered checkboxes are marked.

In the case of these employees that had deductions that were NOT marked as tax sheltered, the TXSHANTY setting was 1 although the tax sheltered checkboxes were all zeroes  (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX).  How could this happen?

Well, with a little testing with Microsoft we found that the rolldown from the setup did not rolldown the tax sheltered checkboxes (SHFRFEDTX, SHFRFICA, SHFRSTTX, SHFRLCLTX) because there was activity but it was still updating the TXSHANTY field behind the scenes.  The interesting part of this is that there is not logical situation where TXSHANTY would be 1 while all of the other checkboxes are zero.

So we used the following scripts to identify and correct the affected records:

--Run select statement to verify number of records to be affected
select * from UPR00500 where TXSHANTY=1 and SFRFEDTX=0 and SHFRFICA=0 and SHFRSTTX=0 and SFRLCLTX=0
--Run update statement to set Tax Sheltered Annuity field to 0 where are all Tax sheltered tax fields are 0
update UPR00500 set TXSHANTY=0 where TXSHANTY=1 and SFRFEDTX=0 and SHFRFICA=0 and SHFRSTTX=0 and SFRLCLTX=0
--Verify number of affected rows against select statement rows

Once we did this, FUTA and SUTA now calculate correctly per the settings in GP.  On an interesting side note, we also found that something in GP might be resetting the TXSHANTY to zero, although we could not figure out what-- we just noticed that over time (with no as zero.  Odd.

Microsoft is working on writing this up as a quality report, but I thought I would share it with you all in case you run across the same oddity!

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.