reconciled transaction without a reconciled date?

[Jack]

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.