Using Current account balance as a variable in scheduled transactions

[Josh Sled]

On Mon, 2006-05-08 at 05:55 -0400, Bryan Phinney wrote:
> Is there any way to refer to the current account balance of a specific account 
> within a scheduled transaction?  Specifically, if I have a mortgage account, 

No, there's not, and this [pre-payments of principal] is the usual
problematic case.

> This could easily be overcome by simply letting the scheduled transaction 
> perform its assessments on the current account balance as the periodic 
> interest rate will be assessed against the current month's balance on the 
> account.  I can do this manually but would prefer to have Gnucash perform the 
> calculation from within the scheduled transaction if that is possible.
> 
> Anyone have any info or suggestions?

Yes, it's just a Simple Matter of Programming.  Patches are welcome, or
I'll eventually get around to resolving this; it's medium-high prioirity
for me.

[Some notes, generally, follow, and a cross-post into gnucash-devel,
where technical discussion should continue...]


The least-Simple part is the user-interface.  One would want the
function to be something like... 

    gnc_acct_balance(account_guid)

... but the user would only want to edit in terms of account name, not
the GUID value.  [Note that you can get away without including the date
here if you make the reasonable simplifying assumption that SXes are
processed in-order.]

Thus, you'd at least want a in/out thunk (so the UI can be in terms of
account name, but the storage is in terms of the resolved GUID)...  in
the more-least-Simple case, this is just a pair of routines that renders
the formulæ going into the credit/debit-formula cells, and parses them
on the way out... erroring if the user enters an invalid account name.
But requiring the user to type in the full account name is far less than
ideal...

Better, you'd like the UI to know that an Account is needed, and use an
account-selection widget, but there are some ... limits ... to the
current register's user-interface and extensibility.  There's likely
room for an expression editor -- a-la Your Favorite Spreadsheet -- that
understands the expression grammar and the defined functions, and the
datatypes of their arguments.  When (double-)clicking on the SX formula
cells, it'd bring up an window that allows the appropriate editing of
the formula fields, including selecting the account for the paramater of
this functions.

Given the later parts are going to take a while, the "more-least-Simple"
thunk approach is probably not *totally* unreasonable ... the UI isn't
great, but possible-but-ugly is usually better than impossible,
especially when you have to go to lengths to see the ugly.


There's some secondary concerns, as well, about the SX subsystem needing
to look for engine events on these formula-referenced accounts; if the
account gets deleted, the SX must to be updated (either passively
sanitized or actively fixed with user involvement).  This mechanism is
partly in place in 1.9.x, but would need refinement.


Also, there's another perhaps simpler approach wherein the function that
the account is operating on is implicit.  Something like
`gnc_loan_liability_account_balance()`, where the account is computed
from the context of the transaction the function is contained in.  This
is a pretty ugly hack, but it too might suffice for a while.  Though in
some ways, it's nice:  It's simple and clear what account is being
referenced, and will work for 80% -- if not all -- of the cases, though
it requires more built-in, task-specific code in GnuCash.

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`