Adding a 'number' field to splits

Derek Atkins derek at ihtfp.com
Fri Sep 16 16:02:31 EDT 2011


The current transaction number is designed to be the "Check Number".
It's the same on all splits because the Credit and Debit of a check-based
transaction do not need to have different numbers, and it's good to be
able to look in an expense account and see that some transaction came from
"check #x".

Artificially moving the check number to a split-level number really
doesn't make sense.

The only time it makes sense to me to have multiple check numbers in a
transaction is when you are depositing multiple checks together.  But I
think that's a rarer situation than the other way around.

So let me ask you this:  What is the purpose of this change?  What
information are you trying to store in this additional field, and what
does it represent?  Is it purely for register ordering?  If so then don't
call it an "entry number", call it a "daytime ordering field" and say what
it really is.

-derek

On Fri, September 16, 2011 3:48 pm, 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. 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).
>
> 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.
>
> Thanks,
>
> Alex
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant



More information about the gnucash-devel mailing list