It is not uncommon for firms to transition from one mapping list to another. This transition can stem from a variety of factors, including changes in company type, where different company types require different account mappings, or a strategic shift towards a more standardized mapping list. While such shifts bring several advantages, they can also introduce unexpected complexities within underlying templates. This is especially the case when these templates rely on comparisons between the previous and current periods.
Consider the following scenario:
We are working with a template featuring two value columns—one displaying the value at the start of the taxable period and the other showing the end balance of the taxable period.
In period 1 (end date 31/12/2021), the liquidation reserve starts at 0 and increases to 48,889.39:
This end balance value is directly linked to a selected account, let’s say with a range of “100000” for simplicity.
Now, moving to the subsequent period (end date 31/12/2022), we would expect the value of 48,889.39 to reappear in the first column (at the beginning of the taxable period). However, during this second year, the mapping list was updated and the mapping for previous year has been locked. One of the significant changes is that liquidation reserve accounts are no longer booked under accounts with the range “100000” but are now associated with accounts having the range “200000.”
As a result, we need to adjust the selected account in the account selector next to Liquidation reserve. So instead of selecting the “100000” account, we will now select the “200000” account to reflect these mapping changes.
However, when inspecting the outcome, we encounter an unexpected situation:
The end value is recognized and displayed correctly (since this is now effectively booked on the new account), but the opening balance remains at 0.
Here is what is happening in the background:
In the Silverfin Templating Language (STL), we often work with the end balance of the previous period to display the opening value (period.minus_1y.year_end), assuming that this end balance is equal to the opening balance of the current period.
The code for our example may look like this:
{% assign previous_period = period.minus_1y.year_end %}
{% assign selected_accounts_range_1012 = custom.selected_accounts.code_1012 %}
{% assign accounts_code_1012_I0 = previous_period.accounts | range:selected_accounts_range_1012 %}
In this case, we look at last year through the lens of the former mapping list, whereas our true intent is to look into the past year through the perspective of the current mapping list. Unfortunately, the newly selected account (range 2) did not exist in the old mapping list, leading to incorrect results.
To address this, we need to access the account in the previous year but with the current mapping list applied. Fortunately, there is a workaround that will do exactly this.
Instead of checking the end balance of the previous period, we can also use the opening_value method on the period-drop. Since we then will be accessing data from a period within the current year, it also applies the updated (latest) mapping list.
Our updated code will then look like this:
{% assign selected_accounts_range_1012 = custom.selected_accounts.code_1012 %}
{% assign accounts = period.accounts | range:selected_accounts_range_1012 %}
{% assign accounts_code_1012_I0 = accounts.opening_value %}
When we implement the above approach in our case, it indeed gives us the expected results:
