tag:infinitekind.tenderapp.com,2009-01-14:/discussions/general-questions/96230-is-it-possible-to-bulk-move-transaction-amounts-from-debit-to-credit-or-vice-versaInfinite Kind: Discussion 2020-07-03T21:40:24Ztag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-01T11:11:00Z2020-04-01T11:11:36Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>I found the source of the issue - for all the good it'll do me. . .</p>
<p>In my other two credit card accounts, charges against the card, (purchases), are marked with a transaction type of "debit". Payments to the account are given a transaction type of "credit".</p>
<p>In the Bogus of America account, purchases are styled as "payment", and payments to the account are styled as "credit" - ergo, <strong><em>everything</em></strong> is a credit to the account and <strong><em>nothing</em></strong> is a charge against it. (<em>i.e.</em> There are no "debit" transactions at all.)</p>
<p>So, aside from doing a global search-and-replace on the original QFX files - one for each and every month! - is there a way to move the transaction amounts within Moneydance without having to re-type everything.</p>
<p>Both of these solutions would entail considerable rework. Importing corrected QFX files will result in duplicate transactions galore and moving the amounts manually entails editing every single non-payment transaction - which is the lions share and is a non-trivial task. Actually <strong><em>both</em></strong> fix-ups are non-trivial.</p>
<p>I'd <strong><em>really</em></strong> rather not have to spend a week-or-so retyping and/or de-duplicating my entire current transaction list by hand.</p></div>jimrhtag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-01T11:52:57Z2020-04-03T09:03:56Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>OK, another update:</p>
<p>What I ultimately ended up doing:</p>
<ol>
<li>Went through each BoA QFX file, (using Notepad++, it preserves the EOL formatting of the file), and replaced every occurrence of <code><TRNTYPE>PAYMENT</code> with <code><TRNTYPE>DEBIT</code>.<br></li>
<li>Went back to the beginning of this year's BoA records and deleted all the transactions.<br></li>
<li>Re-imported everything.</li>
</ol>
<p>Result: All the transaction amounts are in the correct column.</p>
<p>I'd mark this as "[SOLVED]", but I don't know if anyone else has a better solution - yet.</p></div>jimrhtag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-01T13:21:43Z2020-04-01T13:21:43Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>I am not support staff, just a user.<br>
Hi jimrh</p>
<p>As you have found BOA are breaking the OFX specifications.</p>
<p>Moneydance have added a fix that is available in later builds of 2019.<br>
From the Moneydance menu bar, go to File - Preferences.<br>
On the 'Network' tab, tick the checkbox to 'Ignore Transaction Types in Favor of Amount Signs'.</p>
<p>Do a EXPORT BACKUP before you try this in case something goes wrong.</p>
<p>Hope this helps.</p></div>derekkent23tag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-03T08:58:54Z2020-04-03T08:58:54Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>BoA is breaking more than the QFX specification, that's for darn sure - and I don't call them B&^%$#@t of America for no reason. . . .</p>
<p>Reminds me of Russian drivers around Moscow - I think "Must be nice being God - you can do whatever you want and the rest of the world be damned!"</p>
<p>Every stinkin' year, it's something else. . . .</p>
<p>Wish someone there had a pen that could sign a reality check. But then again, that's wishful thinking.<br>
/rant</p>
<p>I decided on the search-and-replace option so that all my QFX files were in a standard format, so I don't have to remember a "trick" if I need to import them again for some reason. Not that your idea won't work, but I'd rather all my QFX files have the same, or at least a similarly effective, internal structure.</p>
<p>I also left myself a note for next year reminding me to check the format and "convert" if necessary.</p>
<p>Thanks!</p></div>jimrhtag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-03T09:05:37Z2020-04-03T09:05:37Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>Marked as [SOLVED] based on replies #2 and #3.</p></div>jimrhtag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-03T13:27:48Z2020-04-03T14:01:34Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>Guess what!</p>
<p>BOA did <strong><em>NOT</em></strong> break the OFX standard - <strong><em>Moneydance</em></strong> isn't handling the <TRNTYPE> transaction type field correctly!</p>
<p>Viz.: <a href="https://www.ofx.net/downloads/OFX%202.2.pdf">https://www.ofx.net/downloads/OFX%202.2.pdf</a><br>
(Note that the current version is 2.2.1, but the 2.2 specification was not changed.)</p>
<p>The problem is that Moneydance is using the <TRNTYPE> to determine if the transaction is a debit or credit and <strong><em>not</em></strong> the sign of the <TRNAMT> as specified in the OFX 2.2 specification referenced above.</p>
<p>In a nutshell, the <TRNTYPE> is used by the financial institution to <strong><em>categorize</em></strong> the transaction. (<em>i.e.</em> Is it a capital gain/loss or a rebase of the securities?) The sign, (positive or negative) of the <TRNAMT> is used to <strong><em>classify</em></strong> the transaction as a credit or debit. (<em>i.e.</em> a POS, (Point of Sale), transaction can be either a purchase or a refund depending on the sign of the amount.)</p>
<p>====================</p>
<p>On page 230 of the PDF file, (Section: 11.4.4.3 Transaction Types Used in <TRNTYPE>), PAYMENT is defined as an "Electronic Transfer", whereas "DEBIT" and "CREDIT" are defined as "generic debit" and "generic credit"</p>
<p>Elsewhere in the document, (page 225 of the PDF, sectiion 11.4.4.1 <STMTTRN>), states that <TRNTYPE> defines the type of the transaction, where "type" can have several identifying values. The actual fixed usage is not rigidly defined as a debit or credit. It also states that <TRNTYPE> is defined as:</p>
<blockquote>
<p>Transaction type, see section 11.4.4.3 for possible values. This element does not change the effect of the transaction upon the balance (<strong>increases and decreases are indicated by the sign of the <TRNAMT></strong>).</p>
</blockquote>
<p>In other words, <PAYMENT> is a perfectly legal tag as used, however <strong><em>the tag alone should not determine if the transaction is a debit or credit</em></strong>, but "...the sign of the <TRNAMT>"</p>
<p>So, apparently, the option to ignore the tag in favor of the sign in <TRNAMT> is actually the correct behavior according to the specification as defined above, and should be the default behavior.</p></div>jimrhtag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-03T20:36:19Z2020-04-03T20:36:19Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>I'm a fellow user.</p>
<p>And that is the sort of way some developers seem to be interpreting things.</p>
<p>However I think it is invalid to call a transaction a Debit or Credit then use a sign to make it into the opposite type of transaction, Debit or credit in itself determines the sign of a transaction. The specification talks about using a sign with transactions that could be either type e.g. interest.</p></div>dwgtag:infinitekind.tenderapp.com,2009-01-14:Comment/482045292020-04-03T21:33:25Z2020-04-03T22:05:43Z[SOLVED] BoA credit card charges (debits) come over as payments (credits) to the account.<div><p>Dwg, I agree with you, but that's not what the specification says.</p>
<p>According to the spec, TRNTYPE is simply a "convenience" label for the financial institution that they can do with as they please - whereas TRNAMT actually determines both the magnitude and direction of cash flow.</p>
<p>Viz.:</p>
<blockquote>
<p>[The] transaction type [...] does not change the effect of the transaction upon the balance [whereas] increases and decreases are indicated by the sign of the <TRNAMT>.</p>
</blockquote>
<p>Currently accepted convention is that a "debit" moves money <strong><em>away</em></strong> from you and a "credit" moves money <strong><em>toward</em></strong> you, but what about a "payment"?</p>
<p>According to the OFX spec, a "payment" is "an electronic funds transfer" of some arbitrary type or kind. It can be a "payment" <strong>TO</strong> you, or a "payment" <strong>FROM</strong> you to someone else. The direction of cash flow is determined by the sign of the TRNAMT.</p>
<p>Interest is the same. In a bank account "interest" is a credit to your account, whereas with a loan account of some kind, "interest" is a debit to the account.</p>
<p>Even the definitions of "credit" and "debit" are not guaranteed to be the same everywhere.</p>
<p>Because the spec is designed to be very institution, country and region agnostic, the TRNTYPE is a label and nothing more.</p>
<p>The definition of the labels "credit", "debit", "payment", "interest", (etc.), is left up to the particular financial institution and, based on the sign of the TRNAMT, the cash can move one way or the other, regardless of label.</p></div>jimrh