transaction dates

[tripp+gnucash-devel at perspex.com]

Peering into my gnucash XML file, I note the following dates:

[tlilley at charmin 2003]$ grep date- books.gnucash | sort -u | grep -v '</'
  <trn:date-entered>
  <trn:date-posted>
[tlilley at charmin 2003]$


As I understand it from comparing the file to the UI, and as is implied by
the self-describing nature of these fields :), date-entered is when I
typed in the transcation entry, and date-posted is the date I entered in
the UI for when the transaction "happened".

In a thread on gnucash-user (or possibly -devel, and, in any case, which
thread I cannot now seem to find), someone asked about differentiating
between the date the transaction happened "in the real world" and the date
the bank "caught up" with the transaction. Specifically, they were asking
how to represent this in GnuCash, and the consensus was that they didn't
need to worry about it, since it's common for the dates not to match
between one's own books and those of other institutions.

After reading Jon's credit card chapter in the tutorial this evening,
though, I thought I should mention why I, personally, want to see at least
one other date added to a transaction:

	accurate interest computation / prediction

I have a Perl script that, given a starting balance, a list of dated
transactions, and an interest rate, does a pretty bang-up job of producing
precisely the number that my credit card (or overdraft loan, or what have
you) comes up with at the end of the period for my interest bill.

Of course, the dates on those transactions are all the dates those
transactions posted to the account holder, not (necessarily) the date on
which I initiated the transaction.

However, I definitely want a record of the initiation date, since that's
going to be the date on my receipt, and, in the case of fun accrual games,
that's the date on which my accrual might very well be based (if I bought
a new toner cartridge on December 31st, for instance, and it didn't post
to my card until January 2nd because of the holiday).

Also, while I'm on the subject of dates, I'd like to see "cleared" and
"reconciled" get dates (if they don't already have them... I couldn't find
them in a casual grep of my file, but if they're there, cool).


Thinking about naming, ideally I'd propose "date-initiated" to be what is
now called "date-posted", and "date-posted" to be the date the external
entity posted the transaction to -their- accounts.

However, I realize this might cause mass confusion, therefore I think this
reasonable. Note that it also includes adding some more dates to the
transaction and (if I understand how reconciling is implemented) the
splits:

	date-entered:	date the transaction was typed / imported /
			whatever into GnuCash (but see below for extended
			notes on an eventual audit trail).

	date-posted:	real-world date of the transaction

	date-cleared:	posting date of the transaction as recorded by the
			external account institution reflected by this
			GnuCash account

	date-marked-cleared:
			date that the "date-cleared" field was updated.
			This is primarily an internal audit-trail device,
			like date-entered, above.

	date-reconciled:
			date of the formal reconciliation process (whether
			manual or automated).


I should note that, ideally, date-entered, date-marked-cleared, and
date-reconciled might eventually become data derived from an audit trail
of updates to the books. This would allow for someone clearing and
un-clearing an entry (for instance "oops, I cleared that but it was
because I mistook it for another, similar transaction"), someone
unreconciling an entry if they were fixing gross errors in the books, etc.
(all of which, sadly, happen, especially with inexperienced bookkeepers).


Now, with that said, what would I be taking on to implement at least
date-cleared, being, again, when the institution posts the transaction to
their account?

I believe this should be a split-level field, not a transaction-level
field, because the split is where the "cleared" field is, and because the
split is where the debit/credit is reflected for a specific account (and
"date cleared" affects just that particular side of the equation).

Is this an appropriate use for a slotmap entry? Or is this something that
should be added "directly" to the split data structure?

How much pain^H^H^H^Hwork is involved in the GUI portion of this? I
haven't done any GTK stuff directly (all through wrapper libraries, etc.),
but was once quite proficient in MFC :(

And on a related note... what will GnuCash do with fields it finds in the
XML file that it doesn't recognize? What about slotmap entries it doesn't
know what to do with? Will it preserve them? Could it be made to do so? I
ask because, depending on the overhead of implementing the above, I may
instead opt to work on an external solution initially :)

Thanks!

- t.