Please @lubos all the customers accounts now bring wrong balance today. The customer that is owning before now have excess in the accounts. the complaints is the same with all my clients today. kindly look into it as urgent as possible please.
What do you mean by “excess in the accounts”?
Are you saying that the receipts are posted twice to a customer?
It would be much easier to help if you post a few screen shots illustrating the problem
This problem is critical. Customers balance suddenly changed with some that were owing before now having excess money in their account. These are customers with more that 200 transactions on their account. It is difficult now to know where thing gone wrong. Some that balance to zero as at 31st of March, 2021 now having balance on that date. Some negative balance and some positive balance. I just need urgent response.
If you do not post some screen shots, it is not possible to offer any useful advise or investigate the cause.
While you describe the problem in words, this is not of any use to me in trying to understand what has gone wrong.
Sorry if I insist, but I am trying to help.
In these kind of situations, sometimes the cause is an underlying problem with the manner the accounting records were entered but which previous versions ignored and which new versions do not ignore. So the error could have been there already but went unnoticed
Is the receipt in your first screen shot from the current version of the program? If so, your statement that the receipt changed from Alabayo to Olaniyan is not correct. That receipt shows money received from Alabayo against the account of Alabayo. The program no longer allows receipts from one customer to be applied to the account of another.
No the receipt on the first screen is from old version of the program. It was created on 31st March. I just check the second screen from History today on new version.
In the old version was the customer at the transaction level identical to the customer at the line item level. In particular do you have two customers with the same name but different GUID (inactive or active).
Yes. In the old version, there are customers that have similar name and sometime customer A would pay for customer B. that is. from "pay by’’ the name of customer A may be written while customer B is selected under account receivables.
There is the source of your problem. A customer in Manager in not just a name on a transaction. A customer is a subsidiary ledger of Accounts receivable. So you cannot receive money from one defined customer against an invoice for another.
If people are literally settling other customers’ invoices, you cannot enter them in the Paid by
field as a Customer, but must select Other. Then, whatever name you enter is simply a name.
Thanks.
In the previous version, it was possible to select different customers in the line item. Now it is not possible but NOTE the previous transactions should not have been affected. As it is now system seems to have changed all the previous transactions that fall into this category on the vice versa. This has made some customers accounts to be credited wrongly and I am facing a lot of challenges now that the customers complaints different balances.
My advice to you - as to all users - is to treat Manager as experimental and do an upgrade on a test system first before upgrading the live version. It is quite serious that problems like this continue to occur. It is very disruptive to your business although I would agree with Tut that the problem is that you have incorrectly allocated customers.
The reason for the change is to actually prevent this kind of error from cropping up. However, the upgrade should assist the user in fixing the problem instead of leaving their accounts completely different from prior to the upgrade.
Upgrade of this nature that will completely change prior transactions supposed to be announced to users/subscribers through mail or other channel before live changes. This mess has caused a lot of issues on our customers balances of which customers with more than 500 payment transactions since 2020 we cannot easily separate or differentiate payment paid by other customer for him. I just need help please.
I agree with you. This not good enough. Upgrades need to be planned properly. My only advice if you are using the desktop version is to revert to an older version for the moment. You will have to ask the developer how you can go about fixing the problem so that you can upgrade to the latest version. I can’t advise on that - you could try batch update. But personally I would revert to an older version first to address the immediate priority causing issues today.
Then at your leisure with the developer or batch update address the problem at root.
Thanks my Friend. I am actually using cloud version for all my clients that are affected. I just need help from the developers now as this needs urgent attention from them.
This is why I use the Server edition. To avoid this precise problem. I don’t know if you can revert to a previous version on the cloud or not.
I am not sure what to advise as only the developer can really do anything.
Perhaps manager could behave differently when there is a conflict in the user data entry.
Specifically when the line item contact is not equal to the transaction contract.
I suppose the option are
-
if this is very rare the few effected users correcting it manually is most efficient
-
ignore the transaction level contact and use the line item contact. Programmatically easiest via overwriting the transaction level user entry, thus loosing users data entry information. This approach is only possible when one line item contact has be used.
-
put the transaction with what is now impossible data entry errors in the equivalent if suspence, directing the user to what needs correcting
Edit 2
Perhaps combining the latter 2 options would be a fourth option
If transaction and line item contacts don’t match
- if multiple different line item contacts then change transaction contact type to “Other”
- if single line item contact then change transaction contact to line item contact
- in both situations create an “Error” custom field of text type and put a descriptive message in it such as “Old receipt contract- … “ or “Contact type was customer”
As similar approach maybe used moving forward where Manager functionality changes resulting in changes to old data (when sensibly possible)
@lubos any suggestions for fixing this urgent issue?
@lubos I also use cloud edition. I requested you earlier to please consider not pushing the updates without notice or information as to what changes we should expect. As cloud user, I expect to have the right to control the updates at my end and not be suddenly surprised with the overnight changes.