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), fetching the opening value of a specific account is not straightforward. Typically, we work with the end balance of the previous period (period.minus_1y.year_end).
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 period period, we can also use period.minus_1y.year_end.plus_1p.
This will give us the end date of the first period after the year end of previous year (so basically, the end date of first period of this year).
Since this will return a period within the current year, it also applies the updated (latest) mapping list.
If we then use the opening_value method of the period-drop, we can fetch the correct opening value.
{% assign year_start_period = period.minus_1y.year_end.plus_1p %}
{% assign selected_accounts_range_1012 = custom.selected_accounts.code_1012 %}
{% assign accounts = year_start_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:
