For now, the workflow is that if you alter a reconciled transaction, you’ll get a warning. (which is dismiss-able, and which you can elect to not be shown) There is at least one (though I think several) bug reports on what should trigger this warning when a reconciled transaction is edited, depending on what data edit causes the trigger.
However, I know of no mechanism in GnuCash currently that checks to see that you’ve entered an historical transaction that *should* have been reconciled in the past, or even has an erroneous date and should be in the present but affects a reconciled period. Presumably, since it is required for the math to work out, if you are entering a real historical transaction, it should be part of the historical reconciliation. Which means if it were not already present, then either you have some serious errors in your current record, or, you made a correcting entry that needs to be erased/modified now that you have more accurate transaction data. Regardless of if you enter an old transaction that should have been included, or mis-enter a date in the past, the next time you reconcile, you’ll see that/those old transactions and notice something is amiss. While it would be nice to get such warning at the point of entry, there might be use cases where warnings are quite a pain, especially for someone intentionally entering historical data. Personally, I don’t have a problem with the current approach. If you successfully reconcile a period and don’t have to make an adjusting transaction, there should be no issue. If you reconcile but made errors and don’t feel like, or can’t at the moment track down why they are there and make an adjusting entry, then you’ll realize this at worst, at the next reconciliation. If you errantly enter an old date on a transaction, you’ll catch this at the next reconciliation. (unless you aren’t careful) Now, it would be nice if upon reconciliation, there were some way to indicate in a particular transaction (the last of the reconciled period) that the asserted balance was at a certain level. I do this from time to time if I happen to count a cash asset, but haven’t gotten around to reconciling it yet. I’ll note that at the point of the transaction I had a certain amount physically on hand. That way, when I do get around to formal reconciliation, I know my balance at that transaction needs to be a certain amount. And if it is off, I’ll have to either search for the error, or enter a miscellaneous transaction as a correction. If I ever have to make a balancing miscellaneous transaction to complete a reconciliation, I’ll indicate in it whatever that asserted balance was supposed to be. That way, if I ever get back to investigating or if I find a lost receipt for example, I can either edit that balancing transaction accordingly, or erase/reverse it entirely. But that doesn’t include the case of doing so automatically from an actual reconciliation. (rather than being not up to date in doing so, or manually noting the asserted balance.) Perhaps an RFE would be in order, however, I don’t know how much work would be involved or where that would even appear in the UI. Regards, Adrien > On Oct 1, 2019 w40d274, at 11:51 PM, Arman Schwarz <[email protected]> > wrote: > > Thanks Christopher, also for putting a name to what I was trying to > describe. > > It seems odd to me that the devs would spend time implementing > "Reconciliation" and then delete the most important part right after it's > provided (the balance). Was this a deliberate design decision or are > balance assertions on the roadmap? If not, what was the reason and what is > the intended workflow to prevent errors creeping into my accounts? > > On Wed, 2 Oct 2019 at 14:38, Christopher Lam <[email protected]> > wrote: > >> This is a feature called balance assertions present in ledger-cli, another >> bookkeeping tool. GnuCash doesn't have it. However you can approximate it: >> >> https://bit.ly/2mMAKmf >> >> On Wed, 2 Oct 2019, 12:28 armanschwarz, <[email protected]> wrote: >> >>> Suppose on July 1, 2019 I get a statement that my account balance is $100. >>> Since I know this is true and won't change in the future, I should be able >>> to tell GnuCash that this is the expected balance, and for some kind of >>> warning to appear if that condition is ever violated for the corresponding >>> account in GnuCash (kind of like a unit test). >>> >>> Looking at the documentation for Reconciliation, it seems like this that >>> feature more targeted at individual transactions rather than setting known >>> values for balances at given points in time. If I reconcile an account for >>> 12 months every month, and then stop reconciling it the year after, what's >>> stopping all of those historic balances from getting thrown out of whack? >>> Does GnuCash remember what the balances should be and prevent this? >>> >>> Also, if I accidentally enter a wrong date every 5% of the time, and I >>> accidentally reconcile them incorrectly 5% of the time, then for a large >>> number of transactions I'm virtually guaranteed to have my history broken, >>> whereas remembering statement balances would avoid this problem. _______________________________________________ gnucash-user mailing list [email protected] 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.
