Dependencies and cache

What are dependencies?

Any source of external data that a template can use is considered a dependency. For example:

A custom drop stored in another template (e.g. period.reconciliations.handle.custom.namespace.key )
Entries in the Trial Balance (any data coming from the accounts drop, and also adjustments)
Any other type of drop like the company drop, people drop or account drop.
Checking the starred status of another template (e.g. period.reconciliations.handle.starred?)
A result fetched from another template (e.g. period.reconciliations.handle.results.result_name)

All the different sources of data mentioned above can only be the first item (the first level) in our chain of dependencies. Results are the exception; they are going to create our extra levels when we start using them across different reconciliations.

You can make use of the debug panel to inspect your template’s dependencies, especially in the "Flame graphs", "Dependencies" and "Dependency tree" sections. All the previous examples will be shown as a dependency in these sections.

Cache differences

It is important to know that there is a limit of three levels of dependencies across templates. So whenever you cross the threshold of 3 levels, cache differences could arise. This depends on which template in the chain has been changed. This limitation is specifically related to performance reasons and loading times of templates on the Silverfin Platform.

This doesn't mean that you cannot link multiple reconciliations in a chain, but you will face this limitation when you start to include a value in a result that is built in a chain of results across different templates. If results are not linked to each other (e.g. not related values or calculations) this issue won't arise.

Input vs Preview/Export

A second type of cache difference exists when results, unreconciled and the required attribute are used in tags that behave differently in input vs export. Think ic/nic tags, ifi-statements and fori-loops.
This is only an issue for account templates, as reconciliation templates always render in input mode.
We explore a couple examples in this case on our Community.

Template result/reconciliation status

While most cache differences are related to named results, the template result (reconciliation status) is also stored in the cache. When a cache difference in template result occurs, you can have situations where the template is in theory reconciled, but the indicator on top is still showing unreconciled (or the other way around). This also impacts workflow progress.

In the example in the screenshot below, the reconciled indicator is influenced by a result from another template, that in its turn depends on a result from a third template. So that's three levels in the chain, meaning there are no cache issues with the logic in this template. However, the result of this template is also stored in the cache and will not be refreshed because it is already the fourth level in the chain. On a workflow level, and as you can see next to the title of the template, the platform is still looking at a cached template result.

Export considerations

If you generate a XBRL/iXBRL export (or any other type of export where you use a liquid export template), this is an extra level in the chain, and you should consider the dependencies it has while exporting
On the other hand, PDF exports from Silverfin behave a bit differently. The PDF is not considered as an extra level in the chain, but rather the templates that are included.

Example

Consider the following case: in a reconciliation (RT 1) you access some data stored in an account from the trial balance, you perform some calculations and create a result with it. Then, in another reconciliation (RT 2) you access this result to do further calculations. This is already the third dependency level in the chain. If you would create a result in this reconciliation to be used in, for example, the XBRL as detailed in the previous diagram, you would be exceeding the limit of 3 levels of dependencies. In this scenario you could face some cache differences; if any of the values in the first level (in this case, the account value) changes, it won't be reflected in the fourth level (the XBRL) where we would still be using the older value.

Check out this case on the Developer Community on how to solve cache issues.

Cache differences UI (coming soon)

On firm level, templates with cached result issues will be flagged with a red warning sign.
This will be visible on custom templates, but not on ones that have been added through the Marketplace.
The warning signs and table with details are visible to all firm admins.

The template edit page will, in case of any registered cache differences, have a table showing some affected results, their cached value, actual value and files in which the difference occurred.

Conditions

Templates only get flagged once an actual issue has popped up in one of your firm’s client files. There may very well be an issue code-wise that isn’t flagged, because the specific requirements to trigger the cache difference haven’t occurred yet.
The UI will show differences that have been recorded. That doesn’t guarantee these differences will still show up in flagged files at the time when you go investigate them.
Updating the template code will reset the query that checks for cache differences. Any differences you saw in the table before the update will be gone, but that doesn’t necessarily mean that the issues have been solved permanently.