Bank transaction total is correct on the Payment screen but different and incorrect amount on the transactions view. See attached screenshots.
Actually the amount on transaction view is correct.
Each line needs to be rounded separately so 17.515 line amount needs to be posted to general ledger as 17.52 otherwise you’d have on your financial statement figures with 3 decimal places which is not desirable.
Editing screen doesn’t reflect that. But even if it would, you are trying to split 35.03 amount 50/50 into two different accounts which Manager would always split as 17.52 + 17.52 = 35.04 so you would still need to allocate minus 1 cent manually to either Mortgage insurance or Owner's withdrawals. Or just manually allocate 17.51 to Mortgage insurance and 17.52 to Owner's withdrawals
@lubos beat me to the punch. But Manager’s arithmetic is correct. The problem is your attempt to split odd numbers. You have put together an arbitrary set of subdivisions of a single transaction without ensuring that your splits added up to the amount of the transaction.
Thanks to @lubos for the explanation. I want to be kind to @Tut as I know you are trying to be helpful, but nearly every issue I’ve reported has received a response that amounts to “You’re doing it wrong.” This is extremely frustrating as it communicates to me yet again that if I want to use Manager long term, then I have to just learn every little nuance and behavior of the program rather than someone at HQ doing any usability testing to learn what everyday people expect it to do. I understand that this is free software, but by the same token I would think someone would be willing to accept some free advice that improves usability. These little quirks deter me from fully committing to Manager and purchasing a server license to use in my larger business.
The fact is the amounts DO add up in the Payment view. I did everything I could as a user to ensure it should have been correct, but Manager does nothing to indicate that it’s going to post something different. I concede that the differing amounts are not a programming bug, but I still take the position that this is a usability flaw. If anything, the “Amount” column in the transaction view should reflect what it’s going to post to the ledger, which would have made it clear to me as the user what was going to happen.
It saddens me that I have to write this. I really like Manager for it’s speed, small data files, and cross-platform nature. But this isn’t the first time that Manager allowed me enter something in a way that didn’t make sense. Such occurrences could have been caught by some kind of input validation or at least some kind of indicator of what was going to post. Instead of catching my mistake immediately, I waste time trying to find out why an account doesn’t balance, then spend time trying to be helpful by reporting an issue, but I’m told it’s my fault and that’s it. I feel like I have little choice but to move to a more mature accounting package next year. My time is too scarce to be reporting usability improvements that are ignored.
1 Like
I want to apologize for last night’s rant. It was a long day and I went off too easily. Manager is a good product, but the usability issues still concern me. Manager would be a better product if it did more to alert users or prevent these issues in the first place. If I had some assurance that usability reports are noted and are implemented, then I’d feel better about sticking with Manager over the long term. I did notice the 17.10.0 version restores the ability to move Manager data files to Dropbox again, so that is great. Thank you.
@blitternand this usability issue will be addressed at some point in the future but it’s more complicated than it seems.
Rounding rules depend on currency you are working in. You can be entering transaction in Bitcoins in which case rounding wouldn’t kick in unless you go over 8 decimal places. You could be entering transaction in Omani Rials where amounts are to be rounded to 3 decimal places. Or you could be entering transaction in Japanese Yens where amounts should be rounded to no decimal places.
You see, the rounding rules are not immutable. They depend on the currency the transaction is entered in. And currently when creating (or editing) transaction in Manager, the forms don’t have yet the capability to do these calculations in real-time as you are entering the figures. They’d have this capability if I could assume rounding will be always to two decimal places - then it would be really simple to implement - but that’s unfortunately not the case.
I’d like the forms to be better. For example, if you are using tax codes, I’d like users to see tax amounts being calculated as you are writing figures so when invoice is generated, it again matches expectations. However that introduces yet another complication on top of multi-currency. So to make every form in Manager (and Manager has a lot of forms) to be aware of rounding rules per each currency and every tax codes is just quite a bit of work which hasn’t been done yet.
Thank you, @lubos. Your detailed answer is appreciated. It makes it clear why this isn’t an easy problem to solve. Thanks for acknowledging the issue and that it might be addressed someday.