Explanation of the bug: Assume we indicated to a US$ Customer on the invoice that US$100 was the amount to be paid. When clicking a new receipt that US$100 now appears as 100 in amount but under the default currency (NGN) with an indication to the right to optionally add the US$ equivalent if one so wishes (and not want it to be calculated by the forex calculator of Manager) see screenshot below. This is a bug as the US$100 should be listed as the amount and the default currency be the calculated conversion.
When creating the receipt, you need to choose an account that is denominated in the currency of the transaction. If you choose a US$ account, the receipt will show as US$100 in your case.
Have you entered at least one currency exchange rate for the US$? Because if you didn’t then Manager will be forced to default to a rate of 1 simply because it has to default to something since you paid a US$ customer account using NGN bank account. That is off-course if you don’t specify the FX amount in the receipt.
You either need to maintain the FX rates from Settings / Exchange Rates or you can simply enter the USD equivalent amount in the small box next to the line in the receipt. Either way you have to tell manager how to convert or else it’s 1 all the way.
1 is as good as any other default value. Why should the default be any different from 1?
That is right when having a domiciliary account for each foreign currency one transacts in. However, it is also common to invoice for example in US$ or GB£ for overseas clients. These transfer the amount to your bank account in the local denomination will add the amount in local currency. Indeed, if I would reconcile the bank receipt with the invoice it would be local currency and would have to indicate the customer to be a local currency payer also. It is not in application terms a real bug, however, it is an operational bug that should be fixed by improving the way the application handles forex transactions.
So then it’s right that Manager is showing your local currency for the receipt, but are you wanting it to automatically populate the USD field according to the invoiced amount and the local currency field based on the USD amount and the exchange rates entered into the program?
My understanding is that regardless of how judiciously you enter exchange rates in the settings, the actual conversion rate used by the bank is always likely to differ slightly. For the way I operate, I would prefer to enter the local currency amounts manually when I receive notification from the bank of a deposit in the account. If Manager took the USD amount and did a conversion based on the exchange rates I have entered in settings, it would probably arrive at a slightly different local currency amount than what actually reflected in my bank account. This difference might not be obvious initially, and I would have to go back and manually correct all such deposits.
You could still have your customer denominated in a foreign currency – you just have to manually specify what the the amounts are when they land in your local currency account. I would argue that this is preferable to the alternative. But if I have misunderstood what you are wanting then please correct me.
Nothing complicated. What I want is that when clicking on New Receipt that it does not change the denomination of the currency. So if US$100 in the Invoice, when clicking receipt it should not change it to NGN100. Ideally in this case it would populate both the “optional” US$ amount with the US$100 as per invoice and the calculated NGN value based on the in-build forex calculator.
OK. I would prefer that it not automatically populate the local currency amount, for reasons mentioned in my previous post and below, but I agree that it might be nice if the US$ field was populated with the amount from the invoice. I guess I’m so used to the way it currently operates that this behaviour doesn’t feel wrong to me.
I update my exchange rates in the settings about once a week. I would like to be able to continue to enter receipts without having to have already entered the exchange rate for that day. As it currently works, I can enter the local currency amount as it appears on my bank statement, and this doesn’t change as I update my exchange rates. All that changes is the foreign currency gains and losses, which is an automatic built-in account anyway. If Manager relied upon the exchange rates in my settings and I updated the rate after entering the receipt, then either the local currency amount would change, possibly messing with account balances and reconciliations, or it would have to be set so that updates to the exchange rates don’t change previous transactions, which would then mean you’re working with multiple rates, and it gets very messy very quickly.
Agreed. I also wouldn’t mind if the local currency field was empty by default (rather than showing the foreign currency amount – I can see how this could be confusing), but I would argue against trying to automatically populate it via the exchange rates in settings or any other method.
I agree that the local value should be the same as on the bank receipt. So populating at least the Forex value properly and leaving the local value blanc would be the preferred solution.
Everyone has overlooked an important fact. When entering a receipt against a sales invoice, the primary amount is in the currency of the cash or bank account where the money is being received, not the currency of the customer or sales invoice. If you have multiple cash/bank accounts in multiple currencies, you can change the primary amount currency by switching the Received in account.
The unit price numbers carry over from the sales invoice without change because:
Manager does not know until you make a selection what the currency of the destination cash/bank account will be.
Exchange rates may not have been entered between the cash/bank account currency and invoice currency. But some number is required, so the one present on the invoice is used.
Also remember that the main purpose for entering the foreign currency number when receiving money against a foreign-currency sales invoice is to ensure the receivable remains satisfied if exchange rates fluctuate in the future. Without this, foreign-currency sales invoices would constantly become over- or underpaid. Manager addresses this annoyance by posting effects of fluctuation to the Foreign exchange gains (losses) account automatically.
Sorry the bug is that it assumes that the $100 = NGN100. It should not assume such or populate the field. Please just follow the steps I recommended and notice it is wrong to change denomination. Thanks.
@eko, your step #5 makes an incorrect assumption. You said the program “copies the 100 to the default currency.” That is not what the program does. It carries the unit price number from the sales invoice to the receipt. Yes, it temporarily shows as being in the base currency, but only because no cash or bank account has yet been selected. Such a transaction would not be entered, but would land in the Suspense account. The ultimate currency will be determined not by your base currency but by the currency of the cash or bank account where you receive the money.
As I wrote earlier, when the receipt form is being generated, the program does not know what cash or bank account you will receive the money in. It could leave the figure blank, default to zero or one, or—as it does—carry over the only number it has. The design choice was to carry over the existing number, because many businesses will receive money against foreign-currency invoices in a bank account denominated in the same foreign currency. If that is not going to be the case, any other number would be a wild guess, since the ultimate currency and exchange rate could be anything.
Your initial example included an invoice in USD. But you are receiving money into a cash or bank account denominated in NGN. The program has no idea what exchange rate to apply. The cash/bank account cannot accept money in USD, only NGN. And since it does not know the applicable exchange rate, it does not guess, but leaves the original number in place. If nothing else, this serves as a reference for offline calculations, if you want to make them.
Once again, this is not a bug. The program operates as designed. You may wish it was differently designed, but it works exactly as intended. @GrahamvdR has provided some compelling reasons why this is advantageous.
Sorry @Tut but the application should never change the denomination. It should put the US$100 in the USD field and never change it to NGN. Alternatively it should just disable the Create Receipt function if not able to correctly put the amount where it is supposed to be.
It is not deposited in US$ but in Naira. The invoice is in dollar. So when clicking on New Receipt one would not expect the NGN to be filled with the amount for dollar. It is incorrect. See also @GrahamvdR the local currency field should stay empty in such case and ideally the foreign optional one should indicate the US$100.
