Tax Free Holiday!

So, I had a client email last week because they had a number of employees with state tax but it was not calculating for that specific state.  The strange part was that all of the setup seemed right....

• Cards>>payroll>>state tax, assigned to the employee
• Cards>>payroll.>>tax information, default state code correct
• Cards>>payroll>>pay code, pay codes marked as subject to state tax
• Transactions>>payroll>>transaction entry, the state code was on the transaction

Bizarre.  So I asked for a copy of the build report, and saw that the state tax code was on the build report correctly.  But on the calculate report, it was not calculating an amount.  Aha!! I looked at the set up for the state tax code (setup>>system>>payroll tax) and saw that the first filing status for the state was a 0% status.  And the employees had been set up with that, since it was the default. 

Some quick scripts if you find yourself in the same boat.  The first selects the records to update, and the second updates the filing status.  Our situation was limited to employees in a specific department that worked in another state, but you could adapt these to limit by any other factor as well.

--identifies the records to be changed

select UPR00100.DEPRTMNT, UPR00700.employid, UPR00700.STATECD, UPR00700.TXFLGSTS from UPR00700 inner join UPR00100 on UPR00700.EMPLOYID=UPR00100.EMPLOYID where UPR00700.STATECD='insert state tax code here' and UPR00100.DEPRTMNT='insert department code here'

--executes the change
UPDATE UPR00700 set UPR00700.TXFLGSTS='insert filing status here' from UPR00700 inner join UPR00100 on UPR00700.EMPLOYID=UPR00100.EMPLOYID where UPR00700.STATECD='insert state tax code here' and UPR00100.DEPRTMNT='insert department code here'

For the filing status variable, you will have to set up one employee correctly and then look at the UPR00700 to see the proper value in TXFLGSTS (select * from UPR00700 where EMPLOYID='insert employee ID here' and STATECD='insert state tax code here') for the state code.

Hope everyone had a great holiday! And here's to a great new year!
 
Take care,
Christina

Ouch, Modifying Direct Deposit Files

I have definitely had my fair share of ouch moments over the generation of ACH files in Dynamics GP. If a payroll is processed with incorrect information like a mistyped routing number or account number, or if a direct deposit is voided after the payroll is posted, the ACH file that is generated contains incorrect information.

The party line is to void the entire payroll and then re-run with corrected information. Although this is fine for small companies, it doesn't work all that well for large companies with large payrolls.

So, we used to edit the ACH file manually. This worked great, although it was always a little hit and miss to make sure you caught all of the fields that needed to be updated. However, in recent years this is no longer an option due the encoding created at the time the ACH file is created in GP (referred to as "hash" entries). These hash entries will vary based on the information in the file, so there is no reasonable way to update the file manually and still have it accepted by the bank.

So what to do? Well, if the client has an understanding bank, or the bank has a full-featured website, often you can upload the file to the bank and either make the changes in their website or the bank will make the changes for you. But what to do if the bank's website does not have that capability, or the bank itself is not helpful?

Well, in those cases, I have found you can use the following script to update the Direct Deposit records in GP and then regenerate the file (which will recreate the correct hash entries as well). Now, I must say, I have anecdotal experience that this works. But it may not work in all instances, so you need to test it with the bank and also make sure you have a functional backup before doing this!

These scripts assume that the payroll build is still available in the Generate ACH window (Transactions>>Payroll>>Generate ACH). The script should be run against the company database.

UPDATE DD10500 SET DDAMTDLR=’1500.00000’ WHERE DEX_ROW_ID=’insert dex row ID of record you need to change’

The field in the script above (DDAMTDLR) will change the dollar amount, DDTRANUM would update the routing number, and DDACTNUM will update the account number. In all cases, once you make the change, you can regenerate the file and the footer information (totals, hash info, etc) will be correct. To view the contents in the table, use SELECT * FROM DD10500 and you can find the correct dex_row_ID of the record you want to update. You will notice that the records in the table are identified with the build number from the Generate ACH window (field INDEX1 in the table).

Since I sort of stumbled on this through trial and error under pressure, please share any insights you have or other fixes or pitfalls you have found.