Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-13 Thread doncram 
Okay, noted that my post with self-labelled rant was outside bounds
accepted by this community.  Just enclosing in "begin rant", "end rant"
doesn't change that.

What I did wrong included, at least, that I characterized two groups and
that I cast aspersions and applied negative adjectives, personalizing
stuff.  I can see that is not good behavior, and I do apologize.  I tried,
within the post, to mitigate what i did say, but that wasn't adequate, and
it wasn't funny.  I apologize especially to those I did offend, and I would
like to make amends if possible, if i come to know more particulars.

I was already on pause, wasn't going to comment any more that way, given
Jim DeLaHunt's prompt and constructive feedback, including his suggestion
to frame it differently, in terms of discussion about target users and
"scope of usage conditions" and more, which I needed to think about.  And
there was point made that this forum is far from being like many others on
the internet, and Jim commented on apparent arrogance and assumptions on my
part, which I really do need to think about.  Anyhow, I had let myself be
aggravated/frustrated by a couple references to the long-running nature of
disagreement, need for a FAQ about it, etc.  And I had thought it would be
okay to share a bald characterization of the situation/issue.  I dunno
about my completely being wrong to ever take such an approach, call it a
boisterous one, if this were some other forum, but it is not, and I realize
I basically don't have standing here to be that way at all.  So, I am
really sorry.  And thank you for considering this.  I am open to
off-email-list comments or suggestions, too.

sincerely, Don Cram


On Wed, Aug 12, 2020 at 3:10 AM Liz Dodd  wrote:

> On Tue, 11 Aug 2020 20:10:44 -0700
> Jim DeLaHunt  wrote:
>
> > First of all, if you think that the vibe in the GnuCash community is
> > "insulting, arrogant, unyielding"; if you think that the GnuCash
> > developers are "being real jerks", then you haven't seen nearly
> > enough of the Internet and of free software projects. The GnuCash
> > community is a respectful vacation resort compared to some projects
> > to which I contribute. The GnuCash developers are usually kind and
> > helpful, and at the very worst, sometimes a touch impatient with
> > requests they are unable to fulfill. The documentation is extensive
> > and at least somewhat helpful.
> >
> > And I see that you put in a little separation between the computer
> > programmers who developed GnuCash, and all those bad programmers, but
> > when you unload on "the effective collection of them" you unload on
> > all of them.
>
> Jim, and others, I do not approve of posts like doncram's which
> preceded this.
> As the Moderator I have intervened and will check future posts from
> doncram.
>
> Kindly note that I do not tolerate coarse language or disparaging
> others.
>
> Liz, Moderator Hat On.
> ___
> 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.
>
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-12 Thread Liz Dodd 
On Tue, 11 Aug 2020 20:10:44 -0700
Jim DeLaHunt  wrote:

> First of all, if you think that the vibe in the GnuCash community is 
> "insulting, arrogant, unyielding"; if you think that the GnuCash 
> developers are "being real jerks", then you haven't seen nearly
> enough of the Internet and of free software projects. The GnuCash
> community is a respectful vacation resort compared to some projects
> to which I contribute. The GnuCash developers are usually kind and
> helpful, and at the very worst, sometimes a touch impatient with
> requests they are unable to fulfill. The documentation is extensive
> and at least somewhat helpful.
> 
> And I see that you put in a little separation between the computer 
> programmers who developed GnuCash, and all those bad programmers, but 
> when you unload on "the effective collection of them" you unload on
> all of them.

Jim, and others, I do not approve of posts like doncram's which
preceded this.
As the Moderator I have intervened and will check future posts from
doncram.

Kindly note that I do not tolerate coarse language or disparaging
others.

Liz, Moderator Hat On.
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-11 Thread Jim DeLaHunt 

Don, Don, Don:

On 2020-08-11 12:36, doncram wrote:

… there is an anti-accounting vibe in the GnuCash community, which is
objectively an insulting, arrogant, unyielding strain.… the computer
programmers who have developed GnuCash and who support it… the computer
programmer types, or at least the effective collection of them if not
every one individually, are being real jerks.…


First of all, if you think that the vibe in the GnuCash community is 
"insulting, arrogant, unyielding"; if you think that the GnuCash 
developers are "being real jerks", then you haven't seen nearly enough 
of the Internet and of free software projects. The GnuCash community is 
a respectful vacation resort compared to some projects to which I 
contribute. The GnuCash developers are usually kind and helpful, and at 
the very worst, sometimes a touch impatient with requests they are 
unable to fulfill. The documentation is extensive and at least somewhat 
helpful.


And I see that you put in a little separation between the computer 
programmers who developed GnuCash, and all those bad programmers, but 
when you unload on "the effective collection of them" you unload on all 
of them.




… They are willfully ignorant of how real organizations work, of real
requirements of individual GnuCash users or would-be users, in this area.…
What part of the following do u not understand: a) [requirement 1 omitted],
and b) [requirement 2 omitted].  That's enough, but further, there is
c) [requirement 3 omitted] 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.…
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.…


I understand this is a rant, and rants can be fun, and fun things can go 
a bit too far. But do you see that you are sliding into self-parody 
here?  You probably think this song is about _you_.


How is it that you get to say the target user you imagine is the only 
one that matters to GnuCash, and that the usage conditions you imagine 
are the only ones that matter, and that requirements 1, 2, and 3 are 
absolutely mandatory?  There are other target users, there are other 
target conditions, where these requirements are not essential, and their 
lack is not especially a problem. Where is your humility that others — 
even accountants who aren't software developers — might evaluate these 
differently than you?


Framing this discussion as "accountants are correct versus software 
developers are arrogant" is not helpful. Let's judge the ideas, not  the 
people who hold them.


Meanwhile, I think Fred Bone's suggestion is very useful:


On Tue, Aug 11, 2020 at 10:24 AM Fred Bone  wrote:

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.



Let's write down this discussion in terms of a) target users, b) scope 
of usage conditions, and c) GnuCash features needed to allow those users 
to do better in those conditions using GnuCash.   We may discover that 
we are talking about different users, and different scopes, than the 
modest ambitions GnuCash currently targets. GnuCash can grow to 
accomplish more, but that takes participation, not just criticism.


    —Jim DeLaHunt, not a trained accountant, self-accounting for 
personal finances and a small sole-proprietor business, not needing 
audits, not complying with Swedish accounting legislation, for whom none 
of these locking features add any value.


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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-11 Thread 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


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Aug 11, 2020 at 10:24 AM Fred Bone  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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-11 Thread Stan Brown 


On 2020-08-11 06:41, Michael or Penny Novack wrote:
> 
> The point is less that the books can't be modified than whether any post
> final approval modification could be easily detected.

Yes and no.

That is _one_ motivation for making a lock. But many of us are using GC
as individuals, not as corporate treasurers. For us, I daresay, the
chief motivation for locking transactions by date would be to prevent
ourselves from accidentally changing something by mistake.

I can't speak for everyone, but for myself: in the early days of a
month, when as I've finished reconciling statements and making accrual
entries for the previous month, I'd like to lock my file up through and
including the last day of that month. If it's August 2nd and I lock
"everything up to 2 days ago," that doesn't help me because as August
progresses I will still have transactions and bills that may need to be
entered for earlier in August.

I'm not saying everyone should follow my process. But I don't understand
why so many people seem resistant to the idea that a user might want to
lock all transactions on or before a fixed date, not some rolling day
interval.

--
Regards,
Stan Brown
https://Brownmath.com
https://oakroadsystems.com
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-11 Thread Fred Bone 
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@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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-11 Thread elvis 
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.



One of the attractions of gnucash is you have access to all your 
accounts, not just what some commercial company says you can have.



On 11/8/20 8:35 am, doncram wrote:

Both fixed date and relative date locking are needed, let me chime in to
say, with reasons that may not have been considered so far.  Relative (same
as number of days?) should be a mild locking, like just a notice that can
be over-ruled ("The transaction is more than 60 days in the past, are you
sure you want to change it?).  This is a simple control to help avoid data
entry mistakes.  In another software, that feature helps me surprisingly
often.

The fixed date locking should be stronger, ideally requiring a password.
The previous year would be locked only when the Treasurer or
other authorized person is really finally signing off on all reporting,
after performing all necessary closing entries to recognize accruals (see
my comment in separate thread "closing of accounts, and locking, "not
needed in Gnucash"? Needed!") and reviewing the financial reports
thoroughly.  This matches up to how nonprofits and businesses have to
operate.  For a nonprofit, the final financial statements would be given to
board , and used in applications for grant funding, and in filing
IRS-required financial statements which are eventually published online at
Guidestar, and so on.  One doesn't want incompatible versions being printed
out and reported publicly, ever!  One really needs to finalize the previous
year, for many purposes.  This allows a nonprofit (or business) to separate
some duties (e.g. a cash withdrawal transaction can not be removed later by
the office-person who took the cash). It can help even a single person
business, too, in making sure that past-years data is fixed (and so
financial statements and tax info is fixed), unless you really really want
to change it for some reason (I can't think of any good reason though).

About the Swedish legal requirement, I say kudos to them for requiring it.
It seems a very good thing, to insist that any organization which will file
reports will have the basic control that the transactions are locked.  It
is good practice to ensure that any organizationsthen defines a change to
prior year to be verboten, and it is therefore a detectable "crime" if that
happens.  The requirement should be easy to achieve, and it has some value
towards ensuring good info.  It's like requiring double-entry accounting,
always having entries that balance!  The fixed date lock may suffice to
meet this requirement.  It seems to me that the further locking feature
(already discussed?), which prevents editing of any existing transactions,
but allows journal entries, would be really helpful.  So that late changes
would be clearly identified.  So that informal internal audit, or external
formal audit, could focus especially on those late journal entries, as it
should properly focus upon all unusual entries (including all or almost all
journal entries).  It would be useful to have a software feature that
allows one to compare one saved version of data vs. current version of
data, to detect any "crime" and then take action on it.  The threat of
being detected itself dissuades "crime" of unauthorized changes.  Trust but
verify.

Informational note:  Many participants here may not be aware, but U.S. GAAP
and International IFRS standards have specific severe provisions about
making changes to any previous year's data, especially but not limited to
any change that affects reported earnings.  Any substantial revision would
be publicly embarrassing and require issuing revised financial statements
very publicly and explaining.  Revisions might be (appropriately) avoided
by argument that, oh, this change may be necessary for accuracy but is not
material enough to warrant a public revision, so do let's make the
correction within the next year's accounting without mentioning it.  *And
even if/when a revision to a prior year is implemented, it is done by
adjustment of current year balances, without changing the past year's
accounting!*  Say a significant amount of accounts receivable should have
been written off, but such expense was not recorded.  A restated Income
Statement and a Balance Sheet and a Statement of Cash Flows, all taking
that into account would be issued, but the correction in the accounting
system is to make a journal entry only in the current year reducing
retained earnings by that amount and reducing accounts receivable.  Getting
to where you would have gotten if the proper entry had been made in the
prior year. Because the prior year's data really really is locked.  I
mention this by way of supporting idea that fixed date locking is a
regular, usual, basic feature of an accounting system.  IMO it should be

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-11 Thread Michael or Penny Novack 





The fixed date locking should be stronger, ideally requiring a password.
The previous year would be locked only when the Treasurer or
other authorized person is really finally signing off on all reporting,
after performing all necessary closing entries to recognize accruals (see
my comment in separate thread "closing of accounts, and locking, "not
needed in Gnucash"? Needed!") and reviewing the financial reports
thoroughly.  This matches up to how nonprofits and businesses have to
operate.  For a nonprofit, the final financial statements would be given to
board , and used in applications for grant funding, and in filing
IRS-required financial statements which are eventually published online at
Guidestar, and so on.  One doesn't want incompatible versions being printed
out and reported publicly, ever!  One really needs to finalize the previous
year, for many purposes.


This IS available in one sense. With all of the organizations that I 
have been Treasurer for (and using gnucash) when the year end 
books/reports have been presented to the Board AND APPROVED (that is a 
vote) I would burn copies (of the books and reports at that point in 
time) to "write once medium", keep one and give one into the custody of 
another organizational officer.


The point is less that the books can't be modified than whether any post 
final approval modification could be easily detected.


Please bear in mind that because I made my living doing software (was a 
senior systems analyst and senior business analyst) I did NOT consider 
any password protection in programs, printed bank statement SUPPOSEDLY 
from the bank, etc. to be a reliable safeguard with respect to ME << 
thus I would request another officer to get a statement directly from 
the bank to compare, not one from me. After all, I was paid to direct 
computers to produce statements just like that >>


Mind, having learned bookkeeping in the old pen and ink on paper days, 
the only editing of transactions I ever did in gnucash was correct 
immediate errors at the time the transaction was being entered. If an 
error older than that was being corrected, would be done the old 
fashioned way with a correcting transaction to preserve an audit trail.


Michael D Novack

PS: I would not (in my case) consider even password protection in even 
proprietary non-open software to be adequate. I have wielded tools like 
disassemblers in my day. The change to almost any program to override 
password protection is quite trivial once you find the spot in the 
program where done; modify the destination of ONE branch instruction so 
a wrong answer goes to the same place as a right one. You don't even 
have to reassemble/recompile, just alter the machine code with a hex 
editor.


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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-10 Thread doncram 
Both fixed date and relative date locking are needed, let me chime in to
say, with reasons that may not have been considered so far.  Relative (same
as number of days?) should be a mild locking, like just a notice that can
be over-ruled ("The transaction is more than 60 days in the past, are you
sure you want to change it?).  This is a simple control to help avoid data
entry mistakes.  In another software, that feature helps me surprisingly
often.

The fixed date locking should be stronger, ideally requiring a password.
The previous year would be locked only when the Treasurer or
other authorized person is really finally signing off on all reporting,
after performing all necessary closing entries to recognize accruals (see
my comment in separate thread "closing of accounts, and locking, "not
needed in Gnucash"? Needed!") and reviewing the financial reports
thoroughly.  This matches up to how nonprofits and businesses have to
operate.  For a nonprofit, the final financial statements would be given to
board , and used in applications for grant funding, and in filing
IRS-required financial statements which are eventually published online at
Guidestar, and so on.  One doesn't want incompatible versions being printed
out and reported publicly, ever!  One really needs to finalize the previous
year, for many purposes.  This allows a nonprofit (or business) to separate
some duties (e.g. a cash withdrawal transaction can not be removed later by
the office-person who took the cash). It can help even a single person
business, too, in making sure that past-years data is fixed (and so
financial statements and tax info is fixed), unless you really really want
to change it for some reason (I can't think of any good reason though).

About the Swedish legal requirement, I say kudos to them for requiring it.
It seems a very good thing, to insist that any organization which will file
reports will have the basic control that the transactions are locked.  It
is good practice to ensure that any organizationsthen defines a change to
prior year to be verboten, and it is therefore a detectable "crime" if that
happens.  The requirement should be easy to achieve, and it has some value
towards ensuring good info.  It's like requiring double-entry accounting,
always having entries that balance!  The fixed date lock may suffice to
meet this requirement.  It seems to me that the further locking feature
(already discussed?), which prevents editing of any existing transactions,
but allows journal entries, would be really helpful.  So that late changes
would be clearly identified.  So that informal internal audit, or external
formal audit, could focus especially on those late journal entries, as it
should properly focus upon all unusual entries (including all or almost all
journal entries).  It would be useful to have a software feature that
allows one to compare one saved version of data vs. current version of
data, to detect any "crime" and then take action on it.  The threat of
being detected itself dissuades "crime" of unauthorized changes.  Trust but
verify.

Informational note:  Many participants here may not be aware, but U.S. GAAP
and International IFRS standards have specific severe provisions about
making changes to any previous year's data, especially but not limited to
any change that affects reported earnings.  Any substantial revision would
be publicly embarrassing and require issuing revised financial statements
very publicly and explaining.  Revisions might be (appropriately) avoided
by argument that, oh, this change may be necessary for accuracy but is not
material enough to warrant a public revision, so do let's make the
correction within the next year's accounting without mentioning it.  *And
even if/when a revision to a prior year is implemented, it is done by
adjustment of current year balances, without changing the past year's
accounting!*  Say a significant amount of accounts receivable should have
been written off, but such expense was not recorded.  A restated Income
Statement and a Balance Sheet and a Statement of Cash Flows, all taking
that into account would be issued, but the correction in the accounting
system is to make a journal entry only in the current year reducing
retained earnings by that amount and reducing accounts receivable.  Getting
to where you would have gotten if the proper entry had been made in the
prior year. Because the prior year's data really really is locked.  I
mention this by way of supporting idea that fixed date locking is a
regular, usual, basic feature of an accounting system.  IMO it should be
allowed in Gnucash.  It would certainly help for use of Gnucash in
accounting education, where it would be the last step in demonstrating how
accounting is done for a firm for a year.

I hope this adds some useful new(?) substance to perennial discussion of
fixed date locking.

Don Cram

On Mon, Aug 10, 2020 at 11:42 AM Stan Brown 
wrote:

>
> On 2020-08-09 20:24, John Ralls wrote:
> > I

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-10 Thread Stan Brown 


On 2020-08-09 20:24, John Ralls wrote:
> I think my proposal--using relative dates like beginning of the current 
> month--fits your use case perfectly and would save you the annoyance of 
> having to update the specified date every month and the risk of possibly 
> forgetting.

Not so much. I need to accrue taxs at the end of (for example) July, but
I don't have the statements necessary to compute the tax amount until
several days into August. So neither a fixed "beginning of current
month" not a fixed "beginning of previous month" would be idea for me.

Seems to me it would make the most sense to let each see decide whether
to do number of days, fixed date, or relative date.

-- 
Regards,
Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
https://OakRoadSystems.com
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-10 Thread Bruce Irving via gnucash-user 
From: Stan Brown 
To: gnucash-user@gnucash.org
Subject: Re: [GNC] GnuCash and Swedish accounting legislation
Message-ID: <6a54ecab-ea17-d69d-9bc1-8f78db1fe...@fastmail.fm>
Content-Type: text/plain; charset=utf-8


On 2020-08-09 10:39, Bruce Irving via gnucash-user wrote:
> The idea of freezing a transaction at some point is an idea that would be 
> appreciated, even by a user like me.? Just before I retired,? There have been 
> times that I accidentally changed a transaction that I didn't intend to. I 
> found that (some of) the commercial programs could allow someone to change 
> transactions - at least by a supervisor.? I retired because 1) I didn't want 
> to learn a system that did not use account numbers and 2) I was confused by 
> having as many as five different accounts with the same name - one in each of 
> the top-level accounts.


You probably know this, but just on the off chance that you don't:

In the File ? Properties dialog, there is a setting "Day threshold for
read-only transactions." If change the default 0 in that box to a
number, then transactions more than that many days before today can't be
edited.

It would be a lot more useful if we could set a date, in my opinion, but
it's better than nothing.

-- 
Regards,
Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
https://OakRoadSystems.com


thanks, Stan.
If I had seen this, it was so long ago that I didn't want it.  (I was entering 
assets from some 50 years before!)  And there was no real cutoff date for that 
process.  I just realized that it has been a long while since I had any old 
entries.
My first thought was like someone suggested: using the first day of the current 
month would be great until I realized I wouldn't be able to work on yesterday's 
transactions on the first day of the month.  Setting the day threshold to 31 
will work for me as I will occasionally find a transaction in the bank that I 
didn't know about and have to track down who or what it was.


Bruce
 Preach the Gospel wherever you go.
 If necessary, use words.
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread John Ralls 


> On Aug 9, 2020, at 3:59 PM, Stan Brown  wrote:
> 
> 
> On 2020-08-09 11:58, John Ralls wrote:
> 
>>> On Aug 9, 2020, at 11:04 AM, Stan Brown  wrote:
>>> You probably know this, but just on the off chance that you don't:
>>> 
>>> In the File » Properties dialog, there is a setting "Day threshold for
>>> read-only transactions." If change the default 0 in that box to a
>>> number, then transactions more than that many days before today can't be
>>> edited.
>>> 
>>> It would be a lot more useful if we could set a date, in my opinion, but
>>> it's better than nothing.
> 
>> Really? ISTM that would be painful to use because you'd have to frequently 
>> change the date. I could understand if you wanted to be able to set a period 
>> selector, e.g. all transactions before the beginning of the current month 
>> are read-only.
> 
> This may be a matter of different users having different use cases.
> 
> Mine is straightforward (to me): Following Adrien's recommendation, I
> don't actually close each month. But I want to make sure that I don't
> inadvertently fumble the date of a new transaction and put it into last
> month, or accidentally change a transaction of last month because of an
> errant mouse click.
> 
> As GC is set up now, to achieve that I would have to change the number
> of days every day, which is, as you say, painful. If I could just setO
> "no alterations of anything dated 2020-07-31 or earlier", that would be
> quite simple, and I'd only have to change it once a month.
> 
> What's your use case for setting number of days, if you're willing to say?
> 
> (I'm not suggesting removing the number-of-days setting, if there's any
> reasonable chance someone actually wants it. But surely it would not be
> hard to add a "freeze transactions before specified date" setting, and
> unless I miss my guess it would prove to be more popular.)

I don't personally have a use-case for the number of days, but I think that 
it's pretty obvious: Once a transaction is N days old it's considered committed 
and shouldn't be changed, and transactions should be entered within those same 
N days of happening in the real world. It's pretty much the topic of this 
thread.

I think my proposal--using relative dates like beginning of the current 
month--fits your use case perfectly and would save you the annoyance of having 
to update the specified date every month and the risk of possibly forgetting.

Regards,
John Ralls

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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread Stan Brown 

On 2020-08-09 11:58, John Ralls wrote:

>> On Aug 9, 2020, at 11:04 AM, Stan Brown  wrote:
>> You probably know this, but just on the off chance that you don't:
>>
>> In the File » Properties dialog, there is a setting "Day threshold for
>> read-only transactions." If change the default 0 in that box to a
>> number, then transactions more than that many days before today can't be
>> edited.
>>
>> It would be a lot more useful if we could set a date, in my opinion, but
>> it's better than nothing.

> Really? ISTM that would be painful to use because you'd have to frequently 
> change the date. I could understand if you wanted to be able to set a period 
> selector, e.g. all transactions before the beginning of the current month are 
> read-only.

This may be a matter of different users having different use cases.

Mine is straightforward (to me): Following Adrien's recommendation, I
don't actually close each month. But I want to make sure that I don't
inadvertently fumble the date of a new transaction and put it into last
month, or accidentally change a transaction of last month because of an
errant mouse click.

As GC is set up now, to achieve that I would have to change the number
of days every day, which is, as you say, painful. If I could just set
"no alterations of anything dated 2020-07-31 or earlier", that would be
quite simple, and I'd only have to change it once a month.

What's your use case for setting number of days, if you're willing to say?

(I'm not suggesting removing the number-of-days setting, if there's any
reasonable chance someone actually wants it. But surely it would not be
hard to add a "freeze transactions before specified date" setting, and
unless I miss my guess it would prove to be more popular.)
.
-- 
Regards,
Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
https://OakRoadSystems.com
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread John Ralls 


> On Aug 9, 2020, at 11:04 AM, Stan Brown  wrote:
> 
> 
> On 2020-08-09 10:39, Bruce Irving via gnucash-user wrote:
>> The idea of freezing a transaction at some point is an idea that would be 
>> appreciated, even by a user like me.  Just before I retired,  There have 
>> been times that I accidentally changed a transaction that I didn't intend 
>> to. I found that (some of) the commercial programs could allow someone to 
>> change transactions - at least by a supervisor.  I retired because 1) I 
>> didn't want to learn a system that did not use account numbers and 2) I was 
>> confused by having as many as five different accounts with the same name - 
>> one in each of the top-level accounts.
> 
> 
> You probably know this, but just on the off chance that you don't:
> 
> In the File » Properties dialog, there is a setting "Day threshold for
> read-only transactions." If change the default 0 in that box to a
> number, then transactions more than that many days before today can't be
> edited.
> 
> It would be a lot more useful if we could set a date, in my opinion, but
> it's better than nothing.

Really? ISTM that would be painful to use because you'd have to frequently 
change the date. I could understand if you wanted to be able to set a period 
selector, e.g. all transactions before the beginning of the current month are 
read-only.

Regards,
John Ralls

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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread bengtxyz 
> -Original Message-
> From: John Ralls 
> 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 w

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread Stan Brown 

On 2020-08-09 10:39, Bruce Irving via gnucash-user wrote:
> The idea of freezing a transaction at some point is an idea that would be 
> appreciated, even by a user like me.  Just before I retired,  There have been 
> times that I accidentally changed a transaction that I didn't intend to. I 
> found that (some of) the commercial programs could allow someone to change 
> transactions - at least by a supervisor.  I retired because 1) I didn't want 
> to learn a system that did not use account numbers and 2) I was confused by 
> having as many as five different accounts with the same name - one in each of 
> the top-level accounts.


You probably know this, but just on the off chance that you don't:

In the File » Properties dialog, there is a setting "Day threshold for
read-only transactions." If change the default 0 in that box to a
number, then transactions more than that many days before today can't be
edited.

It would be a lot more useful if we could set a date, in my opinion, but
it's better than nothing.

-- 
Regards,
Stan Brown
Tehachapi, CA, USA
https://BrownMath.com
https://OakRoadSystems.com
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread Bruce Irving via gnucash-user 
On 8/9/20 5: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? 

When I started using GNC, about 5 or 6 years ago, I had 2 surprises: 1) I 
didn't have to enter the earliest transactions first as I was trying to find 
the old transactions for the assets/liabilities while I was entering daily 
transactions.  And 2) that I could edit entered transactions.
I grew up in the pen and paper era so that editing an entry was a no-no but, 
since my current effort was not for other people, it was great as Idon't make 
mistreaks! Yeah! Right!  (For those of you, myself included, that didn't catch 
the irony of that remark. I do make many mistakes.)
The idea of freezing a transaction at some point is an idea that would be 
appreciated, even by a user like me.  Just before I retired,  There have been 
times that I accidentally changed a transaction that I didn't intend to. I 
found that (some of) the commercial programs could allow someone to change 
transactions - at least by a supervisor.  I retired because 1) I didn't want to 
learn a system that did not use account numbers and 2) I was confused by having 
as many as five different accounts with the same name - one in each of the 
top-level accounts.

Thank you guys for all you have done with this program.  

Bruce
 Preach the Gospel wherever you go.
 If necessary, use words.
___
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.

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread John Ralls 



> 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
>  wrote:
>> 
>>> On Feb 2, 2016, at 8:17 AM, Colin Law
>  wrote:
>>> 
>>> On 18 January 2016 at 08:18, Draug
>  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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread Christopher Lam 
This is not a problem that can be solved in an open-source software.
Perhaps you're looking for a datafile archiving and notarization service?

On Sun, 9 Aug 2020 at 09:27,  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
>  wrote:
> >
> >> On Feb 2, 2016, at 8:17 AM, Colin Law
>  wrote:
> >>
> >> On 18 January 2016 at 08:18, Draug
>  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.
>
> Colin
> ---
>
> Regards
> //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.
>
___
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

Re: [GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread Jean-David Beyer via gnucash-user 
On 8/9/20 5: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? 

I am not an expert at the inner workings of GnuCash, but it seems to me
that there is nothing the author of Gnucash, or any other program, can
do to make files write-only-once. Not because the code of Gnucash could
not be written that way, but because there is little GnuCash can do to
prevent other programs from modifying GnuCash files. In other words, if
a user has permission to write a file, (s)he also has permission to
update (re-write) a file. And if the user (or super-user) is at the
console, he can probably violate controls  by SELinux as well.

-- 
  .~.  Jean-David Beyer
  /V\  PGP-Key:166D840A 0C610C8B
 /( )\ Shrewsbury, New Jersey
 ^^-^^ 08:00:01 up 24 days, 5:59, 2 users, load average: 4.32, 4.41, 4.25
___
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.

[GNC] GnuCash and Swedish accounting legislation

2020-08-09 Thread bengtxyz 
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
 wrote:
>
>> On Feb 2, 2016, at 8:17 AM, Colin Law
 wrote:
>>
>> On 18 January 2016 at 08:18, Draug
 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.

Colin
---

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