QIF importer treatment of zero-sum split transactions

[Charles Day]

On Jan 4, 2008 9:37 AM, William D. Hamblen <William.D.Hamblen at dartmouth.edu>
wrote:

> 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
>

Yeah, 105179 looks like the right bug... from reading the bug description,
the QIF format from Moneydance is different from Quicken (as Derek said).
The Moneydance QIF has a split transaction with a negative total but two
positive splits. Weird! So this is really a Moneydance thing that the QIF
import is handling. Seeing that the last activity on that bug was 4 1/2
years ago, I wonder whether Moneydance has changed their format to match
Quicken's by now (not every importer would be so accomodating).

> 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.
>

I'd hazard to say that how Quicken uses QIF is the standard, if not by
history (it is the Quicken Interchange Format, after all) then de facto by
market share and volume. But that's a convenient answer for me, being a
Quicken user.  ;-)

> 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.
>

Assuming Moneydance hasn't fixed their format, we could ask the user for
guidance. But since all Moneydance split transactions would bomb without the
importer's accomodation, and only zero-sum splits are affected for
non-Moneydance imports, it doesn't seem worth it. Quicken users can fix
their zero-sum split transactions by hand. Although syntactically valid,
they really don't pass the "common sense" test anyway. William and I only
used them to get around a Quicken limitation on depositing checks directly
into investment accounts.

I could add some comments to 105179 to reflect what we've discussed here.

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


-Charles