I have been able to work around the obstacles created by encryption of Social Security numbers and birth dates for this years reports but this is a very bad idea. I need to have that information available for upload to in reports to my 401k provider and TPA, Connecticut Department of Revenue Services, and many other insurance, government agencies etc...
 
Many of these agencies do not accept paper anymore and in the past I was able to satisfy any uploads they needed, by using Crystal Reports and exporting to a cvs file. The data you wish to protect is widely available by crooks through other means and does little to protect my business or employees.
 
IS Tech has done great things with this software to make my life better and business more profitable, but this is a big step backwards. If data encryption is the way of the future, you must make the data available to us for reports that EVO-ERP does not provide for.  
 
Advance notice of major changes like this one,  should be be given to users, so they can opt out of an upgrade that will cripple function of their system. This added a lot of hours to our year end payroll tax reporting this year.
 
Please provide some means to decrypt our data, or roll back that "feature". The work around I used for this year, is not a good long term solution.

Quote from kkmfg on 01/28/09 at 09:52:31:

 
Maybe you read my (warning) post in late December before you upgraded. I saw in the update notice that future payroll enhancement would "including encryption of sensitive payroll information" but I didn't understand that I would be protected from myself. What was I thinking?

I am going to have the programmer convert the PR-I report into an Evo RTM and add the decrypted fields for SSN and Birth Date.  We will also modify the report layout so the SS and Medicare withholdings are separate columns making it easier to load into Excel.  Since that report has both the employee master and pay detail files open and already has subtotals and grand totals, it seems like the obvious candidate as the RTM can then be modified to meet individual reporting needs.  
 
This will enable management/employees with access to the payroll module to get at the encrypted data in a decrypted form either on paper or electronically without having the unencrypted data in a table used by everybody for Job Costing.
 
One of the reasons for creating the new separate ISPRMSTR file for payroll separate from the BKPRMSTR file which used to be the only employee file but now is used for Job Cost Labor only is that since ISPRMSTR file holds the sensitive information such as pay rates as well as SSN and such, it can (through Windows permissions) made hidden to users that are not loading the payroll module because none of the Job Cost programs or SM-G open the new payroll file.  Some people are more protective of their payroll data than others in terms of employees finding out what other employees make but this is a way to keep it somewhat protected.

Lynn  
 
This sounds great. I see the deduction field in that report is a summary. I don't have much experience with trying to add fields to RTMs, hence this question. Will I be able to add individual deduction fields to the modified RTM to separate insurance, garnishments, 401k etc...?

Lynn
 
Just tried it. works great! I was going to suggest filters for terminated and zero pay amounts in PR-I, but you beat me to it in the T7 program.
 
Thanks for your work in this matter. I really appreciate it.
 
Steve

Lynn
 
I was able to add bkpr.curp.uod[4] to my report. Using same technique I can not add bkpr.emp.lmne or fnme. I need the name in two separate fields but the original RTM has it combined somehow. Is that done in the RTM or is that coded in the T7 program? I can't figure this out and figure out were to find the info that would explain this. Is there a manual that can be bought to learn this stuff?