[GNC-dev] About 3.9 and reconciliation balances

[Frank H. Ellenberger]

Hi David,

I have not looked in the sources, but try a theoretical abstrakt:
If all transmitted transactions are cleared by the bank
and the bank statement contains a closing balance
and this closing balance is equal the current (at that date) account
balance, the section can be marked as reconciled. This would be more
reliable than fat finger entered bank stements.

But I don't know, what a) should or b) will happen, when the one or
other condition fails.

Regards
Frank

Am 11.04.20 um 00:57 schrieb David Cousens:
> I was not aware that AQbanking does a reconcile on the fly.  I also use OFX,
> CSV nad very occasionally QIF imports (but not from Quicken) but not that
> heavily any more. I think it would be useful to have this information about
> the reconcile marking process documented at least in the importing section
> of the help manual. There are sections on reconciliation in several sections
> of the guide and the help manual. I suspect it is covered but there isn't a
> nice summary. 
> 
> I don't know enough about how AQbanking works at the bank level, e.g.
> whether it only makes transactions available after all bank internal
> processes (clearing) have occurred as my bank hasn't implemented it and
> refuses to on security grounds (but it does allow MYOB and a number of other
> commercial packages direct server access but only on business accounts not
> personal accounts -  no doubt for a hefty fee) but it is clearly regarded as
> the equivalent of a statement. 
> 
> In my manual OFX downloads for my credit card, the bank records transactions
> as pending in their web portal, which I have made, but are not yet cleared
> through VISA, until they get a clearnce from VISA. I can't include the
> pending transactions in either a CSV or OFX download which makes sense. The
> shortened times for electronic clearance between banks these days usually
> means that i have had no conflicts between downloads and statements for
> several years now unless I have had finger trouble in importing. On my
> Savings account I can't remember having had a transaction marked as pending
> since electronic clearing came in.
> 
> I will put it on my to do list to find an appropraite places to put such a
> summary. I tried to rationalize the Guide recently by having a general
> section Ch4 on reconciliation and then pointing to the existing sections
> which were focussed on reconciling specific account types.
> 
> It makes sense to me to store the last reconciliation date and the ending
> balance at that date in the account data then by comparison with
> calculations of the starting balance on the fly, there would be a good
> mechanism for detecting any altered transaction splits invalidating a
> previous reconciliation and alert the user. Even more useful perhaps than
> just the last reconciliation date and end  balance would be a complete
> reconciliation history for each account but that introduces alot more
> complications for forward/backward compatability but it would improve the
> ability to verify account integrity and to locate when a change affecting
> the account integrity was introduced. 
> 
> By "fix" in this context are you referring to the exclusion of the future
> reconciliation dates from the starting balance sums  or a manual or auto fix
> to the future reconciliation dates themselves.
> 
> I am still trying to work out if an autofix is possible for the future
> reconciliation dates case. It may be possible from the transaction dates
> posted and dates entered for splits which have a future reconciliation date
> to identify a potentially valid reconciliation date if you were also able to
> construct a list of all reconciliation dates used by the account which was
> what i did manually i.e. suggest the earliest and latest reconciliation
> dates a user could choose to be consistent with the rest of the account
> data. The same approach may also be the basis of an internal check on the
> stored reconciliation data validity. 
> 
> David 
> 
> 
> 
> -----
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>