Usually with a consistency check, I simply go to the accounts details and adjust the opening date. Problem solved.

However the last QIF import there are still 110 problems that are still current. The accounts opening datae is 1/7/97 and the consistency check states

* Transaction 'T000000000000012013' has a post date '29/9/97' before one of the referenced account's opening date.
Referenced accounts: Mrs W Errors (S5)
The post date was not updated to '1/7/97'.

After the same QIF import, there are now 2 payees with the same name ? I don't know why the second one got added in the import, the names are exactly the same.

In regards to the payee issue, here is the original data details for that payee

<PAYEE name="XYZ Australia" reference="" id="P000022" matchingenabled="0" email="">
<ADDRESS city="" telephone="" postcode="" state="" street=""/>
</PAYEE>

and here are the data details for the (extra) one that has been added ..

<PAYEE name="XYZ Australia" matchkey="^XYZ Australia$" reference="" id="P000994" usingmatchkey="1" matchingenabled="1" email="" matchignorecase="1">
<ADDRESS city="" telephone="" postcode="" state="" street=""/>
</PAYEE>

In fact, browsing through the XML data, it seems there are a number of duplicate payees. Found https://sourceforge.net/p/kmymoney2/bugs/323/ but it is very old.

In terms of the date issue, there is probably more than one account referenced by the transaction. What type of transaction is it, and is it a split transaction? I don't know why KMM wouldn't adjust the opening date of the problem account, but first we have to figure out which account is being referenced.

On the duplicate payees, in the short term, you can just delete the new payee and assign its transactions to the old payee. As to why the duplicate is being created, can you create a small test data file which shows the problem? That would be great, as it would allow the developers to track exactly where in the code it is failing to recognize the payee as already existing. (Wild guess, probably not relevant - is the name of the payee in the new import file an exact match, or are there perhaps extra spaces?) Even without a test file, if you import that file again, is yet another copy of the payee created?

ostroffjh wrote:In terms of the date issue, there is probably more than one account referenced by the transaction. What type of transaction is it, and is it a split transaction? I don't know why KMM wouldn't adjust the opening date of the problem account, but first we have to figure out which account is being referenced.

Thanks for your reply.

For the account referenced in the consistency check, there are lots of transactions from 1/7/97 through to 13/10/97. Then a line "Next fiscal year" and an entry:

1/7/97 Opening Balances 113.80

which would have been caused by the first transaction in the QIF file used for import:

!Type:Bank
D07/01/97
T113.80
CX
POpening Balance
L[Mrs W Errors (S5)]
^

when I go to that account, the opening date is 1/7/97 and opening balance of 113.80

So, I can see why KMM says all the transactions are BEFORE 1/7/97. So I deleted that transaction, yet still had those 110 consistency check errors. When I was modifying the date for the transaction, KMM did display for a very brief moment 1/7/2097 , so that may be the issue. I assume there is a setting somewhere in KMM. Only a setting in the QIF import, referencing apostrophe and none of the dates in the QIF data had apostrophe's I think ?

Looking at the XML data

<ACCOUNT lastmodified="2022-08-31" description="22571 - S5" type="1" opened="2097-07-01" currency="AUD" parentaccount="AStd::Asset" lastreconciled="" institution="I000007" name="Mrs W Errors (S5)" number="" id="A000646">
<KEYVALUEPAIRS>
<PAIR value="1997-10-13" key="lastImportedTransactionDate"/>
</KEYVALUEPAIRS>
</ACCOUNT>

Notice the year "2097", so that is why KMM states in the consistency check that all the transactions are BEFORE. So, what about this ?

* Take the appropriate backups
* Save the KMY file as XML
* Opne the XML file and modify

opened="2097-07-01"

to

opened="1997-07-01"

then save the file. I think on the next save or auto save, KMM saves it as KMY format, is that correct ??

I'll come back later on the duplicate payees issues, thanks.

I was not able to modify the opening date of this account (via Account | Edit account), as I had been using the calendar option to the right of the date. Considering that "97" was "2097" from a KMM perspective, I then tried using the arrows, ...down, down, eventually it got to 1/7/1997. Pressed OK and then ran consistency check, and all now okay.

So, there is a small "bug" in KMyMoney, that when attempting to alter the opening date using the calendar, it does not work.

I'll look at the duplicate payees issues in the next few days, hopefully.

That's a known issue and caused by KDE's KDatePicker widget. A respective bug entry already exists but apparently has not been addressed yet. KMyMoney master has recently been modified to use the KMyMoneyDateEdit widget in all locations where dates are entered (let us know if we missed one more). It is based on the KDateComboBox and extends it with a few functions but therefore it also relies on the KDatePicker.

Thank you @ipwizard.

With the duplicate payees, it appears they were added in a QIF export. Possibly there was a space somewhere or some other minor character to cause the additions ? I've now marked all the duplicate payees and can simply got through each transaction relative to the payee and select the correct payee in an edit. There is no rush, I'll get it done before Christmas.

You know, that you can delete a payee (the one that was created but is not used) and as part of the process select another payee (the correct one) to which all references will be updated? This way, you will be done in almost no time and have gained much time for Christmas shopping

ipwizard wrote:That's a known issue and caused by KDE's KDatePicker widget. A respective bug entry already exists but apparently has not been addressed yet.

Just found out that the relevant bug fix has been added upstream. So it's just a matter of time to be rolled out into the distros.

ipwizard wrote:You know, that you can delete a payee (the one that was created but is not used) and as part of the process select another payee (the correct one) to which all references will be updated? This way, you will be done in almost no time and have gained much time for Christmas shopping

Thanks @ipwizard - That method works fine where one payee has all the trans and the other payee has none. So just delete the latter one. Yet most of these duplicate payees have a number of transactions each. It's just a matter of picking the payee that has less transactions, then going into the ledger , edit mode and change the trans to the 'other' payee. I think I will still have it all done before Christmas though.

ipwizard wrote:Just found out that the relevant bug fix has been added upstream. So it's just a matter of time to be rolled out into the distros.

Great, thanks

jehoshua wrote:It's just a matter of picking the payee that has less transactions, then going into the ledger , edit mode and change the trans to the 'other' payee. I think I will still have it all done before Christmas though.

Since Christmas is arriving soon: you know that you can select multiple transactions and change the payee for all of them in one go. That currently does not (yet) work in the unstable master version but works well in the 5.1.x versions.

ipwizard wrote:Since Christmas is arriving soon: you know that you can select multiple transactions and change the payee for all of them in one go. That currently does not (yet) work in the unstable master version but works well in the 5.1.x versions.

I haven't tried that as yet. I assume though, that the selected trans have to be in order to select them like that ? Or can you use the space bar to select and 'skip' a select ? My KMM is 5.1.2

Control click allows to select non-adjacent transactions in the ledger. There is probably a keyboard combination to do the same, but I'm not sure what it is. Control-space is possible, but I have not tested it.

ostroffjh wrote:Control click allows to select non-adjacent transactions in the ledger. There is probably a keyboard combination to do the same, but I'm not sure what it is. Control-space is possible, but I have not tested it.

Thanks.