Using Current account balance as a variable in scheduled transactions

[Ryan Dunn]

Well that's a bummer.  It's not too hard to calculate by hand, but would be
less work each month.

On Tue, Dec 23, 2008 at 5:33 PM, Derek Atkins <warlord at mit.edu> wrote:

> Unfortunately no, it has not been implemented.
>
> -derek
>
>
> Quoting Ryan Dunn <oryandunn.ml at gmail.com>:
>
>  Does anyone know if this has been implemented?  I just started using
>> GnuCash and ran into this myself.  It would be far easier if I could
>> use the current loan balance in figuring out how much of a payment
>> should go to interest vs. principal.
>>
>>
>>
>> It would be nice if I could specify my payment=x,
>> interest=curBal*(rate/12), and principal=x-interest.  I frequently
>> make additional payments that render the current ppmt and ipmt that
>> are based solely on loan start amount and months into loan.
>>
>>
>>
>> Thanks, Ryan
>>
>> ------------------
>> 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}`
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>>
>>
>
>
> --
>      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
>      warlord at MIT.EDU                        PGP key available
>
>