Well I've been schooled.
Please refresh and try again.
The headers should match the desired report *post* reconciliation.
The transactions reported are: uncleared, cleared, and reconciliation
whereby split-reconciliation-date = account's last-reconciliation-date.
On 9/2/19 10:19 am, Steve Butler wrote:
Sorry for top posting. Checked the transaction report items. One is
Reconciled Date. That date matches the bank statement date on which
it was reconciled.
How does that report get that date per transaction if the field
doesn't exist?
On Fri, Feb 8, 2019, 17:52 Christopher Lam <christopher....@gmail.com
<mailto:christopher....@gmail.com> wrote:
On 9/2/19 7:49 am, Stephen M. Butler wrote:
> On 2/8/19 5:12 AM, Christopher Lam wrote:
>> I've been experimenting and I think there's a logic error in your
>> thinking -- *during* reconciliation, until it's complete, all
>> 'reconciled' transactions are labelled 'cleared'. Reconciled
>> transactions are, so to speak, gone and don't need to be shown on a
>> reconciliation report.
> The reconciliation report should run just after reconciliation has
> finished. Therefore, the just reconciled items will be marked as
> reconciled.
I do agree in principle... however the internal logic of GnuCash
dictates that there is no such thing as "just reconciled items".
Consider a very busy bank account needing regular
reconciliation... on
15-january you try reconcile but you've written and recorded a
check for
$53.50 on 20-december which is still not cleared. This $53.50 will
remain unreconciled ("outstanding") causing a discrepancy of $53.50
between your 15-January bank statement, and your book. You reconcile,
skipping the $53.50 amount, and all's well.
On 15-february the bank statement arrives, and the $53.50 check has
cleared on 19-january. The $53.50 status changes from
(n)unreconciled to
(c)cleared. Additionally all intermediate transactions are
cleared. Your
15-february bank statement now matches your books.
According to my suggestions above logic the $53.50 will be counted in
the 'cleared' header, and be present in the reconciliation report.
You
will afterwards then complete the reconciliation, which converts all
'c'leared to 'y'reconciled.
If we were to follow your logic, and if we run the reconciliation
report
on 15-february, and if we *aim* to look for the 'just-reconciled'
items,
we will definitely miss the $53.50 transaction dated 20-December
because
it's now reconciled/"archived". Remember the transactions do *NOT*
have
a 'reconciliation date' so we cannot look for them using a simple
query.
Only accounts have a last-reconciliation-date. We will *not* find
them
by querying 'reconciliation-date minus 1 day'.
Logically you're not wrong but GnuCash internal logic will dictate
the
above process must be followed.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
