Entering scheduled transactions.

[Josh Sled]

On Mon, 2004-06-14 at 19:49, Derek Atkins wrote:

> Adam Spiers <gnucash at adamspiers.org> writes:
> > Derek Atkins (warlord at mit.edu) wrote:
> >> Adam Spiers <gnucash at adamspiers.org> writes:
> >> > Donald Henson (tcrf at tcrf.com) wrote:
> >> >> If you're accepting suggestions here, as opposed to bugzilla, I think
> >> >> the most useful variable to make available would be a variable to access
> >> >> the current balance of a given account. (If you need it to be in
> >> >> bugzilla, I'll put it there as well.)
> >> >
> >> > Did anything ever happen on this?  I would find it extremely useful ...
> >> 
> >> Not yet.  When someone submits a patch, something will happen.
> >
> > If you give me a few hints as to how to go about it (which files are
> > likely to need updating, existing code which can be adapted etc.) I'll
> > give it a go.  Or less helpfully, I could file a bug in bugzilla if
> > that's any use?
> 
> Bug #141161
> 
> You'd need to edit at least src/scm/fin.scm but I honestly don't know
> what else you'd need to do.  Hopefully Josh will pipe in, now that I
> know he's back from his business trip.

I don't really have super-concrete direction, but I've thought about
this a bit...

It seems like you'd want to expose a function like...

(defun (gnc:account-balance accountId date)
  "@return the account balance as of the specified date."
  ;; add impl...
 )

The major complication here is around the representation of 'accountId'.
The correct representation of the account is as a GUID, which insulates
the system from account-name/hierarchy changes [since the GUID stays the
same across such events].

The correct thing to do is to...

* internally [in storage as well as the Scheme] represent the account 
  as a [typed] GUID which is looked-up at eval time.

* interface with the user in terms of the account name [path] via an 
  "expression editing interface".  This would be an extension of the 
  current f{cred,debt}cell [read: "formula {credit,debit} cell"] in  
  the ledger.
  * provide the GUID->account-path mapping on display.
  * allow access to the existing GncAccountSel[ection] widget on 
    editing.
  * do the account-path->GUID mapping on cell-save.


However, this does entail a lot more user-interface complexity than
currently exists.  A _lot_ more, in fact, because one would really want
to have some meta-data somewhere bridging the relatively low-level SCM
and expression-parsing with the high level constraints of the data, and
the subsequent implications on the UI... 


A slightly-ghetto alternative would be to have a convention for the
scheme involved in expressions... basically, have the exposed functions 
provide in-/out- expression-rewriting hooks.  Something like:

(defun (gncexp:account-balance account date) ...)
(defun (gncexp:account-balance-in in out) ...)
(defun (gncexp:account-balance-out in out) ...)
(defun (gncexp:account-balance-validate in) "@return errors" ... )

Such that the Name<->GUID mapping could be supported, but the user never
sees it... I guess you'd also want a "validate" so you could enter into
a feedback loop with the user, such that the Name->GUID mapping can be
constrained to be within a range of allowable values.


The cheaper/lamer alternative is just to implement the function in terms
of the String representation of the account name/path, and do the
lookups at eval time, having a reasonable means for handling errors when
the string isn't correct or becomes invalid...  as well, registering a
run-time hook such that all account-tree changes would validate all
formulae would work, but would totally sux0r.


I've been hoping that gnumeric's expression parser would become
available as part of libgoffice, and that -- while it wouldn't save
hardly any work -- would at least be a design+code catalyst for
revamping gnucash's expression-handling.  At the same time, I hear that
gnumeric's expression parser is pretty deeply tied into gnumeric. :/


It does seem like a nice moderate-complexity project of various stripes
if someone is so willing.  I was thinking of trying to bite this off in
the 2.(x>0) timeframe, but would be really happy if the problem went
away in the mean time. ;)

expression-parsing:
	src/app-utils/gnc-exp-parser.[ch]
register, formulacell:
	src/register/register-gnome/formulacell.[ch]
existing SchedXaction financial scheme:
	src/scm/fin.scm

...jsled

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