On 2018.04.19 10:52, Jack wrote:
On 2018.04.19 03:16, Thomas Baumgart wrote:
On Donnerstag, 19. April 2018 00:06:24 CEST Jack wrote:
Since the release of 5.0, there have been several different threads
about accounts not being able to update (direct-ofx) but still
appearing mapped (you can unmap the account, but not update it.)
>
I just ran into this again with a version compiled from git head
maybe two weeks ago. (I'm starting a new compile now.) My main
investment account showed this problem. So - I unmapped and
remapped, set the download start date, updated the account, fixed
some transaction details, and saved the file. I noticed some
apparently missing transactions, and went to update the account
again - but it was back in the starting state - no online details
in the account edit page, but I can unmap and remap. I did that,
then immediately saved the file, and it reverted to not being able
to update the account.
>
Does this seem like something in the file/save process is changing
something so it won't work? I have not yet identified anything in
the file that seems wrong, but other accounts at the same broker
(Merrill Lynch) continue to work fine, so far only this one account
shows this problem.
>
> Does this trigger any thoughts as to what might be going on?
I thought, that I have fixed that a while ago on the 5.0 branch:
commit bd6c509f2b2bef5fed962e751d13e14c68190980 (5.0)
Author: Thomas Baumgart <t...@net-bembel.de>
Date: Mon Apr 2 10:35:42 2018 +0200
Keep the OFX importer object name as provider
Using the new plugin structure there is no need to use a fixed
name anymore. Use the objectName() instead and things match.
BUG: 392603
FIXED-IN: 5.0.2
and master as well:
commit 4480920d5d8627384e5cf1a1396644191e732df5
Author: Thomas Baumgart <t...@net-bembel.de>
Date: Mon Apr 2 10:39:08 2018 +0200
Keep the OFX importer object name as provider
Using the new plugin structure there is no need to use a fixed
name
anymore. Use the objectName() instead and things match.
BUG: 392603
(cherry picked from commit
bd6c509f2b2bef5fed962e751d13e14c68190980)
or do we chase a different one here?
Of course with fresh compiles, I can no longer reproduce this. :-(
Perhaps the last of those commits was after my previous compile.
On the other hand, once KMM managed to correctly (?) import all
pending transactions in the problem account, I now have two more
months with the problem interest transactions I've mentioned
elsewhere. I got January to work OK by downloading the dates other
than the one with those interest transactions, and I suppose I'll
have to do that for Feb and March also. (I know the issue is at
least partly due to how Merrill Lynch creates those transactions, but
once imported, they claim the category used is a closed account and
so I can't edit or delete the transaction. That category does appear
still open, but we can keep that discussion in the other thread.)
It seems I spoke too soon. With new versions (I've tried both 5.0 and
master) I started seeing the problem again. However, I think I finally
found the culprit, although still not the cause. All other mapped
accounts have provider="ofximporter" but the problem account has
provider="OFX Importer" - even if it is case insensitive, there is an
extra space in the middle. Manually fixing this in the file and
reopening in KMM, and I can update.
However, after a new import, I tried to match one imported transaction
with a manually entered on, and got "Unable to accept transaction:
Invalid transaction id 'T000000000000015347', thrown in
/usr/portage/tmpdir/portage/app-office/kmymoney-9999/work/kmymoney-9999/kmymoney/mymoney/storage/mymoneystoragemgr.cpp:915".
Oddly, the match seemed to work OK, and doing a find on that
transaction shows it is the transaction just earlier in time to the
manually entered one I just merged. This seems somehow similar to the
crash I get on closing a file after importing one of those transactions
which ends with a "closed" category complaint. It seems to not be able
to find an account or transaction which does exist. I'm wondering if
there might be a stray, non-printing character in the ID, or if there
might be some encoding or character mapping issue? I know I'm grabbing
at straws here.
As always, troubleshooting suggestions are welcome.
Jack
