1. select account.update all accounts When ofx updates my credit card account, it also seems to create a transfer transaction in my checking account for the transaction that is a payment from the checking to the credit card. The problem is that when ofx updates my checking account it also creates a payment entry for that transaction, so I end up with a duplicate transactions in my checking account every month-the payment and the transfer. In version 4.6.4 I could delete the payment transaction and then have an accurate balance, but in 4.7.2 the payment transaction gets put back in the next time I update the account. I would prefer the transfer transaction didn't get created in my checking account. Reproducible: Always
I think this is a question of how the institution creates the transaction, and how KMM imports it, specifically whether it matches it to a previous transfer transaction or just creates a new withdrawal/deposit transaction. To either institution (bank or credit card) it is just a withdrawal or deposit - it could only be a transfer it both accounts were in the same institution. However, when KMM imports such a transaction, it might recognize it based on the one from the previous month, and so create it as a transfer. As far as KMM recreating the deleted transaction the next time you update the account - it is probably because the bank is sending it again - based on the start date for transaction KMM is requesting. Check whether KMM is requesting updates since the last update, or since a specific date, or for the last N days.
In case both imports create a transaction it is important, if the posting dates of the two transactions are identical or not If they differ, then KMyMoney will keep them as two separate transactions. A possible way out of this is to create a 'transfer account' in KMyMoney which is a simple asset account. Then setup two legs of the transaction ('Acct A to transfer' and 'transfer to Acct B') . Works for me for many years. Check that the balance of the transfer account is zero from time to time. In case a deleted transaction is recreated after the next import check the import options as Jack pointed out. Regularly, use 'last update' and the others only on special purpose. That should avoid recreation of already downloaded transactions in most cases.
The posting dates are different-the credit card deposit is few days before the checking withdrawal. I changed the import start date to "last update" but update account is still going back a couple months and re-adding the transactions after I delete them.
I don't know if there is any good solution to the issue of a transfer wanting to have a different date on each end, since KMM does force a single date for all splits of a transaction. In paying paying my credit card from checking account, I simply accept that one of the dates is actually off by a day or two. At some point, I'll probably file a wish-list bug to allow KMM to maintain two dates for a transaction (or a split, I'm still not sure which will work better if at all possible) - a transaction date and a posting date. Which side shows an earlier date depends whether the trasfer is a paper check (credit account deposit first) or an electronic payment (check withdrawal first.) In terms of how far back the update account goes - is this really a checking account, or an investment account? I have discovered that investment accounts do not actually store the "last update" date, and so always go back 60 days despite the configuration setting. (I need to do more research before submitting a bug and/or patch.) You can check this by creating a file "ofx.log" in your home directory. The ofx update will then store the log of the transaction in that file. See what date KMM is actually requesting as the start date for download.
Yes, I suppose it is an investment account- its a money market account and ofxlog.txt has a <INVSTMTMSGSRQV1> tag in it. Do you know of a workaround so I can get rid of all the double transactions in this acct and not have them reoccur every month?
The question is what kind of account do you have it set up as in KMM? In the ofx log, can you find what date KMM is requesting as the start of downloaded transactions? That is the first key point. If it is the date of your last update, we move on to the second issue. However, if it is 60 days ago, even if you have the account configured to download only since the previous update, then you can try setting the start date each time you download. That will avoid downloading the same transactions multiple times.
This is still occurring in 4.8. When I do an ofx update on my American Express credit card account it automatically creates a transfer transaction every month when the cc bill is paid, which is unwanted because the paying account also gets its own transactions updated by ofx. I worked around this by creating a fake account and setting that as the transfer account.
There are several if's in this reports. Do be able to reproduce this issue, please provide a kmymoney test file along with a related ofx import file. In the save to dialog there is a anonymous file option to create an anonymous file if you want.
Swj - I just reread all the entries here, and when the second transaction is created, do you just delete it, or do you manually match it to the other transaction already present? If you delete it, you will have the situation you opened the bug about. However, if you match them, then the banks ID for the transaction should remain, and the next import should be recognized as a duplicate. Ralf - this would be difficult to do with an anonymized file, as the relation between an investment and brokerage account is lost when saving as anonymous (see bug 340902). However, it might be possible to create a new file with only the necessary accounts, and then manually clean identifiers out of the two ofx files, one for each account.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I'll leave this closed, but I think it may actually have been fixed, or at least improved by a recent enhancement to ofx import - where the actual date of the import is now recognized for investment accounts. (Actually making that work will require at least 5.0.2, and probably also a change to libofx which has not been scheduled for release yet.) That will make an ofx import actually only go back to the previous import date (plus three(?) days) instead of always going back 90 days.