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

Tue May 26 15:57:52 EDT 2009

Got it. Thanks for clarifying.

Havard

Derek Atkins wrote:
> 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.
> 
> -derek
> 
> 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]
>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
> 