@lubos, please make the next update fill all previous transactions with exchange rates that were applied before this update.
Edit: Upon further testing, the historical exchange rates in Journal Entries seem to never apply automatically absent any user input.
I suggest that the Autofill — Exchange Rates field be entirely dropped and instead auto apply Exchange Rates normally since autofill is just a special case of the old setup where only the base rates have been entered and that’s why one could argue that it’s unjustified complexity.
Moreover, how would the user get back to auto applied exchange rates after mistakenly using a custom exchange rate?
Actually the upgrade script should be doing just this. Copying exchange rates from Settings onto journal entries so no balances are affected.
If you are creating new journal entry, then exchange rate will be copied from Autofill - Exchange rate field. Or you can just manually enter desired exchange rate.
Having had a look at the guides (which don’t appear to be updated with these recent changes yet) and this forum topic, I checked the USD currency definition and saw that it had yesterday’s rate in the Autofill — Exchange rate field. So, I have removed it so it is now blank. Since we update our exchange rates daily, I think there is a high risk of introducing errors if we forget to manually change the rate when creating expense claims (and other transactions that now have this feature). But does this mean now that we have to manually enter the rate every time we create a new expense claim? Or is there – or will there be – a way to instruct Manager to just pull the exchange rate from the settings, using the current rate for the date of the transaction (which, I believe, is how it has worked behind the scenes until now)?
I am using the cloud edition, currently on version 23.7.5.861.
While @Ealfardan’s suggestion above would help, I would prefer if there could be an option for this to happen dynamically in the background, and not as a one-time retrieval during the transaction creation. I typically enter the daily exchange rates once every week or two. I find this more efficient than having to look them up and do the entries every day. However, with the new implementation it looks like I’ll have to look up the day’s rate before I can do any journal entries, expense claims, etc, or remember to retrospectively correct all such transactions when I do look up the exchange rates later. Also, we might have one staff member who enters the rates, but others who may want to create expense claims, so we’ll have to ensure that they do not do that until the day’s rates have been entered. So for us the new implementation makes our workflow less efficient and more error-prone.
@GrahamvdR I’m sure we will find the way to support workflow like yours gracefully. For example, there could be Exchange Rate Audit report where you could enter expected exchange rates and this report could show which transactions don’t have expected exchange rates. There could be easy way to update these transactions in bulk if desired.
New multi-currency implementation will be more straightforward and will have more capabilities (e.g. ability to split gains between realized and unrealized and more)
@lubos Thanks. I look forward to seeing how this develops. I’m happy to go through a bit of a teething period as the options are explored and implemented if it’s going to improve Manager, but I do worry that others may not have picked up on some of the changes and may have unwittingly introduced errors into their accounts.
For me the most elegant solution that comes to mind here is to have a check box for Use spot exchange rate. Checking it would bring up the rate field, and leaving it unchecked would leave Manager to use the rate set in Settings. However, it sounds like the changes you’re working on are much broader, so it probably isn’t that simple.
Still the biggest hope and request I have for Manager is to have foreign currency tax accounts, as discussed in this thread. I hope that’s something you’ll be looking at in these changes.
@Lubos this is an excellent development. I hope that you also will consider as per older discussion a possible split between realized Forex Gains / Losses from Operations (payments/receipts) in the P&L (is currently in place) an unrealized Forex Gains / Losses in Balance Sheet as these do not contribute (yet, could be many years later) to taxable profit.
I have just noticed that the clearing account I use for assigning freight-in costs to inventory has a large balance. It was zeroed after I did the most recent stock purchase within the last two weeks, so I think the recent changes have affected it somehow. Drilling down on the balance I see that the last time it was zero is in 2019, so it looks like all the entries since then have been affected.
I use the method described in the guide for Automatic distribution for separate freight-in charges. However, I am doing it with multiple currencies. I described my process in some detail in this post, and it has been working well until I noticed the large balance in the clearing account just now.
I will try to dig into this further and illustrate with screen shots, etc. However, it could take me some time, so I thought I should raise the issue now in case something can be done or guidance offered before I spend too long on it. I’m trying to prepare final 2022 accounts for submission to our tax authorities, and have noticed that the 2022 trial balance is now incorrect because of how the clearing account now has a large balance.
I did try restoring business backups from earlier dates when I know the clearing account balance was zero, and those are now showing large balances too, so I think that means it has come from changes to the program and not anything I have done recently.
I am using Cloud edition, version 23.7.7.863.
(Perhaps this post would be more relevant to the topic about purchase invoice spot exchange rates, as the clearing account in question has debits and credits applied to it only from purchase invoices. Please could an administrator move it if appropriate?)
I’m wondering if the issue could be to do with how tax is handled. From the Summary page I have drilled down on the balance for my clearing account, and I see some rows like this:
VAT 100% on import is a pass-through tax code. You can see in the Amount column that the US$ amount is 0, but the Debit column shows a large base currency amount. Surely this is incorrect and should also be 0?
I have taken my entire transaction history for my clearing account and done some spreadsheet work on it. If I remove all the debits and credits that use the 100% pass-through tax code, the current balance is zeroed out again (or within a few cents, due to the rounding differences introduced by using multiple currencies). So it looks to me like that is the source of the problem.
Let me know if any particular screen shots or other information would be helpful.
Some countries issue standardized tax exchange rates each month or so. This is the case with Bahrain, UAE and Oman.
The previous setup was perfect for recording of foreign currency tax transactions and much more automated and controlled.
This is why I believe would be a downgrade to most users but an upgrade for a few.
Also, manually changing the autofill everyday is more laborious and more prone to error than importing a state issued log.
Not to mention that after all this work, the salesman can just set his own exchange rates.
There must be another way to enable some users to set transaction level for each transaction without forcing the rest – the majority I suppose – to do substantially more work at substantially higher risks.
