I could have sworn there was a simple (and easily defeat-able) locking mechanism based on number of days that had passed, but I can’t seem to find the preference.
Perhaps I was imagining things. Regardless, if one wants to use correcting transactions, that is certainly still doable, and there is even a facility to have a reversing transaction entered for you via the Transaction menu. But I don’t think any of that was what the OP was dealing with. They were editing an auto-filled *new* transaction. Regards, Adrien > On Jun 6, 2019, at 9:07 AM, Stephen C. Camidge <scami...@fastmail.fm> wrote: > > For personal use and for most businesses, this would be the appropriate > method. For larger businesses with EDP Auditors (do they still exist?) and > regulations with accountability for the how data is maintained, the > transactions should be locked. However, in that kind of environment, a free > program like GNU Cash would not likely meet their needs or be permitted. So, > it is safe to continue not to support that feature. > > -- > Stephen C. Camidge scami...@fastmail.fm (519) 363-3912 > > On Thu, Jun 6, 2019, at 9:18 AM, Mike or Penny Novack wrote: >> On 6/5/2019 3:45 PM, Stephen M. Butler wrote: >> >>> >>>> If you did that, then you didn't properly remove the other splits. You >>>> need to go into each cell and manually remove the data, then tab out.. >>>> Then use the arrow key to move up and the split will disappear. Continue >>>> until all the extra splits are gone. >> >> Not a practical "how to do" answer but it might be a good time to >> mention that "how to correct" in general involves the question "how >> formal is your process"? >> >> In the old days, pen and ink on paper, erroneous transactions were >> never removed. They were offset (enter the reverse transaction) and then >> the correct transaction entered. In other words, preserving an audit >> trail that there was an error that was corrected << the description >> fields would explain/refer to the erroneous transaction >> >> >> THIS PROCESS is still what is done by those of us required to maintain >> formal books. SOME accounting software will require it, not allow >> existing transactions to be deleted/altered. Might be required in some >> jurisdictions. There has been discussion in this forum that gnucash >> being unable to prevent deletion/alteration is a fault << that is, not >> offering this option -- in effect, open source software cannot provide >> this sort of security as those with programming ability could use an >> altered version of the program to defeat it >> >> >> HOWEVER -- most of us using gnucash are not following the formal >> process. WE will simply delete/alter erroneous transactions. >> >> Michael _______________________________________________ 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.
