[GNC] GnuCash and Swedish accounting legislation

[doncram]

Yeah, this is a sore point which has been running for years, and indeed
should be written up nicely somehow.  Basically it needs to be said that
accountant type persons need to understand that there is an anti-accounting
vibe in the GnuCash community, which is objectively an insulting, arrogant,
unyielding strain.  Which they will have to ignore or work around. Or maybe
it means that GnuCash cannot be used for their nonprofit or small business.

/* begin rant
Prospective users of GnuCash, new users, old users, should not be subjected
to ... this crap, to put it politely.  Really I do have great respect for
the computer programmers who have developed GnuCash and who support it,
including by participating on this list, but I think it still needs to be
said: the computer programmer types, or at least the effective collection
of them if not every one individually, are being real jerks.  They are
willfully ignorant of how real organizations work, of real requirements of
individual GnuCash users or would-be users, in this area.  They seem to
refuse to understand, repeatedly.  Just because they know they can easily
break a password, and they think the accountant types are so ignorant that
the accountant types do not understand that.  They think that is the key
point, when it is not.

What part of the following do u not understand: a) "it is really necessary
for me, to have one sensible control (like a speed bump "do you really want
to?")  which pauses me before I edit a transaction 90 days old or older",
and b) "it is really necessary for me, to have a further stronger control
which stops me from changing a transaction in the closed last year's
books".  That's enough, but further, there is c) some such controls (maybe
not exactly a and b) are even required by law in Sweden (kudos to the
sensible government there), and are sensible requirements to be imposed
upon any organization in its software choice. Please believe me, I can zoom
through the first control without thinking.  I really really need to be
stopped, for closed year items, by the second control.  I want to be
stopped.  Further, any software program which does not perform these simple
tasks, is stupid, and is marking itself as unsuitable for use.  Even if I
personally like GnuCash and want to use it, the totally unprofessional
nature of the combination (software, its documentation, and support
discussion) may well rule it out as a choice for me for my organization,
because others can easily find proof of how unprofessional, inadequate it
is.  It would hurt my reputation to try to defend use of this.  I likely
cannot recommend its use to others, who would not in fact adopt it and
would think poorly of me.

It is arrogant of computer programmer types to say the requirements a and b
are silly.  They ignorantly think the only purpose of "freezing" is to
completely absolutely stop computer programmers.   You probably think this
song is about you.  No, stopping me myself is one big purpose, the software
needs to help me in this.  And also, the act of freezing is helpful for
drawing a line between okay behavior and fraudulent behavior.  If a
Treasurer goes back into prior year, after it is closed, and makes a
non-obvious change, like any change not documented by a journal entry
approval form requiring one or two more signatures, then they are probably
performing some kind of fraud.  They could not do that accidentally, due to
the password control b.  If they did it, which might be detected and proven
by an audit or by a good board member who took a copy of the closed
end-of-year books, then they probably should be fired and should be
distrusted in all other matters.  Computer programmer dude, if you were in
such an organization, you would think u r so smart and u might dabble in
the closed books, just to make some dumb point, or maybe to commit fraud.
And you could well be caught, and fired, and prosecuted because u r not so
smart after all.

End rant. */

I hope this doesn't offend anyone, I honestly really do respect the
computer programmers, even the ones who are stuck on this point, I guess it
is sort of understandable.  And it is possible/likely that there are some
parts of what the computer programmers are saying which are true but not
understood by me.  However if there is such out there, it is lost in
failure of communication.  I hope this is actually helpful, instead.

--Don

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Aug 11, 2020 at 10:24 AM Fred Bone <fjpbone at gmail.com> wrote:

> On 11 August 2020 at 20:14, elvis said:
>
> > If you want a fixed date burn a cd or use other ways of verifying the
> > files like md5sum
> >
> >
> > All of this fixed date stuff is just security theatre if you can access
> > the source and pretty much the same even if you can't.
>
> There seems to be a fair amount of talking at cross purposes.
> There are (at least) two reasons for wanting to "lock" against
> changing txns before some specified date:
> 1. To freeze the file for audit/regulatory purposes
> 2. To prevent accidental unwanted "backdating" of changes
> Gnucash's mechanism is well suited to (2) but completely useless for
> (1). Conversely, your suggestion is well suited to (1) but completely
> useless for (2).
> This whole discussion rears its ugly head at (ir-)regular intervals
> and perhaps should be in a FAQ document somewhere.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at 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.
>