[Cloud release: 2026.03.18]
[On-prem release: 2026 June]
[On-prem build: 26.05.22002]
With this release the calculation interface has been improved on several points when you create a custom calculation or when you edit an existing calculation.
Bigger syntax field
When creating a new custom calculation or editing an existing calculation, the syntax field has been increased in size.
Furthermore, any line breaks and indentations that are added to the syntax will be preserved, also when saving and reopening the calculation.
Example, bigger syntax field, preserved line breaks:
Calculation IDs
In addition to the calculation title, the calculation now also features a unique calculation ID. The unique ID can be used as a reference in another calculation.
You may rename the ID to something else. E.g. you may rename it to be identical to the calculation title for easier recognition. Just make sure that the ID is still a unique ID within the current object. IDs cannot contain spaces or other special characters, but do accept underscores.
Example, custom Calculation ID being referred to in next calculation:
References
Click the buttons in the References section to display the various reference options directly in the object.
These reference options provide different ways of referring to measures, calculations and dimensions in your calculation syntax.
Measures references
- Title. This is the default display. This is how the measure is displayed to the end-user, including potential translations and dynamic captions.
- ID. This is the "real" name of the measure - stripped from translations and dynamic captions. You can use the ID as reference in a calculation syntax.
Example: sum(d-1, 0, @"Revenue") - Number. This is the numeric value of a measure. You can use the numeric value as reference in a calculation syntax.
Example: sum(d-1, 0, m1)
Calculations references
- Title. This is the default display. This is how the calculation is displayed to the end-user according to its title, including potential translations and dynamic captions.
- ID. This is the calculation ID. You can use the ID as reference in a calculation syntax.
Example: sum(CalcColA, 0, @"Revenue") - Number. This is the numeric value of a calculation. You can use the numeric value as reference in a calculation syntax.
Example: sum(c1, 0, m1)
Dimensions references
- Title. This is the default display. This is how the dimension is displayed to the end-user including potential translations and dynamic captions.
- Short ID. The shortest possible form in which you can refer to this dimension level.
Example: sum(d-1, 0(l"Territory"), m1).
Note that the Short ID will be replaced by Long ID once you click "Apply". - Long ID. The full reference ID of a dimension level. Use the Long ID if the Short ID fails due to being unambiguous.
Example: sum(d-1,0(l"Customer Hierarchy.Customer Hierarchy.Territory"),m1)
Example 1, default Titles:
Example 2, Measures and Calculations IDs:
sum(d-1, 0, @"Profit")sum(@"CalcColA", 0, 0)
Example 3, Measures and Calculations Numbers:
sum(d-1, 0, m2)sum(c1, 0, 0)
Example 4, Dimensions Short ID:
sum(d-1, 0(l"Territory"), m1)
Example 5, Dimensions Long ID:
sum(d-1, 0(l"Customer Hierarchy.Customer Hierarchy.Territory"), m1)
Comments
You can add comments to your calculation syntax by encapsulating comments in /* ... */.
This is also useful for out-commenting temporary syntax bits.
Example:
Comments
Historically References are language dependent - that is, if the dimension in scope for referencing is translated in the datamodel then the calculation only works in the original language used for the calculation. For instanse - the sum(@"[Yes]",0,m1) will not work if "Yes" has been translated to the Danish "Ja". Has this issue been fixed in this version or do we still have to circumvent this in our multi-language setup?
Hello,
After updating TARGIT to the latest version, we noticed an issue with the expression editor when using the rowlevel() function within an IF statement.
For example, with the following expression:
if rowlevel() = 1 and sum(d1,0,m1) > 10000 then 1 else 0
The expression editor displays a validation error ("Invalid expression"), highlighting the subsequent part of the expression as incorrect.
We also noticed that the rowlevel() function is no longer listed in the available functions menu.
However, despite the validation error, the calculation still executes correctly and returns the expected results.
We would like to clarify the following:
Is the rowlevel() function deprecated or scheduled for removal in future versions?
Is this a known issue with the expression editor's syntax validation in the latest version?
Should we consider replacing or refactoring existing calculations that rely on rowlevel()?
We have several calculations that use this function, so we would like to understand whether any changes are required to ensure compatibility with future releases.
I've attached a screenshot illustrating the issue.
Thank you in advance for your assistance.
Please sign in to leave a comment.