Two showstoppers and one pita
Moneydance 2010 735 trial.
First, assigning an address to a transaction is not saved unless something else in the transaction is changed too.
Second, when a cheque is printed, it prints with the due date on it instead of today's date. There appears to be no option to override this.
Also, imported Quicken files have "Print" instead of "{Print}" for cheque transactions which need printing. This initally gives the impression that Moneydance can't print cheques, until you figure it out and change every one of them. This is just one of multiple glitches trying to migrate from Quicken.
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 Graham on 02 Feb, 2010 07:04 PM
Updated to 738. Still the same.
2 Posted by ljb on 02 Feb, 2010 07:37 PM
(Since nobody from MD has picked this up yet, here are my comments.)
1) I tried to duplicate this but it seems to work for me. I selected an existing transaction, pressed the Enter key to edit, cleared the existing description text, then used the pull-down menu for Description to pick something from the address book, and pressed Enter to save. The new description was saved and the entry is linked to the address book. Or am I doing something different?
2) The printed date on the check matches the transaction register date, correct? Whether that is the due date or today's date is up to you when you created the transaction. If the transaction is created by a reminder, the reminder's effective date (not the commit date) goes into the register, and then onto the check.
3 Posted by Angie Rauscher on 02 Feb, 2010 07:58 PM
1) This also works for me. Would you describe the work-flow you are using when the address is not being saved?
2) The printed date on the check should match the transaction register data. If it does not, please let me know.
3) The {Print} vs Print issue: I have created a bug ticket to correct this issue, which can be found here. Our feature request and bug reporting system is integrated with our wiki. We invite our users to register and use these systems to help improve Moneydance by bringing bugs to our attention and requesting new features. Users can also vote on tickets, which helps us determine how wide-spread bugs are and which requests have the most demand.
Please let me know if I can be of further assistance, and thank you for your interest in Moneydance.
Angie Rauscher
Moneydance Support
4 Posted by Graham C. Norri... on 02 Feb, 2010 11:46 PM
** Reply to message from Angie Rauscher
<[email blocked]> on Tue, 2 Feb
2010 11:58:41 -0800
1) I don't know if it makes any difference, but the ones I tried it with were
all imported transactions. The first one each time does save when you step off
it (there appears to be no explicit "save this transaction" action available).
For subsequent ones, it usually does not work: it appears to, and if you return
to it before exiting Moneydance it may even appear correct - or it may not.
2) So what you are saying is that if I want to enter transactions to print as
cheques, I either need to enter them on the day I print them, or change their
date on the day I actually print them, before I print them? I'm sorry, but this
is absurd. All I want to do is enter them, with the date they are due, and then
at some convenient point, print the cheques in batches. Quicken allows the
cheque dates to be the date they are printed. I know of no accounting system
which assumes that the date you want on a cheque is anything other than the
date it is written. (I know some people post date cheques, but that is not an
accepted accounting technique to the best of my knowledge.)
3) Thank you for opening the bug ticket.
Graham.
5 Posted by Angie Rauscher on 03 Feb, 2010 02:18 PM
1) This may be one of the annoyances which was fixed with build 738. You can download the update here. I think this may resolve the issue. If not, do let me know so we can look further into this issue.
2) So here is what happens: You enter checks you want to be printed, with whatever date you desire as the date field. The date printed on your checks is the date you entered in the date field. This is the way the program currently functions. It is also possible we could offer our users the opportunity to select a default "Set date as date printed" option, or something similar. I will add this to our list of options to discuss for future builds.
3) You're welcome.
Please let me know if I can be of further assistance,
Angie Rauscher
Moneydance Support
6 Posted by Graham on 03 Feb, 2010 09:06 PM
Angie, as I said in my second post in this thread, 738 makes no difference.
Angie Rauscher closed this discussion on 02 Mar, 2010 05:12 PM.