QIF importer treatment of zero-sum split transactions

[Charles Day]

On Jan 6, 2008 1:33 AM, Charles Day <cedayiv at gmail.com> wrote:

> 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
> >
>
>
For your consideration, I've attached a patch that allows QIF split
transactions with zero in the "T" line to pass through without sign reversal
(also described above).

Cheers,
Charles
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: zerotline.txt
Url: http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080107/f5dc430e/attachment.txt