Re: Feature request from German list: Disable editing of transactions
Am Freitag, 15. Februar 2008 23:50 schrieb Graham Leggett: > > a gnucash mode of operation > > where the user can not edit older transactions anymore > > You would definitely want to set this per account, because some accounts > in gnucash are authoritative (eg accounts dealing with the issuing of > invoices), but other accounts track some external account source, such > as a bank account. It would be pretty useless if you were prevented from > correcting errors while reconciling a bank account. Makes sense, but do you have any ideas how such a per-account setting can be implemented in the GUI? Currently, all per-account settings can be set in the "Edit Account" dialog. However, a setting "Make this an inalterable account" shouldn't be allowed to be disabled again in the GUI, as this would make the whole setting moot. Do you think the "Edit Account" dialog should get a button to enable that behaviour? Or do you think this should somehow show up in the "Create New File" wizard? Both would require GUI actions of a kind that are not yet implemented there. Also, from an implementation point of view it's not clear to me which kind of editing should be allowed for transactions that contain one split in an inalterable account and another one in an editable account. Some fields like the transaction date are a per-transaction field (as opposed to per-split) - should those fields be allowed to be edited or not? Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Am Sat, 16 Feb 2008 09:18:03 +0100 schrieb Christian Stimming <[EMAIL PROTECTED]>: > Makes sense, but do you have any ideas how such a per-account setting > can be implemented in the GUI? Currently, all per-account settings > can be set in the "Edit Account" dialog. However, a setting "Make > this an inalterable account" shouldn't be allowed to be disabled > again in the GUI, as this would make the whole setting moot. Do you > think the "Edit Account" dialog should get a button to enable that > behaviour? Or do you think this should somehow show up in the "Create > New File" wizard? Both would require GUI actions of a kind that are > not yet implemented there. Create New file wizard. Its very unlikely that people want to change this behaviour - and I wouldnt call it unalterable. I think the difference is that every editing must be displayed and be formally correct. its more that that entries that are made shouldnt be removable How this is solved under the hood is another question. > Also, from an implementation point of view it's not clear to me which > kind of editing should be allowed for transactions that contain one > split in an inalterable account and another one in an editable > account. Some fields like the transaction date are a per-transaction > field (as opposed to per-split) - should those fields be allowed to > be edited or not? I think from the acounting perspective every entry consists on som field like the date, the accounts, some text,... I also dont think a mix of inalterable accounts and alterable accounts makes much sense because every entry has two ends, so if one end is inalterable the other one has to be, too. I have the strong feeling that different views would help. So that one can look at all without correcting entries. My guess is that it would be better if all new files where made in the same way but that the view could be changed (default view / strict accounting view or so). Thilo -- PfennigSolutions - IT-Beratung- Wiki-Systeme c/o Thilo Pfennig - Sandkrug 28 - 24143 Kiel http://www.pfennigsolutions.de/ XING-Profil: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn profile: http://www.linkedin.com/profile?viewProfile=&key=3896641 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GnuCash Localizations
Hi, I have thought a bit about some problems with standard form of accounts and localization in general. GnuCash is one of the applications where localization is more than just translating the interface - or potentially it could. On the german side much work went into SKR03/04 standard form of accounts and I am sure nearly every country in the world will have its own standards. I think one problem we have now is that many things are not right to core GnuCash development - and also that sometimes one local part makes a bug progress, while GnuCash itself hasnt changed much and maybe does not see a new release soon (like it just had a new release). So my idea or question is if it wouldnt be a good thing to split up the repository. So for example there is one core GnuCash module - and that this is what people get as a gnucash.tar.gz, while they would have to install other packages to get what makes sense for them. For example one could have something like gnucash-germany which could have dependecy to (certainly) GnuCash core, but also to some accounting methods or features. This could shrink the core GnuCash archive to some extend, only allowing a rather simple accounting maybe. I would hope that this could allow a development of different modules at different paces. Another option would be to have the ability to download things like standard form of accounts, so people could update them themselves - rather having them installed into the users $HOME directory than system wide - and be able to import them via GnuCash. What du you think? Thilo -- PfennigSolutions - IT-Beratung- Wiki-Systeme c/o Thilo Pfennig - Sandkrug 28 - 24143 Kiel http://www.pfennigsolutions.de/ XING-Profil: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn profile: http://www.linkedin.com/profile?viewProfile=&key=3896641 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash Localizations
Am Samstag, 16. Februar 2008 11:25 schrieb Thilo Pfennig: > GnuCash is one of the > applications where localization is more than just translating the > interface - or potentially it could. Yes. On the other hand I think this has been handled in the gnucash core distribution just fine. Language teams that wanted to submit more than "just" a translation have very much the possibility to do so: In addition to the normal translations, the gnucash core repository accepts account templates, the documentation translation, even locale-dependent features (like the --enable-locale-specific-tax, as broken as it might be, but at least it is possible). I think from a technical point of view enough options are offered. > So my idea or question is if it wouldnt be a good thing to split up the > repository. So for example there is one core GnuCash module - and that > this is what people get as a gnucash.tar.gz, while they would have to > install other packages to get what makes sense for them. For example > one could have something like gnucash-germany which could have > dependecy to (certainly) GnuCash core, but also to some accounting > methods or features. I'm sorry, but I disagree here. I don't think it is a good idea to split up the repository. As I said above, IMHO the infrastructure already exists for many different levels of localizations. IMHO it is merely an issue of country / localization contributors - we don't have more localization because no further contributors are there. Encouraging another form of "splitting up" for third-party "downstream modules" IMHO would give you almost no benefit here, whereas you immediately get a whole bunch of drawbacks. To mention a few: API synchronization issues, requirements of handling more than one translation domain (which will be a pain in the backside in libglade), different levels of code auditing and proof-reading, much less cross-platform testing for the downstream modules, etc. etc. Nevertheless, this is GPL software and we already have a plugin system up and running, hence nobody is hindering anyone to offer a "gnucash plus my preferred localization extensions" to the public. But speaking as a gnucash core developer, I can't see how a repository organization different from our current one would give anyone any noticable gain in terms of localization features. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Christian Stimming wrote: Makes sense, but do you have any ideas how such a per-account setting can be implemented in the GUI? Currently, all per-account settings can be set in the "Edit Account" dialog. However, a setting "Make this an inalterable account" shouldn't be allowed to be disabled again in the GUI, as this would make the whole setting moot. Do you think the "Edit Account" dialog should get a button to enable that behaviour? Or do you think this should somehow show up in the "Create New File" wizard? Both would require GUI actions of a kind that are not yet implemented there. This starts gnucash down the road of having the concept of users, and users having some kind of access level. For example the admin user can log in, and set these kinds of parameters, while a normal user cannot. This isn't a bad thing, but do we want to bite off and chew on so much of the problem at once? There are other parameters other than a lock-date that you would also need to protect from modification, such as the currency of the account, and other metadata. Also, from an implementation point of view it's not clear to me which kind of editing should be allowed for transactions that contain one split in an inalterable account and another one in an editable account. Some fields like the transaction date are a per-transaction field (as opposed to per-split) - should those fields be allowed to be edited or not? I'd say any split in an unalterable account should be unalterable, while any split in an alterable account should remain alterable. For example, if you raise an invoice, you end up with splits in "income - sales" (unalterable), and "accounts receivable" (alterable). The transaction has to balance to zero, otherwise the edit won't be allowed to complete. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Thilo Pfennig wrote: I think from the acounting perspective every entry consists on som field like the date, the accounts, some text,... I also dont think a mix of inalterable accounts and alterable accounts makes much sense because every entry has two ends, so if one end is inalterable the other one has to be, too. This isn't true - each entry can have more than two ends in the form of splits, the only requirement is that all the splits add up to zero. An example of where one split remaining alterable becomes important is when one side of the split goes to "income - sales" (for example), and the other side goes to "bank account". Gnucash isn't the authoritative source for bank account information (the bank is) and therefore it should remain editable until the bank statement is reconciled, but gnucash is the authoritative source for sales. So it must remain possible to allocate the bank split to say "petty cash" or "overs and unders" if a mistake was found. Of course if the end user wanted gnucash to treat the bank account as uneditable, nothing stops the user from locking both the bank account and the sales account. I have the strong feeling that different views would help. So that one can look at all without correcting entries. My guess is that it would be better if all new files where made in the same way but that the view could be changed (default view / strict accounting view or so). I designed a system for an insurance company that worked somewhat like this. Any invoice they raised could be corrected, but this was implemented by automatically reversing out the old entry, and creating a new one. The reversal and the original entry reversed were linked together. This allowed them to view their accounts minus the reversals, while their auditors would view the accounts with the reversals and so have full visibility of what happened. To implement this, you would just need to provide a right-click menu option "reverse this transaction", which would add a mirrored version of the transaction for you. This wouldn't be a solution for everyone though, I certainly wouldn't want that on any accounts I was not authoritative for. Keeping it configurable would be important. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Hi, I'll just chime in with some of my personal findings and observations. Most of this based on my personal experience and may not be valid for everyone. But I thought different insights might be useful to get a complete picture. On Saturday 16 February 2008, Graham Leggett wrote: > An example of where one split remaining alterable becomes important is > when one side of the split goes to "income - sales" (for example), and > the other side goes to "bank account". Gnucash isn't the authoritative > source for bank account information (the bank is) and therefore it > should remain editable until the bank statement is reconciled, but > gnucash is the authoritative source for sales. So it must remain > possible to allocate the bank split to say "petty cash" or "overs and > unders" if a mistake was found. > Graham's comment on bank reconciliation makes me wonder wether this new feature request isn't some kind of variation on reconciliation ? I used to get a warning when I tried ot modify a reconciled transaction with the option to allow the change or not. To my confusion, this doesn't seem to work anymore in version 2.2.1 on Mandriva. Maybe this has changed ? But a similar method could be used to completely disable editing on a per account basis. In another accounting program I'm using (commercial, windows-only program for the Belgian accounting market), disabling the editing of transactions is a user initiated action: after entering a number of transactions, and verifying them, a user can choose an option "doorboeken" which I would translate as "book through". From that point on, these transactions are no longer editable, the "book through" action is irreversible. But allowing the user to initiate the action, provides room to fix human errors (mistyping a number, or posting to a wrong account). It is perfectly normal to make such mistakes, and correcting them doesn't fall in the category of "tampering". It makes sense to only disable the editing after the entries have been verified. In the other accounting program, we usually do the final "booking through" only quarterly, after having verified all inputs and just before printing the official VAT/tax reports. In this particular program, the transactions are grouped in accounting periods (configurable as either months or quarters). When choosing "book through" you select for which accounting period you wish to perform this. Although the "booked through" transactions can't be edited, it's still possible to add new transactions in the same accounting period. This allows for midperiod analysis on data that is verified, while later on still entering new transactions in the period. Although not part of the original request, I would really like to see this concept of accounting periods in GnuCash as well. It's a concept required by Belgian law (we have quarterly or monthly VAT declarations) and it helps in dealing with some other difficult cases as well, like for example booking a forgotten bill from a previous VAT period. Regardless of this, using a set date to disable editing of transactions shouldn't prevent new transactions to be entered before that date, like for example a forgotten invoice. Assuming the feature is user-enabled, it should also be enabled separately per account. In my typical scenario, I enter invoices and bills earlier than I enter bank account information. So I would disable editing on invoices and bills earlier than I would on bank accounts. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Perhaps this should get tied into the book closing clode? When you close the books on a period, all the transactions in that period become uneditable? We DO have the ability to mark a transaction specifically as read-only. It wouldn't be too hard to also mark the txns as read-only as we process them for the book closing. -derek Quoting Geert Janssens <[EMAIL PROTECTED]>: > Hi, > > I'll just chime in with some of my personal findings and > observations. Most of > this based on my personal experience and may not be valid for everyone. But I > thought different insights might be useful to get a complete picture. > > On Saturday 16 February 2008, Graham Leggett wrote: >> An example of where one split remaining alterable becomes important is >> when one side of the split goes to "income - sales" (for example), and >> the other side goes to "bank account". Gnucash isn't the authoritative >> source for bank account information (the bank is) and therefore it >> should remain editable until the bank statement is reconciled, but >> gnucash is the authoritative source for sales. So it must remain >> possible to allocate the bank split to say "petty cash" or "overs and >> unders" if a mistake was found. >> > Graham's comment on bank reconciliation makes me wonder wether this new > feature request isn't some kind of variation on reconciliation ? > > I used to get a warning when I tried ot modify a reconciled transaction with > the option to allow the change or not. To my confusion, this doesn't seem to > work anymore in version 2.2.1 on Mandriva. Maybe this has changed ? But a > similar method could be used to completely disable editing on a per account > basis. > > In another accounting program I'm using (commercial, windows-only program for > the Belgian accounting market), disabling the editing of transactions is a > user initiated action: after entering a number of transactions, and verifying > them, a user can choose an option "doorboeken" which I would translate > as "book through". From that point on, these transactions are no longer > editable, the "book through" action is irreversible. But allowing the user to > initiate the action, provides room to fix human errors (mistyping a number, > or posting to a wrong account). It is perfectly normal to make such mistakes, > and correcting them doesn't fall in the category of "tampering". It makes > sense to only disable the editing after the entries have been verified. In > the other accounting program, we usually do the final "booking through" only > quarterly, after having verified all inputs and just before printing the > official VAT/tax reports. > > > In this particular program, the transactions are grouped in > accounting periods > (configurable as either months or quarters). When choosing "book through" you > select for which accounting period you wish to perform this. Although > the "booked through" transactions can't be edited, it's still possible to add > new transactions in the same accounting period. This allows for midperiod > analysis on data that is verified, while later on still entering new > transactions in the period. > > Although not part of the original request, I would really like to see this > concept of accounting periods in GnuCash as well. It's a concept required by > Belgian law (we have quarterly or monthly VAT declarations) and it helps in > dealing with some other difficult cases as well, like for example booking a > forgotten bill from a previous VAT period. > > > Regardless of this, using a set date to disable editing of transactions > shouldn't prevent new transactions to be entered before that date, like for > example a forgotten invoice. > > Assuming the feature is user-enabled, it should also be enabled > separately per > account. In my typical scenario, I enter invoices and bills earlier than I > enter bank account information. So I would disable editing on invoices and > bills earlier than I would on bank accounts. > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- 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 [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature request from German list: Disable editing of transactions
Am Sat, 16 Feb 2008 16:52:51 +0200 schrieb Graham Leggett <[EMAIL PROTECTED]>: > This isn't true - each entry can have more than two ends in the form > of splits, the only requirement is that all the splits add up to zero. ACK, I should rather have written "at least two ends". > Gnucash isn't the > authoritative source for bank account information (the bank is) and > therefore it should remain editable until the bank statement is > reconciled, Maybe this is a misunderstanding but what I mean is that if I make an entry into the account "bank" I think this should still be visible, because only if it wont there would be an error. I think oen should distinct the real bank account and the bank account in GnuCash. Sure these two should match, but for GnuCash the authorative one should be the GnuCash "bank" account, shouldnt it? If tentries are falshe the user should correct them but this should be visible. If they are just editable without being visible this would make all accounts that interact with bank alsio being editable, because only if one can check both accounts for correctness one is able to make a statement about the overall correctness of the book keeping. At least thats what I learned. Thilo -- PfennigSolutions - IT-Beratung- Wiki-Systeme c/o Thilo Pfennig - Sandkrug 28 - 24143 Kiel http://www.pfennigsolutions.de/ XING-Profil: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn profile: http://www.linkedin.com/profile?viewProfile=&key=3896641 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
stock exchanges
Hi, I found that there is a file src/engine/gnc-commodity.h, which contains some stock exchanges. Some are missing and they are hardcoded. My question or suggestion is: As the sources says that besides NASDAQ none yet has a real function, wouldnt it make sense if the user would be able to add new places? Thilo -- PfennigSolutions - IT-Beratung- Wiki-Systeme c/o Thilo Pfennig - Sandkrug 28 - 24143 Kiel http://www.pfennigsolutions.de/ XING-Profil: https://www.xing.com/profile/Thilo_Pfennig - LinkedIn profile: http://www.linkedin.com/profile?viewProfile=&key=3896641 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: gnucash-devel Digest, Vol 59, Issue 20
On Saturday 16 February 2008, Geert Janssens wrote:> > Hi,> > I'll just chime in with some of my personal findings and observations. Most of > this based on my personal experience and may not be valid for everyone. But I > thought different insights might be useful to get a complete picture.> > On Saturday 16 February 2008, Graham Leggett wrote:> > An example of where one split remaining alterable becomes important is> > when one side of the split goes to "income - sales" (for example), and> > the other side goes to "bank account". Gnucash isn't the authoritative> > source for bank account information (the bank is) and therefore it> > should remain editable until the bank statement is reconciled, but> > gnucash is the authoritative source for sales. So it must remain> > possible to allocate the bank split to say "petty cash" or "overs and> > unders" if a mistake was found.> >> Graham's comment on bank reconciliation makes me wonder wether this new > feature request isn't som! e kind of variation on reconciliation ?> > I used to get a warning when I tried ot modify a reconciled transaction with > the option to allow the change or not. To my confusion, this doesn't seem to > work anymore in version 2.2.1 on Mandriva. Maybe this has changed ? But a > similar method could be used to completely disable editing on a per account > basis.> > In another accounting program I'm using (commercial, windows-only program for > the Belgian accounting market), disabling the editing of transactions is a > user initiated action: after entering a number of transactions, and verifying > them, a user can choose an option "doorboeken" which I would translate > as "book through". From that point on, these transactions are no longer > editable, the "book through" action is irreversible. But allowing the user to > initiate the action, provides room to fix human errors (mistyping a number, > or posting to a wrong account). It is perfectly normal to make such mistakes, > a! nd correcting them doesn't fall in the category of "tampering". It mak es > sense to only disable the editing after the entries have been verified. In > the other accounting program, we usually do the final "booking through" only > quarterly, after having verified all inputs and just before printing the > official VAT/tax reports.> > > In this particular program, the transactions are grouped in accounting periods > (configurable as either months or quarters). When choosing "book through" you > select for which accounting period you wish to perform this. Although > the "booked through" transactions can't be edited, it's still possible to add > new transactions in the same accounting period. This allows for midperiod > analysis on data that is verified, while later on still entering new > transactions in the period.> > Although not part of the original request, I would really like to see this > concept of accounting periods in GnuCash as well. It's a concept required by > Belgian law (we have quarterly or monthly VAT declarations) and i! t helps in > dealing with some other difficult cases as well, like for example booking a > forgotten bill from a previous VAT period.> > > Regardless of this, using a set date to disable editing of transactions > shouldn't prevent new transactions to be entered before that date, like for > example a forgotten invoice.> > Assuming the feature is user-enabled, it should also be enabled separately per > account. In my typical scenario, I enter invoices and bills earlier than I > enter bank account information. So I would disable editing on invoices and > bills earlier than I would on bank accounts.> I think there is some confusion in the discussion about the requirements - I took it to be that there be an unalterable (by the application user, not the systems administrator) audit trail. The discussion reminds me of the days when people kept manual checkbook registers. A "non-accountant" person might write the entries in in pencil and if they ever made a mistake on an entry, simply erase the error and, if necessary, recalculate the balance from that point forward making it "look" like the error had never happened in the first place. An "accountant", however, would always write the entries in in ink and, if an error occurred, write a new "adjusting" entry on the date the error was discovered to get the balance right and annotate the original entry to point to the adjusting entry. That way a full audit trail of what happened would be preserved and when the checkbook was reconciled to the bank statement, the two entries (the original entry and its adjustment) would be treated together to match the bank's item. The trouble is that gnucash looks like the "non-accountant" person writing in pencil - the transaction shown in a register is the "latest version" of the entry which may have been changed many times with no audit trail of the changes. It may be tempting to change gnucas
www.gnucash.org mirror
Hi, just want to mention that I have now set up the mirror at gnucash.alternativ.net. Question: It was mentioned that I could trigger an update when needed. If so, How? Anything that needs fixing? Thilo -- PfennigSolutions - IT-Beratung- Wiki-Systeme c/o Thilo Pfennig - Sandkrug 28 - 24143 Kiel http://www.pfennigsolutions.de/ XING: https://www.xing.com/profile/Thilo_Pfennig LinkedIn: http://www.linkedin.com/in/tpfennig ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
