SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. From File->Import menu select "OFX..." 2. Choose the file 3. Change the account using the droplist has no effect and operations are imported in the account specified in the ofx file OBSERVED RESULT Operations are imported in the account described in the ofx file (<BANKACCTFROM></BANKACCTFROM>) EXPECTED RESULT Operations should be imported in the account choosen in the droplist SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
I think this is by design. Once you have imported an OFX file and specified the account, further files for that account will always be imported to the same account. Why would you want to import to a different account? I suppose if you accidentally made the initial import into the wrong account, then there needs to be a way to correct that by somehow breaking the link between the account identifiers. Please let us know a bit more about what you are trying to accomplish.
Hello, I have a bank account and Visa Credit Card associated to this bank account. I have created an account to monitor my bank account in kMyMoney and I have created a second account to monitor the expenses linked to my Visa Credit Card. My bank provides me an OFX file for my bank account => this file is correctly imported into my bank account. My bank provides me also an OFX file for my credit card => I would like to import this file into the account dedicated to my credit card Both OFX files have the same value in the tag <BANKACCTFROM></BANKACCTFROM>. That is why it is useful for me to manually change the file when importing data from file so that operations are imported in the relevant account. From an UX point of view, if you let the possibility to manually change the destination account in the drop list when importing, we expect this choice has an effect. In case this choice should have no effect, the choice should not be possible. Regards. Lilian Le 13/09/2022 à 00:05, Jack a écrit : > https://bugs.kde.org/show_bug.cgi?id=458995 > > Jack <ostroffjh@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Resolution|--- |WAITINGFORINFO > Status|REPORTED |NEEDSINFO > > --- Comment #1 from Jack <ostroffjh@users.sourceforge.net> --- > I think this is by design. Once you have imported an OFX file and specified > the account, further files for that account will always be imported to the same > account. Why would you want to import to a different account? I suppose if > you accidentally made the initial import into the wrong account, then there > needs to be a way to correct that by somehow breaking the link between the > account identifiers. > Please let us know a bit more about what you are trying to accomplish. >
Please, when you reply to a bug by email, remove everything except your response, as the entire message becomes the next comment in the bug. Personally, I would say your bank is wrong in using the same account number for both a checking and credit card account, but I also know the bank doesn't care. I can think of two possible approaches for this, but I have no idea which is preferable, of if the developers would choose something else. First, as you suggest, is to make the dropdown for account actually active and functional. The other would be to find if there is anything in the OFX file which might determine what type of account it is for, and if it doesn't match the expected target, ask the user. Unfortunately, while I'm sure it is possible to distinguish investment transactions from banking ones, I don't know if there is a distinction between checking and credit card transactions. For now, I think we wait for input from the developers.
Here's what the OFX spec (v2.3) says about the BANKACCTFROM OFX uses the Banking Account aggregates to identify an account at an FI. The aggregates contain enough information to uniquely identify an account for the purposes of statement download, bill payment, and funds transfer. <CCACCTFROM> identifies credit card accounts; see section 11.3.2. <LOANACCTFROM> identifies loan accounts; see section 11.3.7. Within that aggregate, there are the elements ACCTID and ACCTTYPE. Are they present and are they also identical? Can you anonymize the two files by replacing any personal information and provide it as attachment or via personal mail?
Created attachment 152172 [details] checking.ofx Hello, Please, find enclosed the OFX file for the checking account and the credit card account. I guess those files do not follow the standardization rules since the tag <CCACCTFROM> is not present in the credit card file. Regards. Lilian
Created attachment 152173 [details] creditcard.ofx
Well, both statements include "<ACCTTYPE>CHECKING" which is clearly wrong for the credit card account. I don't know if there is any point in your trying to get the bank to fix it's software. One possible thing to check - in the portion of the files you omitted, do they use the same transaction types, or is there a difference? I don't have a copy of the OFX definition to see what they SHOULD be, but it doesn't really matter if the bank doesn't follow the standards.
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 mark the bug 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!
I'm not sure what the right resolution should be here, as it seems the underlying problem is a bank that issues OFX files that do not follow the standard. Given the low probability of getting the bank to change anything, is there anything KMM can do, or does the OP just need to edit the OFX file for one of the two accounts before importing?
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!