Reg Run Balance for Subaccount view
Tim M
tim at filmchicago.org
Sun Sep 6 19:58:03 EDT 2009
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_RC2.diff
Type: text/x-patch
Size: 9409 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20090906/8a4b7d58/attachment.bin>
More information about the gnucash-devel
mailing list