Tables exporting on new page in export without any newpage syntax or group tags?

Templates
1

Have a little bit of an urgent question. You can see below that the table is exporting on a new page. Despite the space being there.

image
image647×761 40.6 KB



However, you can see from the code snippit below that there is no syntax that should be causing that. No group tags or newpage syntax anywhere.

image
image1237×365 32.7 KB



I suspect it has something to do with the Detailed text. But I am not certain. Here is a code snippit of our Detailed text:

image
image948×655 31.3 KB



Code for detailed text:

{% comment %}
------------------------------ INFO DETAIL TEXT ----------------------------------
Detail texts are used to export details from account and reconciliation templates ONLY
(text templates will go automatically)
Basically, detail text is what gets executed when selecting a block “accounts”

We can loop over accounts, using the acc number as the unique key component
We can loop over reconciliations as well, using the virtual account number as key

Access to the needed details sits within the
“export.selected_accounts_and_reconciliation_texts”, which can be filtered on:

  • account or not
  • type (assets, liabilities, …)
  • number (acc and virtual acc number)

Keep in mind that a virtual acc nbr can also be a string, just like an acc nbr can be

attribute “is_account”

To define when a detail is from an account or not

local var “new_page”

We create a variable new_page to dictate that the very first detail of a second block
accounts, is forced on a new page. If not, the second block would start right after the
first block.
So in the beginning this var is false; after that it’s set on true

changeorientation

This is used to decide “landscape” or “portrait”

  • when “preferred_orientation” is used, we will look at the amount of columns defined
    in a detail; more than 7 is automatically “landscape”
  • we can overrule above by using changeorientation “portrait”/“landscape”

{::group}

We need to be sure one detail stays together, which is why we use group-tags.
Keep in mind, {::group} opens a tag while {:/group} closes it.
These tags are also present in details, which is why there we first use a closing group
tag.

{% endcomment %}

{% assign details_wp = export.selected_accounts_and_reconciliation_texts.include_zeros_with_details | range:“1__9,a__z” %}

{% for detail in details_wp %}

{% if forloop.first %}

{% if new_page %}
{% newpage detail.preferred_orientation %}
{% endif %}
{% comment %}
{% assign new_page = true %}
{% endcomment %}

{% changeorientation detail.preferred_orientation %}

{% comment %}Title of a block when in first loop{% endcomment %}

{% endif %}
{% comment %}

      RECONS ONLY

{% endcomment %}

{% comment %}
{% changeorientation detail.preferred_orientation %}
{% endcomment %}

{% comment %}details reconciliation{% endcomment %}
{{ detail.rendered_template }}

{% endfor %}

2

@pgallagher

The solution here may be to add group tags on the template level, in order to ensure that the text will ‘stick’ to the table whenever possible. The trick is to add them before and after the section you would like to be ‘grouped’ (i.e. stick together on one page in export as much as possible). Please check out https://developer.silverfin.com/docs/group for info on how to place group tags. Text documents are treated differently than e.g. recon templates.

As your issue is urgent, please also reach out to support@silverfin.com so we can also have a look in your live environment(s), because based on the print screens you provide I can give you a direction but no specific solution.

1 Like
3

Thanks for your response. This is an option in some cases I think, if the table is small enough. But if the table is too large and I add the group tags it will still end up going onto another page unfortunately.

4

@pgallagher this is because we regularly assume that tables being intact (i.e. on one page) is preferred to having it to stick to a preceding block of text. If a block of text is an integral part of your table and should never be ‘separated’ from it as in your example, consider making the text a part of your table. This would mean creating specific rows in your table containing the text. Please let us know when you need guidance how to do this.