Reg Run Balance for Subaccount view

[Tim M]

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 <tim at filmchicago.org> 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 <tim at filmchicago.org> 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 <tim at filmchicago.org> 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.
>>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reg_run_balance_RC3.diff
Type: text/x-patch
Size: 9575 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20090907/782a391a/attachment.bin>