After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 430032 - OFX import still inserts ignored transactions
OFX import still inserts ignored transactions
Status: VERIFIED DUPLICATE of bug 150569
Product: GnuCash
Classification: Other
Component: Import - OFX
git-master
Other All
: Normal normal
: ---
Assigned To: Benoit Grégoire
Benoit Grégoire
Depends on: 150569
Blocks:
 
 
Reported: 2007-04-15 16:36 UTC by Pete
Modified: 2018-06-29 21:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample ofx file (937 bytes, text/plain)
2007-04-15 16:38 UTC, Pete
Details
test gnucash file to demonstrate ofx import error (990 bytes, application/x-compressed)
2007-04-22 16:07 UTC, Pete
Details

Description Pete 2007-04-15 16:36:02 UTC
Please describe the problem:
When the OFX importer is directed to "Do not import" a specific transaction, the transaction is still imported into the register.  Sample ofx file attached, including a single $0.00 transaction.

Steps to reproduce:
1. Import attached OFX file (single $0.00 transaction in file, identify destination account as appropriate)
2. Select "Do not import (no action selected)" for transaction
3. Click ok.  The $0.00 transaction is still recorded in register.


Actual results:


Expected results:
The transactions do get recorded in the register.

Does this happen every time?


Other information:
This situation happens when I purchase airline tickets online.  Two transactions appear: one for the airline ticket itself, and another ($0.00) for Automatic Flight Insurance.  Manually deleting these $0.00 transactions after directing the importer to ignore them is a pain.
Comment 1 Pete 2007-04-15 16:38:20 UTC
Created attachment 86385 [details]
sample ofx file
Comment 2 Josh Sled 2007-04-21 18:04:48 UTC
I can't confirm with 2.0.5 and libofx-0.8.0-r1 against an empty/new file with the Common accounts hierarchy selected.


What version of libofx?  Can you repro against a new/empty file?
Comment 3 Pete 2007-04-22 16:07:31 UTC
Created attachment 86789 [details]
test gnucash file to demonstrate ofx import error

Using this "default" account file and previous ofx file, can duplicate this issue with Gnucash svn r15950 and libofx cvs (as of 18 April 07).  When importing, Gnucash asks which account to attribute transactions.  For simplicity's sake, I select the Checking Account.  I then direct the importer to "not import" the single transaction, and click ok.  I can see the transaction is recorded when I open the Checking Account register.
Comment 4 David Reiser 2007-06-26 14:45:22 UTC
r16209 or 16210 fixes this particular instance of the behavior.

However, not all cases of "still appears in register after I tell it not to import the transaction" are cured.

The real behavior here is that the transaction appears in the register, but it is not in the data file.

If you:
  tell gnucash not to import the transaction
  click OK in the general import transaction matcher dialog

The transaction appears in the register view. However, the transaction is not in the data file (and, at least for some of my cases, you can't delete it from view -- click on transaction, click Delete button -> nothing happens; and gnucash may crash soon)

After the import, if you:
  save the data file
  quit gnucash
  restart gnucash

The transaction no longer appears in the register.

If you examine the raw xml, the transaction is not there. 

And I think you can tell this because you can reimport the file. Ofx unique transaction IDs will normally keep formerly imported transactions from appearing again. But the 0.00 transaction in the sample file reappears for confirmation of import. In fact, if you tell gnucash not to import the transaction, you can keep importing this file and have multiple phantom transactions appear in the register.

There is definitely some glitch in the hand-off between the import transaction matcher and the register display. I just haven't been able to nail it down cleanly. And I think it is on the register side, not the import side.
Comment 5 Christian Stimming 2007-06-26 15:17:42 UTC
Nah, I think the issue is rather on the import side: If bug#150569 were fixed, the to-be-imported transactions will not show up in the register unless Ok is clicked *and* they have been selected for import. It is suboptimum that they currently already appear in the register *before* Ok was clicked, and that's what bug#150569 is about.
Comment 6 Christian Stimming 2008-12-02 10:23:58 UTC
The one issue of this bug is bug#150569, but there are still reports about transactions being imported, see bug#434944.

*** This bug has been marked as a duplicate of 150569 ***
Comment 7 John Ralls 2018-06-29 21:32:05 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=430032. Please update any external references or bookmarks.