Username
Forgot password?
Welcome to the SSDT Question and Answer Site!
Or Join with FTT

Possible CHGDED change...

0

815 views
Folks:

  It was me (Jeff C.) asking about the copy of DEAMT.IDX, in the Webinar, before a CHGDED run.  This would be a time-saver (possibly - depending on how far a District goes) in case the Districts changed the STRS RATE - BEFORE the advance runs.   If it's not that big of a change - and you could squeeze it in before (or even as an OOPS) the next release - that would be ever-so-special.

Thanks,
Jeff C.
 
Edited May 23, 2014 10:56 AM
Retagged
asked May 13, 2014 11:48 AM

 
We have districts with several payroll users and are concerned that these users could step on user processes when backing up the files if the files have to be restored. Wouldn't it be a good idea to just generate a report each time they run CHGDED so you could see what changes are made or just run an AUDRPT? Can this be time stamped and possibly have the user name of the person that ran CHGDED? Would this also need to prevent other users from accessing the deduction files while this is being backed up?
flag
May 13, 2014 11:56 AM
Kelley: Your point is well taken. One thing is for sure though. If the above happens - like I described (and it happened to us last year)... they'll have more issues than getting "stepped on" to get it straightened out. I was thinking more along the lines of the program itself making the copy... like we see the USPJOB.PRE_USPCHG that gets created, by USPCHG. Of course... there is always the possibility of just using CHGDED to change it back... but... it depends on when it gets caught. Was just throwing it out there.
flag
May 13, 2014 12:06 PM
Kelly (et al): Thought I ought to clear this up after we talked at the SWAFS meeting. WE (that means ME) at MEC have a menu logical defined for USPCHG... so WE control that file copy. I could do the same with CHGDED and DEDAMT.IDX. I think what we did last year when this happened was: 1) We RESTORED the files from the best backup we could get PRIOR TO THE CHGDED mistake and the running of the Advance. We put the files in a test account. 2) The advance was re-run from that account - with the correct rates back in place... and new PDFs created and put into PayrollCD 3) I converted SAVADV.IDX to a sequential file - changed all the bad rates that had been stored in it... back to the origianal rates... and converted it back to an .IDX file (in the "live" data). 4) The resulting STRSAD file from the corrected run (from the test account) was put back into the "live" account... and the users re-sent it. I think we did it this way... if a lot of other payroll record changes had been done by the users between the time of CHGDED the STRSAD run... and the time of catching it. Naturally... the longer it is in time... the potential "worse" it is. Jeff C.
flag
May 21, 2014 03:36 PM

0 Answers

Be the first to answer this question

Join with account you already have

FTT

Preview

Alert