[Fwd: Re: automatic progressive transaction id across accounts]

Derek Atkins warlord at MIT.EDU
Tue May 26 15:05:50 EDT 2009

It's the Invoice # on Invoice transactions in A/R, A/P
It's the Check Number for checking accounts

Basically, the field is already being used for other things by other people,
so suggesting it as the recipient of a globally automated numbering system
is a Bad Idea.


Quoting Havard Rast Blok <nn2 at hblok.net>:

> Hi Derek,
> How would you define the difference between this transaction/receipt 
> number, and the "Num" field then? On the face of it, I think it looks 
> like a good match? What other usage is the Num field dedicated to?
> Regards,
> Havard
> Derek Atkins wrote:
>> No, the Num field is not where you should be putting this.  That field
>> already has a purpose.  You will need to create a new column/field and
>> use that for the (optional) TxnID.  Most of the work will be in the UI
>> to add the field to the register.  Adding it to the Txn is pretty
>> straightforward.  I would suggest storing it in the KVP-frame.
>> You'll need to get into the C to do all this.
>> For a counter example look at the invoice code for the Invoice ID.
>> -derek
>> Quoting paolo palmerini <paolo at palmerini.org>:
>>> dear derek,
>>> i just need a number. but i do not know how to implement the counter ...
>>> i guess i would have to modify the code which deals with entering 
>>> new transactions. before a new transaction is entered, a global 
>>> counter is incremented and assigned to the  "Num" field. if you 
>>> have any other suggestion this would help a lot.
>>> thank you in advance.
>>> p.
>>> On 26/05/2009 16.54, Derek Atkins wrote:
>>>> If you JUST want a number then you can just use a standard counter,
>>>> which is pretty easy to do.  However if you want more than just a number
>>>> and require some other auto-increasing form then we do not have a native
>>>> type to do that and the coding will be MUCH harder.
>>>> -derek
>>>> paolo palmerini <paolo at palmerini.org> writes:
>>>>> dear all,
>>>>> i am forwarding to the devel list a message that i posted on the user
>>>>> list regarding an apparently missing "feature" that i would like to
>>>>> add at least as an option in gnucash: automatic transaction numbering.
>>>>> before i start digging into the code, is there anybody out there that
>>>>> has already thought of something similar? any hints on where to start
>>>>> from? any idea or suggestion at all?
>>>>> as usual, any help is more than appreciated.
>>>>> thanks in advance to everyone,
>>>>> p.
>>>>> -------- Original Message --------
>>>>> Subject:     Re: automatic progressive transaction id across accounts
>>>>> Date:     Mon, 25 May 2009 06:00:35 +0200
>>>>> From:     Havard Rast Blok <nn2 at hblok.net>
>>>>> To:     paolo palmerini <paolo at palmerini.org>
>>>>> CC:     Yawar Amin <yawar.amin at gmail.com>, gnucash-user at gnucash.org
>>>>> References:     <4A164D8D.5070605 at palmerini.org>
>>>>> <efc7f7d00905231035y18016fb6q96eab73fe6909b43 at mail.gmail.com>
>>>>> <4A19A9D2.2090401 at hblok.net> <4A19D026.5050408 at palmerini.org>
>>>>> Hi Paolo,
>>>>> Sure, I'd like to help out. Will you start a thread on the dev-list?
>>>>> Havard
>>>>> paolo palmerini wrote:
>>>>>> Dear all,
>>>>>> havard is absolutely right regarding the interpretation of what i need.
>>>>>> thanks for putting it clearer than i did ;-)
>>>>>> actually , with respect to the list below, i would say that everything
>>>>>> but the last two are strict requirements in my case.
>>>>>> since it does not seem to be a "natural" feature of gnucash, maybe we
>>>>>> should move this discussion to the developers list in order to start
>>>>>> thinking of if and how to start doing it. not sure that i will manage,
>>>>>> though... let's see.
>>>>>> thanks for the support havard. if you are still in we can try to
>>>>>> coordinate our efforts.
>>>>>> p.
>>>>>> On 05/24/2009 10:10 PM, Havard Rast Blok wrote:
>>>>>>> Hi again,
>>>>>>> Although I'm not 100% about Paolo's usage, I can imagine that a 32
>>>>>>> byte "random" string is not quite what he had in mind.
>>>>>>> For my own business accounting, every single transaction has to be
>>>>>>> backed by a physical receipt. To easily search and identify the pile
>>>>>>> of papers which quickly accumulate, each receipt is numbered, from 1
>>>>>>> and up. The link between the papers and the accounting system is this
>>>>>>> number. In other systems, this number is auto-incremented for each new
>>>>>>> transaction.
>>>>>>> From my point of view, the requirements for this ID would be:
>>>>>>> - Auto-increment for each new transaction.
>>>>>>> - IDs of previously typed transactions should not be altered.
>>>>>>> - +1 increment should continue even if a new transaction is back-dated
>>>>>>> to a date before a transaction with a lower ID.
>>>>>>> - There should be a user defined starting ID.
>>>>>>> - Padded zero's should be respected, e.g. 0001, or 09001.
>>>>>>> - Based on what Paolo mentioned, there might also be a requirement to
>>>>>>> define a more complex ID, i.e. based on country, department, etc:
>>>>>>> UK-HR-2009-0001.
>>>>>>> Regards,
>>>>>>> Havard
>>>>>>> Yawar Amin wrote:
>>>>>>>> Hi Paolo,
>>>>>>>> I can confirm that every transaction in Gnucash has a unique 
>>>>>>>> ID. In fact
>>>>>>>> most entities inside a Gnucash file--accounts, transactions, splits,
>>>>>>>> currencies--have unique IDs. These are 32-character GUIDs, or globally
>>>>>>>> unique identifiers, where each character is a digit in the hexadecimal
>>>>>>>> radix. In short, you're pretty much guaranteed that every 
>>>>>>>> transaction in
>>>>>>>> every Gnucash file in the world has a unique ID. However, I 
>>>>>>>> don't think
>>>>>>>> these IDs are incremented one by one when new transactions are added.
>>>>>>>> So you
>>>>>>>> can't do certain things, like calculate how many transactions 
>>>>>>>> there are
>>>>>>>> between any two given transactions.
>>>>>>>> Having said that, I think the transaction GUID should satisfy 
>>>>>>>> your admin
>>>>>>>> dept. Of course, these IDs aren't visible in the Gnucash user 
>>>>>>>> interface.
>>>>>>>> You'll need to open up the XML file to examine them, or have a
>>>>>>>> program/script written which does that.
>>>>>>>> HTH,
>>>>>>>> Yawar
>>>>>>>> On Fri, May 22, 2009 at 3:00 AM, paolo palmerini
>>>>>>>> <paolo at palmerini.org>wrote:
>>>>>>>>> dear all,
>>>>>>>>> i am a new gnucash user and i am trying to promote the wide scale
>>>>>>>>> adoption of gnucash within my NGO,  working in about 10 different
>>>>>>>>> countries with different languages and currencies. gnucash 
>>>>>>>>> seems to be
>>>>>>>>> the right software to manage our accounts but still there are 
>>>>>>>>> a couple
>>>>>>>>> of issues that limit its unconditional adoption.
>>>>>>>>> the first and most important requirement coming from my organisation
>>>>>>>>> admin department is the possibility of automatic numbering of
>>>>>>>>> transactions across different accounts within the same gnucash file.
>>>>>>>>> from what i understand, at present gnucash provides a "num" field for
>>>>>>>>> each transaction that can be manually filled by the user and can
>>>>>>>>> be automatically incremented within the same account typing the
>>>>>>>>> "+" key on it. however, the system does not prevent from assigning
>>>>>>>>> twice
>>>>>>>>> the same number to different transactions within the same account or
>>>>>>>>> across different accounts.
>>>>>>>>> my question is: is there a simple way to achieve this automatic
>>>>>>>>> progressive numbering (with the possibility of resetting the 
>>>>>>>>> numbering
>>>>>>>>> every year?). if not, where in the code would one have to put his/her
>>>>>>>>> hands to add this feature?
>>>>>>>>> last question: am i the only one with such requirement? is there
>>>>>>>>> another
>>>>>>>>> way to get a unique transaction id?
>>>>>>>>> thanks for any help,
>>>>>>>>> p.
>>> -- 
>>> me, myself... [http://www.palmerini.org]
>>> ...and my podcast
>>> [http://www.palmerini.org/podkasbaht]

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list