Version: 4.5.3 (using KDE 4.4.5) OS: Linux Importing a QIF file for an existing credit card account or deposit account is not properly working. Instead of adding the new entries to the existing account, a new account with the identical name is created. Importing a QIF file for a giro account works as expected and the new entries are added to the existing account. Debian Squeeze contains kmymoney 3.98.1 but issue also happens with 4.5.3. I cannot test 4.6 at the moment but I assume issue is the same. This is a regression as kmymoney 0.8.9 in Debian Lenny was working as expected. Reproducible: Always Steps to Reproduce: 1) Create a new credit card account or deposit account 2) Add some entries (bookings) 3) Export the account as QIF 4) Import the exported QIF file Actual Results: A new account with an identical name is created. Expected Results: The entries should be added to the existing account.
(In reply to comment #0) > Version: 4.5.3 (using KDE 4.4.5) > OS: Linux > > Importing a QIF file for an existing credit card account or deposit account is > not properly working. Instead of adding the new entries to the existing > account, a new account with the identical name is created. > > Importing a QIF file for a giro account works as expected and the new entries > are added to the existing account. > > Debian Squeeze contains kmymoney 3.98.1 but issue also happens with 4.5.3. I > cannot test 4.6 at the moment but I assume issue is the same. > > This is a regression as kmymoney 0.8.9 in Debian Lenny was working as expected. > > Reproducible: Always > > Steps to Reproduce: > 1) Create a new credit card account or deposit account > 2) Add some entries (bookings) > 3) Export the account as QIF > 4) Import the exported QIF file > > Actual Results: > A new account with an identical name is created. > > Expected Results: > The entries should be added to the existing account. Do you think you could clarify your results? If I create a credit card qif file and import it, it creates the credit card account as expected. If I then re-import the file, it identifies the transaction as a duplicate of the existing one in the existing account. If, however, I export a credit card account and then import that, it doesn't create a duplicate account, but instead creates a checking account with the same name. So that we're on the same wavelength, could you recheck your result? Is the newly created account a checking account or a credit card account? Looking at the exported file, it shows as a !Type:Bank not !Type:CCard. So, it looks like an export problem, not an import one.
Credit card account export works better if the default Qif profile is not used! Instead, create a new profile with the Type field text set to 'CCard', use that profile when exporting, but select the default profile when importing. Let me know if that helps.
Actually I am interested in importing data to an existing account. The "Steps to Reproduce" was just an example but maybe not a good one, sorry for the confusion. My old script created QIF files with the following header: !Type:Bank CX POpening Balance L[name of the account] This was working fine with all type of accounts and kmymoney 0.8.9 (Debian Lenny). The data are imported to the existing accounts as expected. The script is still working for giro accounts in newer kmymoney versions. But it does not work with other accounts like credit card or deposit accounts. A new account is created instead with the same name. Then I checked the QIF specification and found out that using !Type:Bank is not the right thing to do for all accounts, so I updated my script to use !Type:CCard for credit card accounts, but it was still not working. Unfortunately I am not sure anymore if I tested it with kmymoney 4.5.3 or only with 3.98.1. As exports always showing !Type:Bank I was assuming that the type is ignored by kmymoney and it's not worth to play around with it. Basically you confirmed now that the type is important which is good to know! Let me try it again with !Type:CCard for a credit card account and kmymoney 4.5.3. What type do I need to use for a deposit account? PS.: If the type is important then yes I agree, the export should use the correct type of the account and not a static one configured on a QIF profile. PPS.: Just as a feedback, I am not very happy with the date auto-detection feature for QIF imports because if there are only a few entries in the QIF file with dates like 12.10.2011 or 05.11.2011 then the auto-detection fails and I have to select each time the date format manually.
Created attachment 65258 [details] creditcard-test.qif
Here are the test results: Imported the attached creditcard-test.qif file to kmymoney 3.98.1 Result: A new giro account is created and the entries are not added to the existing credit card account Imported the attached creditcard-test.qif file to kmymoney 4.5.3 Result: A new giro account is created and the entries are not added to the existing credit card account
(In reply to comment #5) > Here are the test results: > > Imported the attached creditcard-test.qif file to kmymoney 3.98.1 > Result: A new giro account is created and the entries are not added to the > existing credit card account > > Imported the attached creditcard-test.qif file to kmymoney 4.5.3 > Result: A new giro account is created and the entries are not added to the > existing credit card account I've just imported your qif into 4.6.1, using the default profile and it correctly created a credit card account. I then deleted the transactions and re-imported. No new account was created - the existing credit card account was used. Which profile did you use? If you want to try 4.6, look for the Claydoh PPA.
(In reply to comment #3) > Actually I am interested in importing data to an existing account. The "Steps > to Reproduce" was just an example but maybe not a good one, sorry for the > confusion. > > My old script created QIF files with the following header: > > !Type:Bank > CX > POpening Balance > L[name of the account] > > This was working fine with all type of accounts and kmymoney 0.8.9 (Debian > Lenny). The data are imported to the existing accounts as expected. > > The script is still working for giro accounts in newer kmymoney versions. But > it does not work with other accounts like credit card or deposit accounts. A > new account is created instead with the same name. > > Then I checked the QIF specification and found out that using !Type:Bank is not > the right thing to do for all accounts, so I updated my script to use > !Type:CCard for credit card accounts, but it was still not working. > Unfortunately I am not sure anymore if I tested it with kmymoney 4.5.3 or only > with 3.98.1. As exports always showing !Type:Bank I was assuming that the type > is ignored by kmymoney and it's not worth to play around with it. > > Basically you confirmed now that the type is important which is good to know! > Let me try it again with !Type:CCard for a credit card account and kmymoney > 4.5.3. > > What type do I need to use for a deposit account? > I'm pretty sure you can use !Type:Bank for that. > PS.: If the type is important then yes I agree, the export should use the > correct type of the account and not a static one configured on a QIF profile. > > PPS.: Just as a feedback, I am not very happy with the date auto-detection > feature for QIF imports because if there are only a few entries in the QIF file > with dates like 12.10.2011 or 05.11.2011 then the auto-detection fails and I > have to select each time the date format manually. Can you think of a way for KMM to deduce the correct format in such cases, bearing in mind it will not know the country of origin of the file. With more items, the date format can be determined correctly.
> Which profile did you use? If you want to try 4.6, look for the Claydoh PPA. I have used the default profile but have not tested 4.6 yet. This is on my TODO list and I will let you know the results once available. > > What type do I need to use for a deposit account? > > I'm pretty sure you can use !Type:Bank for that. Okay, let me test this as well with 4.6. > > PPS.: Just as a feedback, I am not very happy with the date auto-detection > > feature for QIF imports because if there are only a few entries in the QIF > > file with dates like 12.10.2011 or 05.11.2011 then the auto-detection fails > > and I have to select each time the date format manually. > > Can you think of a way for KMM to deduce the correct format in such > cases, bearing in mind it will not know the country of origin of the > file. With more items, the date format can be determined correctly. I don't think there is a way to automatically detect it in this cases. I am not sure what's the benefit of the autodetection as there is none in my use case. All QIF files that I import are using the same date format, a statical configuration option would work perfect in my case. I assume the autodetection provides a benefit to users who import QIF files with different date formats. IMHO the perfect solution for both use cases would be a configuration option to enable or disable autodetection and if disabled there should be another configuration option to setup the date format used for all imports with this profile.
Were you able to test whether this works ok in 4.6.0 or not?
Just to let you know that this issue is solved in KMyMoney 4.6.2 (Debian Wheezy)
Solved as per user comment