I have scoured the forums about this problem but am confused as to whether I have a bug or whether this is normal behaviour.
I have several currency fields in custom modules. These custom fields show the ‘$’ symbol in front of amounts in list views and subpanels no problem. However the ‘$’ symbols do not show in detail view fields in any module, including the built in INVOICES module.
I have just one currency. I have the currency_id field included in the custom modules with the id value set to the default currency in each record.
I have also tried using field names with ‘_usd’ on the end.
I would have thought that by default the currency fields would show the ‘$’ symbol before the amount in the field itself. Or, is this something that must be coded into the field?
Sorry, I also thought you were talking about the front end. I’ve encountered this problem in email templates and successfully added the “$” to currency fields in the email template. You may want to review the PDF template for same:
Not only the currency symbol isn’t displayed in the view,
When you print quotes, they aren’t displaying the currency symbol either (have you ever seen a quote without a currency? Usually it’s not just the currency symbol, there’s a dedicated field that mentions the base currency, which is lacking)
And I’m sure it’s also missing from other places.
I believe an issue on Github should be opened with this and corrected all across the application.
I appreciate your comment and suggestion (really), as it provides a quick fix for an issue.
However, I believe we have to evaluate the use-case and determine if it calls for a “quick” fix, or a definite fix.
If you’re working with multiple currencies (like for example Euro and USD) you’re not putting the dollar sign before an Euro value. So you’d have to edit the template each time.
I find it paramount to identify the correct unit type to each column
accountant
One of ours
So, not only they come with the currency sign next to the values, they also specify clearly what currency is being dealt with.
I think this is simple to understand and on a global world selling services abroad without identifying the correct currency … doesn’t make any sense to me.
If you send the same quote to a customer on the USA and on Canada, is it USD or CAD? And if you send it to Mexico, is it Pesos?
No, the currency must be clearly identified. And this should happen automatically for each document produced.
I add the currency type field at the bottom of the quote. I sell in $can and $US both have the same symbol so adding it inline really doesn’t help that much. There are always creative work arounds.
Super, was lazy to search (so I’m sorry and thank you for doing it) but heck with it the solution stays here.
That solves all issues, one just has to put the currency symbol where it should be, and the currency ISO code, and so on as per each likings, on the template.
Good morning, I see I have started quite a discussion here. Thanks to you both for clearing up the issues with templates and pdfs etc.
However, I am indeed talking about the frontend. It seemed to me weird that the $ symbol should be displayed in the field (not label) of lists and subpanels etc, but not in the detail view of a page for ANY module.
This does seem to be normal behaviour for SCRM, but my thinking and preference is that ALL currency fields whether list or detail view should include the $ as part of the value. Assuming of course that this is the default symbol, which it is for me.
I have been stepping through the code with VSCode and see that custom DetailView.tpl is checked for existence.
include/SugarFields/Fields/Base/SugarFieldBase.php line 129.
So, with this, I’m exploring this possibility to format the currency fields in a custom DetailView.tpl along with custom Detail View.
for some this might be old news, but for newbies this might be good info…
I have now discovered why the CURRENCY only shows in the field label for ‘Opportunities’ and ‘Campaign’ modules. The code to do this is only included in these 2 modules.
I copied modules/Opportunities/views/view.detail.php to custom/modules/your-module_name/Views/view.detail.php
Then changed the class name at line 57 to match the module name.
Then in custom/modules/your-module_name/metadata/detailviewdefs.php, I replaced the labels for each currency type field ;
Hey Presto the CURRENCY field labels properly formatted.
Now to see whether code can be altered to show that $ symbol in the value field rather than in the label for all currency fields in all modules in detail views.
Ok so I might need some help to make this upgrade safe.
My quest to make currency fields show the currency symbol continues…
The easiest way seems to be to alter template file;
include/SugarFields/Fields/Currency/DetailView.tpl
changing {sugar_number_format …
to {sugar_currency_format …
This is what is called in ListView.tpl
However this is not upgrade safe!
Before finding the above solution I went down a different path which has the advantage of showing a % symbol for Percentage fields.
Altering the file ;
include/Smarty/plugins/function.sugar_number_format.php
as follows will do the trick. It also adds the % symbol for integer presumed to be percentage. I have tested this on a various modules and it all works as expected so far.
function smarty_function_sugar_number_format($params, &$smarty) {
global $locale;
if(!isset($params['var']) || $params['var'] === '') {
return '';
}
if ( !isset($params['precision']) ) {
$params['precision'] = $locale->getPrecedentPreference('default_currency_significant_digits');
$params['currency_symbol'] = true; // New line
} else{ // New line
$params['percentage'] = true; // New line
}
$_contents = format_number($params['var'], $params['precision'], $params['precision'], $params);
if (!empty($params['assign'])) {
$smarty->assign($params['assign'], $_contents);
} else {
return $_contents;
}
}
However, I have so far not been able to make either of these methods upgrade safe and could do with some help please.
Adding the function to custom/Extension/Application/Ext/Utils works only if I delete or rename the original function. Which defeats the purpose.
I don’t know why I didn’t try this, but yes that works.
However, given that the other method ( of altering the Plugin) which gives me % as well, it would be preferable to make this upgrade safe. But I don’t see a way.