Looks good
Yes, everything is ok now . thank you @lubos
I had the same problem. But now I have to go back to prior payslips and fixed 12 months of payslips one by one. This is more 100 payslips per month.
Why was it changed when it worked just fine. The time alone to fix this is a huge frustration.
This can be fixed in a few minutes with a Batch Update.
Have a look at this thread as I think it is more relevant to your issue Database corruption - #7 by Patch
I disagree, for an IT specialist yes it is quick and easy. But I am an accountant not an IT specialist. This should not have happened in the first place.
I am so frustrated for having to double check and reconcile all my pay slips for the past 12 months. Software changes should not change already posted and updated data.
How can we trust that this will not happen again?
@Optimus what exactly are you fixing on payslips? Any issue should have been fixed automatically.
@Optimus, I will not respond further to you about this subject, now that you are addressing your problem in the correct thread. You have the direct, personal attention of the developer.
All the blank units that changed automatically as one instead of zero.
Why blank units should be changed to zero anyway? Blank units on payslips always implied quantity of 1. This means when you have unit rate 100.00
then it doesn’t matter whether quantity is blank or one. Line total will be the same.
I’m not saying it should have happened, I’m trying to understand scope of the problem and why it makes a difference whether quantity is blank or number one.
My guess is the issue mostly effects cloud users who use recurring payslip. To explain:
-
employees on a fixed salary are likely entered with a rate set to their salary for the fortnight and blank units.
-
employees on a wage with different hourly rate for exceptional work (over time, public holidays, annual leave etc) are likely to have a line on the recurring payslip entered for each with the rate entered but zero in units. (Standard pay entered with rate & units so less likely to be effected)
-
If blank is interpreted as a zero that would make the the zero entries for unused exceptional work lines obsolete. If Manager converted these zeros to blank that would be equivalent. If the interpretation of blanks was then changed back to 1, that would then cause a problem for all unused exceptional payslip items for employees on a variable wage.
I have not confirmed the problem by installing all updates. Neither have I been impacted by the issue as I didn’t install all updates. As a result my theory may be completely wrong.
Last month when I did payroll runs and prior months, recurring and normal pay slips did not see a blank unit as 1. If a unit was automatically 1, you could delete it and it calculated as zero, it worked perfectly.
Now you are forced to add a zero in blank units, which is fine. I honestly do not have a problem with that. My concern is that this software/update change, changed backdated data and transactions already processed.
Updates should only effect new and future transactions. Changes like this can put an accountant in a very awkward position with clients and authorities.
But I calmed down a bit and just have to work extra overtime to fix backdated pay slips and pray that customer invoices were not effected as well.
Thank you
Have you looked at your old backups, if they are OK you could try the above link Database corruption - #7 by Patch
If not this post would work and maybe faster than a completely manual approach Database corruption - #6 by Tut
Thank you I will try it