Re: [GNC-dev] Reports -- Cleanup
Stephen, while I agree in principle that the reports need cleanup, as a user, I don’t want to see functionality removed, just moved. Consider the following: For example on your #1, Why do I need to see the credit split for every transaction when running the report for an expense account? Maybe I want to know where the money came from, but more likely, I want to know who I paid it to and when and how much. Maybe I’d like some 'how much' totals for the 'who to' and when ‘questions'. To have to see the other side of every transaction even for a few dozen is unnecessary clutter, imagine a report with hundreds of transactions. One purpose of a report is to condense/consolidate information. This would turn the Transaction Report into just a fancy Register Report. I might as well look at the expense register itself then run a report. On the #2, So I shouldn’t be able to see what else might have happened in that transaction, but I always have to see both the credit and debit sides of it? How is that consistent? or possible? If I can’t see the other splits, I can’t see the balancing part of the transaction like you want in #1, or, maybe I see a debit to an expense and the credit to checking, but maybe there were other offsetting debits for other expense accounts in that transaction. Now I’m looking at an expense debit that is less than the credit line and things don’t balance at the least, and worst, now I have clutter that gives me no useful information and can’t see the info I might want to see. (such as, is there a pattern that two expenses go together?) I do agree however that the Transaction report is really more of a ‘master report’ of sorts. The multi-column is another. There might be others. Those should probably be either in their own sub-menu, or the only ones in the main Reports menu. Then the various useful reports one routinely needs that are based off of those masters can be in the topic specific sub-menus. I don’t see the myriad of options as ‘gold plating’ I see them as making the report more useful. (though obtuse as well) Perhaps if some more routine and useful reports were created from this and added to the relevant sub-menus, less people would need the ‘master report’ though it can still be there for those who know how to wield its power. Just my 2¢. Regards, Adrien > On Jan 7, 2019, at 4:50 PM, Stephen M. Butler wrote: > > I think one of the developers here mentioned that there is a lot of > duplication in the reports arena. I concur. At first it was very > confusing as to which was the "correct" one. Finally figured out none > where -- according to the in house SME (pronounced "smee" and standing > for Subject Matter Expert) and needed to roll my own. Of which, I only > have the Balance Sheet sorta working like she wants it. > > Following some email exchange via the bug reporting system regarding the > Transaction report module, I agree that it has too many options already > and requires a near programmer to figure out which options need to be > set what way to get something close to desirable. > > Please note that I'm not a smee in this arena and, with my project > manager hat on, my wife barely qualifies. There are others on this > mailing list better qualified who will have differing opinions. > > However, here are my thoughts: > > 1. A transaction report (however it is organized) should always show > the split amount. I propose that the Amount (None, Single, Double) > option be removed and the report always produces the Amount in two > columns Debit to the left and Credit to the right. > > 2. The Multi-line versus Single-line option may add confusion. If one > wants to group the splits in a transaction together, then the report > should be organized that way. When one picks the multi-line option, the > report becomes hard to read and understand especially as the other > splits are not included in the totals. I suggest that Single-line be > the reporting style and the multi-line (meaning -- as best I can > determine -- multi-splits) removed. > > These are just two of many simplifications that could be made to help > guide the end-user into the reports they need rather than letting them > create a report that is useless to them and anybody else. > > Along those lines, I see this code needing to generate the following > types of reports: > > A. Transaction Journal -- this one lists the transactions within the > date range in date order and keeps all the splits together on the > report. A printed version of the General Ledger screen (in multi-split > mode). > > B. Reconciliation Report -- rather than have the user pick the > accounts, a first pass should show the Dates within Accounts for which > there were reconciliations done (with the date range selected). Let the > user select one or more of these to be reported, but each selection > becomes its own report or page. Usually show the transactions > reconciled on that date (by
Re: [GNC-dev] Reports -- Cleanup
Stephen, I'm sure I would welcome improvement in the reports. I don't have many concrete points here, except to suggest that the ideal UI point for a reconciliation report would be at the end of the reconciliation process. A check box on the reconcile window would trigger the report, automatically passing the current account and reconciliation dates along to the report. David T. On Tue, Jan 8, 2019 at 4:21, Stephen M. Butler wrote: I think one of the developers here mentioned that there is a lot of duplication in the reports arena. I concur. At first it was very confusing as to which was the "correct" one. Finally figured out none where -- according to the in house SME (pronounced "smee" and standing for Subject Matter Expert) and needed to roll my own. Of which, I only have the Balance Sheet sorta working like she wants it. Following some email exchange via the bug reporting system regarding the Transaction report module, I agree that it has too many options already and requires a near programmer to figure out which options need to be set what way to get something close to desirable. Please note that I'm not a smee in this arena and, with my project manager hat on, my wife barely qualifies. There are others on this mailing list better qualified who will have differing opinions. However, here are my thoughts: 1. A transaction report (however it is organized) should always show the split amount. I propose that the Amount (None, Single, Double) option be removed and the report always produces the Amount in two columns Debit to the left and Credit to the right. 2. The Multi-line versus Single-line option may add confusion. If one wants to group the splits in a transaction together, then the report should be organized that way. When one picks the multi-line option, the report becomes hard to read and understand especially as the other splits are not included in the totals. I suggest that Single-line be the reporting style and the multi-line (meaning -- as best I can determine -- multi-splits) removed. These are just two of many simplifications that could be made to help guide the end-user into the reports they need rather than letting them create a report that is useless to them and anybody else. Along those lines, I see this code needing to generate the following types of reports: A. Transaction Journal -- this one lists the transactions within the date range in date order and keeps all the splits together on the report. A printed version of the General Ledger screen (in multi-split mode). B. Reconciliation Report -- rather than have the user pick the accounts, a first pass should show the Dates within Accounts for which there were reconciliations done (with the date range selected). Let the user select one or more of these to be reported, but each selection becomes its own report or page. Usually show the transactions reconciled on that date (by account and in date order) optionally followed by the transactions not yet reconciled within that account. C. Account Details -- here the user should pick the account(s) for which the detailed transaction should be shown for the date range selected. There may be a couple more variants, but if we start thinking about what a bookkeeper/accountant needs we can reduce the number of options available and thus remove complexity from the reports (at least this particular one). As a software engineer, I love to gold plate things. As a project manager, I realize that gold plates rarely provide the end user with something useful. Hey, but it looks good! So, which options on the transaction report do you never use? Which options do you always set one particular way? --Steve -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Bug # 796687
Geert, On Sun, Jan 6, 2019 at 9:17 AM Alex Aycinena wrote: > Geert, > > On Sun, Jan 6, 2019 at 8:11 AM Geert Janssens > wrote: > >> On Sunday, January 6, 2019 4:55:09 AM CET Alex Aycinena wrote: >> > Geert, >> > >> > I have been investigating bug # 796687 (Tax Entity name and type for an >> > account won't work under "Tax Reporting Options" in Gnucash 3.2) and it >> > seems that your commit 4053f2ca5331b345f04f75022658d254c36bdd15 on Mar >> 31, >> > 2018, has caused book string options not to work. I ran gnucash under >> gdb >> > and got the following: >> > >> > qof_book_set_string_option (book=0xb49af0, >> > opt_name=0x7fffefcd57e9 "book/tax_US/type", opt_val=0x2600640 >> "F1040") >> > at >> > >> /home/gnucash-dev/gitcheckouts/gnucash-acct-maint-latest/libgnucash/engine/q >> > ofbook.cpp:1163 1163qof_book_begin_edit(book); >> > >> > going into the function. The book, opt_name and opt_val all seem fine >> but >> > the KVP is not saved. When I checked-out the commit just prior to >> yours, it >> > seems to work fine: the data is saved and retrieved as expected. After >> your >> > commit, it seems to stop working. >> > >> > I tried to analyze your commit but I'm not sure I understand it. Perhaps >> > you could help me understand it. The funny thing is, the unit test >> seems to >> > pass. >> > >> > Can you help me figure out why it is not working? >> > >> > Thanks, >> > >> > Alex >> >> Alex, >> >> I'm not at my development machine until Wednesday. I'll get back to this >> later >> this week. >> >> Geert >> >> > OK. Thanks, > > Alex > The following change seems to fix it: diff --git a/libgnucash/engine/qofbook.cpp b/libgnucash/engine/qofbook.cpp index c0cb043ba..fa67f5b65 100644 --- a/libgnucash/engine/qofbook.cpp +++ b/libgnucash/engine/qofbook.cpp @@ -1164,9 +1164,9 @@ qof_book_set_string_option(QofBook* book, const char* opt_name, const char* opt_ auto frame = qof_instance_get_slots(QOF_INSTANCE(book)); auto opt_path = opt_name_to_path(opt_name); if (opt_val && (*opt_val != '\0')) -delete frame->set(opt_path, new KvpValue(g_strdup(opt_val))); +delete frame->set_path(opt_path, new KvpValue(g_strdup(opt_val))); else -delete frame->set(opt_path, nullptr); +delete frame->set_path(opt_path, nullptr); qof_instance_set_dirty (QOF_INSTANCE (book)); qof_book_commit_edit(book); } If you agree with the change, I will commit it. Thanks, Alex ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Reports -- Cleanup
I think one of the developers here mentioned that there is a lot of duplication in the reports arena. I concur. At first it was very confusing as to which was the "correct" one. Finally figured out none where -- according to the in house SME (pronounced "smee" and standing for Subject Matter Expert) and needed to roll my own. Of which, I only have the Balance Sheet sorta working like she wants it. Following some email exchange via the bug reporting system regarding the Transaction report module, I agree that it has too many options already and requires a near programmer to figure out which options need to be set what way to get something close to desirable. Please note that I'm not a smee in this arena and, with my project manager hat on, my wife barely qualifies. There are others on this mailing list better qualified who will have differing opinions. However, here are my thoughts: 1. A transaction report (however it is organized) should always show the split amount. I propose that the Amount (None, Single, Double) option be removed and the report always produces the Amount in two columns Debit to the left and Credit to the right. 2. The Multi-line versus Single-line option may add confusion. If one wants to group the splits in a transaction together, then the report should be organized that way. When one picks the multi-line option, the report becomes hard to read and understand especially as the other splits are not included in the totals. I suggest that Single-line be the reporting style and the multi-line (meaning -- as best I can determine -- multi-splits) removed. These are just two of many simplifications that could be made to help guide the end-user into the reports they need rather than letting them create a report that is useless to them and anybody else. Along those lines, I see this code needing to generate the following types of reports: A. Transaction Journal -- this one lists the transactions within the date range in date order and keeps all the splits together on the report. A printed version of the General Ledger screen (in multi-split mode). B. Reconciliation Report -- rather than have the user pick the accounts, a first pass should show the Dates within Accounts for which there were reconciliations done (with the date range selected). Let the user select one or more of these to be reported, but each selection becomes its own report or page. Usually show the transactions reconciled on that date (by account and in date order) optionally followed by the transactions not yet reconciled within that account. C. Account Details -- here the user should pick the account(s) for which the detailed transaction should be shown for the date range selected. There may be a couple more variants, but if we start thinking about what a bookkeeper/accountant needs we can reduce the number of options available and thus remove complexity from the reports (at least this particular one). As a software engineer, I love to gold plate things. As a project manager, I realize that gold plates rarely provide the end user with something useful. Hey, but it looks good! So, which options on the transaction report do you never use? Which options do you always set one particular way? --Steve -- Stephen M Butler, PMP, PSM stephen.m.butle...@gmail.com kg...@arrl.net 253-350-0166 --- GnuPG Fingerprint: 8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
