CASE: Original vs. mapped account numbers

Templates Cases
, , , ,
1

One of the upcoming changes in Silverfin is that firms will be able to choose whether they want to display the mapped or the original account numbers in their templates, where until now the .number method always returned the mapped number.

We can print the different methods in liquid like this:

{% comment %}Add your account to an accounts drop{% endcomment %}

{% assign my_accounts = period.accounts | range:"WBedAlkOal.000" %}

{% comment %}print methods of the account drop{% endcomment %}
<table class="usr-width-100">
  <tbody>
    {% for account in my_accounts %}
      <tr>
        <td></td>
        <td></td>
      </tr>
      <tr>
        <td>.number method</td>
        <td>{{ account.number }}</td>
      </tr>
      <tr>
        <td>.mapped_number method</td>
        <td>{{ account.mapped_number }}</td>
      </tr>
      <tr>
        <td>.original_number method</td>
        <td>{{ account.original_number }}</td>
      </tr>
    {% endfor %}
  </tbody>
</table>

Which currently gives following result:

While in the future it can look like this for your firm, based on the option chosen in advanced settings:

You clearly see that the .number method is variable, depending on your advanced settings. As a consequence, .number can no longer be used in the following cases:

  1. As part of the name of a custom variable
{% assign my_accounts = period.accounts | range:"WBedAlkOal.000" %}

{% for account in my_accounts %}
  Don't do: {% input custom.[account.number].some_value %}
  Do: {% capture account_id %}{{ account.id }}{% endcapture %}
      {% input custom.[account_id].some_value %}
{% endfor %}

Since the result of the .number method can change depending on the option a firm chooses (original vs. mapped account number) , the name of your custom variable would change accordingly, and the inputted value would be stored in one variable but would no longer be shown when the option has changed.

Remark that all variables as described above in custom templates will have to be migrated before the firm can use the new functionality.

  1. As you may have noticed in the print screens with liquid code, we used the mapped account number in the range. Since the .number method can also contain the original number in the future, this will no longer work:
{% assign your_account_collection = period.accounts | range: account.number %}

We always want to use the mapped account number here, so the code in all templates should change to

{% assign your_account_collection = period.accounts | range: account.mapped_number %}

You can still use the .number method when printing the account number: e.g. {{ account.number }}. This will return the number that was chosen in the advanced settings page of the firm, so either the mapped number or the original number.

This case has been updated on 03/10/2022 to include HTML tables.