Using Current account balance as a variable in scheduled transactions

[Derek Atkins]

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