I’m not sure, can you check the client has their country set correctly. It could explain the problem.
My Company Localization settings
This is the Client Details
This is the product details
This is the main product settings
and finaly my env file if that helps
Am absolutely stumped why this is not working.
When you select a client in the edit invoice page it should set the exchange rate.
You may want to try using the network tab in the browser console to debug the login response to see what exchange rates are being returned by the API. This would isolate the issue to the frontend or backend.
this is the Network Payload when I select a client -
I may be wrong, but here it seems the exchange rate is fixed unlike other items.
You need to check the currencies data in the login response, clients will always default to 1.
When logging in on a completely fresh browser - cache/history cleared etc
Server response to all currencies is 1 and even the symbol is incorrect as per the database
@david do you have any ideas?
Note: the app expects USD to be the base currency with an exchange rate of 1, in the screenshot above it looks like it’s been changed. It may cause problems.
I take it there is a schedule when the app, backend, queries the database to update specific cached files like the currency list. is there anyway to see this schedule or where this cache is kept as I have now just gone back into the database to reset all the exchange rates to be based on the USD of 1 so it would be good to run some sort of job to refresh any cached currency info. or does the app update these cached files during the regular Cron Job
We refresh the currency cache daily, to force the cache to refresh run /update?secret=secret in the url
serv.com/update?secret=secret on the end gives a 500 - Server Error
just an update, I changed the secret in my env file and the system refreshed, there were jobs in the queue which have now run, cleared the cache in the browser, now trying on another computer that hasen’t been to the app and the same issue, no changes in exchange rates.
Check your logs in storage/logs/laravel.log for the exact error, most likely a permissions error writing to bootstrap/cache
Gave up trying to find the error in this. Can only conclude that changing the database currency table to have HKD as the default 1 rate and changing the USD rate accordingly, broke something that could not be resolved during regular system refreshes.
Anyway, completely rebuilt my environment, but had issues importing data.
Think it is best to remove the CSV options as you cannot export vendors, or import invoice items. maybe missed something.
The multicurrency is now working sweet, but have now got the Cron warning even though the Cron Jobs are working perfectly; will see how this plays out over the next few days. Version installed now is v5.5.24-C93
Having ironed out all my original problems with using Multi Currencies, all seemed to be working great until I upgraded to v5.5.74. When I upgraded to this version, the dashboard has seemed to be broken when calculating outstanding and active invoices, and also in the display of information.
This indicates all the currencies from invoices and clients and the total value of active and outstanding invoices (the totals are wildly out)
This is all the invoices within the period which has gone wrong.
shows the HKD invoices (correct total)
shows the PHP invoices (amounts are correct amount, but wrong currency)
this shows the AUD invoices (correct amounts but wrong currency)
this is my currency table in the database that has not been changed and is fixed per my needs.
This is really confusing as i have tried to figure out where the totals are coming from, and it seems completely out even adding all the items up without currency conversion, just doesnt work.
Appreciate any ideas on this. (reminder everything was perfect up to v5.5.74. I have now upgraded to v5.5.80 with no change.
Are you using the web app or the desktop app?
If the exchange rate it set on the invoice it will use that value, not the value in the currencies table.
I hadn’t checked that as all the invoices are recurring without exchange rates set. I have now checked and seems that when the recurrence was triggered it used the currency table to set the exchange rate to my local currency, then when displaying in the dashboard, it is converting again to a completely wrong number. I have manually changed all the outstanding invoices and now the numbers match. I will check when the next recuring invoices are posted to see what happens with the currency rates.
One item that may be modification that I recommend is the “Outstanding Invoices” this calculation only shows those invoices within the date range selected. Would this not be more accurate to show all invoices that are outstanding within the date range even if the invoice was issued before the range (it is still an outstanding invoice) if the date range was before the outstanding invoice, then I can understand not including it, but if I select say the last 7 days, it only shows the invoices unpaid, issued in the last 7 days, an invoice issued along time ago is still outstanding, but does not affect the outstanding balance (which I would expect it should).
Also, is there a way to change the currency display, when changing the view to a different currency? showing “ALL” currency invoices, shows it in my local currency, but if I select another currency (say “PHP”) it shows the correct amount for the invoices, but it still uses my local currency symbol which makes it very misleading (This is where there was the confusion on my previous post, as I was seeing crazy numbers outstanding, but when switching to the currencies, the numbers were correct)
Sorry, I don’t understand the problem. When the recurring invoice runs I believe it should copy the exchange rate from the recurring invoice to the standard invoice.
The currency symbol looks like a bug, we’ll make sure it’s corrected.
Appreciate this. will see what happens when the processing of my next recurring invoices happens, as they shouldnt have any set exchange rates.
I think the strange totals may be caused by manually setting the exchange rates in the database, the app expects the rates to use USD as the base for conversion.