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

Havard Rast Blok nn2 at hblok.net
Tue May 26 14:52:32 EDT 2009


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


More information about the gnucash-devel mailing list