On 2023.02.13 02:03, Thomas Baumgart via KMyMoney-devel wrote:
On Sonntag, 12. Februar 2023 20:51:51 CET Jack via KMyMoney-devel
wrote:
> On 2023.02.12 07:19, Thomas Baumgart via KMyMoney-devel wrote:
> > On Samstag, 11. Februar 2023 21:51:38 CET Jack via KMyMoney-devel
wrote:
> >
When testing the new "reconciled date" as a ledger sort item, I
had a transaction from 2018 at the end of the list. Finding that
transaction in the file, I get:
> > >
> > > <TRANSACTION id="T000000000000016243" postdate="2018-08-06"
memo=""
> > > entrydate="2018-08-14" commodity="USD">
> > > <SPLITS>
> > > <SPLIT id="S0001" payee="" reconciledate="2018-08-31"
action=""
> > > reconcileflag="2" value="-8000/1" shares="-8000/1" price="1/1"
> > memo=""
> > > account="A000150" number="" bankid="ID
> > 20180806AF190321500016194-1"/>
> > > <SPLIT id="S0002" payee="" reconciledate="" action=""
> > > reconcileflag="2" value="8000/1" shares="8000/1" price="1/1"
memo=""
> > > account="A000370" number="" bankid="ID D2018218T1953469"/>
> > > </SPLITS>
> > > </TRANSACTION>
> > >
I have no idea how a transaction/split could get reconciled
without a reconciledate being set. I also have no idea how to fix
it without manually editing my data file. I suppose I could
change the state from R to not-reconciled to C to R, but even if
that does reset the reconciledate to today, it would be wrong, and
sort badly using the new sort criteria.
> > >
> > > Why do I always seem to find these anomalies?
> >
... maybe, because you were playing with the new features while I
was sleeping :)
>
> I plead guilty.
>
I stepped on this problem myself and could only think that this was
caused by some historic version of KMyMoney. I made a change to use
the postdate in this case, which is still not 100% correct but
helps the sorting.
>
> I don't see that commit. Did you push it?
Ooops, you got me on this one.
> Changing the status of that transaction to "C" and then doing a
> reconciliation as of a few days after that did set reconciledate to
> that date, although the amount shown on that reconciliation header
is
> the current balance, not the one in 2018. That's probably because
all
> following transactions are already reconciled, so I don't think it
will
> affect any normal use.
Hm, I have to check that. The amount shown should reflect the ending
balance that the reconciliation process shows. Maybe it does not cover
the corner case that "future" transactions are already reconciled.
Will
check.
> However, sorting with Reconciliation Date first still shows no
headers
> in the ledger at all.
Yep, due to the missing push (which I just did).
With the new commit, we're better, but. Things do sort as expected,
but even though the reconciliation headers show the same balance as the
transaction immediately above them, they (at least many) still show in
red.
