When I did my import (over a decade ago, I believe), I had no problem with 
transfers. Since I was importing all in one pass, there were no duplicates 
created by transfers. 

I believe the duplication problem you describe specifically arises when you opt 
to import transaction data from individual accounts separately, since you have 
to tell the importer when a given transfer is already in the system from the 
other side. It’s precisely why I think it should NOT be the “preferred” way of 
importing from Quicken, since it forces the user to manually identify the other 
side of a transfer every time. That makes my head hurt just thinking about it. 

This is why I chose to run the Export-Import process iteratively, until I got 
the Quicken data massaged to my satisfaction. Then the imported data was all 

Most of the challenge had to do with random category variations, and 
uncategorized transactions—which you well know will end up in IMBALANCE-USD.

David T.

> On Apr 4, 2018, at 7:16 PM, David Carlson <david.carlson....@gmail.com> wrote:
> David T,
> Does the QIF importer detect duplicates created by transfers within the same 
> import file?  I seem to recall needing to separate accounts to different 
> files to detect them.
> David C
> On Wed, Apr 4, 2018 at 9:00 AM, David T. <sunfis...@yahoo.com 
> <mailto:sunfis...@yahoo.com>> wrote:
> Alen,
> What you’ve done with the Benefits section is better, but I still feel that 
> any mention of benefits of migration is misplaced here. Someone looking for 
> ways to migrate from Quicken presumably has already come to this conclusion.
> * I have edited the tips portion further. I added a tip regarding the whole 
> Categories/Accounts paradigm.
> * I modified your tip regarding import of categories only, since it isn’t 
> strictly necessary.
> I think it’s useful here to note that I didn’t have to either import the 
> account structure or individual accounts separately when I imported my large 
> QIF file way back in the dark ages—I simply exported everything in one big 
> QIF and did the import from that. That was when I discovered the holes in my 
> Quicken data. I chose to go back in to Quicken, fill in those holes, and 
> re-export the entire file again, repeating until I had a clean enough import 
> to move forward. I know that others have had a different experience.
> * I modified the tip about multiple currencies to more accurately reflect the 
> situation and make it clear that the problem isn’t with GnuCash, but with QIF.
> Cheers,
> David
> > On Apr 4, 2018, at 12:52 PM, Alen Siljak <alen.sil...@gmx.com 
> > <mailto:alen.sil...@gmx.com>> wrote:
> >
> > Hi, David,
> >
> > You are right. I've removed the benefits section but kept the fact about 
> > open data standards. Apart from being a benefit (to me), it is also a 
> > consequence of migration that may or may not be important for users.
> >
> >> You mention multi-currency problems with QIF, saying that GnuCash only 
> >> handles one currency per file. However, I am under the impression that the 
> >> problem of multiple currencies had to do with the *QIF* specification, and 
> >> not GnuCash. In other words, the problem isn't that GnuCash doesn’t handle 
> >> multiple currencies, it’s that QIF doesn’t. Can anyone confirm that for me?
> >
> > Yes, that's probably true. However, if an application interprets a transfer 
> > in such a manner that it takes 100 Euros from one and then deposits 100 AUD 
> > into another account without warning the user, that's a big no-no for me.
> >
> > Thanks for the feedback!

gnucash-user mailing list
To update your subscription preferences or to unsubscribe:
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Reply via email to