Re: Reg Run Balance for Subaccount view
OK, here is one more update... reg_run_balance_RC3.diff includes the following update(s): 1. Minor code cleanup 2. Fixed issue where 'negative' accounts such as the Equity accounts would show up with negative balances (negative balances would be positive and positive would be negative), but would have the correct color in "Open Subaccounts" view. They now have the correct color and balance. 3. Fixed "Open Subaccounts" view for Income/Expense accounts which would not display debit/credit totals for transactions. Only 'issue' left is clean-up for the overall Tools->General Ledger register. The General Ledger now displays a 'Balance' column because it is of the GENERAL_LEDGER type, but always has a $0.00 balance because transactions will always balance out. So, a new ledger type (SUBACCOUNTS_LEDGER) may be necessary to be used for the 'open subaccounts' view so that the general ledger can be left without a balance column, or the GENERAL_LEDGER type could sift out the balance column based on the ld->type property, although I'm uncertain of how to do this myself. The current behavior of the General Ledger register is not a bug, however, although ideally the Balance column would not be displayed in this register. I opted not to create a new ledger type for this patch, since it could perhaps more easily be done if it is possible to compare the ld->type and only display the balance column for the GENERAL_LEDGER if the ld->type == LD_SUBACCOUNTS. -Tim On Sun, Sep 6, 2009 at 6:58 PM, Tim M wrote: > Attached is an update to the RC1 patch > > This patch improves the original "RC1" patch in the following ways: > 1. reg_run_balance_RC2.diff adds the gnc_split_register_get_rbaln() function, > > whose code was originally duplicated in the > gnc_split_register_get_balance_fg_color() and > gnc_split_register_get_rbaln_entry() functions in the first patch. > > 2. Modified the gnc_split_register_get_tdebcred_entry() function to display > the > > debit/credit amount for the register's parent account and all subaccounts when > the GENERAL_LEDGER register is in use (used by Show Subaccounts feature). > > 3. Added the get_trans_total_amount_subaccounts() function which returns the > > total amount of a transaction for the register's parent account and all > subaccounts. > > > > On Fri, Sep 4, 2009 at 12:01 AM, Tim M wrote: > >> OK, IMO the updated patch attached to this mail is ready for testing. >> This patch does the following: >> >> 1. When opening an account register and it's subaccounts by right clicking >> it in the Accounts tab and selecting "Open Subaccounts," there is now a >> Balance column as there normally is in a single account register. >> >> 2. This new RBALN balance column tallies the balance of the splits for the >> account and all subaccounts at runtime. >> >> 3. Because the balance is calculated at runtime, this also means that the >> balance column always reflects an accurate running balance regardless of >> sort order. This is a big benefit and could certainly be modified to work >> for single account view as well. With the current single account register, >> when the sort order is changed the Balance displayed will only reflect the >> balance of the account associated with each split - not a running balance in >> relation to the sort order of the register, so that the 'Balance' displayed >> for each split when the sort order is not the default causes the 'Balance' >> column to be more or less unusable. >> >> I believe this should also resolve the following issue: >> http://bugzilla.gnome.org/show_bug.cgi?id=107929 >> >> I resolved issue #1 in my original mailing list post. Issue #2 remains a >> matter of testing by other users to ensure the patch doesn't have any >> unintended consequences. >> >> I've tested this patch locally by opening an account and it's subaccounts >> using the "Open Subaccounts" option. The newly added balance column tallies >> the balance properly at runtime, and sets the balance color properly as well >> (red for negative, black positive). I also tested different sort orders, >> and the running balance was spot on regardless. Since this affects only the >> "Open Subaccounts" register (and possibly other similar registers?), this >> does not affect single account registers so those still do not tally Balance >> properly when using a non-default sort order. >> >> This patch is against an older version of the SVN repository (I think a >> trunk snapshot of version 3.1), so it may or may not work OK with the latest >> trunk. Let me know if I need to make a new patch with the current trunk. >> >> >> As a side note and as matter of cleanup, it would be useful to >> functionalize the part of the new gnc_split_register_get_rbaln_entry() >> function which does the actual calculations to get the running balance of >> the register at a specific split, because the running balance also has to be >> calculated for the gnc_split_register_get_balance_fg_color() function to set >>
Re: Reg Run Balance for Subaccount view
Attached is an update to the RC1 patch This patch improves the original "RC1" patch in the following ways: 1. reg_run_balance_RC2.diff adds the gnc_split_register_get_rbaln() function, whose code was originally duplicated in the gnc_split_register_get_balance_fg_color() and gnc_split_register_get_rbaln_entry() functions in the first patch. 2. Modified the gnc_split_register_get_tdebcred_entry() function to display the debit/credit amount for the register's parent account and all subaccounts when the GENERAL_LEDGER register is in use (used by Show Subaccounts feature). 3. Added the get_trans_total_amount_subaccounts() function which returns the total amount of a transaction for the register's parent account and all subaccounts. On Fri, Sep 4, 2009 at 12:01 AM, Tim M wrote: > OK, IMO the updated patch attached to this mail is ready for testing. This > patch does the following: > > 1. When opening an account register and it's subaccounts by right clicking > it in the Accounts tab and selecting "Open Subaccounts," there is now a > Balance column as there normally is in a single account register. > > 2. This new RBALN balance column tallies the balance of the splits for the > account and all subaccounts at runtime. > > 3. Because the balance is calculated at runtime, this also means that the > balance column always reflects an accurate running balance regardless of > sort order. This is a big benefit and could certainly be modified to work > for single account view as well. With the current single account register, > when the sort order is changed the Balance displayed will only reflect the > balance of the account associated with each split - not a running balance in > relation to the sort order of the register, so that the 'Balance' displayed > for each split when the sort order is not the default causes the 'Balance' > column to be more or less unusable. > > I believe this should also resolve the following issue: > http://bugzilla.gnome.org/show_bug.cgi?id=107929 > > I resolved issue #1 in my original mailing list post. Issue #2 remains a > matter of testing by other users to ensure the patch doesn't have any > unintended consequences. > > I've tested this patch locally by opening an account and it's subaccounts > using the "Open Subaccounts" option. The newly added balance column tallies > the balance properly at runtime, and sets the balance color properly as well > (red for negative, black positive). I also tested different sort orders, > and the running balance was spot on regardless. Since this affects only the > "Open Subaccounts" register (and possibly other similar registers?), this > does not affect single account registers so those still do not tally Balance > properly when using a non-default sort order. > > This patch is against an older version of the SVN repository (I think a > trunk snapshot of version 3.1), so it may or may not work OK with the latest > trunk. Let me know if I need to make a new patch with the current trunk. > > > As a side note and as matter of cleanup, it would be useful to > functionalize the part of the new gnc_split_register_get_rbaln_entry() > function which does the actual calculations to get the running balance of > the register at a specific split, because the running balance also has to be > calculated for the gnc_split_register_get_balance_fg_color() function to set > the text color properly when the RBALN cell type is used. Currently I've > just copied the code from the rbaln function to the fg_color function, so it > would be helpful to put this in a function that returns a gnu_numeric value > of the split's running balance for the register which could then be called > by both functions. However, I'm not an experienced C programmer so I was > having some trouble figuring out just where to put such a function and how > to get it working. I did try! > > Also, this is my first FOSS patch, so let me know if there is anything I > can do differently or improve on, thanks! > > -Tim M. > > > > On Fri, Jul 10, 2009 at 10:53 AM, Tim M wrote: > >> Hello, >> >> I've attached a BETA svn diff patch against HEAD which creates a new cell >> type, RBALN_CELL. I could use some help tweaking this patch if someone is >> able to provide answers to my questions below. >> >> This cell calculates the balance of all transactions in a register at >> runtime, allowing a running balance to be displayed when using the "Open >> Subaccounts" feature. The cell currently calculates the running balance of >> all splits that are going to/from the lead account and all of its >> subaccounts, therefore it is not appropriate (currently) to use this cell >> type in a non-subaccount register view. >> >> My Questions: >> >> 1. There is an outstanding issue with this patch where it appears the >> return value of the gnc_split_register_get_rbaln_entry() function is printed >> in the Balance column of the split rows. The running Balance is correctly >> printed on the Transaction rows,
Re: Reg Run Balance for Subaccount view
OK, IMO the updated patch attached to this mail is ready for testing. This patch does the following: 1. When opening an account register and it's subaccounts by right clicking it in the Accounts tab and selecting "Open Subaccounts," there is now a Balance column as there normally is in a single account register. 2. This new RBALN balance column tallies the balance of the splits for the account and all subaccounts at runtime. 3. Because the balance is calculated at runtime, this also means that the balance column always reflects an accurate running balance regardless of sort order. This is a big benefit and could certainly be modified to work for single account view as well. With the current single account register, when the sort order is changed the Balance displayed will only reflect the balance of the account associated with each split - not a running balance in relation to the sort order of the register, so that the 'Balance' displayed for each split when the sort order is not the default causes the 'Balance' column to be more or less unusable. I believe this should also resolve the following issue: http://bugzilla.gnome.org/show_bug.cgi?id=107929 I resolved issue #1 in my original mailing list post. Issue #2 remains a matter of testing by other users to ensure the patch doesn't have any unintended consequences. I've tested this patch locally by opening an account and it's subaccounts using the "Open Subaccounts" option. The newly added balance column tallies the balance properly at runtime, and sets the balance color properly as well (red for negative, black positive). I also tested different sort orders, and the running balance was spot on regardless. Since this affects only the "Open Subaccounts" register (and possibly other similar registers?), this does not affect single account registers so those still do not tally Balance properly when using a non-default sort order. This patch is against an older version of the SVN repository (I think a trunk snapshot of version 3.1), so it may or may not work OK with the latest trunk. Let me know if I need to make a new patch with the current trunk. As a side note and as matter of cleanup, it would be useful to functionalize the part of the new gnc_split_register_get_rbaln_entry() function which does the actual calculations to get the running balance of the register at a specific split, because the running balance also has to be calculated for the gnc_split_register_get_balance_fg_color() function to set the text color properly when the RBALN cell type is used. Currently I've just copied the code from the rbaln function to the fg_color function, so it would be helpful to put this in a function that returns a gnu_numeric value of the split's running balance for the register which could then be called by both functions. However, I'm not an experienced C programmer so I was having some trouble figuring out just where to put such a function and how to get it working. I did try! Also, this is my first FOSS patch, so let me know if there is anything I can do differently or improve on, thanks! -Tim M. On Fri, Jul 10, 2009 at 10:53 AM, Tim M wrote: > Hello, > > I've attached a BETA svn diff patch against HEAD which creates a new cell > type, RBALN_CELL. I could use some help tweaking this patch if someone is > able to provide answers to my questions below. > > This cell calculates the balance of all transactions in a register at > runtime, allowing a running balance to be displayed when using the "Open > Subaccounts" feature. The cell currently calculates the running balance of > all splits that are going to/from the lead account and all of its > subaccounts, therefore it is not appropriate (currently) to use this cell > type in a non-subaccount register view. > > My Questions: > > 1. There is an outstanding issue with this patch where it appears the > return value of the gnc_split_register_get_rbaln_entry() function is printed > in the Balance column of the split rows. The running Balance is correctly > printed on the Transaction rows, but the cells in the Balance column on the > lines of the split should be blank. Instead, they display 1 (for all > transactions where a balance is printed) or 0 (for the blank split at the > bottom because the function returns NULL since we don't print the balance > for that txn). How can I fix this so that the balance cell of the split > lines is blank? > > 2. The RBALN_CELL was added to the CURSOR_SINGLE_JOURNAL cursor of the > INCOME_LEDGER/GENERAL_LEDGER/SEARCH_LEDGER cases in > split-register-layout.c. Will this affect other register views besides the > subaccount view? I have only tested this with asset accounts (bank, > checking) so I'm not sure if it might cause problems with different account > types. > > > Please take a look and let me know how I can further improve it! > > Thanks, > -Tim M. > Index: src/register/ledger-core/split-register-model.c ==
Re: Reg Run Balance for Subaccount view
Hi Tim, Tim M writes: > Hi guys, > > I wrote a (beta) patch to display the running register balance in "View > Subaccounts" register view, which I submitted to the mailing list on July > 10th. The original thread is here: > > https://lists.gnucash.org/pipermail/gnucash-devel/2009-July/025807.html > > (I don't have the original post in my email anymore so I can't do a direct > reply) > > Has anyone taken a look at this and/or can anyone give me advice on how to > improve it and/or address the issues I was unable to resolve? It's nearly > finished except for the couple of minor issues mentioned in my original > post. Any help that can be offered is appreciated. I'm sorry nobody has had the time to get to it yet. I'm sure someone will eventually. I know that I personally have been insanely busy recently. Hang in there... > Thanks, > -Tim > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reg Run Balance for Subaccount view
Hi guys, I wrote a (beta) patch to display the running register balance in "View Subaccounts" register view, which I submitted to the mailing list on July 10th. The original thread is here: https://lists.gnucash.org/pipermail/gnucash-devel/2009-July/025807.html (I don't have the original post in my email anymore so I can't do a direct reply) Has anyone taken a look at this and/or can anyone give me advice on how to improve it and/or address the issues I was unable to resolve? It's nearly finished except for the couple of minor issues mentioned in my original post. Any help that can be offered is appreciated. Thanks, -Tim ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reg Run Balance for Subaccount view
Hello, I've attached a BETA svn diff patch against HEAD which creates a new cell type, RBALN_CELL. I could use some help tweaking this patch if someone is able to provide answers to my questions below. This cell calculates the balance of all transactions in a register at runtime, allowing a running balance to be displayed when using the "Open Subaccounts" feature. The cell currently calculates the running balance of all splits that are going to/from the lead account and all of its subaccounts, therefore it is not appropriate (currently) to use this cell type in a non-subaccount register view. My Questions: 1. There is an outstanding issue with this patch where it appears the return value of the gnc_split_register_get_rbaln_entry() function is printed in the Balance column of the split rows. The running Balance is correctly printed on the Transaction rows, but the cells in the Balance column on the lines of the split should be blank. Instead, they display 1 (for all transactions where a balance is printed) or 0 (for the blank split at the bottom because the function returns NULL since we don't print the balance for that txn). How can I fix this so that the balance cell of the split lines is blank? 2. The RBALN_CELL was added to the CURSOR_SINGLE_JOURNAL cursor of the INCOME_LEDGER/GENERAL_LEDGER/SEARCH_LEDGER cases in split-register-layout.c. Will this affect other register views besides the subaccount view? I have only tested this with asset accounts (bank, checking) so I'm not sure if it might cause problems with different account types. Please take a look and let me know how I can further improve it! Thanks, -Tim M. Index: src/register/ledger-core/split-register-model.c === --- src/register/ledger-core/split-register-model.c (revision 18194) +++ src/register/ledger-core/split-register-model.c (working copy) @@ -1505,6 +1505,65 @@ } } +static const char * +gnc_split_register_get_rbaln_entry (VirtualLocation virt_loc, + gboolean translate, + gboolean *conditionally_changed, + gpointer user_data) +{ + SplitRegister *reg = user_data; + SRInfo *info = gnc_split_register_get_info (reg); + gnc_numeric value = gnc_numeric_zero(), balance = gnc_numeric_zero(); + Split *split; + Account *account; + Transaction *trans; + GList *node, *children, *child; + int i, row; + + /* This cell calculates the register balance for a particular split at runtime. + * This function should work regardless of the sort order. */ + + /* Return NULL if this is a blank transaction. */ + split = gnc_split_register_get_split (reg, virt_loc.vcell_loc); + if (split == xaccSplitLookup (&info->blank_split_guid, +gnc_get_current_book ())) +return NULL; + + /* Get a list of all subaccounts for matching */ + children = gnc_account_get_descendants(gnc_split_register_get_default_account(reg)); + children = g_list_append(children, gnc_split_register_get_default_account(reg)); + + /* Get the row number we're on, then start with the first row. */ + row = virt_loc.vcell_loc.virt_row; + virt_loc.vcell_loc.virt_row=0; + + while (virt_loc.vcell_loc.virt_row <= row ) { +/* Get new temporary split and its parent transaction */ +split = gnc_split_register_get_split (reg, virt_loc.vcell_loc); +trans = xaccSplitGetParent (split); + +i = 1; +for (node = xaccTransGetSplitList (trans); node; node = node->next) { + Split *secondary = node->data; + i++; + + /* Add up the splits that belong to the transaction if they are + * from the lead account or one of the subaccounts. */ + account = xaccSplitGetAccount (secondary); + + for (child = children; child; child = child->next) { +if (account == child->data) { + balance = gnc_numeric_add_fixed(balance, xaccSplitGetAmount(secondary)); + break; +} + } +} +virt_loc.vcell_loc.virt_row+=i; + } + + return xaccPrintAmount (balance, gnc_split_register_print_info (reg)); +} + static gboolean gnc_split_register_cursor_is_readonly (VirtualLocation virt_loc, gpointer user_data) @@ -2012,7 +2071,11 @@ gnc_split_register_get_debcred_entry, CRED_CELL); + gnc_table_model_set_entry_handler (model, + gnc_split_register_get_rbaln_entry, + RBALN_CELL); + gnc_table_model_set_label_handler (model, gnc_split_register_get_date_label, DATE_CELL); @@ -2101,7 +2164,11 @@ gnc_split_register_get_fcredit_label, FCRED_CELL); + gnc_table_model_set_label_handler (model, +