I have a priject I'm working on and I need to format a number into a money value, I used the Format.money() function but the string it gave me had a dollar symbol, is there an option to change this to English Pounds (£)
The API automatically uses the currency that's configured in the store admin - it can be changed from the Settings page. https://help.bigcartel.com/basics/settings/#basics
Related
Date and number abbreviations in Data Studio Report look different on different users. In English, abbreviation of 1000 is K and abbreviation of 1,000,000,000 is B. But In Turkish, abbreviation of 1000 is B.
This causes confusion between a thousand or a billion. When examined users with different report views, we found that Google Account Language Settings are different.Is it possible set these abbreviations so that they do not change with the Google Account Language Settings?
The number format is based on the language of the respective Google Account that's logged in by the viewer. To display the Report URL in a specific language (e.g. English), add the suffix:
?hl=en
More Language Codes
1) Standard URL
https://datastudio.google.com/reporting/48900f64-2068-4331-b707-f82df114542a
2) English (US)
https://datastudio.google.com/reporting/48900f64-2068-4331-b707-f82df114542a?hl=en
3) Spanish
https://datastudio.google.com/reporting/48900f64-2068-4331-b707-f82df114542a?hl=es
Source: Google Forum Post (Nimantha 13 Jan 2020)
I'm having a problem using Google Finance historical data. I need to know the price a particular stock had on a particular date (Usually within the last month).
The problem is, when I use a URL such as https://finance.google.com/finance/historical?q=abx I get different results depending on where I issue the query from.
At home I'm in Argentina and my production server is in the US... when I run the query locally I get the prices in AR$, but when run from the server I get USD (Which is what I actually need).
I tried using a X-Forwared-For header but didn't make a difference...
Ideally I'd like to send an extra parameter (something like cur=USD) to explicitly ask for USD... is there such a thing?
Thanks
I use, currency conversion along with the price of the stock.
For Example:
Price of ABB Ltd in SEK = GOOGLEFINANCE("ABB","price") * GOOGLEFINANCE(("CURRENCY:USDSEK"))
Then I format the cells, rows, columns with prices to local currency(i.e. SEK) as mentioned in the link: Format Numbers in excel.
You could add other parameters such as date as mentioned in below link:
Get exchange rate on a specific date from GoogleFinance
I'm attempting to set up an OpenCart store for a client.
I'm getting the following error on the shipping page.
"Warning: No Shipping options are available. Please contact us for assistance!"
Research suggests that this error happens when there is a mismatch between the weight-class for the store and for the plugin, or something similar.
I've tried every combination of configuration settings that I can think of without result.
I'm not familiar enough with OpenCart to debug this issue. Where do I need to start looking?
Firstly you have to enable the shipping status and the values from admin panel shipping tab.After that you can get it in the front end.
My troubleshooting procedure:
The store weight UOM had been set to ounces.
The Fedex plugin doesn't support ounces as a weight UOM.
Nothing works.
The store weight UOM was changed to LBS.
Nothing works.
The package size was set to FedEx 10 KG Box
The Fedex plugin can't convert from Lbs to KG on the fly.
The package size was changed to "Fedex Box", without a weight class
Some products now working, all shipping estimates are WAY high.
When changing the default UOM for the store, no existing weights are converted in to the new units, although any weights stored without a unit are now read as being in the new unit.
This meant that the fedex system was trying to pull prices for items that "weighed" hundred of ounces (which it should have been able to do, even though those weights were incorrect.)
I updated the weights on all products to be in line with their unit of measure
At this point, the plugin was working for most, but not all, products, with reasonable accuracy.
I changed the plugin settings from List Rate to Account rate.
Now everything works.
To simplify - The fedex shipping plugin in opencart 1.5.6 will only work if:
All the products in the system have their weights stored in the same UOM.
That UOM is either pounds or kilograms (not ounces!)
A geozone is set, and a zip code is supplied(zip codes are important!)
The package size matches the unit of measure for the weight (no mixing kilograms and pounds!)
The product weights are actually correct
The account in question has a rate for a package of the indicated size
Hopefully someone else will find this helpful.
Ive been through this problem as well and I haven't yet fixed it completely.
But in my particular problem, I had a syntax error in the XML retrieved by the Fedex server after the cURL request.
Printing the $response variable I could find some good hints about some of the problems, for example, commas (,) instead of dots (.) to refer to decimal numbers and decimal numbers where it was expecting an integer.
So var_dump($response) could help some people find their specific issues.
This may be a niche question but I'm working with ICU to format currency strings. I've bumped into a situation that I don't quite understand.
When using the MesssageFormat class, is it possible to get access to the NumberFormat object it uses to format currency strings. When you create a NumberFormat instance yourself, you can specify attributes like precision and rounding used when creating currency strings.
I have an issue where for the South Korean locale ("ko_KR"), the MessageFormat class seems to create currency strings w/ rounding (100.50 -> ₩100).
In areas where I use NumberFormat directly, I set setMaximumFractionDigits and setMinimumFractionDigits to 2 but I can't seem to set this in the MessageFormat.
Any ideas?
Probably because one Korean Won is worth $0.00088. They don't have pennies.
Same idea with the Swiss Franc, the 1 centime coin stopped being legal tender in 2007.
I've determined that gaining access to the internal formatter used is not possible. I've opened a ticket with the ICU project. http://bugs.icu-project.org/trac/ticket/7571#preview
If a customer were "silly" (being polite here) enough to try and add, as an example, 4.6 items to their basket, what would you expect to see? or how would you deal with it. Obviously, we only deal with digital quantities (our hacksaw broke last week).
There seems to be a lot of inconsistence across the web.
Amazon Rounds down (4.6->4, 1.3->1)
FireBox Rounds (4.6->5, 1.3->1)
Ebuyer ignores the input (no error)
Expansys removes the item from your basket
I'm assuming some site will show an error
Which is the best solution
Add JavaScript verification that would remove non-numeric input while the user is typing in
Implement backward solution for the situation when JavaScript is off, either display an error message or round the value but then display a message saying "your input has been adjusted"
ADDED: Also be aware that the character that separates the fractional part from the integer one differs from country to country. In US I believe it is '.', in Europe it is usually ','. If your applications is targeted at customers in different countries with varying number representation, it would make sense to implement the support for both characters in your application logic. Otherwise some users will get format error messages without knowing why - non-techie people are often unaware of this format issue.
How about validating the user input and accepting only numeric characters?
One solution would be to bring the incorrect input to the user's attention so they can correct it. Rounding can be too much of an assumption depending on the context.
Displaying an error message next to the amount something like this: "I'm sorry, we cannot supply you with 4.6 items. Please enter a whole number." ...or something along those lines.
Another solution would be to avoid displaying error messages by restricting the input field to only allow valid input. ie If you don't want 4.6 items...only allow the user to be able to type 0-9. If the user can't enter incorrect input then there is never any reason to display an error message.
Assuming you're talking about a web app here, you can limit the characters allowed in the input box.
Alternatively, IMO you could use spinner (+/-) controls to change the quantity.
I believe tesco.com does this.
The best solution according to me would be
Customer enters: 4.6
Value changes to 5 after submitting (or if 4.4, round it to 4)
Notice is displayed telling the user that only integers are valid and that the system has roundedy "your" input (4.6) to 5
One solution would be to inform the user that their selection is invalid when they tab off the edit field that's allowed them to enter the fraction.
A lesser option would be to round (down, unless you're greedy to sell 1 extra item), or to reject the input completely.
The best solution is to prevent fractions in the first place by giving them a slider or spin control to select only whole numbers.
At the end it's always safer add server side check.
So if the input it's not an integer value:
I will redirect the user to the same form.
I will set the field with the floor value (4).
I will put on top of the field a message like"This field must be an integer value. May be did you want 4 pieces of this product?"
In my opinion if your product is an shopping system then it makes sense that primary goal is to sell some items. Usually customers want to perform as less actions as possible, so the system should predict what customer could possibly want when typing incorrect inputs.
Amazon Rounds down (4.6->4, 1.3->1) - the best for me, because everything after the decimal point can be destined to some other input;
FireBox Rounds (4.6->5, 1.3->1) - as for me I don't like when someone want to sell me more than I want to buy, so better 'floor' than 'round';
Ebuyer ignores the input (no error) - then you'll sell nothing and user needs to enter some values once again;
Expansys removes the item from your basket - terrible, now I need to search for the item in the shop once again;
I'm assuming some site will show an error. - not bad but required user to retype value;
I would implemented as Amazon plus informing user that input was not fully clear and asking him to recheck the value. So if the system guessed right then user need to change nothing but if he mistyped he'll see it immediately.
Also you could log all this kind of incidents and then perform an analysis, what user typed for the first time and what was the actual count he bought. Just for curiosity...
Well, you definitely should never round up. You should not ever bill for more materials than the customer requested, no matter how inane the request.