Count yourself lucky! I reported this issue to IK in March 2017 in some detail (and there is more wrong in this area than you mention in your post), and while I did get a few replies at first I haven't heard anything since May in spite of some reminders to them. The whole discussion has been moved by IK to the private discussion area, so you won't see it, but I assure you that I am as annoyed as you that nothing seems to be happening. I don't even know whether they have recognised it as a bug or have entered a trouble ticket or anything - just silence.
They did fix the "Inverse currency rate" problem which was complicating the issue at first, but the issue you mention and its fallout still remains.
Multi-currency support is why I moved to MD in the first place, and when I travel split transactions are common. This problem is a royal pain!
Ian O on 07 Aug, 2017 03:10 PM
I hope you will both accept my sincerest apologies for the lack of support on this issue. I have raised this problem with the lead developer directly and he has confirmed that he will be looking into this. I will let you know what he says as soon as I have a response.
Please accept my apologies again for the delay you have endured, I'd like to assure you that you can expect a higher level of service moving forward.
This is still an open issue with me, and is still causing me grief. It is now 7 months since we were promised a speedy response, and only silence since then. Obviously IK are hoping the problem will go away, but it won't without some action from them. I expected better than this!
Ian O on 08 Apr, 2018 10:19 AM
Please accept my sincere apologies again for the lack of response on this thread. I have been unable to replicate this behaviour in the most recent build of Moneydance. Would you like to try upgrading to see if this resolves the problems? If you let me know what version of Moneydance you are currently using, I will provide steps to take a secure backup before upgrading.
The latest version is Moneydance 2017.7.1 (1671) and can be downloaded from here.
If the problems persist after upgrading, we can look into arranging a TeamViewer session. This will allow me to log into your system to see what's happening. I'll be able to gather the information needed for the development team to get this resolved.
Yes, the problem is still there in Build 1671, which I have been using for a little while. There seem to be occasional minor variations, but it’s still basically there.
I would be happy to participate in a TeamViewer session at a mutually convenient time, to demonstrate the problem for you and to allow you to gather such information as would help. Let me know what is involved.
I have just installed 2017.7.1 (1671) on a separate laptop.
I will not put "New Moneydance" anywhere near my 18 years of Transaction Data.
I have therefore used the Unlicensed Trial Version.
The Download immediately shows Euro with an Exchange Rate, but when you check the Currency rates there is nothing. When you try the Currency History Report it says nothing to show.
I tried this Currency and the issue still existed.
So I deleted the Currency Euro and started it again.
I entered Rates and tried again.
Base Currency GBP
Enter an Opening Salary Trx to the Current Account - So you have some funds to spend.
Create a New Euro Account with Currency Euro
Purchase Euro from the Current account and the rate is correctly defaulted from the rates.
Enter a Euro Transaction without Split and the rate is defaulted correctly.
Enter a Euro Transaction with a split - the first line gets the correct rate, the second line gets the rate = 1 - incorrect.
You can do a screenshare if you like, but it really is easy to reproduce using your own download.
I am sure you are embarrassed by the poor support we have had, but I have made the discussion Public again, for the second time. Please do not make it Private. We want a solution for this. I want to Upgrade and pay my fee, you need support from the user base to continue to enhance the product but I cannot upgrade with this issue and making it Private isn't going to get it solved.
Ian O on 09 Apr, 2018 09:25 AM
Hi Jon and Paul,
Thank you for supplying the steps to reproduce this issue. They were crystal clear and I can confirm I have now reproduced the issue within a data file. I'll be communicating with our development team today and will update you as soon as I have further information.
The discussion was assigned as private as I had offered a TeamViewer session - sensitive information can be given when arranging and setting up these sessions (We also don't offer TeamViewer sessions as standard level support - only when troubleshooting bugs or the rare instances email support isn't appropriate).
As I have been able to replicate the problem with your steps, a TeamViewer session won't be required so I'm happy to leave this as public.
I'll ensure the development team are made aware that this issue has been present for some time, so we can work to get a resolution as quickly as possible.
Good to hear that you have been able to duplicate the main part of the issue. However, I would encourage the developers to explore related aspects that fall out from it, e.g.
- Reports (as well as the register) show the first split line correctly converted into the base currency, but subsequent ones show the amount as the foreign currency as if it were the base currency.
- It is sometimes possible to manually enter a Rate for the second and subsequent lines, as long as you do it at the same time as you are entering those lines. If you try and do it later, the Rate appears to go in, but disappears as soon as you move on.
- Sometimes, even the first line of a split doesn’t get a Rate assigned: this often seems to happen if using a Description (merchant) that hasn’t been used before. But not always.
- Entries of 1.0 appear in the currency tables.
- In the register, the foreign amount for completed split transactions isn’t shown for the Split total as it is for simple transactions. If you highlight the split transaction, however, the foreign amount does show up, albeit grayed out. It should always show.
- It currently isn’t possible to go back and correct entries that were erroneously defaulted to Rate=1. This is important to be able to go back and fix history.
And I am sure there are more. But it could be that once the basic problem has been fixed, all these ‘funnies’ will automatically straighten out.
Ian O on 10 Apr, 2018 12:17 PM
Thanks for sending through the additional information on various strange behaviours you are seeing. I'll ensure these comments are passed to the developer as they might prove useful. As you have pointed out, it may be that the once the core issue is resolved these other issues will be eliminated. Regardless, the more information we have, the better positioned we'll be to get things straightened out. I appreciate you taking the time to jot down these observations, if you uncover anything else please let me know.
I'll let you know as soon as I have further information on this issue. Apologies again for the inconvenience this issue has caused.
Another related thing that has only recently started happening, is that simple (non-split) transactions are picking up the 1.00 Rate entries in the currency table, and thus effectively not always getting the correct base ('foreign') currency equivalent. It appears to have started once currency downloads from Yahoo stopped and started to use AlphaVantage, and AlphaVantage seems to only be able to download less than 20% of currency exchange rates into Canadian $$ (unfortunately, the $US/$Can rate, which I use a lot, is one it rarely if ever seems to get).
This may be part of the split transaction problem, so perhaps you can advise the developers that the needs to be checked as well.
And talking of which, is there any progress towards getting the foreign currency split-transaction problem identified and resolved?
Reopened the discussion again.
The system just closing a ticket because you don't work it is abysmal "Support".
I don't update, not because the issue went away or I lost interest, I don't update it because I have nothing new to add.
You have posted on Facebook again announcing a discount. Why would I "Upgrade" to a version that is flawed in an area that is important to me. ?
Thanks, Jon, for keeping this discussion open. The similarone I started last year seems to have gone into the private domain (I.e. Just between IK and me.) I keep prodding them, but never get even an acknowledgement. I can't believe that you and I are the only ones with this issue, but judging from IK's level of attention you would think so. What more can we do?
Jenny on 14 Sep, 2018 01:08 PM
Hi Jon and Paul,
We've released a new preview version of Moneydance that should help resolve this problem. The preview version fixes the bug that set the default exchange rate to 1.0, for new inter-currency entries in a split transaction.
The new preview version is 2017.10 build 1701 and can be downloaded from this page. Can you try upgrading and let me know if the problems persist? Take a manual backup of your file via File --> Export Backup before you download the newer version.
If you'd prefer not to download the preview version, I will flag this discussion so you're notified when these fixes are included in the stable release.
I downloaded the beta you identified, and it helps (quite a lot) with this issue. As long as I am careful when I do the entry, and do it in one particular way, I seem to get the correct exchange rate applied for all the split transactions.
But I still see the following problems:
1. I still cannot go back and edit the exchange rate for a split line after I have moved on to the next one, or after I have committed the transaction. The correction appears to go in, but reverts as soon as I move on. I can do this editing for simple transactions. I need to be able to do this to correct my history of incorrect exchange rates, as well as dealing with problem #2.
2. If I make a split entry that ‘overflows’ the transaction total that I originally put in, then I get an exchange rate which is the inverse of the correct value (e.g. 0.75 instead of 1.33) for the overflow split line. The transaction total correctly shows the increased amount in the account currency. Attempts to edit the transaction occasionally work OK, but more often get into deeper trouble.
[ Example procedure to show this: make a new transaction in the foreign account of $10.00 with category “Pharmacy” - 10.00 shows in the Charge column, 1.33 shows in the Rate box, and 13.30 shows in the Foreign Amount box - OK. Enter command-L for a split, then Command-N for a new split line, and immediately 0.75 shows up in the Rate box; I then enter category “Groceries” and an amount of 20.00, and I get a foreign amount of 15.00. I cannot edit the 0.75 Rate amount permanently. If I then save the split transaction, I get a Charge amount total of $30.00 (correct), with one correct and one wrong foreign amount.]
’Overflowing’ splits like this in non-foreign accounts works fine.
I can and will use this improved version, but there is still some way to go Please feed these issues back to the development team. Please keep me up-to-date.
I will continue to experiment further in this area, and let you know if I find anything else.
The Rate Defaulted at Header Level is the rate applicable for the date of the last edited transaction.
My Expectation would be that the Rate is Defaulted for the Transaction Date and then it updates as either I +/- on the date field or if I key a new date the rate should change to the applicable rate for that date with the OPTION to Update it.
If you can default the inverse of the rate you are defaulting in the Beta version and also update the rate using the transaction date then I will accept the solution.
In principle, that would work for me too. However, the ability to retroactively edit the exchange rate in individual split lines is important too, since I have 2 years worth of incorrect foreign split transactions that need correcting. Such editing is possible in non-foreign splits.