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 150569 - OFX/HBCI importer should help the user more not to create Imbalance-XY transactions
OFX/HBCI importer should help the user more not to create Imbalance-XY transa...
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Import - AqBanking
git-master
Other All
: Normal enhancement
: ---
Assigned To: gnucash-import-maint
gnucash-import-maint
: 430032 (view as bug list)
Depends on:
Blocks: 430032
 
 
Reported: 2004-08-19 17:34 UTC by Derek Atkins
Modified: 2018-06-29 20:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Derek Atkins 2004-08-19 17:34:56 UTC 
The OFX importer can create imbalanced transactions.  It should never do this. 
If the user does not supply an account then the importer should use (or create
if it does not already exist) an Unspecified account and use that for the
balancing split.

Gnucash should NEVER create imbalanced transactions.
Comment 1 Christian Stimming 2004-08-24 14:32:53 UTC 
For the record: The same thing happens on HBCI imports. The reason is in the
current implementation of the import-matcher and this would need to be deeply
changed in order to fix this. 

Currently the import-matcher already receives a gnucash-Transaction, no
intermediate other data type. The Transaction needs to have an account. If the
Transaction should point to some Unspecified account, it would need to exist
beforehand -- but in most cases it is needed only temporarily, which means it
should not be created as a "normal" gnucash-Account. This can IMHO only be fixed
if the import-matcher would receive a new data type (say, ImportTransaction),
which only upon hitting "Ok" will be converted to actual gnucash transaction.
Comment 2 Christian Stimming 2006-08-04 09:48:14 UTC 
Issue still exists in 2.0.x/SVN.
Comment 3 Christian Stimming 2008-12-02 10:23:58 UTC 
*** Bug 430032 has been marked as a duplicate of this bug. ***
Comment 4 Phil Longstaff 2009-04-23 23:51:50 UTC 
Would it be sufficient to have xaccTransCommitEdit check that the transaction is balanced and do something (destroy transaction, log info and provide dialog message for user) if it isn't?  Will all cases where a transaction is created and/or split is added require xaccTransCommitEdit?
Comment 5 Manfred Usselmann 2010-12-14 15:11:05 UTC 
Isn't that already implemented with the the call to xaccTransScrubImbalance from xaccTransCommitEdit?
Comment 6 Derek Atkins 2010-12-14 15:56:55 UTC 
Arguably..  I think the UI makes it too easy to leave it imbalanced.  The scrubbing will put it into an IMBALANCE-XXX account, but I think the UI should be more proactive in encouraging users to apply destination accounts to transactions.
Comment 7 Derek Atkins 2010-12-14 15:57:36 UTC 
... However re-reading my original report I guess technically this bug might be solved, but I still think the UI should be more proactive...
Comment 8 Manfred Usselmann 2010-12-14 17:28:47 UTC 
Well, in case of missing destination account the transaction is highlighted with orange background color, so it is clearly visible to the user that something is not quite right. 

When using the register to enter transactions, it is very easy the skip the destination account with the tab key and there is no feedback at all. The IMBALANCE-XXX account is used as well in this case.

I think we can close this bug, if you agree? Or at least lower the priority. :-)
Comment 9 Christian Stimming 2010-12-14 19:45:50 UTC 
Right. Changing to enhancement.
Comment 10 John Ralls 2018-06-29 20:46:25 UTC 
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=150569. Please continue processing the bug there and please update any external references or bookmarks.