tag:infinitekind.tenderapp.com,2009-01-14:/discussions/praise/61-thank-you-and-one-oddityInfinite Kind: Discussion 2015-03-31T16:05:43Ztag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-05-25T21:53:10Z2010-05-25T21:53:13ZThank you and one oddity...<div><p>Oh, I should add that I followed the import instructions to the
letter. Each file in one export containing all accounts, and
importing the accounts only first, followed by the data.</p></div>ciarantag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-05-25T23:54:51Z2010-05-25T23:54:51ZThank you and one oddity...<div><p>FYI, when Moneydance shows the memo in square brackets, it means
you are looking at the "other side" of the transaction - meaning
the side other than where the transaction was created or entered.
For example, if you transfer 100. from checking to savings, and
make the entry in your checking account with the category
<em>Savings</em>, and memo <em>Transfer</em>, then open the savings
account register, you will see a deposit of 100. with category
<em>Checking</em> and the memo will show as
<em>[Transfer]</em>.</p></div>ljbtag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-05-26T03:51:03Z2010-05-26T03:51:08ZThank you and one oddity...<div><p>Ahhh... well that seems consistent with what I was observing,
and thus not really an additional symptom. Nonetheless, something,
either Quicken under the covers on export, or MoneyDance on import,
forked a copy of one of the splits as a separate transaction,
duplicating one of the splits. In all cases it was the flip side of
a transfer to another account (hence the square brackets). I
suppose I could try to grovel through the .qif file and figure out
if the transaction is actually there (hence a Quicken artifact).
But since it's all kinda working right now, AND I'm kinda busy, my
motivation is low :-/</p></div>ciarantag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-05-26T21:54:09Z2010-05-26T21:54:09ZThank you and one oddity...<div><p>OK, so I was needing a break from studying and I did some
investigation. It looks like a MoneyDance import error! Here's the
record as it appears in QIF (I changed the data to obscure private
information, but the format is exact):</p>
<p>D11/ 6/95<br>
U-1,724.00<br>
T-1,724.00<br>
CX<br>
NEFT-W<br>
PThe Co-Operative Bank<br>
M125 Nagog Park, Acton, MA 01720<br>
L[USTrust 104 Tower Street]<br>
S[USTrust 104 Tower Street]<br>
$-474.46 S104 Tower St.:Mortgage - Int<br>
$-683.20 S[USTrust 104 Tower Street]<br>
EAddition to Principal<br>
$-200.00 S[USTrust 104 Tower Tax Escrow]<br>
$-366.34 ^</p>
<p>Importing this record caused a correct transaction with 4
splits:<br>
1) $474.46 to the mortgage ACCOUNT<br>
2) $683.20 to mortgage interest CATEGORY<br>
3) $200.00 to the mortgage ACCOUNT (addition to principle)<br>
4) $466.34 to the tax escrow ACCOUNT</p>
<p>This transaction did not appear to update my balance in the last
column.</p>
<p>This transaction was followed by a transaction deducting $674.46
from the mortgage ACCOUNT. The memo here indicated a backside
transaction marked with [ ]. This transaction DID update my balance
in the last column.</p>
<p>However, the net effect of both these transactions was to debit
the $674.46 twice!</p>
<p>When I went through my account and deleted these transactions
that appeared to not update my running balance (always following a
split), everything cleared up and the account balanced
correctly.</p>
<p>I'll attach images of the spit and the two transactions in
MoneyDance.</p>
<p>Ciarán...</p></div>ciarantag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-06-10T15:59:35Z2010-06-10T15:59:39ZThank you and one oddity...<div><p>This is the exact issue I had when updating my Quicken data from
Quicken 2005 (including date pulled from Quicken 2001). In my case
the records were easy to spot because <strong>the duplicates were
not marked as resolved</strong>. It struck me as odd when I found
the first one because I intentionally resolved everything in
Quicken before the transfer, and have been good about resolving
items based on statements (even 401K items, which typically don't
get resolved). When I found the second one, it dawned on me what
was going on, and a quick search for all unresolved items found all
the duplicates (about 12 out of 4,000 imports) and made resolving
them easier.</p>
<p>MD folks: <em>You may want to mention this in your FAQ</em> area
as a tip to help those importing lots of historic data into
MoneyDance. Resolving everything before the transfer, and being
able to use the unresolved status to find/correct improper imports
was a huge time saver for me. :) But over all, pulling a decade of
info over with so few errors from a 3rd party app is pretty
impressive.</p></div>woody14619tag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-06-23T14:43:52Z2010-06-23T14:43:52ZThank you and one oddity...<div><p>Thank you all for this great information and these helpful
suggestions. We'll work it into our FAQ on the importing process in
the next few weeks.</p>
<p>Please let me know if I can be of further assistance, and thank
you again for sharing your tips and tricks for transitioning from
other programs.</p>
<p>Angie Rauscher<br>
Moneydance Support</p></div>Angie Rauschertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-06-23T15:02:55Z2010-06-23T15:02:55ZThank you and one oddity...<div><p>Hi Angie,</p>
<p>Do you think that the debugging information provided will help
unearth a<br>
bug? I'm not quite certain if the error is in how Quicken output
the<br>
QIF or how Moneydance pulls in the information, but I'm thinking
it<br>
might be Moneydance (I use to run a software QA organization in the
90s).</p>
<p>Ciarán...</p></div>ciarantag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-07-10T20:53:40Z2010-07-10T20:53:40ZThank you and one oddity...<div><p>I think the answer is that both Moneydance and the way Quicken
outputs the QIF are to blame.</p>
<p>If a transfer is included in a QIF file between two accounts
that transaction will be listed twice in the QIF file, once for
each account. Unfortunately the QIF file format does not include
any information that indicates that the two transactions are infact
two sides of the same transaction. Typically this is not too much
of a problem as moneydance will automatically look through all the
accounts near the end of the import process and determine if there
are duplicates based on the date and amount of the transaction.
Unfortunately when a split is involved in a transfer the amount in
the receiving account is not equal the total amount in the source
account. So we end up with a situation where Moneydance cannot
determine conclusively that the transaction is a duplicate.</p>
<p>The situation would be greatly improved if the QIF file format
contained a unique id linking both sides of a transaction and sadly
it does not.</p>
<p>I am sorry for the trouble this has caused you.</p>
<p>Sincerely<br>
Ben Spencer<br>
Moneydance Support</p></div>Ben Spencertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-07-11T02:02:30Z2010-07-11T02:02:30ZThank you and one oddity...<div><p>Hi Ben,</p>
<p>It was relatively easy to resolve, and I'm completely delighted
with<br>
Moneydance!!</p>
<p>Is there any way that the import process could apply a tag to
make<br>
finding splits with transfers easier? Then all you would have to do
is<br>
instruct users to validate tagged items for errors!</p>
<p>Ciarán...</p>
<p>Ciaran Anthony DellaFera, BSG<br>
UMass Medical School<br>
Class of 2012<br>
Sent from my iPhone</p></div>ciarantag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242010-07-13T15:38:34Z2010-07-13T15:38:34ZThank you and one oddity...<div><p>That is a really interesting suggestion. I could imagine auto
tagging foreign currency transfers as potential problems as well.
I'll being it up with the developers and see what they think.</p>
<p>I am glad Moneydance is working well for you.</p>
<p>Sincerely<br>
Ben Spencer</p></div>Ben Spencertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-02-21T05:30:38Z2011-02-21T05:30:38ZThank you and one oddity...<div><p>Just curious if this caught any further interest. Obviously
<em>I</em> don't need to import anything from Quicken ever again,
but others will :-)</p></div>ciarantag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-02-21T16:31:30Z2011-02-21T16:31:30ZThank you and one oddity...<div><p>Hi</p>
<p>It something we have left on the back burner for the time being.
The developers are hard at work getting Md2011 ready for release
and I am afraid a solution to this problem wont make it into the
release.</p>
<p>Sincerely<br>
Ben Spencer<br>
Moneydance Support</p></div>Ben Spencertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-07-08T03:16:53Z2011-07-08T03:18:05ZThank you and one oddity...<div><p>Hi,</p>
<p>I'm in the process of moving all my Quicken 2007 (Mac) files to
MD. During this process several of my accounts did not move
correctly. I traced the problem to how Quicken handles splits. If
you have more than one transaction within a split which has the
same account then Quicken will sum those transactions and generate
a single transaction for that account. MD sees that single
transaction and since it can't find a similar one in the other
account, generates a transaction to match it. See the attached
register files.</p>
<p>In the Chicago Title Register, the TCU Payoff split on 8/17/09
had two transactions for the TUC - Line of Credit account and four
for the House Base account. In each case the register for the TCU -
Line of Credit account had a single transaction which was the sum
($144,797.29) of the two transactions within the split. Likewise
the House Base register has a single transaction which was the sum
($587) for the four transactions in the split. In the Quicken file
the balance for each of the three accounts is zero. Not so after
importing into MD. These single transactions got added to the
Chicago Title account. There were other similar multiple
transactions which cause other account to be off.</p>
<p>I've attached the Splits.qif file which contains the above
mention accounts. This a good test case for MD use, just in case
they wish to add logic to handle multiple transactions for the same
account within a split. That is, logic could be added that looked
at all transactions within a split and if more than one was
associated with the same account, then just sum those transactions
and look at the transfer to account and check for a match.</p>
<p>As a work around I will remove the multiple transactions within
the split and enter them as single transactions.</p>
<p>John Prewitt</p></div>john.prewitttag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-07-11T06:27:38Z2011-07-11T06:27:38ZThank you and one oddity...<div><p>Hi John</p>
<p>Thank you so much for clarifying the cause of the issue. I am
quite confident that thanks to your help we will have a solution
implemented.</p>
<p>Sincerely<br>
Ben Spencer<br>
Moneydance Support</p></div>Ben Spencertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-07-19T03:04:10Z2011-07-19T03:04:10ZThank you and one oddity...<div><p>Hi John</p>
<p>We have a first pass at an algorithm that identifies and removes
collapsed split transactions during the QIF import process. I ran
it against your example QIF file and the algorithm identified and
removed the following transactions and their balancing entries.</p>
<p>[ParentTxn(-1) desc=Bank Of America Payoff; val=11700; stat= ;
#splits=1; chk=; acct=House Base; date=20090817; dirty;
splits=SplitTxn(-1): val=-11700; rate=1.0; amt=11700; desc=Bank Of
America Payoff; stat= ; cat=Chicago Title for Becado; ], ; ]</p>
<p>[ParentTxn(-1) desc=TCU Payoff; val=58700; stat= ; #splits=1;
chk=; acct=House Base; date=20090817; dirty; splits=SplitTxn(-1):
val=-58700; rate=1.0; amt=58700; desc=TCU Payoff; stat= ;
cat=Chicago Title for Becado; ], ; ]</p>
<p>ParentTxn(-1) desc=TCU Payoff; val=14479729; stat= ; #splits=1;
chk=; acct=TCU - Line of Credit; date=20090817; dirty;
splits=SplitTxn(-1): val=-14479729; rate=1.0; amt=14479729;
desc=TCU Payoff; stat= ; cat=Chicago Title for Becado; ], ; ]<br>
setStatus(, 0.0)</p>
<p>I have attached two .md data files.</p>
<p>"withoutCollapsedSplitRemoval.md" which is the result of
importing your QIF file without the new algorithm.</p>
<p>and</p>
<p>"withCollapsedSplitRemoval.md" which is the result of importing
your QIF with the new algorithm.</p>
<p>Would you be willing to take a look at the two files and let me
know if you are satisfied with the results. Do you see other
transactions in your data file that should have been caught and
removed?</p>
<p>Many thanks<br>
Sincerely<br>
Ben Spencer<br>
Moneydance Support</p></div>Ben Spencertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-07-20T15:23:48Z2011-07-20T15:23:48ZThank you and one oddity...<div><p>Ben,</p>
<p>I looked at the two files and they look o.k. to me. I could
provide a full .qif file which contains many more such splits.
Would you want such a file.</p>
<p>John</p></div>john.prewitttag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-07-25T19:52:41Z2011-07-25T19:52:41ZThank you and one oddity...<div><p>John,</p>
<p>I think we're good with the current data we have, but I'll
certainly let you know if we need anything else. Thanks for your
help and energy in running and working on correcting this
issue.</p>
<p>Angie Rauscher<br>
Moneydance Support</p></div>Angie Rauschertag:infinitekind.tenderapp.com,2009-01-14:Comment/17766242011-07-25T20:01:33Z2011-07-25T20:01:33ZThank you and one oddity...<div><p>Angie,</p>
<p>Via another discussion, Ben showed that Build 792 had fixed this
problem so I downloaded it and imported the full .qif and it
worked.</p>
<p>John</p></div>john.prewitt