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 good. 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 gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user 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.
