7

You don't have an option of selecting multiple currency in the same page So, Creating separate page of each currency could be a best option also easier way. Or You can create an extension for listing multiple currency in a single page, playing around price set - which is going to take some time


5

I managed to solve this. I looked at what adding a contribution touches in the database. I ruled out differences in the settings table, but then when I looked at civicrm_currency I found that in this database, some characters were not present, even though the encoding would support them. so for instance the civicrm_currency record (6,'INR','₨','356','Indian ...


4

We had the same issue. The cause of the membership creation issue is with the email template syntax. Look in your system-generated messages and change the receipt templates you are using with, any instance of: {$line.unit_price|crmMoney:$currency} {$line.line_total|crmMoney:$currency} {$formValues.total_amount|crmMoney:$currency} Needs to be changed to: {...


3

Well - there's a bug worth reporting here, but I understand your priority is getting these letters out. This should do the trick: Go to Administer menu » Localizations » Languages, Currency, Locations. Change Monetary Amount Display to %a.


3

There are many ways you can do this Create contribution page and price set for each currency. Provide a list of contribution page to user and based on currency they can use the contribution page Create contribution page and price set for each currency. Add currency field on each contribution page using buildform hook and on selection of currency load the ...


3

Here is an extension that might help a bit with money formatting issues in Canada: https://civicrm.org/extensions/canadianbacon It basically sets the CiviCRM money settings dynamically when it detects the fr_CA or fr_FR language. We have been using these kind of hacks for a while, but had never bothered to make a proper extension, hoping it would be fixed in ...


2

It transpired that the error was due to the fact that the affected transactions were recurring payments, and the stripe extension did not pass currency data to stripe.com. So, in my use case, a user has submitted a recurring payment in GBP, and a subsequent user has attempted to submit the same payment in terms of amount and frequency, but in USD. As the ...


2

Yes, you can change the invoice value based the currency To start with please create an extension using hook_civicrm_tokens and hook_civicrm_tokenValues Make the necessary changes in Message Templates -> System Workflow Message -> Contribution Invoice Receipt This will allow you to make the changes in Invoice


2

If you install Fuzion's Extension: ExtendedReport (nz.co.fuzion.extendedreport) - specifically the Line Item report for price sets - then you can pull currency into your Reports; here's a screenshot of what that looks like (for a variety of Donations/Events pages). You can then make a report a) for one currency and b) for another currency [using filters]. ...


2

I am afraid that CiviCRM will not provide a lot of features out of the box for multi-currency use. Also, it does not know exchange rates (in fact it only stores the currency and one amount value - not both). Searches and reports will usually not differentiate between the currencies and (depending on your requirements) you may have to invest quite some time ...


2

My workaround for this is to immediately convert the CSV file in a text editor such as Notepad++ or UltraEdit. As soon as it's downloaded I open the CSV as UTF8, then immediately save it as ANSI. It's a bit fiddly, but fixes the £ problem, as well as any unusual characters in names/addresses.


2

This was curious, so I tracked it down. Apparently the list of valid currencies predates the civicrm_currency table. So right now the valid currencies are hardcoded - you can see that in <civiroot>/CRM/Core/Pseudoconstant.php around line 1077 - the currencyCode() function. As a quick workaround, you could add your currency to the list. However, the ...


2

The crmMoney function uses php's money_format() function to format the numbers. On Windows, this function does not exist! (https://issues.civicrm.org/jira/browse/CRM-650) However you can use crmNumberFormat to format it yourself, and add in the currency symbol manually, for example, assuming you want the US dollar symbol: Instead of {$amount|crmMoney:$...


2

If you need to change the settings globally, not just for the single statement, you have the option under Administer -> Localization -> Languages, Currency, Locations. There you can define the "Thousands Separator" as well as the "Decimal Delimiter".


2

This was a regression and was fixed. https://lab.civicrm.org/dev/core/-/issues/2344


1

I believe the standard workflow for accounting requires a single currency per batch. At least that was all that we aimed to support. Please create an issue at lab.civicrm.org indicating that there should be a 'friendly' error message preventing transactions that have a different currency from ones already in the batch from being added. This should include an ...


1

Try re-saving the contribution pages so that the new default currency is updated. You can cross check the currency used for contribution page using api explorer, it might be helpful to track the error. HTH Pradeep


1

I tried to replicate it in Civicrm 4.7.23 and Drupal 7.56 and i also got same error message through API call: $result = civicrm_api3('Contribution', 'create', array( 'financial_type_id' => "Donation", 'total_amount' => 100, 'contact_id' => 202, 'currency' => "RSD", )); Looks like its bug (maybe) in civicrm, i have created Jira issue ...


1

When you look at the csv, what software do you use? Are you looking with Excel, and if so is Excel also expecting UTF8?


1

It sounds like the API call and/or payment form in CiviCRM would need modification to handle say, USD -OR- Euros -OR- GBP, is that right? Seeing that no further answers were given since Feb 2017. And in Authorize, the payments might have to go to different accounts?


1

After spending time to resolve this across several days and working with our site administrator to troubleshoot we figured it out. The site administrator was able to confirm that the values were being stored in the database, so it was probably something to do with formatting. I eventually discovered that the display rules were configured wrong. It was ...


Only top voted, non community-wiki answers of a minimum length are eligible