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 > 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
