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

Tue May 26 11:38:25 EDT 2009

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