Hello, since the last update (21.3.24), the database has been corrupted. Some “Employees” transactions are no longer correct as they were before. The system has changed some values on its own. Were these changes noticed by anyone else?
Some screenshots of affected transactions together with detailed description of any changes would definitely help.
@brfranco, please do not divert topics with unrelated issues. Your question is not related to the bug report where you posted it. (That bug was fixed in v21.3.30, 6 versions after the one you are reporting on.) Your post was moved to a new topic.
You first need to update your software. Then, if whatever problem you believe exists is still present, you need to describe it completely, using terminology from the program. There is no such thing as an “employee transaction” in Manager. So no one will understand what you are referring to.
OK, I apologize. I thought the topic was related to my problem presented. I will try to be more succinct this time. My English is not good, but I will try.
Since the last update I made (version 21.3.34), the Employee Balance had errors. I’ll give you an example, which I managed to capture from a backup of January 27, 2021 that I had saved.
As you can see in this balance sheet attachment, the balance is R$ 227,50, which should be zero:
This problem was caused because in a “payslip” of this employee, as you can see below, in the third line where before there was “zero” in the quantity column, it is now blank, and calculates the R $ 227.50 times 1, causing the whole problem in that employee’s balance sheet.
The balance sheets have been changed in several employee balance sheets, however I have not been able to verify them all yet.
I updated Manager to version 21.3.37, and the problem continues.
If you import and old backup of your business file,
- are the payslip correct and
- contain a zero for unused payslip items or
- a blank for unused payslip items
@brfranco, now that you have more fully explained your problem, it turns out that it is related to one that was introduced in the other thread late in the discussion, after the issue that started that topic had been fixed. This illustrates why no one should divert topics with new issues—important responses get buried under incorrect subjects.
Here is what happened to you. Due to some revisions to underlying program code, your zeros were converted to blanks. Blank quantities are interpreted throughout the program as 1’s. (That is why, for example, you can leave the quantity on a sales invoice blank and enter a total amount as the unit price.) So, while you correctly entered a zero on a paysip line where there were no earnings, that unfortunately is now interpreted as a 1 because of the dropped digit. You did nothing wrong.
There are a couple ways to fix this:
-
You can scan through your employees’ registers (if you have a way to know which are incorrect) and manually insert zeros where the blanks are now. That will be quick if there are only a few payslips involved.
-
You could also do everything at once with a Batch Update. To do this, Copy to Clipboard and paste into a spreadsheet. I will illustrate with Excel, which allows you to autofit row height and column width. That will allow you to see everything in the cells. You want to look under the variable heading
Earnings.Units. Any row within a cell that does not have a number, enter a zero. Below is an excerpt from such a spreadsheet that covers two payslips:
Notice that the first row in the cell at the end of the arrow has no number to correspond with the earnings rate of 2000 in the next cell. But the second row in that cell has a zero, to correspond with the -100 rate next to it. This entry corresponds to a payslip that looks like this:
No units is interpreted as 1, so the Amount shows as 2000. This is exactly what is happening to you. But the line below on the payslip, showing zero units of a reduction for absences, shows a zero Amount.
Now, if I fill that spreadsheet cell with a zero, like this:
and paste the spreadsheet back into the Batch Update window, the payslip is updated like this:
Both approaches accomplish the same thing. But the Batch Update would let you fix all your back payslips at once. All you have to do is look for missing zeros in one column of the spreadsheet. Of course, make sure you keep a backup before performing any batch operation.
Perhaps this could be reversed by
-
Back up the current business
-
Start a Batch update of payslips in the current business, and proceed to just after copy to clipboard
-
In another window start a Batch update in an old back up version of the business (containing old “0” for payslip items with no hours worked). Proceed to just after copy to clipboard
-
Return to the batch update in the current Manager business
-
Paste in the batch update from the old business. The old payslip items should revert to how they were in the old backup. This will remove any other corrections made to old payslips since the old backup
Good idea. Success would require that no changes occurred to the database structure between versions. Given that the problem arose because of changes to the database’s interpretation, that might not be the case. But I don’t know about that. I know my illustrated method works.
@Patch If I import and old backup, contain a zero for that unused payslip item, which is correct.
@Tut and @Patch I will try to fix the problem manually. I believe it will not be so difficult. Thank you very much for your support once again.
WHY would the developer and programme code want to do this?
Zeros are a valid digit just as ones are a valid digit - so why would the programme want to convert a valid digit into a blank. If the User has entered a zero, then they have done so for a valid reason. For the programme to overrule the User and modify their transaction outcomes is just completely unsatisfactory.
The programme should be protecting the User’s database, not corrupting it by ad hoc code changes. Nor should Users have to become IT specialists ( Batch Update) to fix their own data bases.
Increasingly it appears in various topics, Manager is removing previous standard features at the expense of User functionality, two examples being:
- Removal of the selection of “Today” from the calendar.
- Removal of the chart of account “grouping” from the chart of account dropdown.
e.g. this is a particular issue when you have P&L accounts with similar names as BS accounts, now you can’t tell which one is which.
4 Likes
I fully agree. This constant changing and removal of features that were present is not good business practice. And the expectation that end users should be IT specialists to fix problems created as result of an update is also not good. Many businesses do not have the time or the interest to fiddle with their accounting program and should not have to. It is a shame, because otherwise Manager is a really good product.
1 Like
I agree with you.
I am completely amazed at the superficiality with which the latest changes have been applied and the amount of bugs and errors that they have introduced.
The latest threads are only about complaints. I hope this is teaching for the future so that there will be a change of practice for the future. This attitude is very dangerous.
1 Like