reconciled transaction without a reconciled date?

[Thomas Baumgart]

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).

-- 

Regards

Thomas Baumgart

-------------------------------------------------------------
When Apple constructs a car, will it have Windows?
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20230213/bffe959e/attachment-0001.sig>