When splitting budgets across quarters, the FinancialValues class is used to get the closest exchange rate for the currency in question, which is then used to calculate the figure for the value_local fields, given the figure in USD or the original currency.
This behaviour will produce inaccurate figures if the exchange rate changes across the course of the budget, because the exchange rate figure for the first quarter of the budget period is used for every subsequent period. This will very rarely be a problem, the results being so small as to be negligible. But in very rare cases (e.g. when the budget spans a long period, and there is an economic crash part way through), it has the potential to result in figures which are more substantially inaccurate.
The budget splitting code is in model.py, class ActivtyBudget._get_list_budget_periods; the code which gets the exchange rates is in the FinancialValues class, the method called _values_local. (also in model.py).
As of Sept 2023, it is possible to see this bug in action with the activity NL-KVK-53521129-materials that is found in file idh_activities.xml; however, the bug is only visible here because there is bad data in this activity file: the third budget in the file has a start date and budget value date of 1970-01-01 and so runs for 54 years; this causes the code above to employ a 1970s exchange rate for all countries it splits the data over, and in Brazil's case, the exchange rate in 1970 was 1.58181818151268E-12 (against USD), and the result is very low figures across the value_local column for that budget. But that is only due to bad data. The likelihood of this occurring with good data is extremely low.
When splitting budgets across quarters, the
FinancialValuesclass is used to get the closest exchange rate for the currency in question, which is then used to calculate the figure for thevalue_localfields, given the figure in USD or the original currency.This behaviour will produce inaccurate figures if the exchange rate changes across the course of the budget, because the exchange rate figure for the first quarter of the budget period is used for every subsequent period. This will very rarely be a problem, the results being so small as to be negligible. But in very rare cases (e.g. when the budget spans a long period, and there is an economic crash part way through), it has the potential to result in figures which are more substantially inaccurate.
The budget splitting code is in
model.py, classActivtyBudget._get_list_budget_periods; the code which gets the exchange rates is in theFinancialValuesclass, the method called_values_local. (also inmodel.py).As of Sept 2023, it is possible to see this bug in action with the activity
NL-KVK-53521129-materialsthat is found in fileidh_activities.xml; however, the bug is only visible here because there is bad data in this activity file: the third budget in the file has a start date and budget value date of1970-01-01and so runs for 54 years; this causes the code above to employ a 1970s exchange rate for all countries it splits the data over, and in Brazil's case, the exchange rate in 1970 was1.58181818151268E-12(against USD), and the result is very low figures across thevalue_localcolumn for that budget. But that is only due to bad data. The likelihood of this occurring with good data is extremely low.Example data: