tag:infinitekind.tenderapp.com,2009-01-14:/discussions/switching-from-another-personal-finance-program/17750-incorrect-import-of-quicken-2007-split-transfersInfinite Kind: Discussion 2021-02-03T05:40:23Ztag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-02T00:13:46Z2020-11-02T00:13:46ZIncorrect import of Quicken 2007 split transfers<div><p>I'm also holding off importing my complete history due to this issue so</p>
<p>+1 please.</p></div>tgilbert666tag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-02T00:27:31Z2020-11-02T00:27:31ZIncorrect import of Quicken 2007 split transfers<div><p>I'm a fellow user.</p>
<p>I believe I understand what is happening here.</p>
<p>Moneydance is built upon the principles of Double Entry Accounting. At the core of Double Entry is the rule that for every debit there must be a corresponding and equal credit.</p>
<p>There is no provision in Accounting for aggregating entries on one side of a transaction. So I think you are seeing how double entry works with such transactions. You have individual splits on one side hence individual transactions for all intent. Moneydance replicates this on the other side (in the other account) to satisfy accounting rules. you then have what you know is a consolidated transaction. All Moneydance can see is there is not a corresponding transaction in the other account hence creates it.</p>
<p>Having corresponding and equal transactions are an absolute rule in Accounting</p></div>dwgtag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-02T03:42:54Z2020-11-02T03:45:33ZIncorrect import of Quicken 2007 split transfers<div><p>a user here<br>
As dwg stated, MD relies on accounting principles.</p>
<p>To try to state it more simply (imo), Quicken allows the creation and destruction of money when one uses an account to apply all cash (or some cash) to its own account.</p>
<p>MD doesn't allow that. I find that usually MD creates a new ACCOUNTX account to hold those funds, but maybe in a split transaction, that's not what happens.</p>
<p>Still, dwg is correct - Quicken allows money creation/destruction, whereas MD insists on putting that money "somewhere" - which can be confusing, even if it is Quicken that is not following proper accounting principles.</p></div>dtdtag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-03T01:04:29Z2020-11-03T01:19:56ZIncorrect import of Quicken 2007 split transfers<div><p>@dtd: I know what you mean about Quicken allowing using the own account as a source of money. In no transaction am I doing that, except for the opening balance transaction, which Moneydance doesn't have a problem with.</p>
<p>@dwg: The issue here is not what Moneydance allows or does not allow. The problem here is that it is unable to import the QIF and convert the transactions correctly into what it does support.</p>
<p>What we have here is a transaction matching problem. On one side of the transfer, the QIF contains two split details for the same account. On the other side of the transfer, the QIF contains a single entry for the aggregate amount. This balances perfectly, if you match up the two sides of the transfer.</p>
<p>Moneydance has three options for how to handle this, depending on what it supports:</p>
<ol>
<li>
<p>It could import as in Quicken: separate line items on the split side, aggregate on the other side.</p>
</li>
<li>
<p>It could combine the two split details into an aggregate on the split side, so that they then will match to the aggregate entry on the other side. (The disadvantage would be if the two line items have different memo values, you'd lose the distinction.)</p>
</li>
<li>
<p>It determine that the aggregate on the other side is a match for the two line items, and replace the aggregate entry with two separate transactions.</p>
</li>
</ol>
<p>What it should not do is import what is in the QIF and then create extra transactions on both sides. That is just wrong.</p>
<p>Note: I have a reduced test case that demonstrates this issue, with a small QIF file, if you want to see exactly what is happening. I can upload it.</p></div>mschmitttag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-03T01:25:47Z2020-11-03T01:25:47ZIncorrect import of Quicken 2007 split transfers<div><p>You should upload it. That way some may test it (sorry, I am in the middle of a few things, but there are many here who will check it out)</p>
<p>Here's my interpretation of what you said, so if I don't understand, you can clarify.</p>
<p>You have a transaction, and it is a split. You have a memo, and a category, but the value goes into an account, so it is a transfer. You have another memo, and a category, and that value goes into the same account.</p>
<p>Could you give an example of this (other than the QIF file) where this makes more than just theoretical sense?</p>
<p>Thanks!</p></div>dtdtag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-03T05:46:03Z2020-11-03T05:46:07ZIncorrect import of Quicken 2007 split transfers<div><p>I'd have to hunt down all the cases where I have this kind of double-transfer to see why, but I can assure you I have a good reason in each case.</p>
<p>In the particular transaction I was looking at this time, it was because I had paid for a purchase using three sources of money: cash, plus 2 gift cards. The transaction was entered in the cash account. The transfers were from an account that held the gift card balances. It was two transfers to show how much was paid from each of the two gift cards.</p>
<p>Another example would be a paycheck, with contributions for Roth IRA plus Roth IRA Catch-up. They are two separate line items because that's how they are on the paycheck, but they are transferring out to the same Roth IRA account.</p></div>mschmitttag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-03T05:55:22Z2020-11-03T05:55:24ZIncorrect import of Quicken 2007 split transfers<div><p>Attached is a recreation of both import problems in a reduced test case.</p>
<p>The zip file contains:</p>
<ul>
<li>A small Quicken 2007 data file</li>
<li>The exported QIF of that file</li>
<li>The Moneydance 2021 data file that results when you import this QIF</li>
<li>A screen shot of the Quicken 2007 accounts</li>
</ul>
<p>The Quicken file contains three accounts:</p>
<ul>
<li>Cash: This account has 1 transaction</li>
<li>Checking: This account has 3 transactions</li>
<li>Brokerage: This account has 1 transaction</li>
</ul>
<p>On a successful import, all three accounts would have a $0 balance. The Market value in the Brokerage account would be $100.01.</p>
<p>The actual results are that the Cash account is $38.65, the Checking account is -138.65, the Brokerage account has a $100 cash balance.</p>
<p>The import shows the following problems:</p>
<ol>
<li>
<p>It created an empty account “Unknown: PAYEE” for no apparent reason.</p>
</li>
<li>
<p>The Cash account created an extra transaction depositing $38.65.</p>
</li>
<li>
<p>The Checking account double-posted the 7/2 transactions, and created an extra BuyX transaction on 7/14. Also note that the BuyX transaction has a blank description.</p>
</li>
<li>
<p>The Brokerage account created an extra transaction. Which transaction is the extra one depends what you think it should be doing here.</p>
</li>
</ol>
<p>The trick to creating the Brokerage problem is this:</p>
<ol>
<li>
<p>Start with a Checking transaction that is a split.</p>
</li>
<li>
<p>One of the split line items transfers $ to a “Mutual Fund” account. This creates a special situation: A BUY transaction that is transferring money from a split line item. This is the only way to create this situation; it’s not possible when transferring money to a Brokerage account.<br>
That might be enough to create the Moneydance issue, but in this example I then:</p>
</li>
<li>
<p>Convert the Mutual Fund account into a Brokerage account, by:<br>
3a. Create a brokerage account<br>
3b. In the Quicken Portfolio, drag the security from the Mutual Fund account to the Brokerage account.</p>
</li>
</ol></div>mschmitttag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-03T05:57:16Z2020-11-03T05:57:18ZIncorrect import of Quicken 2007 split transfers<div><p>Hmm, lost the attachment, let's try again...</p></div>mschmitttag:infinitekind.tenderapp.com,2009-01-14:Comment/487904362020-11-04T05:31:57Z2020-11-04T06:41:45ZIncorrect import of Quicken 2007 split transfers<div><p>I'm a fellow user.</p>
<p>I have examined you gift card split transaction.</p>
<p>In the split your have two transactions:</p>
<ol>
<li>
<p>transfer to Cheque A/C 17.43</p>
</li>
<li>
<p>Transfer to Cheque A/c 21.22</p>
</li>
</ol>
<p>For a total of 38.65</p>
<p>Quicken has the ability to take these two transactions and to post a single transaction for the total amount to the Cheque A/C which is what has happened.</p>
<p>From a Quicken perspective this is just fine.</p>
<p>For any program that is based on accounting principles this is a totally invalid thing to do. You just do not do this in accounting.</p>
<p>When receiving this data Moneydance needs to resolve the problem.</p>
<p>There is no linkage between the 2 split transactions and the aggregate transaction in the QIF data, there is no way in QIF of having anything that would indicate there is a relationship. In Quicken there is no linkage either, the Data Entry Wizzard is what created the aggregate transaction. The underlying Quicken data structures do not following accounting principles.</p>
<p>The decision Moneydance has to make is how to make the transactions comply with the rules. The data coming from another program is deemed to have been reconciled and is correct as it is, there is no sense that this data should be altered in any way, and in any case Moneydance would not know how to change it, the software does not have the underlying knowledge the user does on the data.</p>
<p>The software is left with the option of adding in the transaction that the existing transaction would indicate is required.</p>
<p>An entry in one register for 38.65 that is a transfer from another account where there is no corresponding entry points to a need to have a transactions in that account for this amount.</p>
<p>Likewise with the transactions of 17.43 & 21.22. They do not exist in the other account so are created.</p>
<p>A basic principle of double entry accounting that for every debit transaction there must be a corresponding and equal credit transaction.</p></div>dwg