QIF importer treatment of zero-sum split transactions

Charles Day cedayiv at gmail.com
Sun Jan 6 04:33:55 EST 2008


On Jan 4, 2008 2:54 PM, Charles Day <cedayiv at gmail.com> wrote:

> 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).
>
(snip)

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

Derek, zero-sum split transactions that also have a zero amount in the QIF
"T" line don't make any sense. But Quicken users are forced to enter them to
work around certain limitations. Moneydance users probably don't have any
need for these. Could we go back to the normal behavior (no reversals) for
split transactions that have a zero "T" line?  This would continue to
accommodate reversals for Moneydance imports, but also support the Quicken
workaround.

(snip)

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


More information about the gnucash-devel mailing list