Adding a 'number' field to splits

[Alex Aycinena]

Derek

On Fri, Sep 16, 2011 at 1:02 PM, Derek Atkins <derek at ihtfp.com> wrote:
> The current transaction number is designed to be the "Check Number".

I'm aware that that is the case now, but I want to provide the option
to use the new field for that purpose instead. How the fields are used
is a matter of a user's work practices. Those who want to continue to
use the systems as they do now don't have to change anything.

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

This would still be possible - see below.

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

Suppose you buy a car using a check from one account as part of your
down payment, a check from a second account as the rest of the down
payment, you take out a loan for the remainder, and you pay some car
registration expenses. Today you have to artificially break this down
into two transactions so that each one has a check number and you
spread the other parts of the transaction across the two. With the new
field you would put the first check number with the first split, the
second with the second, perhaps a loan number with the third, an asset
number for the fourth (the car), and leave the field blank for the
expense, depending on your personal work practices. If you want to see
the check number(s) from the expense register, you simply look at the
numbers on the splits and see two check numbers in this case. You can
use the transaction-level number for something else or leave it blank.

Granted that with your run-of-the-mill two line entry (dr. expense,
cr. checking), the current system is just fine. This just provides
more flexibility.

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

See above - has nothing to do with this.


>
> -derek
>


Alex