Adrien, I thought there was also an option to turn on or off the blue line in the register after today's date. I cannot find that either.
David Carlson On Thu, Jun 6, 2019 at 11:22 AM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > 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. > -- David Carlson _______________________________________________ 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.
