> -----Original Message----- > From: John Ralls <jra...@ceridwen.us> > Sent: den 9 augusti 2020 18:02 > To: bengt...@gmail.com > Cc: gnucash-user@gnucash.org > Subject: Re: [GNC] GnuCash and Swedish accounting legislation > > > > On Aug 9, 2020, at 2:25 AM, bengt...@gmail.com wrote: > > > > Would like to revive this old thread since the request made by the OP > > is still valid for us Swedish users (and maybe German users according > > to one post in the thread?). I wonder if there has been some > > development along making transactions "persistent" or read-only/locked/un- > changeable? > > > > In short the request was made since the Swedish accounting legislation > > requires transactions to be persistent, i.e. when entered into the > > ledger it shall not be possible to change it afterward (or rather, > > entering of the transaction is considered completed when it has been > > made persistent). To shortcut a long discussion about how silly this > > requirement is, because you can always change your transactions > > somehow by editing databases etc., we can postulate that it would be > > enough to fulfill this requirement if the transactions somehow was > > made read-only in an irreversible manner from the user interface. I.e. > > once a transaction is made read-only, it should not be possible to > > change it from the UI. ( I also understand that a differently compiled > > version of gnucash could import the data files and change the > > read-only transactions, but that would be ok also since the intention > > is not to fully secure a system against such changes, which is more or > > less impossible, but make it difficult for the ordinary user to change > transactions afterwards). > > > > Here is the last post in the old thread from 2016: > > > > --- > > On 2 February 2016 at 15:39, John Ralls > > <https://lists.gnucash.org/mailman/listinfo/gnucash-user> wrote: > >> > >>> On Feb 2, 2016, at 8:17 AM, Colin Law > > <https://lists.gnucash.org/mailman/listinfo/gnucash-user> wrote: > >>> > >>> On 18 January 2016 at 08:18, Draug > > <https://lists.gnucash.org/mailman/listinfo/gnucash-user> wrote: > >>>> Hi, > >>>> > >>>> For quite a while I've used GnuCash for the accounting of my > >>>> company, > > but > >>>> recently I've come to question if it's legal to use GnuCash for > >>>> that purpose. According to Swedish accounting legislation, you are > >>>> not > > allowed to > >>>> use accounting software that allows you to edit registered > >>>> transactions (where they use Excel as an example), which to my > >>>> knowledge is quite > > easy to > >>>> do in GnuCash, even after reconcilation. Swedish accounting > >>>> legislation requires that every mistake is corrected with another > >>>> transaction, and > > that > >>>> the mistake is left intact in the records. > >>>> > >>>> Is there anything that I've missed that makes it possible to use > >>>> GnuCash > > in > >>>> accordance with Swedish law? I really want to avoid switching to > >>>> some proprietary, cloud-based accounting software that costs $12 a > >>>> month to > > use. > >>> > >>> An email from Geert in a different thread has reminded me that there > >>> is already code that optionally makes reconciled transactions read > >>> only. I wonder then whether it would in fact be a fairly simple > >>> change to the code to make it so that /all/ transactions would be > >>> locked, dependent on a configuration option that could be set but not > cleared. > >>> > >> > >> Yes, the locking code is already in place-or more likely, in several > > places-so it would just take a creation option in the New File > > Assistant to make a book immediately lock transactions. Like the root > > account currency, it would be unchangeable once the book is created. > >> > >> I don't think we'd want it to be a config option because that would > > require either that users who want the feature build it themselves or > > that distros and we provide multiple packages. Building is beyond the > > ability of most of our target audience, particularly on Macs and > > Windows, and aside from the distros probably not wanting to cooperate > > there's a good chance that many users would accidentally get the build they > didn't want. > > > > Sloppy use of words on my part, I meant a setting rather than a build > > option, but a creation option would be even better. > > There's already such a facility: Select File>Properties and on the accounts tab set > Day threshold for read-only transactions to 1. That makes a transaction read- > only the day after it is entered. > > That's obviously trivial to defeat, as a bad user could easily change the setting, > edit stuff that they shouldn't, and then put the setting back. > > We've had some discussions about making certain properties settable only while > creating the book (principally the root currency). Perhaps this should be one of > them. > > It might work, and be even more secure, to use a SQL server (i.e. MySQL or > Postgresql) backend and after the first creation of the database create a new > role with only CREATE, INSERT, and SELECT privileges on the tables and have > users log in with that role. There would have to be an admin user with full access > in order to accomplish GnuCash upgrades as this sometimes involves altering or > recreating tables because of schema changes. > > On the other hand immutable transactions is only one of the controls usually > required of accounting software in a large enough organization that outside > auditors are involved and that sort of law applies. GnuCash has *none* of those > controls so this one feature is unlikely to make GnuCash an acceptable > alternative. GnuCash isn't designed for that environment and would have to be > rewritten from scratch to get there. That's not going to happen and it's why we > say that GnuCash is intended only for individuals and small businesses that aren't > subject to independent auditing. > > Regards, > John Ralls
Yes, the read-only day threshold (of 1) would be ideal for this purpose if it was a creation option of the book. Since the day threshold is configurable as described above, the feature is not usable for this purpose now. I put my vote for making such a creation option! I think this is what is needed in order to claim that GNC fulfills the Swedish book keeping requirements in this respect. Many answers here are based on the assumption that whatever we do in GNC there is always a way to change a transaction if you have the right SW skills. But I believe that this is not the problem the legislators try to address, since they also know that computer records can be changed given enough effort and skills. The point is, I believe is that the _there should be no way to change a transaction from within the program_. Compare with using ink for paper books, making it difficult (but not impossible) to change entered transactions. Using a SQL server and don't allow DELETE for transactions is probably a good idea also (and probably what is used in commercial packages for this purpose), but at least I would feel safe to use GNC with a persistent one day read-only threshold option. //Bengt _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
