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 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. -- Regards Thomas Baumgart ------------------------------------------------------------- "The flame that burns twice as bright burns half as long." ― Lao Tzu, Te Tao Ching -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
