1 Statement Email Template for 2 types of Customer Statements

1

The application has 2 types of ‘Customer Statements’: Customer Statement (Unpaid Invoices) and Customer Statement (Transactions). Both statememnts can be emailed.
In Settings, Email templates, Statememnt, only 1 email template for a Statement can be defined.

How can I distinguish between the 2 different customer statements when building the message body (thru HTML) of the Statement email, like
{% if statement type == “something” %}
TEXT1
{% else %}
TEXT2
{ % endif %}

And what are the field names for the Date and the Total amount?

2

Email templates are not written in HTML. They are written in Liquid. See Use email templates | Manager. You can see the Liquid variables involved by examining the code for the Plain theme.

3

Define a custom field then test that in your if statement.

4

For sure, I am missig the obvious but where do I define the Custom field. Cannot find ‘Customer Statements’ in Settings - Custom Fields - New Custom Fields

Running Cloud version on Mac OS Big Sur

5

You’re referring to the Customer Statement report. Custom fields can only be created for the modules(?) in the left-hand side menu, but not for report types. So I suspect @Patch may have been mistaken there.

What @Tut mentioned about using liquid syntax does apply, however. I’m trying to work out what variable you need at the moment …

EDIT: The only variable that I can find for Customer Statement email templates is recipient. I’ve guessed at a whole bunch of other potential email variable names but can’t find any others.

  • recipient.code
  • recipient.name
  • recipient.address
  • recipient.identifier
  • recipient.email
  • recipient.telephone

Used as follows: {{ recipient.name }}

All of those should work (if the related customer record has a value in that field), but unfortunately none of them are suitable for what you need.

6

Which is why I suggested creating a custom field specifically for the task. Users could then manually update to field to create what ever report format they wanted.

The alternative is to program the format change based on properties of the data being displayed. Removing user control reduces operator error but also decreases flexibility and means data must be available to write the boolean statement.

7

Thank you Guys.
Likely something that @lubos needs to work on.