Bug 249363 - "Map to Online Account" cannot distinguish different accounts properly
Summary: "Map to Online Account" cannot distinguish different accounts properly
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: git (master)
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2010-08-28 23:50 UTC by Jan
Modified: 2018-09-28 18:32 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan 2010-08-28 23:50:57 UTC
Version:           unspecified (using KDE 1.2) 
OS:                Linux

I have defined two separate retirement (401K) accounts with the same financial institution. The accounts have separate logins and separate passwords when logging in manually, but correspond to the same employer.  When mapping to the online account, I can connect with either account, but the mapping tool can only map to a single account.  That is, when I enter the username and password in the mapping tool, I can only select from a single account, even though two exist.  Most likely, the reason is that the employer ID at the financial institution is the same.  The account number in the online settings is an employer account number; not an employee account number.  It is the same for both accounts.

Reproducible: Didn't try
Comment 1 Jan 2010-08-28 23:53:07 UTC
KMM 1.0.4 KDE 3.5.10
Comment 2 Tobias 2010-09-01 19:52:35 UTC
Hi,
I have a similar issue: I have several online accounts at the same bank institute. If I press "update account" kmymoney fetches the updates of the wrong account.
As a workaround: If I unmap the account and map it again, everything works fine.

I already had a look, if the account IDs of the online-accounts change, but as far as I can see, they remain constant.
Comment 3 Thomas Baumgart 2010-09-02 10:21:34 UTC
@Tobias: these are two seperate issues since you use different backends (OFX vs. HBCI). Do you use different KMyMoney files to access the accounts?

@Jan: If I get this right, you map an OFX account and after you entered your credentials in the wizard you see only one account at the institution. Which one of the two you have depends on the credentials you entered. Is that right? Do the accounts have different names/ids?

The credentials are based on a per institution base. Having different credentials for accounts at the same institution is not supported (yet).
Comment 4 Jan 2010-09-03 14:41:17 UTC
Sorry for the delay:  boot problems yesterday, and I have still not solved them.

Yes to Q1, No to Q2, Yes to Q3.

The wizard only lists a single account.  It gives an account number and a name.  The account number is the same whether I set up the map for the first account or the second.  It is the employer ID at the institution, and it must be returned by the institution's server, as I have not used this ID anywhere in KMM.  I believe the account name behind the number is the same as well.  In other words, I do not recall having been able to distinguish which account the wizard is displaying.  Inside KMM, the accounts have different names and ids:  "401K Jan" and "401K Cecile"; acct numbers "1", resp. "2".

The wizard maps the second account onto the first one, and downloads from both remote accounts go to the first local account.  So, KMM gets the remote connections right, but not the download of the second account.
Comment 5 Tobias 2010-09-03 17:11:43 UTC
(In reply to comment #3)

> @Tobias: these are two seperate issues since you use different backends (OFX
> vs. HBCI). Do you use different KMyMoney files to access the accounts?

Yes, I do.
Comment 6 Thomas Baumgart 2010-09-03 18:09:52 UTC
(In reply to comment #5)
> (In reply to comment #3)
> 
> > @Tobias: these are two seperate issues since you use different backends (OFX
> > vs. HBCI). Do you use different KMyMoney files to access the accounts?
> 
> Yes, I do.

This is a known limitation.  I opened the wish list item 250051 for it.
Comment 7 Cristian Oneț 2014-08-20 20:31:15 UTC
Moving this wish to kmymoney4.
Comment 8 Cristian Oneț 2014-08-22 06:47:23 UTC
Is this still valid or BUG 250051 fixes the problem?
Comment 9 Jan 2016-02-21 18:01:45 UTC
Bug still present.

1. When I update my wife's account, it puts her transactions in my account.

2. When I update my account, it says the password is not valid.

3. When I unmap and remap my account, it invalidates my password with the provider.  I can no longer use the company's interactive website and have to reset my password first.  After this is done, I can remap my KMM account, but the result is the same:  password invalid - see #2.

It looks like my comment #4 is still accurate:  the wizzard only lists one account.  I unmapped my account and mapped it again:  had only one choice.  I unmapped my wife's account; remapped it and had only one (the same) choice.  There are two different accounts with the same institution; only one can be mapped, but it maps to the wrong KMM account.  The other maps to the wrong online account and fails at login.
Comment 10 Jack 2016-02-21 22:12:51 UTC
If you have two accounts mapped, and then unmap one, when you go to remap that account, it will only show you the one which is currently unmapped.  I don't know if it will change anything, but if you unmap both accounts, and then try remapping, you might get the right one to each account. (This is only a guess on my part, based on some of the comments.)  Another thing you might try, is to check the full ofx log.  If you create an empty file in your home directory called ofx.log, then after you connect, it will contain a log of the OFX session.  I would try that with both accounts unmapped, and then again after you have mapped one of the accounts.
Comment 11 Jan 2016-02-21 23:33:56 UTC
Right, but I'd expect to see a difference between the two.  I noticed my wife's account had an account number 1 assigned and mine a  2 [edit account, institution tab).  That's not what I saw in the list.
As recommended, I unmapped both accounts and then remapped mine:  again only one account was listed.  Number shown was 09876.  Map succeeded.  When I updated my account, I again get the invalid user ID or password error.  Here is the full error text:
"Unable to import '/tmp/kde-jan/kmymoneypd6365.tmp' using the OFX importer plugin.  The plugin returned the following error: SONRS: Signon invalid (Code 15500):  The use cannot signon because he or she entered an invalid user ID or password. (Error occurred logging in)..." etc.  This time, my password was not invalidated.  That is, I connected to the provider's site in a browser without having to reset the password.  The tmp file mentioned contained a similar error message in html format.  I tried everything twice to make sure I did not accidentally enter a wrong password.

Next, I remapped my wife's account.  Again only one choice in the wizard.  Again, the transactions were added to my account.
Comment 12 Thomas Baumgart 2016-02-22 10:09:44 UTC
Could it be, that the OFX provider ask for a pin change procedure after first login? I kind of remember that we had trouble with this in the past. KMyMoney 1.0.4 certainly does not support it and I don't know if the newest one does.

Here's what someone with more OFX foo wrote to me about three years ago:

---8<---
In the OFX Profile response, within the <SIGNONINFO> aggregrate in a response will be the <PINCH> tag.  If this content of this <PINCH> tag is set to Y this means that the FI supports 'PIN Change'.  If it is set to N it means they do not support or require it.

Then, in the second phase of this (the OFX spec doesn't really discuss this in terms of phases, so this is my phrasing) what will occur is during a normal transaction of OFX which would include the SIGNONMSGSRQV1 (SONRQ) aggregate, the FI will return a status code of 15000 in the SIGNONMSGSRSV1 (SONRS) response.  This OFX status code specifically means that the password was rejected because it needs to be changed first.
---8<---
Comment 13 Jan 2016-02-22 15:47:53 UTC
Would the existence of a pin procedure be consistent with the fact that I can import operations for one account, even if they are loaded to the wrong ledger?

The Fidelity FAQ mentions that only a password is needed to access the account download service, the same as the interactive logon password.
Comment 14 Jan 2016-02-22 16:24:04 UTC
I think I see the problem.  We were both working for the same employer (I quit in the mean time but still have the 401K account).  The wizard showed only one account with a number.  It turns out this is the employer account number, not the individual's account number.

So, KMM seems to think there is only one account because there is only one number.  Is it possible to make it see both accounts?
Comment 15 Ralf Habacker 2017-11-25 00:41:39 UTC
Git commit dac4c32a569f6d7b9d81d675a74b9915269da143 by Ralf Habacker.
Committed on 25/11/2017 at 00:41.
Pushed by habacker into branch 'master'.

Extend ofx web service to provide two independent accounts

M  +121  -59   ofxtest.php

https://commits.kde.org/websites/kmymoney-org/dac4c32a569f6d7b9d81d675a74b9915269da143
Comment 16 Andrew Crouthamel 2018-09-28 02:33:43 UTC
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!
Comment 17 Andrew Crouthamel 2018-09-28 18:32:51 UTC
Git fix, moving to resolved.