Adding a 'number' field to splits

[Wm Tarr]

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 ...