Search options for Number field treat it as a string, not a number

Michael Hendry hendry.michael at gmail.com
Sat May 11 18:55:47 EDT 2013


On 11 May 2013, at 19:02, Alex Aycinena <alex.aycinena at gmail.com> wrote:

>> 
>> Michael,
>> 
>> ---------- Forwarded message ----------
>> From: Michael Hendry <hendry.michael at gmail.com>
>> To: Fred.Bone at dial.pipex.com
>> Cc: gnucash-user at gnucash.org
>> Date: Sat, 11 May 2013 14:56:18 +0100
>> Subject: Re: Search options for Number field treat it as a string, not a
>> number
>> 
>> On 11 May 2013, at 14:13, Fred Bone <Fred.Bone at dial.pipex.com> wrote:
>> 
>>> On 10 May 2013 at 8:55, Michael Hendry said:
>>> 
>>> [...]
>>>> Can anyone suggest a more reliable way of determining the highest number
>>>> used in the Number field of any register?
>>> 
>>> Why doesn't sorting on the number field do what you need?
>>> 
>> 
>> 
>> Thanks, Fred.
>> 
>> I've found that the answer is to use the General Ledger - as suggested by
>> Derek Atkins.
>> 
>> I should perhaps have made it clear that I wanted to find the highest
>> number which has already been used - in any of the registers, not just the
>> one I'm about to use for an entry.
>> 
>> As I pointed out in my response to Derek's suggestion, this immediately
>> showed up a duplicate transaction number (my error), but also revealed a
>> problem in the use of the + sign to generate the next transaction number.
>> 
>> I'll need to do some experiments on this, but I think that GnuCash must
>> keep track of the last number used in a transaction in any given register -
>> it doesn't check all the numbers and find the largest one each time.
>> 
> 
> Each account keeps track of the latest number used in it's register and
> when the '+' is entered in the register when focus is in the 'num' field,
> it enters the next number, which you can then change if you want. This is
> strictly intended to be a data entry convenience for things like check
> numbers (since you can have multiple checking accounts, each with its own
> number sequence, it needs to be account based). When a new transaction in
> entered within a register, that number in the account is replaced by the
> one just entered to be incremented for the next transaction. These numbers
> are not system-wide, like your use case, but account specific. But since
> the field is just a string, you can enter anything useful to you, like your
> system-wide number scheme; it is just that you have to keep track of the
> nubers yourself.

Thanks, Alex - that falls in line with my observations.

The value incremented by 1 and placed in the "Num" column in any of the registers (including the General Ledger) when the + sign is pressed is the last Num entered directly through that register.

At the end of the reconciliation of a credit card register, GC offers to set up the payment of the balance from a bank account. If you accept that offer, although the General Ledger screen isn't opened, the transaction is effected through the General Ledger - any transaction number entered in the Number field increments the counter in the GL, not in the credit card's register.

I must say that I find it helpful to have a unique sequence number for every transaction - it makes it much easier to get back to the receipt or other source document for any given transaction, to identify duplicate transactions and to distinguish these from multiple transactions involving the same register and the same value.

It seems that this isn't a feature that anyone else wants, so I'll just have to keep my wits about me. Keeping the General Ledger tab available, sorted by Num, will make the process easier.

Michael

> 
>> 
>> In the screenshot, you'll see that transaction 117923 was a transaction
>> between my bank account and a credit card account. This was done at the end
>> of the last reconciliation of this account, and I suspect the General
>> Ledger is invoked for this transaction.
>> 
>> This would mean that as far as the General Ledger was concerned, the
>> highest transaction number used was 117923, and the + sign would move on to
>> 117924, ignoring subsequent transactions not posted through the General
>> Ledger.
>> 
>> Michael
>> 
>> 
>> 
> Alex
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.




More information about the gnucash-user mailing list