Duplicate transaction moves amount from payment to charge, then gets strange

dtd's Avatar


06 Jun, 2020 11:21 PM

I was making an interim payment (in between months), so decided to "duplicate transaction" vs. using reminders.

When I did duplicate transaction, a new transaction was indeed created (where I would then edit date, etc.) but the PAYMENT amount had been moved to CHARGE. Not cool, but hey, the amount is different anyway. So I put the correct payment in, which of course made the moved charge disappear. I hit enter, and it was entered as originally badly duplicated - i.e a charge for the duplicated payment.

OOOKKKK... I went and reentered the correct payment again. Enter. Now - it says this is an entry for a charge of 0.00 .... ok, wut?

I tried yet again - now it worked.

This is very duplicatable - try it in your own home. I doubt this is the intent, so I'm reporting what I consider a program bug.

  1. 1 Posted by dwg on 07 Jun, 2020 03:03 AM

    dwg's Avatar

    I see the same thing on Moneydance 2012, so this behaviour has been around for a while,

  2. 2 Posted by dtd on 07 Jun, 2020 03:37 AM

    dtd's Avatar

    Age doesn't make it better.... ;)

  3. 3 Posted by dwg on 07 Jun, 2020 04:50 AM

    dwg's Avatar

    Pretty good when you consider there has been at least one major rewrite in the intervening years.

  4. 4 Posted by dtd on 07 Jun, 2020 05:15 AM

    dtd's Avatar

    Maybe I just pay too close attention when things go wrong...

  5. 5 Posted by -Kevin N. on 07 Jun, 2020 01:04 PM

    -Kevin N.'s Avatar

    Hi dantdavis,

    Window 10 Pro V.2004
    MD 2019.4 (1904) Preview build

    I can not seem to reproduce this behavior in the above environment.

    -Kevin N. (not a member of MD support)

  6. 6 Posted by dtd on 07 Jun, 2020 05:30 PM

    dtd's Avatar

    Kevin - I am also using MD 2019.4 (1904) preview build on a Macbook Pro OS10.15.5, Given the code base, I doubt platform is an issue.

    Looking further, this occurs when I duplicate a downloaded payment transaction, so I suspect the transaction details are part of the issue. I found a different account to try, and it did NOT exhibit this behavior. Looking at the transaction details of both, I found that one value was XX.XX, the other was -YY.YY so I have a feeling that Moneydance is fixing that somehow on import, but duplicate transaction handles one wrong - but that's my educated guess based on my I/T experience.

    Curious to see if I can upload this video of the process.

  7. 7 Posted by -Kevin N. on 07 Jun, 2020 07:11 PM

    -Kevin N.'s Avatar

    Hi dantdavis,

    Well that is just bizarre!

    MD support, you're up.

    -Kevin N. (not a member of MD support)

  8. Support Staff 8 Posted by Sean Reilly on 08 Jun, 2020 10:40 AM

    Sean Reilly's Avatar

    I suspect the problem is related to the original transaction being originally entered into the other account (Checking - USAA) and the register you're in is the "other side" of that transaction. This is definitely a bug and we'll fix it, but a likely workaround could be to duplicate the transaction in the checking account rather than the credit card. Can you let me know if that doesn't work?


    Sean Reilly
    Developer, The Infinite Kind

  9. 9 Posted by dwg on 08 Jun, 2020 11:38 AM

    dwg's Avatar

    I think you may be right Sean.

    I know my original transaction was done on the Cheque account side, but I know I often do it these days from the credit card side. I tried on Build 1904 from the Credit card side and it moved the payment to a charge, which is naturally wrong. I then tried doing a duplicate on the Cheque account side and it worked correctly.


  10. 10 Posted by dtd on 08 Jun, 2020 07:37 PM

    dtd's Avatar

    Sean - quite correct. The bug is indeed related to duplicating "the other side", and your conjecture as to a "workaround" does work.

    You've already said the bug will be fixed, so this is just a statement that, these days, I don't automatically know which IS the other side. I think I mentioned in my june 7 11:30 message that I found a different account where it did duplicate properly, and sure enough, when I went to Checking - USAA - it exhibited the duplication problem - because THAT was the other side.

    i.e. given automatic downloads and such, it's not automatic to know which is the primary side and which is the "other side" - is there a way to know which is primary?

  11. System closed this discussion on 07 Sep, 2020 07:40 PM.

  12. dtd re-opened this discussion on 07 Sep, 2020 10:22 PM

  13. 11 Posted by dtd on 07 Sep, 2020 10:22 PM

    dtd's Avatar

    I notice this thread is listed as "resolved". I don't think I'd consider it resolved until the bug is fixed.

    Personal opinion, I'd rather it be "assigned" to insure it doesn't get forgotten.

    As an add on about not knowing primary/secondary - these credit card payments are made through reminders, and yes, paid by (Checking - USAA), but since I don't create the transaction myself - obviously at times I duplicate it :) - I have no idea which is primary... it appears (Checking - USAA) is, but from my POV, I'm just paying the card, so don't know where it becomes primary.

    Thanks for adding it to your fix list.

  14. 12 Posted by dwg on 07 Sep, 2020 10:28 PM

    dwg's Avatar

    Unless an issue is fixed at the time I think it should be marked as assigned and a bug ticket attached to the thread.

  15. 13 Posted by dtd on 07 Sep, 2020 10:31 PM

    dtd's Avatar

    I agree, and hmmm - it is assigned now that I've reopened this. Maybe it gets "resolved" automatically when the System closes it after 3 months? I don't know.

    Dang! I see that I rediscovered this thread only two hours after it was closed. Sends shivers down my spine.

  16. 14 Posted by dtd on 03 Oct, 2020 03:27 AM

    dtd's Avatar

    And another month passes, and I deal with this again. I've had this about three times tonight.

    It would be nice to be fixed.

    As to my own query of June 8 (anyone notice the consistency of the time of the month?)
    "i.e. given automatic downloads and such, it's not automatic to know which is the primary side and which is the "other side" - is there a way to know which is primary?"

    the only thing I personally see is that my verification code is in brackets which indicates that it is secondary. SOOOO - when I set up a payment from USAA, the checking account is primary (makes sense). But when I make auxiliary payments, I'm in the other account, and the problem (obviously) occurs.

    Still - I shouldn't be required to go to the checking account to make the auxiliary payment.

  17. System closed this discussion on 02 Jan, 2021 03:30 AM.

  18. dtd re-opened this discussion on 06 May, 2021 10:38 PM

  19. 15 Posted by dtd on 06 May, 2021 10:38 PM

    dtd's Avatar

    Eh, time to reopen this again (seven more months) in the hope that the bug acknowledged by Sean might actually be resolved.

    I think I need say no more than "check out post 6" in this thread.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:


Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts


? 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