Hi. Thanks for downloading QHacc.

The one central tenet of QHacc was keeeping the saved files obvious. I didn't
want to use unprintable characters, or run all the data together and let the
program count bytes or something. The result is that the program probably
loads a bit slower than it otherwise could, but you can change your data
without running the program, if you like. In order to facilitate this, here
are the file formats for transactions for every released version of QHacc.
These tokens are separated by "||" in the files, but to keep things more
readable here, I'm separating fields with a space.

VERSION 0.2
	A C E F G H I J

VERSION 0.2.1
	A C D E F G H I J

VERSION 0.2.5 and above
	A B C D E F G H I J (C and D repeat based on B)


where
A: transaction id (unique)
B: number of splits
C: transaction pair's id (double entry transactions only)
D: transaction pair's owner account (double entry transactions only)
E: number
F: payee
G: memo
H: amount
I: reconciled? (Y or N)
J: date (MM/DD/YYYY)



SPLIT TRANSACTIONS
In QHacc, every transaction can be a split transaction. The load process finds
all transactions that are paired with each other, and links them together. In
previous releases, each split was comprised of one split base transaction and
one or more satellite transactions. For that reason, if you had a split
transaction comprised of five parts, four of them would think they are regular
doubly-entered transactions. Only the split base would know they were all
connected. That is, in the format above, only one transaction would have a B>1.
As of release 0.6, however, every transaction knows if it is part of a split
(in the above terms, B>1 for everybody). I think this makes editing the
transaction files by hand slightly more difficult, but it simplifies the
program, and make split transactions easier to find in the files.


FINAL
As a final note, I'm not planning on changing this format with every release.
I know it looks that way now. In fact, I'd like to stop changing it all
together. (I won't say never again, but something like that.) I'd like the
program to load quickly and be flexible, and I think I have a good combination
of that now.

ryan bobko <ryan@ostrich-emulators.cx>

