I think we are mostly talking about removing errors in new transactions before they are initially committed, not removing old errors. If every sloppy keystroke or cat--track had to stay, we would never get anything done.
David Carlson On Thu, Jun 6, 2019, 9:09 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. > > > _______________________________________________ > 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.
