Detailed Expense Report shows bank payee, not my edited value
I am using MD 2010 r3 build 749 on Mac 10.6 Intel. When I run a Detailed Expense Report, the transaction descriptions appear as the original downloaded value. Why don't they appear with the new values I've entered during reconciliation?
Likewise, if I choose "View Other Side" on these transactions, e.g. for category Dining, some transactions have original values and some do not. This is true for different accounts in the same category.
Thanks,
David
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 Ben Spencer on 21 Jun, 2010 02:49 PM
Hi David
I am not able to reproduce this problem in the latest stable build 751. Could you upgrade to751 and let me know if that resolves the issue. It can be downloaded from the link below:
http://moneydance.com/other
Ben Spencer
Moneydance Support
2 Posted by wrenhunter on 21 Jun, 2010 08:52 PM
Thanks Ben. I have upgraded to 751 and the problem persists. I have narrowed it down a bit: if I click through to a transaction that has the old name, so that I'm in my checking account for instance, I see the new name.
If I then choose "Show Other Side", that transaction (e.g. in Dining) has the old name. So it appears that:
a. the reconciliation process is not updating the Description in both accounts, and
b. the Detailed Expense Report may be reading from the "other side" accounts
3 Posted by Ben Spencer on 21 Jun, 2010 09:09 PM
a) This was a problem in a previous beta version. If you were using that version it will not have correctly modified the description on both sides of the transactions when you accepted, as you have described. Going forward the problem is fixed however you still have transactions in your register that have different descriptions on each side. I am afraid you would have to correct these by hand or delete the transactions and download them again.
b) I believe you are correct in that this report does take the description from the income and expense accounts side of the transaction.
I am sorry for the trouble this has caused you.
Ben Spencer
Moneydance Support
wrenhunter closed this discussion on 21 Jun, 2010 10:06 PM.
wrenhunter re-opened this discussion on 21 Jun, 2010 10:06 PM
4 Posted by wrenhunter on 21 Jun, 2010 10:06 PM
OK, at least it will stop happening in the future. Thanks.
5 Posted by Ben Spencer on 22 Jun, 2010 01:20 AM
You are welcome. I'm sorry I didn't a better solution.
Ben
Ben Spencer closed this discussion on 22 Jun, 2010 01:20 AM.
wrenhunter re-opened this discussion on 28 Jun, 2010 04:47 PM
6 Posted by wrenhunter on 28 Jun, 2010 04:47 PM
Unfortunately, this problem seems to persist in 751. I downloaded about a dozen transactions to my checking account today. Several were not picked up by MD matching, but most were, including one for a local coffee shop, City Feed.
Again, the description appears correctly in the checking register, but when I click "View Other Side", I see this in the Description field:
CITY FEED AND 06/25 #000781976
If I look at the Transaction Details (edited):
City Feed X 2010.06.25 2010.06.28 12:18:46:103 …
ol.orig-txn { "dtpstd-int" = "20100625" "name" = "CITY FEED AND 06/25 #000781976" "fitxnid" = "000-4.7.7" "fi_id" = "ofx:HAN:5959" "txntype" = "DEBIT" "amt" = "-477" } ol.orig-payee CITY FEED AND 06/25 #000781976
it seems that MD is using the "orig-payee" to display in the Dining register (i.e. the other side).
David
7 Posted by wrenhunter on 13 Jul, 2010 04:09 PM
Hi, any news on this?
8 Posted by Angie Rauscher on 13 Jul, 2010 04:39 PM
Wren,
I am having a difficult time re-producing this bug in 751. Can you confirm that you are using Moneydance 2010r3 build 751? Would you also let me know what OS and version of Java you are running? Could you also let me know if you are manually changing the description, or if it is being changed by the matching procedure?
Thank you for your patience and assistance in diagnosing this issue,
Angie Rauscher
Moneydance Support
9 Posted by wrenhunter on 13 Jul, 2010 06:45 PM
Angie, I am running OS 10.6.4. Java is version SE 6. (I don't know how to get more detail on Mac.)
As you might guess from my other thread, I am manually changing the Payee IN MOST CASES. However, I do get the occasional match in this account.
This is how I do it for my BoA checking account:
Thanks.
10 Posted by Ben Spencer on 13 Jul, 2010 07:28 PM
Hi
I am definitely not able to reproduce this problem. I imagine that if you are matching to a transaction that already has the banks description on the other side of the transaction (caused by the problem in the earlier beta) then that will be reproduced with the match. I am sorry that the use of that beta caused these problems with your descriptions. I think you will have to manually fix all the descriptions on the old transactions other sides.
With regard to your question asking why the category isn't set automatically when the description is changed. The current version of Moneydance only automatically changes the category when you are entering new transaction. This allows for users to modify an existing transaction without changing the category. We recognize that this is not always the best behaviour and the developers tell me that the next version will automatically change the category when the description is modified on unconfirmed transactions as well as new ones.
Sincerely
Ben Spencer
11 Posted by wrenhunter on 13 Jul, 2010 08:43 PM
But this continues to happen with new transactions that I've downloaded since upgrading to 751. Are you saying that the fact that I matched a given payee at any time in the past has "corrupted" that payee, and I need to manually change every entry in, say, the Dining register?
If so, which is not pleasant news, how can I use Batch Change to do this more easily? Whenever I try this on a given payee, it only ever changes the transaction at hand.
12 Posted by Ben Spencer on 13 Jul, 2010 09:00 PM
Moneydance doesn't maintain a separate payee list for matching purposes other than the data that is stored directly in the register. When a matched payee/description is found it is being matched to a particular transaction in your register. Without being able to see you data file I cannot be sure exactly what is going on.
When you said "7. Hit -return to "match"." did you mean you pressed ctrl-Return? What was the type of the selected match when you accepted it? e.g. ORIGINAL, CATEGORIZE, MERGE, REVERT.
Ben
13 Posted by wrenhunter on 13 Jul, 2010 11:09 PM
Yes, I mean to write [apple key], but the form stripped out "cmd".
I don't know what the type was, as I'm so sick of having to match these manually (see other thread) that I don't bother to look. It wasn't MERGE or REVERT.
14 Posted by Ben Spencer on 14 Jul, 2010 12:29 PM
I have done some further testing.
If you have an transaction with the correct Payee/Description in the checking account but still the Banks Payee/Description on the other side, downloading a new transaction and matching to the existing one with a CATEGORIZE option, does not have the effect of changing the description of the newly downloaded transaction to match the other side description of the existing transaction. Which is to say when you match a transaction with the CATEGORIZE option the transaction you are accepting gets the same description on both sides. And that description is the one that you matched to on this side. Any descriptions in your register that are still the banks descriptions left over from the bug in the beta that are on the other side should not be applied to incoming transactions when you accept them with the categorize option. In my testing following the steps that you described above, with a variety of test data, I am not able to reproduce the problem you are describing.
Given that I do not think there is a need to try and fix the old bank descriptions on the other side of these transactions. I do no see how they can be affecting newly downloaded transactions. The matching process only uses the description on this side of the transaction,
I understand that you are feeling frustrated and I want to help resolve this situation. To do that I need to be able to reproduce the problem and verify the steps you are taking to cause this problem to show its self. If you are willing, I encourage you to take a series of screenshots showing exactly what happens the next time you download and match a transaction.
Sincerely
Ben Spencer
15 Posted by wrenhunter on 18 Jul, 2010 07:33 PM
OK, I just did a new download from BoA, and prepared a bullet list and screenshots, etc. Then the problem went away :)
Thanks for your investigation and concern. I don't think I did anything different, and I think all the transactions were always new ones (i.e. I had not entered them beforehand). But there you go.
David
wrenhunter closed this discussion on 18 Jul, 2010 07:33 PM.