RE: C Compiler Question
Thanks, Christian! Just what I was hoping to find out. Much appreciated! Tom -Original Message- From: Christian Stimming [mailto:stimm...@tuhh.de] Sent: Sunday, May 24, 2009 9:00 AM To: gnucash-devel@gnucash.org; Thomas Bullock Subject: Re: C Compiler Question Am Sonntag, 24. Mai 2009 14:38 schrieb Tom Bullock: I don't have access to a C compiler at work. So I want to download a free compiler at home. Since currently all I run at home is Windows XP, would I still be able to use the gcc compiler in that operating system, Yes. Gnucash on Windows compiles with gcc and there is a gcc on Windows available (in the MinGW package). Just follow the instructions on http://wiki.gnucash.org/wiki/Windows and after the script there has finished you will have the free gcc compiler installed on your Windows XP as well. Christian or would I first have to set up a linux environment in order to use that? If I had to use linux for gcc, what compiler should I use as long as I am using Windows XP? TIA. Tom ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scheduled Transactions as Unscheduled Templates
How do you plan to change the XML-schema? On Mon, 25 May 2009 21:42:16 +0200, Havard Rast Blok n...@hblok.net wrote: Hi Marcus, Well, here's my first simple, but perhaps naive, suggestion: In the current Frequency tab of the Edit Scheduled Transaction window, add an entry to the list of Frequencies: Never. The rest of the UI in that tab would then be disabled (gray?). To recall the template, use the current auto-complete functionality for previous transactions. If the new Description auto-completes and matches a template, bring up the window Since Last run... to enter the custom fields. (Might want to rename the title of that window, though.) What do you think? Too simple? Confusing? Or worth a try? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: automatic progressive transaction id across accounts]
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 pa...@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 pa...@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 n...@hblok.net To: paolo palmerini pa...@palmerini.org CC: Yawar Amin yawar.a...@gmail.com, gnucash-u...@gnucash.org References: 4a164d8d.5070...@palmerini.org efc7f7d00905231035y18016fb6q96eab73fe6909...@mail.gmail.com 4a19a9d2.2090...@hblok.net 4a19d026.5050...@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 pa...@palmerini.orgwrote: dear all, i am a new gnucash user and i am
Re: [Fwd: Re: automatic progressive transaction id across accounts]
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 pa...@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 n...@hblok.net To: paolo palmerini pa...@palmerini.org CC: Yawar Amin yawar.a...@gmail.com, gnucash-u...@gnucash.org References: 4a164d8d.5070...@palmerini.org efc7f7d00905231035y18016fb6q96eab73fe6909...@mail.gmail.com 4a19a9d2.2090...@hblok.net 4a19d026.5050...@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 pa...@palmerini.orgwrote: 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
Re: [Fwd: Re: automatic progressive transaction id across accounts]
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 pa...@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 n...@hblok.net To: paolo palmerini pa...@palmerini.org CC: Yawar Amin yawar.a...@gmail.com, gnucash-u...@gnucash.org References: 4a164d8d.5070...@palmerini.org efc7f7d00905231035y18016fb6q96eab73fe6909...@mail.gmail.com 4a19a9d2.2090...@hblok.net 4a19d026.5050...@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 pa...@palmerini.orgwrote: 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
Re: [Fwd: Re: automatic progressive transaction id across accounts]
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 pa...@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 pa...@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 n...@hblok.net To: paolo palmerini pa...@palmerini.org CC: Yawar Amin yawar.a...@gmail.com, gnucash-u...@gnucash.org References: 4a164d8d.5070...@palmerini.org efc7f7d00905231035y18016fb6q96eab73fe6909...@mail.gmail.com 4a19a9d2.2090...@hblok.net 4a19d026.5050...@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
Re: Scheduled Transactions as Unscheduled Templates
Hi again, I gave it another look now, and in fact, following on my previous suggestion, there is already a None frequency. In gnome/glade/sched-xact.glade, freq_combobox/items. Choosing this, currently gives a warning, which could be replaced by a message on how to recall it. However, somehow I think you were looking for something else for your scripting work? What did you have in mind? Regards, Havard marcus.wolsc...@googlemail.com wrote: How do you plan to change the XML-schema? On Mon, 25 May 2009 21:42:16 +0200, Havard Rast Blok n...@hblok.net wrote: Hi Marcus, Well, here's my first simple, but perhaps naive, suggestion: In the current Frequency tab of the Edit Scheduled Transaction window, add an entry to the list of Frequencies: Never. The rest of the UI in that tab would then be disabled (gray?). To recall the template, use the current auto-complete functionality for previous transactions. If the new Description auto-completes and matches a template, bring up the window Since Last run... to enter the custom fields. (Might want to rename the title of that window, though.) What do you think? Too simple? Confusing? Or worth a try? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: automatic progressive transaction id across accounts]
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 n...@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 pa...@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 pa...@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 n...@hblok.net To: paolo palmerini pa...@palmerini.org CC: Yawar Amin yawar.a...@gmail.com, gnucash-u...@gnucash.org References: 4a164d8d.5070...@palmerini.org efc7f7d00905231035y18016fb6q96eab73fe6909...@mail.gmail.com 4a19a9d2.2090...@hblok.net 4a19d026.5050...@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
Re: [Fwd: Re: automatic progressive transaction id across accounts]
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 n...@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 pa...@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 pa...@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 n...@hblok.net To: paolo palmerini pa...@palmerini.org CC: Yawar Amin yawar.a...@gmail.com, gnucash-u...@gnucash.org References: 4a164d8d.5070...@palmerini.org efc7f7d00905231035y18016fb6q96eab73fe6909...@mail.gmail.com 4a19a9d2.2090...@hblok.net 4a19d026.5050...@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
Re: Scheduled Transactions as Unscheduled Templates
Havard Rast Blok n...@hblok.net writes:
I recently sent out this on the user-list, however did not receive any
answers (only two, me too), so I thought I'd try here.
Original Message
Subject: Scheduled Transactions as Unscheduled Templates
Date: Mon, 18 May 2009 09:22:23 +0200
From: Havard Rast Blok n...@hblok.net
To: gnucash-u...@gnucash.org
Hi,
The automatic transaction history of GnuCash is one of my favourite
features, and scheduled transactions takes this one step further: now
only a single number is all it takes to complete a transaction.
However, not all reoccurring transactions follow a defined schedule.
Take paying for postage or stamps as an example: It happens frequently
with different amounts, but is usually not scheduled. When I need to
enter a transaction of this type, I'd still like the power of the
template functionality, though. Then I can type in only the gross
amount, and the rest (VAT, etc.) is filled out automatically.
I've browsed several threads, wiki and docs, but cannot find any way to
set up an unscheduled template. Is it worth a feature request?
It's been a feature request for a long time, though perhaps informally.
Havard Rast Blok n...@hblok.net writes:
Well, here's my first simple, but perhaps naive, suggestion:
In the current Frequency tab of the Edit Scheduled Transaction window,
add an entry to the list of Frequencies: Never. The rest of the UI in that
tab would then be disabled (gray?).
To recall the template, use the current auto-complete functionality for
previous transactions. If the new Description auto-completes and matches a
template, bring up the window Since Last run... to enter the custom
fields. (Might want to rename the title of that window, though.)
What do you think? Too simple? Confusing? Or worth a try?
Popping up a (new) dialog to solicit a set of named values from the
user, and then creating the relevant Transaction … is not hard. It's
probably easier than misusing the SX UI code to do so, actually.
I'd approach it from the other direction: you really want to promote the
existing implicit templates that auto-complete starts to surface into
a first-order, explicit UI concept. Forget about scheduled
transactions, and focus on the templating.
Maybe after you have it working where the template set is scheduled
transactions with frequency=none, you can improve it by making the
templates have their own identity … have a way in the UI to explicitly
CRUD named templates … separate storage in the data file, c.
Hooking into the autocomplete code to do what you want is not going to
be easy, I don't think. You might want an explicit Transaction
Create From Template, maybe which popups up a text entry which has
autocomplete over the available-template names.
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgpbohe2Pk0EI.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
eguile-based reports -- progress
Hello folks I have put an new improved version of the 'Tax Invoice' eguile-based report on the bugzilla page at http://bugzilla.gnome.org/show_bug.cgi?id=574582 The new version has been tidied up considerably. It now looks for the template part of the report in the user's .gnucash directory or in the gnucash/report directory. I've tested this on Ubuntu Linux and Windows Vista only, so I would be very grateful if someone could test it on other operating systems. It also uses the pixmap option routine to allow the user to choose a logo properly. For tax table columns, it still relies on bug fix 573645 which became part of trunk on 29 April and should be part of 2.3.0. Invoices that don't reference tax tables are fine without that fix. It works fine with 2.2.9, but has some enhancements when used with the Webkit branch -- i.e. the use of CSS styling, which it makes it look much nicer, and the user can choose font face and size. (The tax table fix isn't in the webkit branch yet though.) I hope it proves useful eventually. I've also been working on an eguile-based balance sheet report -- getting the columns to line up nicely is tricky... cheers Chris -- Chris Dennis cgden...@btinternet.com Fordingbridge, Hampshire, UK ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
