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

Tue May 26 10:54:42 EDT 2009

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

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