With the introduction of the Account Drop Modal (Accounts Drop Modal), we added the possibility to display account values that are negative in output (eg. liability accounts) and yet show the output as a positive:
{{ period.accounts.liability | currency,invert:true }}
This filter has been available since the release of the Account Drop Modal, but it was not yet possible to use it as an attribute when creating values. That is until now; this new attribute allows you to enter a value that will be saved with the opposite sign. Just add ,invert:true to the currency attribute:
{% input custom.some.value as:currency,invert:true placeholder:0 assign:my_value %}
{{ my_value | currency }}
Outcome:
So, in the database -500,00 will be saved when one enters 500,00 (and vice versa).
A good use-case in which this can be adapted (although it could be debated that it’s merely a UX decision), is when you have an account template that can be used to detail either asset or liability accounts. In such cases, the outcome of the account is either positive or negative. But to detail the account however, you want to avoid that the user needs to think on what kind of values (positive or negative) they need to enter.
An example:
{% comment %}
------------------------------
check type current account
------------------------------
{% endcomment %}
{% comment %}variable that marks if an input needs to be saved as negative or not{% endcomment %}
{% assign save_as_negative = false %}
{% comment %}only in case of a LIABILITY or INCOME account, are values needed reversed of sign{% endcomment %}
{% if current_account.liability_or_income %}
{% assign save_as_negative = true %}
{% endif %}
{% comment %}
=====================
TABLE DETAILS
=====================
{% endcomment %}
{% stripnewlines %}
<table class="usr-width-100">
{% comment %}table header{% endcomment %}
<thead>
<tr>
<th class="usr-line-bottom">{% t "date" %}</th>
<th class="usr-line-bottom">{% t "description" %}</th>
<th class="usr-line-bottom">{% t "value" %}</th>
</tr>
</thead>
{% comment %}details{% endcomment %}
<tbody>
{% fori detail in custom.details %}
<tr>
<td class="">{% input detail.date as:date placeholder:"DD/MM/YYYY" %}</td>
<td class="">{% input detail.description placeholder:"description" %}</td>
<td class="">
{% comment %}no matter type of account, make user to enter positive values{% endcomment %}
{% if save_as_negative %}
{% input detail.value as:currency,invert:true placeholder:0 assign:detail_value %}
{% else %}
{% input detail.value as:currency placeholder:0 assign:detail_value %}
{% endif %}
{% assign total_value_details = total_value_details+detail_value %}
</td>
</tr>
{% endfori %}
</tbody>
</table>
{% endstripnewlines %}
Take a look at this specific code:
{% if save_as_negative %}
{% input detail.value as:currency,invert:true placeholder:0 assign:detail_value %}
{% else %}
{% input detail.value as:currency placeholder:0 assign:detail_value %}
{% endif %}
This means that - if the account in which you are creating details for - is a liability or an income account (meaning the outcome of that account is negative), the user can enter the details as a positive (just as one would do when the account would be an asset or expense). The values will however be stored as negatives, and the value of total_value_details will be negative as well, thus matching the total on the account.
It could be debated that if the outcome of an account is negative, so must be the details, but that forces the user to think about which sign needs to be entered. In the end, this is a UX decision.
With the invert,true attribute, it can be accomplished that positive values are always entered while on database level these values are stored with the opposite sign.