On 2011-09-16 20:48, Alex Aycinena wrote:
Currently gnucash has a 'number' field at the transaction-level so
that the 'num' field displayed on the register for each split is the
same as that displayed on the register for each other split of the
same transaction.
Thing is the number field in the transaction table doesn't mean
anything, it is a convenience. Beware of overloading it, please.
I have spent time to add an additional 'number'
field at the split-level so that it would be possible to have multiple
numbers for each transaction and display either or both in the
register/reports. (For our users who come from Quicken, Quicken only
has number field at the split-level, at least the old version I'm
familiar with).
I have looked at non-double entry systems too and they all seem to work
on one leg of the transaction.
Surely -4 from cash and +4 for snacks are one endian transactions for
the Quicken and similar minded folks so you only need to look at one end
of the tx if you are that way inclined.
My point is, why do you need the splits to be counted?
At this time, I have only modified the engine and the xml and sql
backends, including logging, so it is not visible to users. I would
like to commit these changes now and then follow-up with changes to
the GUI, importing/exporting and reporting in subsequent commits.
However, I would like to describe what I am doing and get feedback and
remarks, answer any questions, and make changes to my approach
accordingly before making this first commit. What I have done so far
is:
1. I have called the split-level number 'entry-num' to avoid confusion
with the transaction-level number. This is not intended to be a
numbering of splits within a transaction, but rather the numbering of
entries within a register for an account (i.e., check number).
2. I have not modified the current transaction number in any way, nor
do I intend to, so any functionality that is dependent on it should
not be affected.
3. For sql backends, the addition of a new column will bump up the
split-table version number. The work Phil did on this backend already
handles this; the user will be notified of an upgrade on reading a
previous version sql backend and will also be notified if trying to
read a later version backend db with an earlier version gnucash.
4. For xml backends, this kind of version tracking didn't exist. I
bumped the xml version written out from 'gnc-v2' to 'gnc-v2.0.1', as
well as the transaction version number from '2.0.0' to '2.0.1', and
added logic so that a user will be notified that an earlier-version
file saved with this version will not be readable with the earlier
version gnucash (the user is told they will get an 'error parsing
file' message). I also added logic so that if this version ever tries
to read a future version xml file, the user will get a message similar
to that provided by the sql backend rather the cryptic 'error parsing
file' message the currently released version provides.
5. The field has been added to the log writing and replay code.
Subsequent commits would then:
1. Add this new field to the GUI (registers, find) with perhaps some
user-selected options for how it should be displayed on the
register/reports.
2. Print the new field on reports where appropriate
3. Add the field to importing/exporting
I will commit these changes after responding to any comments I receive.
General comment: I think I am against Alex's proposal because the num in
question is a hand or import thing so there is nothing it can be
connected to.
Alex: I think your proposal will need to be more general.
P.S. you said Quicken, just take one leg and report on that and you have
got what it and similar do :) No need for an extra field as far as I
can see though I do agree with you about the obscurity to some extent.
-- Wm ...
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
