How do I eliminate spurious duplicate accounts without corrupting properly transferred accounts after uploading QIF data?
I have downloaded the trial version of MD and am trying to see if it will work with my data. I transferred 18 years' worth of Quicken data using QIF, and uploaded them into my new Imac in two stages, as suggested (account list first followed by transaction data). The process worked surprisingly well. All of my categories transferred correctly and all the respective balances tallied. I thought everything was going well until I scrolled down the list and found many duplicate account entries that had the same respective account names but ended with an "X". When I checked to see what was going on, some of these "bogus" accounts contained duplicate transactions, others contained no transactions yielding zero balances, while at least one had no name at all. When I tried to delete a few of these "bogus" accounts (with zero balances), the transactions of the corresponding "real" accounts were corrupted, as well as their totals. How do I eliminate these obviously bogus accounts without corrupting the correct data in the real accounts?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Bob on 21 May, 2009 01:31 PM
I also see similar accounts. I blundered into them while looking at the XML. So I also would like to either clean them up or know why there are there. Is it somehting I did while importing from other software? And like dweber, how do I get rid of them without messing up the real accounts.
2 Posted by Ben Spencer on 22 May, 2009 02:40 PM
Hi
I'm afraid this is rather confusing and I'll try my best to explain.
Quicken puts some special transactions, such as "starting balance", into QIF files that have a category set equal to the account name, but with square brackets around it (which means it is a transfer). Instead of recording these as transfers to the same account (which would result in a zero overall value) Moneydance creates a category or account called "X" and sets the category to that. Deleting that category or account would result in those transactions being deleted, which would throw off the balance of the imported account. If you delete the "starting balance" transactions from these accounts and also adjusting the starting balance of the account to compensate it should be fine to then delete the "X" accounts.
Let me know if you need any further assistance.
Sincerely
Ben Spencer
3 Posted by Ben Spencer on 22 May, 2009 02:45 PM
I am not sure why you would be having a problem if you delete one of the "X" accounts if it is not involved in any transactions. What exactly do you mean by "the transactions of the corresponding 'real' accounts were corrupted," Please try and be as specific as you can.
Sincerely
Ben Spencer
4 Posted by dwebber on 22 May, 2009 09:58 PM
Thanks Ben, for your helpful explanation. Armed with this information, I checked to see whether most of the problematical transactions were related to transfers. When I found this to be true, I tracked some that so behaved. In the process, I also found some other discrepancies in the original Quicken data. Most were caused by inappropriate category designations which alluded to either income or expense depending on the particular circumstance. Other erroneous transactions were the result of inadvertent assignments to orphaned categories, etc. Needless to say, problems of this sort can play havoc when imported data are interpreted by MD; garbage in, garbage out! Rather than try to chase down all of these phantom account references individually in 18 year's data, I decided simply to archive the old data and start fresh in MD with newly defined (less ambiguous) categories, being careful to check the accuracy of the transfer sources and destinations. Fortunately, MD makes this easy by invoking the "move to other side" option when recording an unfamiliar transfer. Again, thanks! dwebber
5 Posted by Ben Spencer on 23 May, 2009 02:44 PM
You are very welcome
I'm sorry the import process did not go more smoothly for you.
Ben
Ben Spencer closed this discussion on 23 May, 2009 02:44 PM.