Created attachment 373363 [details] unbalanced register report I would expect total credit and debit in the register report to be equal and the difference should be zero. As can be seen in the attachment it is not the case (on my system)
Why would you expect that unless the register that the report is based on happens to have a zero balance?
This register report (reprotrs->assets and liabilities->general journal), do not let you select any variables (accounts or dates) so it must pull all transactions from all accounts for all dates (or accounting period?). If this is the case, then the total debit and total credit of the journal should be equal (not zero), should be no difference between debit and credit totals.
No, it's called a Register Report and is in the menu as Account Report for a reason: It pulls in the visible (i.e. not filtered by View>Filter By...) transactions in the register that has focus at the time that you run the report. You'll notice that it's not in the menu when the Accounts page has focus. The primary use-case is to be able to create a custom report of sorts by running a Find query and then running the Account Report on the results register. If you want a configurable dump of all of the transactions in the book use the Transaction Report.
Created attachment 373365 [details] General Journal Report Great! But that's not the report I was talking about. Please see the attached screenshot and the navigation to the report in question under the report menu. (The report on the menu is called 'General Journal' although the report header says 'Register." I created this bug report not before I copied the entire report to a spreadsheet just to make sure that there actually is a total calculation issue. Unfortunately, there is one.
Sorry, I misunderstood your comment 2. I've changed the bug title to point to the right report. The results are the same when one runs the Account report on the register created by Tools>General Journal and changes the date in View>Filter By... to "All". It does look like the report's debit total doesn't include everything: In fact with a simple book having only a few income and expense transactions there is no debit column at all.
Created attachment 373366 [details] Example book showing some journal report oddities.
Created attachment 373367 [details] CSV of the Journal Report. I've created a sample book and made a spreadsheet of the General Journal Report (by hand, because the report won't copy-and-paste in an intelligible way). The book includes some expenses, some income, a mutual fund purchase, dividend reinvestment, and sale. Notice that the General Journal report doesn't even provide a total for the debits, and that the credits sum differs from the spreadsheet's by $250, the amount of the Income:Capital Gain split.
A single transaction book would be nice to debug this :) If the General Journal delegates to the Register report we'll need to ensure the Register report isn't adversely affected.
I'd say that it's more like the Register report has the same problem whatever it is. Since the symptom is that not all debits are included in the total ISTM a single txn book isn't likely to exemplify the problem; rather what's needed is a book that contains one of every possible transaction type so that one can see what's common among the debit splits that are included in the total and those that aren't.
Created attachment 373368 [details] trimmed journal I've trimmed the book by deleting all regular transactions. So I understand the General Journal should show the following? Total Debits $125500 Total Debits 1011.231 PIODX Total Credits $125500 Total Credits 1011.231 PIODX
Correct, that's what I'd expect
Try the following hack. Basically remove the equality predicate. I don't think there's any negative effects. Need to test: all options in General Journal, and the Register report obtained from Register->Report->Account Report. modified gnucash/report/standard-reports/register.scm @@ -644,8 +644,7 @@ (if multi-rows? (for-each (lambda (split) - (if (equal? (xaccSplitGetAccount current) - (xaccSplitGetAccount split)) + (if #t (accumulate-totals split total-collector total-value debit-collector debit-value
Also need to test the above reports in a book *with* currency conversions
P.S. while testing the above change please thoroughly test the "Value change" line -- I suspect it'll now always show "$0.00". If this is the case, then perhaps we need to reconsider whether to remove this line, or the fix is incorrect?
That's something of a special case of a single-commodity General Journal report. A register report of a single account will nearly always have a non-zero value change, and a multi-commodity General Journal often will as well: Consider that you hold 100 shares of XYZ bought for 1000 AUD: The report will show changes in value of +100 XYZ and -1000 AUD. Failing to record realized gains and losses will also produce a difference in debits and credits and so a change in value.
Sorry, but I can't make it run, after modifying register.scm, GnuCash crashes with the following error msg: "avi@avi-PC-Mint19:~$ gnucash ;;; note: source file /home/avi/opt/share/gnucash/scm/html-document.scm ;;; newer than compiled /home/avi/opt/lib/gnucash/scm/ccache/2.0/html-document.go ;;; found fresh local cache at /home/avi/.cache/guile/ccache/2.0-LE-8-2.0/home/avi/opt/share/gnucash/scm/html-document.scm.go ;;; note: source file /home/avi/opt/share/gnucash/scm/html-fonts.scm ;;; newer than compiled /home/avi/opt/lib/gnucash/scm/ccache/2.0/html-fonts.go ;;; found fresh local cache at /home/avi/.cache/guile/ccache/2.0-LE-8-2.0/home/avi/opt/share/gnucash/scm/html-fonts.scm.go Backtrace: In ice-9/eval-string.scm: 44: 19 [read-and-eval #<input: string 564540024340> #:lang ...] 37: 18 [lp (use-modules (gnucash report standard-reports))] In ice-9/eval.scm: 505: 17 [#<procedure 56453f224520 at ice-9/eval.scm:499:4 (exp)> (use-modules #)] In ice-9/psyntax.scm: 1106: 16 [expand-top-sequence ((use-modules #)) () ((top)) ...] 989: 15 [scan ((use-modules (gnucash report standard-reports))) () ...] 279: 14 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...] In ice-9/boot-9.scm: 3589: 13 [process-use-modules (((gnucash report standard-reports)))] 705: 12 [map #<procedure 56453f2d5540 at ice-9/boot-9.scm:3589:25 (mif-args)> ((#))] 3590: 11 [#<procedure 56453f2d5540 at ice-9/boot-9.scm:3589:25 (mif-args)> (#)] 2867: 10 [resolve-interface (gnucash report standard-reports) #:select ...] 2792: 9 [#<procedure 56453f2cbde0 at ice-9/boot-9.scm:2780:4 (name #:optional autoload version #:key ensure)> # ...] 3068: 8 [try-module-autoload (gnucash report standard-reports) #f] 2404: 7 [save-module-excursion #<procedure 56453fb11630 at ice-9/boot-9.scm:3069:17 ()>] 3088: 6 [#<procedure 56453fb11630 at ice-9/boot-9.scm:3069:17 ()>] In unknown file: ?: 5 [primitive-load-path "gnucash/report/standard-reports" ...] In standard-reports.scm: 119: 4 [#<procedure 5645402d4080 ()>] In ice-9/boot-9.scm: 778: 3 [for-each #<procedure 56453fd7e880 at standard-reports.scm:120:1 (x)> #] In standard-reports.scm: 123: 2 [#<procedure 56453fd7e880 at standard-reports.scm:120:1 (x)> #{register \x28;copy\x29;}#] In ice-9/boot-9.scm: 2870: 1 [resolve-interface (gnucash report standard-reports ...) #:select ...] In unknown file: ?: 0 [scm-error misc-error #f ...] ERROR: In procedure scm-error: ERROR: no code for module (gnucash report standard-reports #{register \x28;copy\x29;}#)"
Created attachment 373371 [details] screenshot showing change of value = $0 @jralls I mean the Value columns which are only present when Display/Value is switched on. It queries xaccSplitGetValue which always balances. See screenshot. @avi you've renamed to register-copy.csm -- won't work. Edit register.scm directly.
addendum @Jralls always balances for "General Journal" report. For Register->Report->Account Report it won't.
OIC. FWIW it works the same with trading accounts enabled. I guess it would be a surprise if it didn't.
This looks good to me...
Fixed in maint, using a slightly different (neater) approach but equivalent logic. Thank you for reporting; the GJ report was annoying me for a while now.
