This forum has been archived. All content is frozen. Please use KDE Discuss instead.

KMM QIF Importing Problems

Tags: None
(comma "," separated)
drfritze
Registered Member
Posts
9
Karma
0

KMM QIF Importing Problems

Tue Sep 20, 2022 1:56 pm
ipwizard wrote:Regarding your comment on the account opening date: this maybe true if the QIF file does not have an opening balance transaction that contains a date.


That comment was made in the discussion on "Installation: QT Platform Not Initialized." That thread does not seem to be an appropriate place to have an unrelated discussion so I'm making a new post. The situation I was facing was transferring data from MS Money Sunset to KMM. Trying some of the utilities to access the MS ISAM database leads to password issues so the only avenue left to accomplish the task is to export QIF files from Money and import them into a fresh KMM. Money can only export QIF format and one has to export for each account one at a time.

The account which is the subject of the first QIF file (call it the "original" account) is not the problem. For discussion, assume we are talking about the very first QIF one tries to import and let's call this the "original QIF." When importing, all of the accounts referenced in balance sheet transactions are created on the fly. The newly created accounts are all checking accounts leading to things like Citibank Visa checking account or Wells Fargo Mortgage checking account. Also, all of those newly created accounts have an opening date of today even though they are created from a transaction with a posting date before today (GUARANTEED problem). If one then goes back and edits the new created accounts, the date can be changed but the only options for that Citibank Visa account are checking, savings, and cash. To lessen confusion call these the "bogus" accounts.

Importing a QIF for one of the bogus accounts establishes a second account with the same name and correct opening date and type. For discussion, call these the "intended" accounts. The transactions in the bogus account will also appear in the intended account leading to duplicate entries in the original account. Confused? Yes, it is confusing and frustrating.

Deleting the transactions in the bogus account or the account itself creates havoc. One way to help the situation is to watch for all of those bogus accounts as they are created. Before importing anything else, create new accounts with the same name and the correct date and type. Then move the transactions from the bogus account to this user created account and delete the bogus account. Now, when a QIF file is imported for one of these accounts, the user created account is used and the duplicate transaction flagging works like I think it was intended. New bogus accounts are only created if they have a name that is different than one of the accounts, bogus or intended or whatever, that already exists.

If you want me to provide a step-by-step script so you can see these problems, I'd be happy to.

-Don
drfritze
Registered Member
Posts
9
Karma
0

Re: KMM QIF Importing Problems

Thu Sep 29, 2022 11:54 am
ipwizard, the importer creates accounts on the fly based on balance sheet transfer transactions. The dates on those accounts are today regardless of the posting date for the transaction. The statement is true.

For example, starting with a fresh KMM file import a QIF for a checking account that contains a transaction last money to pay a credit card. The checking account will be created with the correct date. The credit card account will also be created. It will have a type of checking account (wrong) and a date of today (guaranteed problem). Try it.
User avatar
ostroffjh
Registered Member
Posts
253
Karma
0
OS

Re: KMM QIF Importing Problems

Sun Oct 09, 2022 5:42 pm
Wrong account opening dates are easily corrected, and if memory serves, the consistency checker will automatically adjust an account's opening date to be the date of the oldest transaction in that account.
In terms of changing the type of an account, there are some limitations. I do not know the exact rules, but most likely you cannot change from an asset type account (savings, checking, ...) to a liability type account (credit card, loan.) However, what you can to is to create a new credit card account, then move the transactions from the bogus checking account into that new credit card account. If you do that before importing the credit card account, then when you do that import, the transactions should be recognized and matched, so you don't end up with duplicates.
Does this help any?


Bookmarks



Who is online

Registered users: bartoloni, Bing [Bot], Google [Bot], Yahoo [Bot]