[GNC] Unsplitting a transaction

David Carlson david.carlson.417 at gmail.com
Thu Jun 6 10:25:56 EDT 2019


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 <scamidge at 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             scamidge at 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 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.
> >
> _______________________________________________
> 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.
>


More information about the gnucash-user mailing list