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.
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.
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 especially an issue for account templates, but can lead to cache differences in reconciliation texts as well.
We explore a couple examples in this case on our Community.
- 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.
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.
Updated 5 days ago