On Jan 6, 2008 1:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008 2:54 PM, Charles Day <[EMAIL PROTECTED]> wrote:
>
> > On Jan 4, 2008 9:37 AM, William D. Hamblen <
> > [EMAIL PROTECTED]> wrote:
> >
> > > Hi everyone,
> > >
> > > On Fri, 4 Jan 2008, Derek Atkins wrote:
> > >
> > > > Quoting Charles Day <[EMAIL PROTECTED]>:
> > > >
> > > >> 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
Index: src/import-export/qif-import/qif-objects.scm
===================================================================
--- src/import-export/qif-import/qif-objects.scm (revision 16844)
+++ src/import-export/qif-import/qif-objects.scm (working copy)
@@ -300,12 +300,14 @@
(qif-xtn:splits self) amounts))
(define (need-neg amounts)
- (let ((sum (gnc-numeric-zero)))
- (for-each
- (lambda (amt)
- (set! sum (gnc-numeric-add sum amt 0 GNC-DENOM-LCD)))
- amounts)
- (gnc-numeric-zero-p sum)))
+ (if (gnc-numeric-zero-p (car amounts))
+ #f
+ (let ((sum (gnc-numeric-zero)))
+ (for-each
+ (lambda (amt)
+ (set! sum (gnc-numeric-add sum amt 0 GNC-DENOM-LCD)))
+ amounts)
+ (gnc-numeric-zero-p sum))))
(let ((def-spl (qif-xtn:default-split self)))
(if def-spl
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
