I came across what might be an error in the journal section, but I have never had this issue before. As per usual I set off a purchase invoice in a journal against the capital account, which shows that it is balanced on the main screen, but in the journal itself it is off with decimal points. Did I do something wrong?
No, that just happens on occasions for no explainable reason.
Your screen shots suggest you are using journal entries for all your transactions. You may be doing this as you get your business started up, recording purchases by capital account owners as equivalent contributions of capital. A more normal method would be to use expense claims for such transactions. See this Guide: Use expense claims | Manager.
It also looks like you are using purchase invoices to record cash transactions. Purchase invoices are normally used when buying from a supplier on credit. See this Guide: Make cash purchases (purchase without purchase invoices) | Manager.
Lastly, did either purchase invoice to Burgers Mica involve a tax code? I am wondering whether this is a rounding difference. Could you post screen shots of those?
The company was begun by my sister, and at present she has not opened a bank account yet. I have spoken to her this weekend when I captured the last entries and she said she would get around to it within the week as payments can then be done from the cash accounts tab. There were no tax codes involved as she is not registered for VAT due to her income threshold per month being below the annual amount to be registered. I figured to not use the expense claims as it will be a long time before any claims can be paid back to her due to the business only starting recently.
Expense claims don’t have to be paid back. She has a capital account, so her name will show automatically in the Members group under Expense Claims Payers when doing an expense claim. These amounts post directly to the capital account of the member, bypassing the Expense claims liability account.
I would still like to see the screen shots I asked for. I don’t consider such unexplainable imbalances acceptable and would like to discover the source.
Regarding the purchase invoice, I only do it that way to keep track of all purchases at the different companies she gets her supplies from. The tutorial did mention at the end that it is a viable option to keep record that way. As for the screen shot, below is the invoice that had the rounding error in the journal:
Fair enough; that’s certainly a valid reason.
On to the rounding error. Something seems amiss. The invoice number on your purchase invoice is “Cash Sale.” But your journal entry (2nd line item) was posted to “Cash Sale 768600.” So some editing seems to have been done somewhere along the line. If you have a non-unique invoice number like “Cash Sale” and have used it more than once, you could cause problems. What is going on there?
Secondly, what happens if you split your multi-line journal entry into two, with a single debit and credit for each? Of course, that shouldn’t make any difference, but I’m searching for a potential bug. If that doesn’t show anything unusual, try deleting the journal entry and re-entering it as you originally did. Does the problem persist?
I’m using version 17.4.40 and I’ve experienced the rounding problem. I was able to recreate it in the Northwind company (just picking accounts at random).
It seems that the journal entry must have 3 lines and there must be cents in the amount on each line. Here is a screeen-shot:
I can reproduce this problem, too. Whatever is causing it is worrisome because of the potential for arithmetic errors to build up over time because of the problem. My experimentation confirms what @dcVest reports (great detective work):
It only seems to happen with 3 lines, but it doesn’t matter whether those lines are debits or credits. See this comparison:
More lines, even with the same totals eliminates the problem. Here is with 4. I also tried 5.
Cents are required, but not on all three lines. What matters seems to be the total cents, though which lines have which values can also influence the outcome. And an absolute magnitude change sometimes causes the problem to go away even if the cents remain the same. When 200 is added to both sides of the balance, for example, the error can alter (or disappear).
Lastly, I notice the same numerical errors coming up again and again. But they are not constant.
In summary, there is a bug in how arithmetic is being performed. It doesn’t appear to be related to operating systems. I’m using a Mac. @Paul_Joubert and @dcVest are on Windows.
I’m elevating this as a bug. I’d be curious whether anyone can discover the pattern that produces the error.
Not always on a 3 liner, but sometimes on a 5 liner but only after the last figure has been entered
You found a combination on a 5-liner I didn’t. But your observation that it only appears as the last figure is entered matches my experience. The error crops up only as the difference approaches (and should be) zero.
Yes and has been occurring for years, it’s not a recent condition. As the Journal can only have whole numbers entered per line, that is - no calculations are occurring, its just the balancing mathematics at issue and doesn’t impact any transaction postings.
I hope and suspect you are right. But when I see one arithmetic error, it makes me wonder if there could be more. What’s puzzling is that we are only talking about simple addition and subtraction in however many decimal places the currency and local practice use. No percentages, apportionments, or carryovers from some other calculation. How can this go wrong?
I guess that is due to how floating points are handled in programming.
More details => The Floating-Point Guide - Floating Point Numbers
I suspect that there will no be such error when whole numbers (i.e. no cents, or whatever you call them in other currencies) are used in Journal.
@koroko is correct.
Fixed in the lastest version (17.4.50).
@lubos @Tut I am using version 17.5.18 and the small rounding problem is again showing in Journal Entries.
I have learned that it is not an error, but thought you should know that it is displaying.
1 Like
I will mark this as a bug. I suspect a regression issue. Presumably the fix is already known.
1 Like
Fixed in the latest version (17.6.50), hopefully permanently now (I did it a bit differently this time).
1 Like