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

Tue May 26 11:27:59 EDT 2009

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]