QIF importer treatment of zero-sum split transactions

[William D. Hamblen]

Hi everyone,

On Fri, 4 Jan 2008, Derek Atkins wrote:

> Quoting Charles Day <cedayiv at gmail.com>:
>
>> There is some code in the QIF importer which says that if a QIF split 
>> transaction adds up to zero, then the signs of all of its split lines 
>> must get reversed. It looks very deliberate. Does anyone know why 
>> this would be?  It is causing a problem: because the signs get 
>> reversed, any split lines that contain a transfer between accounts 
>> don't match up properly with the other half of the transfer, causing 
>> the importer to create an extra, spurious transaction. (Try importing 
>> the attached QIF to see what I mean.)
>
> Yes, I remember adding that code a long time ago to handle the import 
> of certain types of transactions created by, IIRC, either Money or 
> Quicken.  So yes, it's very deliberate.  I'm pretty sure there's a 
> bugID attached to the changeset; feel free to look for that.

I think the relevant bugID is 105179.  Note that the svn log entry 
(r7994) has a typo; it mistakenly refers to bug 105139.  Here is a link 
to the bug report itself. 
http://bugzilla.gnome.org/show_bug.cgi?id=105179

> The biggest problem with QIF is that there really is no standard. 
> There are so many different ways to doing it that getting it right 
> 100% of the time is impossible.  If you fix it for person A, you break 
> it for person B.  So the only way to get it to work for both people 
> are to ask the user about ambiguities, or to include additional 
> information in your decision on how to interpret the data.

This is certainly very very true with QIF.  But does anyone have a sense 
for whether the current default behavior (reversing the signs on splits 
for a transaction which has a net zero value) is better than the 
alternative (just leaving it alone)?

In 17 years of exported Quicken data, I got bitten (but only once that I 
know of so far) by the behavior Charles described. The original filer of 
the bug exported from MoneyDance - could this be purely a MoneyDance 
export quirk?  If so there is an argument for doing what works for 
Quicken.  However, at the moment I have no idea how many of my Quicken 
transactions, if any, were "saved" by the current behavior.  So maybe 
the status quo is better for Quicken too.

  - Bill