I think that function is needed too because we need two approaches:

1. convert every transaction (this function)
2. convert only sum of transactions (the function you've written)

According to what you've written, the only problem with this function is that it takes entry date instead of transaction date for conversion rates.

This happens in the the pivotable class:

1. Fetch related transactions

2,. Add relates split values, bugdet values and so on to the current grid entry. The current grid entry has a date derived from report settings e.g. for yearly report it is Jan 30, Feb 28, Mar 31. [1]

3. After collecting the values convert the grid entry values based on the grid entry date, which may differ from the transaction date

After topic 2. the original transaction date is lost and only a sum based on the current grid entry date is available. I don't see how convertToBaseCurrency() could be able to convert a sum based on different single values without having each single value and without the transaction date of each single value. From my observation the conversion need to be done for each transaction before adding to the grid at topic 2., which is implemented in this patch.

What I see is that current convertToBaseCurrency has many loops and you want to replace that function with the one without loops, which I think is wrong. If we loose transaction date then that's bad, so maybe we should convert currency when transaction date is available.
I think your patch, in current form, may fix one issue and introduce another one, so it's not good neither.

... with the one without loops ...

If you display the patch with "show all content" or apply this patch to git master (I hope it fits) and take a look at the context, you will see that this function is called inside the loops adding data to grid before values are added to the report grid by calling assignCell(). [1]

If we loose transaction date then that's bad, so maybe we should convert currency when transaction date is available.

Which is only available in the loops mentioned at [1] and why the conversion is done there.

I think your patch, in current form, may fix one issue and introduce another one,

You are refering to that the conversion has been moved up in init() inside the initial loops and that the following calls may also need also conversions ? Or do you refering to something else ?

//
// Get forecast data
//
if (m_config_f.isIncludingForecast())
  calculateForecast();

//
//Insert Price data
//
if (m_config_f.isIncludingPrice())
  fillBasePriceUnit(ePrice);

//
//Insert Average Price data
//
if (m_config_f.isIncludingAveragePrice()) {
  fillBasePriceUnit(eActual);
  calculateMovingAverage();
}

//
// Collapse columns to match column type
//


if (m_config_f.columnPitch() > 1)
  collapseColumns();

//
// Calculate the running sums
// (for running sum reports only)
//

if (m_config_f.isRunningSum())
  calculateRunningSums();

//
// Calculate Moving Average
//
if (m_config_f.isIncludingMovingAverage())
  calculateMovingAverage();

//
// Calculate Budget Difference
//

if (m_config_f.isIncludingBudgetActuals())
  calculateBudgetDiff();

//
// Convert all values to the deep currency
//

convertToDeepCurrency();