Variables, Buttons and Keys
A Variable is a storage location or an entity. It is a value that can change, depending on the conditions or on the information passed to the program. The actions in TDL can be delivered in three ways: by activating a Menu Item, by pressing a Key or by activating a Button. The definitions of both Buttons and Keys are the same, but at the time of deployment, Keys differ from Buttons.
Release 6 enhancement – ActionEx
Variable
In TDL, a Variable is one of the important definitions, since it helps to control the behaviour of Reports and their contents. Variables assume different values during execution and these values affect the behaviour of the Reports. A Variable definition is similar to any other definition.
Syntax
[Variable : <Variable Name>]
Attribute : Value
A variable should be given a meaningful name which determines its purpose.
Attributes of a Variable
The attributes of a Variable determine its nature and behaviour. Some of the widely used attributes are discussed below:
Type
This attribute determines the Type of the value that will be held by the variable. The Types of values that a variable can handle are String, Logical, Date and Number. In the absence of this attribute, a variable assumes to be of the Type String, by default.
Syntax
[Variable : <Variable Name>]
Type : <Data Type>
Example
[Variable : ICFG Supplementary]
Type : Logical
A logical variable ICFG Supplementary is defined and used to control the behaviour of certain reports, based on its logical value, as configured by the user.
Default
This attribute is used to assign a default value to a variable, based on the ‘Type’ defined.
Syntax
[Variable : <Variable Name>]
Default : <Initial Value>
Value of the variable should adhere to the data type specified with ‘Type’ Attribute.
Example
[Variable : DSP HasColumnTotal]
Type : Logical
Default : Yes
The Default initial value for the logical Variable DSP HasColumnTotal is set to YES. This variable will begin with an initial value YES in the Reports, unless overridden by the System Formula. We will learn about the System Formula in the coming sections.
Persistent
This attribute decides the retention periodicity of the attribute. If the attribute ‘Persistent’ is set to YES, then the latest value of the variable will be retained across the sessions, provided the variable is not a local variable.
We will learn about the concept of local and global variables shortly.
Syntax
[Variable : <Variable Name>]
Persistent : <Logical Value>
Example
[Variable : SV Backup Path]
Type : String
Persistent : Yes
The attribute ‘Persistent’ of the variable SV Backup Path has been set to YES, which means that it retains the latest path given by the user even during the concurrent sessions of Tally.
Volatile
In cases where the ‘Volatile’ attribute in the Variable definition is set to YES, the variable is capable of retaining multiple values, i.e., its original value with its subsequent values, are stored as a stack. The default value of this attribute is YES.
In cases where a new report R2 is initiated, using a volatile variable V, from the current report R1, the current value of the volatile variable will be saved as in a stack, and the variable can assume a new value in the new report R2. Once the previous report R1 is returned back from the report R2, the previous value of the variable will be restored. A classic example of this is a drill-down Trial Balance.
Syntax
[Variable : <Variable Name>]
Volatile : <Logical Value>
Example
[Variable : GroupName]
Type : String
Volatile : Yes
The ‘Volatile’ attribute of Group Name Variable is set to YES, which means that the variable ‘Group Name’ can store multiple values, which have been received from multiple reports.
Repeat
This attribute is mainly used to achieve the Auto Column behaviour in various Reports. Each Column is created with a subsequent Object in a Collection automatically, till all the columns required for Auto Columns exhaust. The ‘Repeat’ attribute has its value as a variable which has the collection of Objects, for which the columns need to be generated. Every time the Repeat is executed, the column for the subsequent Object is added.
Syntax
[Variable : <Variable Name>]
Repeat : <Variable Value>
Example
[Variable : SV FromDate]
Type : Date
Volatile : Yes
Repeat : ##DSPRepeatCollection
##DSPRepeatCollection variable receives the Collection Name from a Child report, which accepts inputs from the user regarding the columns required. Variable SVFromDate gets repeated over the subsequent period in the Collection each time the column repeats.
The Scope of a Variable
The scope of a Variable can be broadly classified as follows:
- Local
- Global
- Field acting as a variable
Local
A variable is termed as a local variable when it is associated to a Report. This means that the scope of the variable covers only the current report and its components. It is not mandatory for local variables to have an initial value.
Syntax
[Report : <Report Name>]
Variable : <Variable Name>
Example
[Report : Balance Sheet]
Variable : Explode Flag
Explode Flag Variable is made local to the Report ‘Balance Sheet’ by associating it using the Report attribute ‘Variable’. This variable retains its value as long as we work with this Report. On exiting the Report, the original value if given, is returned and the value modified within this report is lost. For example, consider a situation where ‘Stock Summary’ Report is being viewed with Opening, Inwards, Outwards and Closing Columns enabled through Configuration settings. Once we quit this Report and re-enter the Report, the variables return to the default settings.
Global
A variable is termed as Global variable when it is defined under System Variable section. It means that the scope of the variable covers all reports. An initial value is mandatory for global variables.
Note: A Global variable can also be made local to a Report by associating it to a Report, as discussed in Local variables above.
Syntax
[System: Variable]
Variable : < Initial Type Based Value>
Example
[System: Variable]
BSVerticalFlag : No
The BSVerticalFlag Variable is made Global. Hence, this variable value being modified in a Report is retained, even after we quit and re-enter the Report. The retention of a Global Variable can be done on two levels, i.e., either within the current session or across the sessions. If the Variable attribute ‘Persistent’ is set to YES, then the modified variable value is retained across the sessions, else the value defaults back to initial value on re-entering another session of Tally.
Field Acting as a Variable
The Variable attribute in a ‘Field’ Definition is used to make the Field behave as a Variable. when value is entered/altered in a Field, the variable assumes the same value with immediate effect. The Variable need not be defined previously, since it inherits its data type from the Field itself.
For example, in a Trial Balance Report, which is a drill down report, there is a need to retain the Group Name which has been selected by the user. So, each time the user scrolls up and down, the field value changes and the current field value is passed on to the variable immediately, so that if the current group is selected and drilled down, the report begins with the sub groups and ledgers of the selected group.
Note: The Variables used in a Field Acting as a Variable are local variables, and are local to the Report.
Syntax
[Field : <Field Name>]
Variable : <Variable Name>
Example
[!Field : DSP Group Acc]
Variable : Group Name
This is used in the ‘Chart of Accounts’ Report in TallyPrime, wherein the optional Field DSP Group Acc is made to act as a variable by using the Field attribute ‘Variable’, and the value selected by the user is passed on to this variable for further use.
Modifying the Variable Value
A field attribute Modifies is used to modify the value of a variable.
Syntax
[Field : <Field Name>]
Modifies : <Variable Name>
Example
[Field : SLedger]
Modifies : SLedger
The SLedger Variable is modified with the value stored/keyed in the Field SLedger.
Example – Variables
The following code snippet explains the usage of Local variable.
[Variable : LocVar]
Type : String
Default : “This is the default value”
;; Variable LocVar of Type String is defined and it is assigned a Default Value
[Report : Local Variable]
Variable : LocVar
;; At this point, Variable LocVar becomes a Local Variable for this Report
[Field : Local Variable Field]
Set As : “This is a Local Variable in Report”
Modifies : LocVar
;; Here, the variable value is modified with the Field contents specified in ‘Set As’
In this code snippet, a local variable LocVar is defined and locally attached to the Report ‘Local Variable’. This Report modifies the Variable Value to ‘This is a Local Variable in Report’. Once we exit from this Report, the value of the variable locvar modified in this Report is lost.
Buttons and Keys
The actions in TDL can be delivered in three ways – by activating a Menu Item, by pressing a Key or by activating a Button.
The definition of both Buttons and Keys are the same, but at the time of deployment, Keys differ from Buttons.
All the Buttons used within the attribute ‘Buttons’ are visible on the button bar, so that the user can either click it or press the unique key combination. All the Buttons used within the attribute ‘Keys’ are invisible entities and the key combination associated in the Key must be pressed to activate a key; whereas to activate a button, either it can be clicked or the key combination assigned for the button can be pressed.
Attributes of Buttons/Keys
Title
The ‘Title’ attribute can be used to give a meaningful Title to the Button being displayed on the Button Bar. This attribute is optional.
Syntax
[Key/Button : <Key/Button Name>]
Title : <Button Title>
Example
[Button : NonColumnar]
Title : “No Columns”
Key/Keys
This attribute is used to give a unique key combination, which can be activated by pressing the same from any Report or Menu. This attribute is mandatory if action is specified in this definition.
Syntax
[Key/Button : <Key/Button Name>]
Key : <Combination of Keys>
Example
[Button: NonColumnar]
Key : Alt + F5
Action
The Action attribute is used to associate an Action with the Button. Every Button or Key is defined for the purpose of executing certain predefined actions.
Syntax
[Key/Button : <Key/Button Name>]
Action : <Required Action>
Example
[Button : NonColumnar]
Action : Set : ColumnarDayBook : NOT ##ColumnarDayBook
Inactive
The Inactive attribute is used to activate the Button, based on some condition. If the condition is FALSE, the button will be displayed, but it cannot be activated.
Syntax
[Key/Button : <Key/Button Name>]
Inactive : <Logical Condition>
Example
[Button: Close Company]
Inactive : $$SelectedCmps < 1
ActionEx
The attribute ActionEx is used to enhance the multi-action support at button or key level. It allows you to specify multiple actions for executions when you invoke a key or button. ActionEx is a triple list attribute.
Syntax
[Button:<Button Name>]
ActionEx: <Label>:<Action Keyword>[:<Action Parameters>]
OR
[Button :<Button Name>]
<Label>:<Action Keyword>[:<Action Parameters>]
Where,
<Button Name> is the name of the button definition.
<Label> is any string to identify the ActionEx statement. Label supports for deletion, addition, modification, and replacement of the ActionEx statements. It is a mandatory sub-attribute.
- If the labels are unique, every ActionEx statements are executed in the order of their specifications.
- If the labels are same, the last action within the same label is executed.
<Action Keyword> is any platform or object-specific action except the function specific actions.
<Action Parameters> List of parameters as required by the action specified, separated by colon. Depending on the specified action keyword this parameter can be optional.
Example: 1
[Button: Show Final Accounts]
Key : Ctrl + F
ActionEx: TB : Display : Trial Balance
ActionEx: PL : Display : Profit and Loss
ActionEx: BS : Display : Balance Sheet
OR
[Button: Show Final Accounts]
Key : Ctrl + F
TB : Display : Trial Balance
PL : Display : Profit and Loss
BS : Display : Balance Sheet
Example: 2
Modify the code in example 1 to display the modified final accounts as given below:
- Delete the action to display TrialBalance using the attribute Delete: TB.
- Add the action to set the attribute ExplodeFlag as yes, after the label PL.
- Modify BS label to display the report ‘MyBalanceSheet’.
[Button: Modified Final Accounts]
Use : Show Final Accounts
Delete : TB
Add : ActionEx: After:PL: ExplodeFlagNo: Set: ExplodeFlag: No
Replace : ActionEx: BS :BS: Display : My Balance Sheet
[Report: My Balance Sheet]
……
Form: Balance Sheet
Example: 3
Use the button Show Final Accounts mentioned in Example 1, in the report MyReport and modify it locally to delete the display of Trial Balance using ActionEx.
[Report: My Report]
……
Form: My Report
[Form: My Report]
….
Button: Show Final Accounts
Local : Button: Show Final Accounts: Delete: ActionEx: TB
You can use the attribute ActioEx to achieve multi-action support which reduces the code size, instead of the attribute Action List with additional key definitions.
To display the final accounts using a button you need to write the following code using the attribute Action List.
Example
[Button: Show Final Accounts]
Key : Ctrl + F
Action List : Show Trial Balance, Show Profit and Loss, Show Balance Sheet
;; Key Names which are to be triggered in sequence
[Button: Show Trial Balance]
Key : Ctrl + F
Action : Display : Trial Balance
[Button: Show Profit and Loss]
Key : Ctrl + F
Action : Display : Profit and Loss
[Button: Show Balance sheet]
Key : Ctrl + F
Action : Display : Balance Sheet
Whereas when you use the attribute ActionEx, it reduces the code size.
Example:
[Button: Show Final Accounts]
Key : Ctrl + F
ActionEx: TrialBalance : Display : Trial Balance
ActionEx: ProfitandLoss : Display : Profit and Loss
ActionEx: BalanceSheet : Display : Balance Sheet
FAQ
What is the order of execution when ActionEx is specified with unique labels?
When ActionEx is specified with unique labels, the order of execution is same as the order of specification.
Example
[Button: Show Final Accounts]
Key : Ctrl + F
Title : Final Accounts
ActionEx: TB : Display : Trial Balance
ActionEx: PL : Display : Profit and Loss
ActionEx: BS : Display : Balance Sheet
In the above example, the button Final Accounts displays the reports in the given order Trial Balance, Profit and Loss, and Balance Sheet.
What is the order of execution when multiple instances of ActionEx are specified with the same label?
When multiple instances of ActionEx are specified with the same label name, then only the action specified in the last label occurrence will get executed.
Example
[Button: Show Final Accounts]
Key : Ctrl + F
Title : Final Accounts
ActionEx: TB: Display : Trial Balance
ActionEx: PL: Display : Profit and Loss
ActionEx: TB: Display : Balance Sheet
In the above example, the button Final Accounts displays the report Balance Sheet first and then the report Profit and Loss. It ignores the report Trial Balance.
I have used the attributes Action List, Action, and ActionEx in my project. What is the order of execution for these actions?
When you use these attributes together in your button definition, in any combination, the order of priority for actions is as given below:
- Action List
- ActionEx
- Action
It executes only the highest priority action statement and other action statements are ignored. Refer the following table to understand more about the order of execution.
Attributes Specified |
Executed |
Ignored |
Action, Action List, and ActionEx |
Action List |
Action and ActionEx |
Action List and ActionEx |
Action List |
ActionEx |
Action List and Action |
Action List |
Action |
Action Ex and Action |
ActionEx |
Action |
Enhancements in Tally.ERP 9 Releases
Release 1.5
List Variables Introduced
The TDL programmer community is aware of the functionality of variables, and their usage as context-free structures in TDL. Till this release, two types of variables were supported – ‘Simple’ and ‘Repeat’. The following scope can be defined for variables:
- Report Level – commonly referred to as Local Variables
- System Level – commonly referred to as Global Variables.
- Function Level – Local variables used inside User-defined functions.
The variable framework has been enhanced to support a new type of variable called ‘List Variable’, which allows us to perform complex calculations on data available from multiple objects.
List Variable
List variable can store multiple values of single data type in the key: value format. Every single value in the List variable is uniquely identified by a ‘key’. The ‘Key‘ is of type String by default and is maintained internally.
List Var is the alias of the attribute List Variable.
Syntax
List Variable : <Variable Name> [ : <Data Type>]
Where,
<Variable Name> is the name of the variable.
<Data Type> is the data type of the variable. It is Optional. If it is specified, a separate Variable definition is not required. If not specified, a variable definition with the same name must be specified.
Example
[Function : Test Function]
ListVariable : List Var : String
The variable List Var can hold multiple string values.
Example
[Report : Test Report]
ListVariable : List Var Rep : String
The variable ListVar Rep can hold multiple strings in the ‘Report’ scope. The List variable provides a set of actions and internal functions for data manipulation, which will be explained in the following section.
List Variable Manipulation
List variable supports various data manipulation operations, which include:
- Adding/Deleting Values – Actions List Add and List Delete
- Populating List Var from a Collection – Action List Fill
- Accessing List Variable values – Function $$ListValue
- Sorting the values in the List Variable
Adding/Deleting values in a List Variable
The actions used to add/delete values in the list variable are LIST ADD and LIST DELETE.
Action – LIST ADD
The action LIST ADD is used to add the values in a List variable. It adds a single value at a time to the list variable, identified by a key. If the value is added to the list with a duplicate key, then the existing value is overwritten. LIST SET is an alias for the action LIST ADD.
Syntax
LIST ADD : <List Var Name> : <Key Formula> : <Value Formula>
Where,
<List Var Name> is the name of the list variable.
<Key Formula> can be any expression formula which evaluates to a unique string value.
<Value Formula> can be any expression formula which returns a value. The data type of the value must be the same as that of the List variable.
Example
LIST ADD : TestFuncVar : “Mobile” : 9340193401
LIST ADD : TestFuncVar : “Office” : 08066282559
LIST ADD : TestFuncVar : “Fax” : 08041508775
LIST ADD : TestFuncVar : “Residence” : 08026662666
The four values inserted in the list variable ‘Test Func Var’ are identified by the key values ‘Mobile’, ‘Office’, ‘Fax’ and ‘Residence’ respectively.
Note : The same List is considered in explaining further examples.
To add multiple values dynamically in the list variable, looping constructs WHILE, WALK COLLECTION, etc., can be used. LIST REMOVE is an alias for LIST DELETE.
Action – LIST DELETE
The action LIST DELETE is used to delete values from the List variable. It allows deleting a single value at a time or all the values in one go.
Syntax
LIST DELETE : <List Var Name> [:<Key Formula>]
Where,
<List Var Name> is the name of the list variable.
<Key Formula> can be any expression formula which evaluates to a unique string value. In the absence of key formula, all the values in the list will be deleted. In other words, if key formula is omitted, the list is reset.
Example: 1
LIST DELETE : TestFuncVar : “Office”
The value identified by the key ‘Office’ is deleted from the list variable ‘Test Func Var’.
Example: 2
LIST DELETE : TestFuncVar
All the values in the list variable TestFuncVar are removed. The list variable is empty after the execution of the action.
Populating List variable from a collection
Instead of using looping constructs, multiple values from a collection can be added to the list variable using one statement. Action LIST FILL is used for the same.
Action – LIST FILL
It is used to add multiple values from a collection to the List Variable.
Syntax
LIST FILL : <List Var Name> : <Collection Name : <Key Formula> : <Value Formula>
Where,
<List Var Name> is the name of the list variable.
<Collection Name> is the name of the collection from which values are fetched to fill the list variable.
<Key Formula> can be any expression formula which evaluates to a string value.
<Value Formula> can be any expression formula which returns a value. The data type of the value must be the same as that of the List variable.
The action LIST FILL returns the number of items added to the list variable.
Example
LIST FILL : TestFuncVar : Group : $Name : $Name
Accessing List variable values
To access values from a list variable, a function is to be used. TDL provides different functions to fetch the value from a list variable, identified by the given key.
Function – $$ListValue
$$ListValue returns the value identified by the given key in the list variable.
Syntax
$$ListValue : <List Var Name> : <Key Formula>
Where,
<List Var Name> is the name of the list variable.
<Key Formula> can be any expression formula which evaluates to a string value.
Example
$$ListValue:TestFuncVar:”Mobile”
In this example, the function returns the values identified by the key ‘Mobile’ from the list variable ‘TestFuncVar‘, when the function is executed.
Sorting values in a List variable
By default, the values in the list variable are sorted in the order of entry. TDL provides the facility to sort the values in the list variable either by key or by value. The data type can be specified while sorting based on key. Following actions allows changing the sort order:
- List Key Sort
- List Value Sort
- List Reset Sort
These actions accept three parameters. The first parameter is the name of the List variable, followed by the Sorting flag and a key data type.
In the absence of <key data type>, natural sorting method is used. In natural sorting method, the key data type is identified as one of the data types Date, Number OR String.
Date data type accepts any valid date format. If it is not of ‘Date’ data type and starts with a number or a decimal, then it is assumed as Number. If it is neither ‘Date’ nor ‘Number’, then it is considered as String. Different data types are compared in the following order as Number, Date and String.
Action – LIST KEY SORT
This action allows sorting the list based on a key value. If the data type specified while sorting the list is different than the original, then this action will temporarily convert the original data type to the specified data type while comparing the elements for sorting the list and the list will be sorted based on the new data type specified. The original list and the key data type remains as it is, on which a new sorting can be applied, based on some other data type, at any other point of time. LIST SORT is an alias of the action LIST KEY SORT.
Syntax
LIST KEY SORT : <List Var Name> [:<Asc/Desc flag> : <Key Data Type>]
Where,
<List Var Name> is the name of the list variable.
<Asc/Desc> can be YES/NO. YES is used to sort the list in ascending order and NO for descending. If the flag is not specified, then the default order is ascending.
<Key Data Type> can be String, Number, etc. It is optional.
Example: 1
LIST KEY SORT : Test Func Var : YES : String
The values in the list variable are sorted in ascending order of the key.
Example: 2
In case a different data type is used for sorting, the key may become duplicate if the conversion fails as per the data type specified for sorting. If the key becomes duplicate, then the insertion order of the items in the list variable is used for comparison.
LIST KEY SORT : Test Func Var : YES : Number
In this example, the action LIST KEY SORT will convert the key to ZERO (0) for all the list items while comparing, as all the keys are of type String. In this case, the insertion order will be considered for sorting. As a result, the values in the list will be sorted in the following order: 9340193401, 08066282559, 08041508775, and 08026662666.
In case the key contains numeric values like “11”, “30”, “35” and “20”, which can be converted to Number, the list is sorted based on the key values, else it converts them to ZERO and sorts the list as per the order of insertion.
Action – LIST VALUE SORT
Action LIST VALUES SORT sorts the list items based on value. As there can be duplicate values in the list, the combination of key and value is considered as key for sorting duplicate values.
Syntax
LIST VALUE SORT : <List Var Name> [:<Asc/Desc flag> : <Key Data Type>]
Where,
<List Var Name> is the name of the list variable.
<Asc/Desc> can be YES/NO. YES is used sort the list in ascending order and NO for descending. It is optional. If the flag is not specified, then the default order is ascending.
<Key Data Type> can be String, Number, etc. It is optional.
Example
LIST VALUE SORT : Test Func Var : YES : String
The values in the list variable are sorted in ascending order of values.
Action – LIST RESET SORT
The action LIST RESET SORT retains the sorting back to the order of insertion.
Syntax
LIST RESET SORT : <List Var Name>
Where,
<List Var Name> is the name of the list variable.
Example
LIST RESET SORT : TestFuncVar
Here, the action resets the sort order of the list variable ‘Test Func Var’ to the order of insertion.
Functions Used with List Variables
TDL supports some functions for general operations like finding the total number of items in a list, checking whether the last action was successful, etc.
Function – $$ListValue
As explained earlier in section 2.1, this function is used to access values from a list variable.
Function – $$ListCount
The function $$ListCount gives the total number of values available in the list variable.
Syntax
$$ListCount : <List Var Name>
Where,
<List Var Name> is the name of the list variable.
Example
$$ListCount:TestFuncVar
The action returns the number of items in the list variable ‘Test func Var’ when it is executed.
Function – $$ListFind
The function ListFind is used to search if the value belonging to a specific key is available in the list variable. If the key is found, $$ListFind returns TRUE, otherwise it returns FALSE.
Syntax
$$ListFind : <List Var Name> : <Key Formula>
Where,
<List Var Name> is the name of the list variable.
<Key Formula> can be any expression formula, which evaluates to a string value.
Example
$$ListFind:TestFuncVar:”Mobile”
It returns TRUE if the key ‘Mobile’ is present in list variable ‘Test func Var’, else returns FALSE.
Note: Function $$LastResult is used to check if the last executed action was successful.
If the last action that was executed is LIST ADD or LIST DELETE, then the function returns TRUE if the action was successful, and FALSE otherwise.
If the last action that was executed is LIST FILL, then $$LastResult returns the number of items inserted in the list variable.
Constructs introduced in Functions for List Var
Looping Construct – FOR IN
The FOR IN loop is supported to iterate the values in the list variable. The number of iterations depends on the number of items in the list variable.
Syntax
FOR IN : <Iterator Var Name> : <List Var Name> . . END FOR
Where,
<Iterator Var Name> is the name of the variable used for iteration. The variable is created implicitly.
<List Var Name> is the name of the list variable.
Example
FOR IN : Cnt : Test Func Var
LOG : $$String:$$ListValue:TestFuncVar:##Cnt END FOR
All the values of the list variable ‘Test Func Var‘ are logged in the file ‘tdlfunc.txt’.
Release 1.8
Variable Framework with Compound Variables Introduced
Variables in TDL (Tally Definition Language) are entities which can hold values during the execution of a program. The values of these variables are initialized when they are created and can change during the entire execution of program. The Program can change the variable value by specifying expressions which are evaluated to set the values of the variables.
Variables are context-free structures which do not require any specific object context for manipulation. They are declared by name and can be operated using the same name. It is also possible to access and operate variables declared at the parent scope.
Variables are lightweight data structures, which are simple to operate and provide the capability of storing multiple values of the same type and different types as well. It is also possible to perform various manipulation operations like insert/update/delete/sort/find. These are mainly used to perform complex computations.
Variable can hold a single value, or more than one value of same type or different types. It can be declared at various scopes such as Report, Function and System Level.
Classification of Variables
The various types of variables in TDL are:
- Simple Variable
Simple variables allow the storage of a single value of the specified data type.
- Simple Repeat Variables
The Simple Variable can hold method values of multiple objects of a collection based on an implicit index. This concept is used in Columnar Reports only, where the lines should be repeated vertically and the fields should be repeated horizontally.
- Compound Variable
Compound Variables allow us to store the values of different data types. This is achieved by making the variable itself compound, by allowing Variable declaration inside itself. These sub-variables are called member variables of the main variable.
A member variable can be a single instance or a list variable. A member variable can be a compound variable and can have members again, and therefore any hierarchy can be created.
Compound variables help grouping of related information together into one specification. In another te r ms, we can think about compound variables as an ‘object’.
Following table shows the similarities between an object and a compound variable:
Object |
Compound Variable |
Can have methods |
Can have Simple Variables as its members |
Can have repeated methods (simple collections) |
Can have a simple List Variable as member |
Can have collections (compound collections) |
Can have Compound List Variable as its member |
*Cannot have objects under it directly* |
Can have Compound Variables as members |
We can have a comparison between the internal data Object ‘ Voucher ’ and a Compound Variable ‘CLV Emp ’ to understand the similarities between an Object and Compound Variable.
For instance, the Compound Variable ‘CLV Emp’ is defined as follows:
[Variable : CLV Emp]
Variable : Name : String
Variable : Designation : String
Variable : Age : Number
Variable : Salary : Amount
List Variable : Contact Nos : String
List Variable : Relatives
Variable : Contact Address
;; Defining Compound Variable
[Variable : Relatives]
Variable : Name : String
Variable : Age : Number
Variable : Relation : String
Variable : Salary : Amount
;;Defining another compound variable
[Variable : Contact Address]
Variable : Street Name : String
Variable : City Name : String
Object: Voucher |
Compound Variable: CLV Emp |
Object “Voucher” is having methods directly under it such as Date, Voucher Number, Narration, etc. |
Compound Variable “CLV Emp” is having Simple Member Variables such as Name, Age, Salary, etc. |
Voucher is having the repeated method BasicBuyerAddress (Simple Collection) |
CLV Emp is having the Simple List Member Variable ‘Contact Nos’ |
Voucher is having the collection “Inventory Entries” (Compound Collection). |
CLV Emp is having the Compound List Member Variable ‘Relatives’ |
Voucher object is not having another voucher (primary object) under it directly. |
CLV Emp is having the another Compound Member Variable ‘Contact Address’ |
- List Variable
A variable at declaration time can be declared as a single instance or as a list. List variable is a container (datAstructure) variable and hence it is not defined. Variables can be declared as list.
List Variable can hold one or more variables which can be either a simple or a compound variable. Each of these is called Element Variable. Element Variable holds value as well as key, if specified. The key is optional, and hence without a key also, elements can be added to list variables. The value of key specified for each of the element variables must be unique.
- Simple List Variable
Simple Variable can be declared as a list. Simple List Variables can hold multiple values of single data type.
- Compound List Variable
Compound Variable can be declared as a list. Compound List Variables can hold multiple values of different data types.
‘Variable’ Definition and its Attributes
Definition – VARIABLE
A Variable definition is similar to any other definition. The behaviour of the variable is specified by the programmer via ‘Variable’ definition.
Syntax
[Variable : <Variable Name>]
Attribute : Value
A meaningful name which determines its purpose can be given as a variable name.
Attributes of ‘Variable’ Definition
Let us discuss the attributes of ‘Variable’ definition in detail.
Attribute – TYPE
This attribute determines the Type of value that will be held by the variable. All the data types
supported by TDL such as String, Number, Date, etc., can be used to specify the variable data type. In the absence of this attribute, a variable assumes to be of the Type ‘String’ by default.
Syntax
[Variable : <Variable Name>]
Type : <Data Type>
Example:
[Variable : GroupNameVar]
Type : String
In this example, a variable which holds the data of Type ‘String’ is defined.
Attribute- DEFAULT
The default value of variables can be specified during definition, using DEFAULT attribute. It is the initial value assigned to the variable when it is instantiated / declared. We can also specify the default value during declaration / instantiation. The difference is that the default value specified using this attribute at definition time will be applicable to all instances of the variable declared (at any scope). Default value specified while declaration will apply only to the specific instance.
Note: Declaration and scope will be covered in detail in the subsequent topics. The above explanation will be more clear after that.
Syntax
[Variable : <Variable Name>]
Default : <Default Value>
Example
[Variable : GroupNameVar]
Type : String
Default : $$LocaleString:”SundryDebtors”
In this example, the default value for the variable is set as “Sundry Debtors”.
Attribute – VOLATILE
If the Volatile attribute in Variable definition is set to Yes, then the variable is capable of retaining previous values from the caller scope. The default value of this attribute is Yes, i.e., if the variable by the same name is declared in the called Report/Function and the ‘Volatile’ attribute is set to “Yes”, then in the called Report, it will assume the last value from the caller Report. The default value of the attribute ‘Volatile’ is always YES.
For better understanding, let us elaborate it further. When a variable is declared/instantiated, it assumes a default value. The default value which it assumes is controlled by the following factors:
- If ‘Volatile’ is set to “Yes” for a variable in its definition which is instantiated/declared inside a function/report, and the variable by the same name exists in the parent scope, then it will take its default value from the Parent scope. If no variable by the same name exists in the parent scope, it will take the default value specified within the definition.
- If the default value is specified within the declaration itself, it will assume that value.
If a new report Report2 is initiated, using a volatile variable GroupNameVar, from the current report Report1, the same variable in Report 2 will have the default value as the last value saved in Report 1. Within Report 2, the variable can assume a new value. Once the previous report Report1 is returned back from Report2, the previous value of the variable will be restored. A classic example of this is a drill down Trial Balance.
Syntax
[Variable : <Variable Name>]
Volatil e : <Logical Value>
Example
[Variable : GroupNameVar]
Type : String
Volatile : Yes
Volatile Attribute of GroupNameVar Variable is set to Yes, which means that ‘GroupNameVar’ can inherit values from one Report to another.
Variables defined at the function level are Non Volatile by default. They do not inherit the values from the caller scope.
Note: Scope will be discussed in detail in the subsequent topics.
Attribute – PERSISTENT
This Attribute decides the retention periodicity of the variable, i.e., till when it will retain the value: i) till application termination, or ii) after application termination as well. Setting the attribute Persistent to Yes, means that the value saved during the last application session will be retained permanently in the system. When the next session of Tally is started, it will take its initial value from the value saved in the previous session, i.e., the latest value of the variable will be retained across the sessions. Please note that Variables declared at the system scope can only be persisted.
A List variable at System scope can also be persisted by specifying the ‘Persistent’ attribute for its element variable (whether it is simple/compound) within the definition. Inline variables even at system scope cannot be persisted. Inline variable declaration will be discussed in further topics.
Syntax
[Variable : <Variable Name>]
Persistent : <Logical Value>
Example:
[Variable : SV Backup Path]
Type : String
Persistent : Yes
The attribute Persistent of the variable SV Backup Path has been set to Yes, which means that it retains the latest path given by the user, even during the subsequent sessions of Tally.
Note: All the Persistent Variable Values are stored in a File Named TallySav.Cfg in the folder path specified for Tally Configuration file in F12 -> Data Configuration. Each time Tally is restarted, these variable values are accessed from this file.
Attribute – REPEAT
The attribute Repeat for a variable is used for its usage in Columnar Reports. It accepts Collection name and optional Method name, as parameters. Multiple values are stored in the variable based on an implicit Index. Method value of each object of the collection will have to be picked up and stored in the variable, based on implicit index. In case the method name is not specified, the variable name is considered as the method name and picked up from the collection.
Syntax
[Variable : <Variable Name>]
Repeat : <Collection Name> [:<Method Name>]
Where,
<Variable Name> is the name of the variable.
<Collection Name> can be any expression which evaluates to a Collection name.
<Method name> is the name of the method whose value needs to be picked up from each object of the collection. If not specified, the variable name is considered as the method name.
Example
[Variable : SVCurrentCompany]
Volatile : Yes
Repeat : ##DSPRepeatCollection
Suppose ‘DSPRepeatCollection’ holds the value “List of Primary Companies”. Method value ‘SVCurrentCompany’ will be gathered from each object of the collection and stored in index 1, index2, and so on.
Note: Repeat attribute will be elaborated further under the topic “Implication of Repeat Variables in Columnar Report”.
Attribute – VARIABLE
The attribute Variable is used to define the member variables (Simple/Compound) for a Compound Variable.
Syntax
[Variable : <Variable Name>]
Variable : <Variable Names> [:<Data Type> [:<Va l ue>]]
Where,
<Variable Names> is the list of Simple or Compound Variables, separated by comma.
<Data Type> is used to specify the data type of Simple Variable. In case of Compound Variable, data type cannot be specified, as it consists of members belonging to various data types. If the data type is not mentioned, the primary variable definition is mandatory.
<Value> is the default/initial value provided for the variable.
Specifying <Data Type> and <Value> is optional. If data type is specified, then it is called inline declaration of variable. [We will learn about inline declarations and Compound Variables further].
Example
[Variable : CLV Emp]
Variable : Name : String
Variable : Age : Number : 25
Variable : Salary : Amount
Variable : Relatives
In this example, the simple variables Name, Age and Salary and the compound variable ‘Relatives’ are defined as members for the Compound Variable CLV Emp.
Attribute – LIST VARIABLE
The attribute List Variable is used to specify a list of Simple/Compound Variables.
Syntax
[Variable : <Variable Name>]
List Variable : <Variable Names> [:<Data Type> [:<Value>]]
Where,
<Variable Names> is the list of Simple or Compound Variables, separated by comma.
<Data Type> is the data type of Simple Variable. In case of Compound Variable, data type cannot be specified, as it consists of members belonging to various data types.
<Value> denotes the no. of elements in the list. Specifying <Data Type> and <Value> is optional.
Example
[Variable : CLV Emp]
Variable : Name : String
Variable : Age : Number
Variable : Salary: Amount
List Variable : City : String : 3
List Variable : Relatives
[Variable : Relatives]
Variable : Name : String
Variable : Age : Number
Variable : Relation : String
Variable : Salary : Amount
In this example, in addition to simple variables, a simple list variable City and a compound list variable Relatives are defined as members using the attribute List Variable. A separate definition is required for the compound list variable Relatives, as it holds the multiple values of different data types.
Variable Declaration and Scope
Variables can be declared at various scopes. The availability of the variable within the definition under which it is declared is called as the scope. The lifetime of the variable will be within the scope. For example, if the scope of a particular variable is within a function, then the variable will last till the function is executing, and then it is destroyed.
Variables can be declared at System, Report and Function scopes. Let us have a detailed look on the variable scopes.
System Scope declaration
Variables declared at the system level will start their life when the application starts, and will be alive till the application’s termination. System variables are declared using a special [System: Variable] definition. The variables declared at system scope are accessible everywhere in the system.
Syntax
[System : Variable]
Variable Name : <Initial Type Based Value>
OR
Variable : <Variable Names> [ :<Data Type>[:<Value>]]
List Variable : <Variable Names> [:<Data Type>[ : <Value>]]
Where,
<Initial Type Based Value> is the initial value specified to the variable.
The variables can be declared at the system scope by using the above. The usage of the attributes ‘Variable’ and ‘List Variable’ is same as described above in the “Variable Definition”.
Example
[System : Variable]
BSVerticalFlag : No
The BSVerticalFlag Variable is declared in System Scope. Hence, this variable value being modified in a Report, is retained even after we quit and re-enter the report.
Report Scope declaration
Variables declared at Report definition are termed as having ‘Report’ Scope. These variables will exist till the life of the report. The variables declared at Report scope are accessible from the report itself and all the TDL elements which are executed from within this report such as another report, function, etc.
Report variables get their default value from definition specification, or from the declaration specification, or the values are inherited from the owner scope, if the variable is marked as Volatile.
Report allows two special attributes SET and PRINT SET to set/override the values of the variable during the startup of the report in Display / Print mode respectively.
‘Form’ definition also has a SET attribute, which overrides the variable’s value during startup creation and subsequent re-creation of the form during any refresh/regeneration. We will study about these value specification attributes in detail under the topic “Manipulating Simple and Compound List Variables”.
Syntax
[Report : <Report Name>]
Variable : <Variable Names>
OR
Variable : <Variable Names> [:<Data Type> [:<Val ue>]]
OR
List Variable : <Variable N ames> [:<Data Type> [:<Value>]]
The variables can be declared at Report scope by using the above. The usage of attributes Variable and List Variable is same as described above in the “Variable definition”.
Example
[#Report : Balance Sheet]
Variable : Explode Flag
‘Explode Flag’ Variable is made local to the Report ‘Balance Sheet’ by associating it using the Report attribute ‘Variable’. This variable retains its value as long as we work with this Report. On exiting the Report, the variable is destroyed and the values are lost.
Function Scope declaration
Function (User Defined Function) also allows the variables to be declared at its scope. Function variables have lifetime till the end of execution of the function. Function variables can also be declared with default value. Function variables will never inherit the value from the parent context. This means that ‘Volatile’ attribute on function variables has no effect. Functions allow actions to change the values of the variables.
Function allows A special scope called STATIC. A static variable declared in a function is equivalent to a system variable, but can be accessed only within the defined function. Its initial value is set only during the first call to the function, and later it retains the value for further calls. Only simple or compound variables can be declared as static. List variables are not currently supported at ‘Static’ scope.
Syntax
Variable : <Variable Names>
OR
Variable : <Variable Names> [:<D ata Type> [:<Value>]]
OR
List Varia ble : <Variable Names> [:<Data Type> [:<Value>]]
OR
Static Variable : <Variable Names> [:<Data Type> [:<Value>]]
The variables can be declared at ‘Function’ scope by using the above. The usage of the attributes Variable and List Variable is the same as described above in the “Variable” definition.
Example
[Function : FactorialOf]
Variable : Factorial
The Function ‘FactorialOf’ requires variable ‘Factorial’ for calculation within the Function.
Example:
[Function : Sample Function]
Static Variable : Sample Static Var : Number
The static variable ‘Sample Static Var’ retains the value between successive calls to the Function ‘Sample Function’.
Inline Declaration
Variables can also be defined (with limited behaviour) during declaration itself; so a separate definition would not be mandatory. This is called inline variable specification (i.e., during declaration itself, the variables are defined inline).
Only the DATA TYPE and the DEFAULT VALUE can be specified as the behaviour for inline variables. If the DATA TYPE is specified as a variable name (i.e., not an implicit data type key word such as String, Amount, etc.) or is left blank, it is treated as a pre-defined variable.
Persistence: Inline variables even at system scope cannot be persisted.
Declaring Simple Variable Inline
The ‘Variable’ attribute allows declaring Simple Variable inline by specifying the data type. Initial value to the variable can also be specified optionally.
Syntax
Variable : <Variable Names> [:<Data Type> [:<Value>]]
Where,
<Variable Names> is a list of Simple Variables, separated by comma.
<Data Type> is the data type of the Simple Variable.
<Value> is the default/initial value provided for the variables, and this value specification is optional.
Example
[Report : Cust Group Report]
Variable : VarGroupName1, VarGroupName2 : String : “Sundry Debtors”
In this example, the Simple Variables ‘VarGroupName1’ and ‘VarGroupName2’ of type ‘String’ are declared in a Report; hence, the following separate variable definitions are not required, which will help to reduce the coding complexity.
[Variable : VarGroupName1]
Type : String
[Variable : VarGroupName2]
Type : String
Declaring Simple List Variable Inline
‘List Variable’ attribute allows declaring Simple List Variable inline by specifying the Data Type. If the default value is specified, it is treated as the count to initialize the list with the specified elements by default.
Syntax
List Variable : <Variable Names> [: <Data Type> [: <Value>]]
Where,
<Variable Names> is a list of Simple Variables, separated by comma.
<Data Type> is the data type of the Simple Variable.
<Value> is treated as the count to initialize the list with the specified elements by default. The number of elements can be specified only for an index-based list.
Example:
[System : Variable]
List Variable : VarGroupName1, VarGroupName2 : String : 10
In this example, the variables ‘VarGroupName1’ and ‘VarGroupName2’ of ‘String’ data type are declared as inline simple list variables at System level, and each variable will have 10 elements by default.
Declaring Com pound List Variable Inline
For Compound List Variables , definition is mandatory. They cannot be declared inline.
Using Modifiers with Variables
Variable allows static modifiers such as Add/Delete/Change and Dynamic modifier ‘Local’.
Static Modification
Add/Delete/change modifiers can be used on variables to change the behaviour.
Example:
[#Variable : SV From Date]
Delete : Default
Locally modifying variables
When different reports require the same Compound Variable, and some modifications are required specific to respective reports, like adding additional members (local to the report); this is possible through the Dynamic Modifier ‘Local’.
Example:
In this example, a Compound Variable CLVEMP is defined as shown:
[Variable : CLV Emp]
Variable : Name : String
Variable : Designation : String
Variable : Age : Number
Variable : Salary : Amount
List Variable : Contact Nos : String
List Variable : Relatives
Variable : Contact Address
;; Defining Compound List Variable
[Variable : Relatives]
Variable : Name : String
Variable : Age : Number
Variable : Relation : String
Variable : Salary : Amount
;;Defining another compound variable
[Variable : Contact Address]
Variable : Street Name : String
Variable : City Name : String
In ‘Employee Report1’, the variable is declared and no modifications are required locally.
[Report : Employee Report1]
Variable : CLV EMP
In ‘Employee Report2’, the same variable is declared but locally one member variable is added and one existing member variable is deleted.
[Report : Employee Report2]
Variable : CLV EMP
Local : Variable : CLV EMP : Add : Variable : Qualification : String
Local : Variable : CLV EMP : Delete : Variable : Age
Also, member variables can be localized within a compound variable. This provides the ability to re-use a compound structure defined earlier and do any local modifications, as required.
Example:
[Variable : CLVEMP]
Variable : Contact Address
Local : Variable : Contact Address : Add : Variable : State : String
List Variable Manipulations
Simple and Compound List variables support various data manipulation operations such as Adding/Deleting/Expanding List elements, Value Specifications, Retrieving values from the list elements, Searching and Sorting, Populating List Variable from a Collection, etc. New Actions and Functions specific to List Variables have been introduced for these manipulations. Before looking into these manipulations, let us understand the concept of Key, Index and Variable Path Specification using Dotted Notation Syntax.
Concept
Key
List variables can hold multiple values of variable types using a string based ‘Key’ specification. ‘Key’ is of type String, by default. We can specify a different data type for a key only in scenarios where we require key-based sorting. It is optional to specify key value while adding values to the list variable. The TDL Programmer has to explicitly specify the key value. Key is unique for all elements in the list. If an element is added with duplicate key, the existing element is overwritten. It is advisable to use a key only if we require frequent access to elements of the list based on key.
Index
An element of the list can be accessed via ‘Index’. Index of an element is the location/position of the variable from the first element in the current sorting order. Even if we have specified keys for elements of a list, index is generated internally. It is always possible to access each element in the list by specifying the index within square brackets [ ] in the dotted notation syntax. This is explained below. Index can be negative as well. In that case, it is possible to access the elements in the reverse order of entry.
Variable Path Specification using Dotted Notation Syntax
We aware that in Tally.ERP 9, method value of any object including its sub-collections to any level can be accessed or modified with dotted notation syntax. The behaviour of the symbol prefix $ was enhanced to access the method value of any object, and an action MODIFY OBJECT was introduced to modify multiple values of any object.
Compound Variables allow us to store values of different data types. A member variable can be a single instance or a list variable. A member variable can be a compound variable and can have members again, and thus, any hierarchy can be created. In short, it is similar to a Data Object. Hence, all the attributes and actions which operate the Variable, have now been enhanced to take extended variable path syntax, i.e., the variable path can be specified using dotted notation syntax. The syntax can be used to fetch any value from any member within the hierarchy. This syntax is applicable wherever we need to specify either the variable identifier or access the value of the variable. In case of value access the operator ## is used. Value access using operator ## has been discussed in detail in the topic Index Based Retrieval using ## Operator.
Syntax
<Element Variable Specification>.<Member Variable Specification>. <Simple Member Value specification>
Where,
<Element Variable Specification> can be a Compound Variable or Compound List Variable [Index Expression].
<Member Variable Specification> can be a Compound Variable Member or Compound List Member Variable [Index Expression].
<Simple Member Value Specification> refers to the name of the simple member in the specified path.
<Index Expression> is an expression evaluating to a number. Suffixing a variable with index refers to an Element Variable. It can be positive or negative. Negative index denotes reverse access.
Example: 1
Consider the compound variable defined below:-
[Variable : CLV Emp]
Variable : Name : String
Variable : Age : Number
Variable : Salary : Amount
List Variable : Relatives
[Variable : Relatives]
Variable : Name : String
Variable : Age : Number
Variable : Relation : String
Variable : Salary : Amount
The same is declared at System Scope, and hence can be accessed anywhere in the system.
[System : Variable]
List Variable : CLV Emp
Example: 2
Suppose we want to set the value of a simple variable ‘Employee Name’, which is declared at Report Level:
[Report : Employee Report]
Variable : Employee Name : String
SET : Employee Name : ##CLVEMP[1].Name
The variable Employee Name will be set with the value of the member “Name” of the first element of the Compound List Variable “CLVEMP”.
Example: 3
In case the age of the first relative of the second employee needs to be displayed, the following statement would be used in the field in a report.
[Field : RelAge]
Set As : ##CLVEMP[2].Relatives[1].age
The value specification attributes and actions, with the enhanced variable path specification, will be discussed in detail in the further topics.
List Variable Manipulations – A Detailed Look
Let us have a detailed look on List Variable manipulations with examples:-
Adding/Deleting/Expanding Elements
Adding Elements to the List Variable
- Action – LIST ADD
The Action LIST ADD is used on a list variable to add an element to the list variable based on KEY. This is mandatory before we set value into the element. KEY is compulsory in this case. Key is unique for all elements in the list. If an element is added with duplicate key, then the existing element is overwritten.
Syntax
LIST ADD : <List Variable Specification> : <Key Formula> [:<Value Formula> [:<Member Specification>]]
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
<Key Formula> can be any expression which evaluates to a unique string value.
<Value Formula> can be any expression which returns a value. It sets the initial value of the element variable, and is optional.
<Member Specification> is required only if the value needs to be added to a specific member of a Compound List Variable. If member specification is not provided, the first member variable is considered for the value.
Note: The actions LIST APPEND and LIST SET are aliases for the action LIST ADD.
To add multiple values dynamically to the List variable, we can use LIST ADD within a looping construct like While, Walk Collection, etc.
Example:
Adding elements to Simple List Variable using LIST ADD
- Adding an element to the Simple List Variable SLV Emp with a Key
LIST ADD : SLV Emp : “E001”
- Adding an element to the Simple List Variable SLV Emp with a Key and a value
LIST ADD : SLV Emp : “E001” : “Kumar”
- Adding an element to the Simple List Variable SLV Emp with a Key and value, and subsequently overriding a value corresponding to a particular key
LIST ADD : SLV Emp : “E001” : “Kumar”
LIST SET : SLV Emp : “E001” : “Keshav”
- The value corresponding to the Key ‘E001’ is changed to Keshav
Adding Elements to Compound List Variable using LIST ADD
A Compound Variable CLV Emp is defined, which stores employee details such as Name, Age, Salary, etc., and the details of the Relatives.
[Variable : CLV Emp]
;;simple member variable
Variable : Name : String
;;simple member variable
Variable : Age : Number
;;simple member variable
Variable : Salary : Amount
;;compound list member variable
List Variable : Relatives
;; Compound Variable is defined here
[Variable : Relatives]
Variable : Name : String
Variable : Age : Number
Variable : Relation : String
Variable : Salary : Amount
The same is declared at the System Scope; hence, can be accessed anywhere in the system.
[System: Variable]
List Variable: CLV Emp
- Adding an element to Compound List Variable CLV Emp with a Key.
LIST ADD : CLVEmp : “E001”
- Adding an element to Compound List Variable CLV Emp with a Key and a Value.
LIST ADD : CLVEmp : “E001” : “Kumar”
Since member specification is not provided, the first member variable is considered for value.
- Adding an element to Compound List Variable CLV Emp with a Key and a value with member specification
LIST ADD : CLVEmp : “E001” : 25 : Age
Since member specification is provided , member variable ‘Age’ is considered.
- Adding an element to the Compound List Member of a Compound List Variable with a Key and value with member specification
LIST ADD : CLVEmp[1].Relatives : “R001” : “Prem” : Name
In this example, we are adding an element to the Compound List Variable “Relatives” and the member variable ‘Name’ is considered for the value. ‘Relatives’ is a Compound List Member variable of the Compound List Variable CLVEMP.
Note: The values are hardcoded in the examples for explanation purpose. The above Simple and Compound List Variable examples are used to explain further list variable manipulations.
Action – LIST ADD EX
This action is used on a list variable to a d d an element to the list variable without KEY.
Syntax
LIST ADD EX : <List Variable Specification> [:<Value Formula> [:<Member Specification>]]
Where,
<List Variable Specification> is the Simple List/Compound List Variable specification.
<Key Formula> can be any expression which evaluates to a unique string value.
<Value Formula> can be any expression which returns a value. It sets the initial value of the element variable, and is optional.
<Member Specification> is required only if the value needs to be added to a specific member of a Compound List Variable. If member specification is not provided, the first member variable is considered for the value.
Note: Action LIST APPENDEX is an alias for the action LIST ADDEX.
Adding elements to Simple List Variable using LIST ADD EX
- Adding an element to Simple List Variable SLV Emp
LIST ADD EX : SLV Emp
- Adding an element to Simple List Variable SLV Emp, with Value
LIST ADD EX : SLV Emp : “Kumar”
Adding elements to Compound List Variable using LIST ADD EX
- Adding an element to Compound List Variable CLV Emp
LIST ADD EX : CLV Emp
- Adding an element to Compound List Variable CLV Emp, with value
LIST ADD EX : CLV Emp : “Kumar”
Here, since member specification is not provided, first member variable is considered for value.
- Adding an element to Compound List Variable CLV Emp, with value and member specification
LIST ADDEX : CLV Emp : 25 : Age
Here, member specification is provided, hence member variable ‘Age’ is considered for the value.
- Adding an element to the Compound List Member variable of a Compound List Variable with value and member specification
LIST ADDEX : CLVEmp[1].Relatives : “Prem” : Name
In this example, we are adding an element to the Compound List Variable “Relatives” and the member variable ‘Name’ is considered for the value. ‘Relatives’ is a Compound List Member variable of the Compound List Variable CLVEMP.
Deleting Elements from the List Variable
Action – LIST DELETE
The Action LIST DELETE is used to delete an element from the list based on Key. The key formula is optional. If not specified, all the elements in the list are deleted.
Syntax
LIST DELETE : <List Variable S pecification> [ : <Key Formula>]
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
<Key Formula> can be any expression which evaluates to a unique string value . It is optional.
Note: Action LIST REMOVE is an alias for the action LIST DELETE.
Deleting elements from Simple List Variable using LIST DELETE.
- Deleting a single element from a simple List Variable
LIST DELETE : SLV Emp : “E001”
The element identified by key ‘E001’ will be deleted from the Simple List Variable SLV Emp.
- Deleting all elements from a simple List Variable
LIST DELETE : SLV Emp
Since key formula is not specified, all elements from simple list variable SLV EMP will be deleted.
Deleting elements from a Compound List Variable using List Delete.
- Deleting an element from a Compound List Variable
LIST DELETE : CLV Emp : “E001”
The element identified by key E01 will be deleted from the Compound List Variable “CLV Emp”.
- Deleting all elements from a Compound List Variable
LIST DELETE : CLV Emp
Since key formula isn’t specified, all elements from compound list variable CLV Emp are deleted.
- Action – LIST DELETE EX
This action is used to delete an element from the list based on index. Index formula is optional. If not specified all the elements in the list are deleted. A negative index denotes reverse position.
Syntax
LIST DELETE EX : <List Variable Specification> [:<Index Formula>]
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
<Index Formula> can be any expression which evaluates to an index number. It is optional.
Note: Action LIST REMOVE EX is an alias for the action LIST DELETE EX.
Deleting elements from Simple List Variable using LIST DELETE EX
- Deleting a single element from a simple List Variable
LIST DELETE EX : SLVEmp : 2
The element identified by index number ‘ 2 ’ will be deleted from Simple List Variable SLC Emp.
- Deleting all elements from a simple List Variable
LIST DELETE EX : SLVEmp
Since index formula is not specified, all elements from Simple List Variable SLV Emp are deleted.
Deleting elements from a Compound List Variable using LIST DELETE EX
- Deleting an element from a Compound List Variable
LIST DELETE EX : CLVEmp : 10
The element identified by index ‘1 ’ will be deleted from the Compound List Variable CLV Emp.
- Deleting all elements from a Compound List Variable
LIST DELETE EX : CLVEMP
Since index formula isn’t specified, all elements of compound list variable CLV EMP are deleted.
- Expanding Element s in the List Variab le
- Action – LIST EXPAND
The Action LIST EXPAND is used to create the specified number of blank elements and insert them into the list. All these elements are created without a key. If key specification is required for each element then either LIST FILL or a loop can be used to add elements individually.
Syntax
LIST EXPAND : <List Variable Specification> : <Count Formula>
Where,
<List Variable Specification> is the Simple List or Compound List variable specification.
<Count Formula> can be any expression which evaluates to a number.
Example:
Expanding Simple List Variable using LIST EXPAND
LIST EXPAND : SLVEMP : 10
Here, count formula is 10. Hence , 10 blank elements are added to Simple List Variable ‘ SLVEMP’.
Expanding Compound List Variable using LIST EXPAND.
LIST EXPAND : CLVEMP : 5
Here, count formula is 5. Thus, 5 blank elements are added to the Compound List Variable ‘CLV EMP’.
LIST EXPAND : CLVEMP[1].Relatives : 10
Here, count formula is 1. Hence, 10 blank elements are added to Compound List Variable ‘Relatives’. ‘Relatives’ is a Compound List Member variable of the Compound List Variable ‘CLVEMP’.
Value Specifications
The value for the Simple/List Variables (Simple & Compound) can be specified using Attributes at Report and Form Level, and using Actions in User Defined Functions.
Value specification at Report level
The attributes SET and PRINTSET are used to specify the variable values at Report level.
- Attribute – SET
The Report attribute SET can be used to specify a Variable name and its value, which will be set during the startup of the report.
Syntax
SET : <Variable Specification> : <Value Expression>
Where,
<Variable Specification> is the variable path specification.
<Value Expression> can be any expression, which evaluates to a value for the Variable of the specified data type.
Example:
;; Setting value to a simple Variable
SET : Var : “ABC”
;; Setting value to a simple List Variable element
SET : ListVar[1] : “XYZ”
;; Setting value to Compound List Variable element’s member
SET : CLVEMP[1].Name : “Kumar”
- Attribute – PRINT SET
The Report attribute Print Set is similar to the SET attribute but sets the value of the variables to the specified value w h en the report is started in Print mode.
Syntax
PRINT SET : <Variable Specification> : <Value Expression>
Where,
<Variable Specification> is the variable path specification.
<Value Expression> can be any expression which evaluates to a value for the variable of the specified data type.
Example:
;; Setting value to a simple Variable
PRINTSET : Var : “ABC”
;; Setting value to a simple List Variable element
PRINTSET : ListVar[1] : “XYZ”
;; Setting value to Compound List Variable element’s member
PRINTSET : CLVEMP[1].Name : “Kumar”
Value specification at Form Level
- Attribute – SET
The Form attribute SET is similar to the Report attribute SET, the difference being that while the report sets the value once in its lifetime, the form SET is executed during every regeneration/ refresh of the report.
Syntax
SET : <Variable Specification> : <Value Expression>
Where,
<Variable Specification> is the variable path specification.
<Value Expression> can be any expression, which evaluates to a value for the Variable of the specified data type.
Example:
;; Setting value to a simple Variable
SET : Var : “ABC”
;; Setting value to a simple List Variable element
SET : ListVar[1] : “XYZ”
;; Setting value to Compound List Variable element’s member
SET : CLVEMP[1].Name : “Kumar”
Value specification at Function level
Actions SET , MULTISET , EXCHANGE, INCREMENT and DECREMENT are used.
- Action – SET
Values of variables can be set/updated via the SET action. This action is available as a global action, and can be used within a function also. List variables and compound variables cannot have values; they can have only element/member variables inside them, respectively. If SET action is used on compound variables, the value will be set to the FIRST member variable. If the first member variable is again compound, the program would search for the first non-compound leaf member and set the value.
For list variables, the value is treated as the count, and the list is expanded by the number of elements provided in the expression.
Syntax
ET : <Variable Specification> : <Value Expression>
Where,
<Variable Specification> is the variable path specification.
<Value Expression> can be any expression which evaluates to a value for the variable of the specified data type.
Example:
;; Setting value to a simple Variable
SET : Var : “ABC”
;; Setting value to a simple List Variable element
SET : SLVEMP[1] : “XYZ”
;; Setting value to Compound List Variable element’s member
SET : CLVEMP[1].Name: “Kumar”
- Action – MULTISET
The action MULTI SET is used to set the values of compound member variables in one call. All member specifications are relative to the compound variable specification given.
Syntax
MULTI SET : <CompoundVariable Specification> + : <Member Specification :Value> [, <Member Specification : Value>, …]
Where,
<Compoound Variable Specification> is the Compound Variable specification.
<Member Specification : V alue> is the list of name-value pairs for setting member values.
Example: 1
MULTISET : CLVEMP[1] : Name : “Vimal”,Age : 26, Salary :($$AsAmount:10000)
All member variables of 1st element of Compound List Variable CLV EMP are set with MULTISET .
Example: 2
MULTISET : CLVEMP[1].Relatives[1] : Name : “Hari”, Age : 20, +
Relation:“Brother”
Here, all member variables for the first element of the Compound List Variable Relatives are set.
Relatives is a Compound List Member variable of the Compound List Variable CLV EMP.
- Action – EXCHANGE
This action is used to swap the values of two variables, provided both belong to the same data type. This cannot be done for Simple List or Compound List as a whole. However, values of elements of Simple List and Compound List member variables having same data type can be exchanged.
Syntax
EXCHANGE : <First Variable Specification> : <Second Variable Specification>
Where,
<First Variable Specification> is the simple variable specification.
<Second Variable Specification> is the simple variable specification.
Exchanging value of a simple variable with another simple variable.
EXCHANGE : EmpVarOld : EmpVarNew
Both the Variables are of ‘ String’ data type. The value of the variable Emp VarOld is exchanged with that of the variable Emp VarNew on execution of the action.
Exchanging value of an element o Simple List Variable with that of another Simple List Variable.
EXCHANGE : SlvEmpOld[1] : SlvEmpNew[1]
The value of the first element of SLV EmpOld is exchanged with that of the first element of SlvEmpNew. Both the Simple List Variables are of ‘String’ data type
Exchanging value of a simple variable a simple variable with a member variable of a compound list variable.
EXCHANGE : EMP Salary : CLVEmp[1].Salary
The value of a variable EMP Salary is exchanged with that of the member variable “Salary’ of the Compound List Variable CLV Emp. Both the simple variables are of String data type.
- Action – INCREMENT
INCREMENT is a special action provided in ‘Function’ scope to increment values of the variable. This is supported only on simple variables of type Number.
Syntax
INCREMENT : <Simple Variable Specifica t ion> [:<NumIncrement Expression>]
Where,
<Simple Variable Specification is the simple variable specification.
<NumIncrementExpression> is an expression which evaluates to a number. Based on this, the Variable value is incremented. It is optional. If not specified, the variable value is incremented by 1.
Example:
INCREMENT : Counter
;; Incrementing the variable value by 1
INCR : Counter : 2
;; Incrementing the variable value by 2
- Action – D E CREMENT
Decrement is a special action provided in ‘Function’ scope to decrement values of the variable. It is supported only on simple variables of type Number.
Syntax
DECREMENT : <Simple Variable Specification> [:<NumIncrementExpression>]
Where,
<SimpleVar Specifiction> is the simple variable specification.
<NumIncrement Expression> is anexpression evaluating to a no., based on which , the Variable value is decremented. It is optional. If not specified, the variable value is decremented by 1.
Note: Action DECR is an alias for the action DECREMENT.
Example:
;; Decrementing the variable value by 1
DECREMENT : Counter
;; Decrementing the variable value by 2
DECR : Counter : 2
V alue M odific a tion at Field Le v el
- Attribute – MODIFIES
The Field attribute ‘Modifies’ is used to modify the value of the variable.
Syntax
Modifies : <Variable Specification> [:<Logical Flag>]
Where,
<Variable Specification> is the variable path specification.
<Logical Flag> can be a logical value TRUE / FALSE. TRUE would set the value after the field’s acceptance, while FALSE will set it during the acceptance of the report having the field.
Example:
[Field : EMP Age]
Modifies : EMPAgeVar : Yes
Here, value of the variable EMPAgeVar will be modified with the values stored/keyed in the field EMPAgeafter the field’s acceptance.
Retrieving value from List
- Function – $$ListValue
It is used to retrieve the value of an element in the list for a given key. If the list is of compound Variables, an optional member specification can be given to extract value of a specific member.
Syntax
$$ListValue : <List Variable Specification> : <Key Formula> [:<Member Specification>]
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
<Key Formula> can be any expression which evaluates to a string value.
<Member Specification> is required only if the value needs to be extracted from a specific memeber of a Compound List Variable.
Example:
Retrieving value from Simple List Variable using $$List Value
$$ListValue:SLVEMP:”E001″
In this example, the function returns the value of the element identified by the key ‘E001’ from the simple list variable ‘SLV Emp’.
$$ListValue:SLVEMP:##KeyVar
In this example, the variable ‘KeyVar ’ holds the key value. The function returns the value of the element identified by the key from the simple list variable SLV Emp.
Retrieving value from Compound List Variable using $$LISTValue
$$ListValue:CLVEmp:##KeyVar:Age
In this example, the variable KeyVar holds the key value. The function returns the identified Compound List Variable elements member Variable value. In this case, the member specification has been specified as ‘Age’.
- Function – $$ListValueEx
The Function $$ListValueEx returns the value of an element at the specified index in the list.
Syntax
$$ListValueEx : <List Variable Specification>:<Index Formula> [:<Member Specification>]
Where,
<List Variable Specification> is the Simple or Compound List Variable specification.
<Index Formula> can be any expression which evauates to an index number.
<Member Specification> is required only if the value needs to be extracted from a specific member of a Compound List Variable.
Example:
Retrieving value from Simple List Variable using $$List Value Ex
$$ListValueEx:SLVEmp:##IndexVar
In this example, the variable ‘IndexVar’ holds the index value. The function returns the value of the elementidentified by the index from the simple list variable ‘SLV Emp’.
Retrieving value fr om Compound List Variable using $$ListValueEx.
$$ListValueEx:CLVEmp:##IndexVar:Age
Here, Variable ‘Key V ar’ holds the index value. The functi o n returns the identifi e d C ompound List Variable eleme n t’s mem b er variab l e value. Here , the member specified is ‘Age’.
- In d ex Based Retri e val us i ng ## Operator
The o p erator ## is us e d to access t he value of the variable. It also allows dotted no t ation s yntax to access variables/m e mber variables/elem e nt Variables o f a list at any level.
When ## is used on a compound variable (without path specification), it ret u rns t he value of the first member variable , by default. Similarl y , on a list varia b le, it returns the no. of items in the list.
Syntax
##<Element Variable Specification>.<Member Variable Specification>.<Simple Member Value specification>
Where,
<Elem e nt V ari a ble S pecific a tion> can be a Compound Variable or C ompound List Variable [In d ex Expressio n ].
<Member V ariable S p e cificat i on> can be a Comp o und V ariable Member or Compound List Member Variable [Index Expr e ssion].
<Simple Me m ber V alue S p e cificat i on> refers to t h e name of a simple member in speci f ied p ath.
<Ind e x Expressi o n> is an expression that evaluates to a no. S uffixing a variable with i ndex refers to an element variable . It can be p ositive or negative. Negative index denotes reverse access.
Example:
Re t rieving V a lue from Simple Li s t V a r i a ble using # # Op e ra t or
SET : TempVar : ##SLVEMP[3]
V a lue o f el e ment in SLVEM P , identifi e d by the index ‘3’, will be set to t h e Variable ‘ T emp V ar’.
Re t rieving V a lue from Compo u nd List Variable using # #O p er a tor
LOG : ##CLVEmp[2].Relatives[1].Name
Here, we are re t rieving value of the identified C o mpound List V ariable (R e latives) el e ment ’ s member variable value. ‘Relatives’ is a member variable of the Comp o und List Vari a ble C L VEMP .
Loop i ng Construct – For In/For Each
The F OR IN loop is used to iterate over the values in t he list variable. The n u mber o f itera t ions depends on the number of items in the list variable .
Syntax
FOR IN : <I terator Variable> : <List Variable Name>
.
.
END FOR
Where,
<Iterator V ariable> is the name of the variable w h ich hol d s the Key value in e very iter a tion.
<List V ar i able Nam e> is the n a me o f the Simple Li s t or Compound List V ariable.
This construct will w a lk o nly the elemen t s in the list which a r e having a ke y . Since the iterat o r variable is filled with a key for e ach el e ment , all elemen t s w h ich do not have a k e y a re ignore d . This is useful to w alk keyed list Variable e lements in the current sorting orde r . If t he e lement does not have a k e y , t hen oth e r loo p s like WHILE, FOR, etc., can be used and the elem e nts can be op e rated via index.
Example:
Iterat i n g the Simple List Variable V alues
FOR IN : KeyVar : SLV Emp
LOG : $$ListValue:SLVEmp:##KeyVar
END FOR
Here, t h e iter a tor Variable “Key V ar” holds the Key val u e in every occurrence of the iteration. In every iter a tion, the value of the element identified by t h e key is logged using the function $$Li s t V alue .
It e ra t i n g the Comp o und List V ariable V a l u es
FOR IN : KeyVar : CLV Emp
LOG : $$ListValue:CLVEmp:##KeyVar:Age
END FOR
Here, t h e it e rator v ariable “KeyVar” holds the Key value in every iteration. In every iteration, the v a lue o f the member “Age” of the element o f “C L VEMP” iden t ified by the key is logged using the function $$Li s t V alue .
Note: The looping construct FOR EACH is an alias for the looping construct FOR IN.
List V ariable S pecific Functions
- Fu n ction – $ $ ListKey
The function $$ListKey returns the corresponding key f o r the given index.
Syntax
$$ListKey : <List Variable Spe c ification> : <Index Specification>
Where,
<List V ar i able S p e cificati o n> is the Simple List or Compound List Variable s p ecification.
<Ind e x S pecif i cation> can be any ex p ression which evaluates to a num b er.
Example:
Retrieving key from a simple L ist V ariable using $ $ListKey
01 : LOG : $$ListKey:SLVEMP:2
In this example, the fu n ction $ $ListKey retrieves the Key of t h e sec o nd element of the Simple List Variable ‘S L VEMP’.
Retrieving key from a Compound List V ariab l e using $$ListKey
02 : LOG : $$ListKey:CLVEmp[1].Relatives:1
Here, key of first element of Compou n d L ist V ariable ‘Relative s ’ is retrieved. ‘Relatives’ i s a m e mber of Compound List Variable ‘CLVEMP’.
- Fu n ction – $ $ ListIndex
The function $ $ListIn d ex ret u rns t h e Corresponding index for the given Key .
Syntax
$$ListIndex : <List Variable Specification> : <Key Specification>
Where,
<List V ar i able S p e cificati o n> is the Simple List or Compound List Variable s p ecification.
<Key S p e cificat i on> c a n be any expression which evalu a tes to As t ring val u e.
Example:
Retrieving index from a simple List V ariab l e using $$ListI n dex
01 : LOG : $$ListIndex:SLVEMP:E001
Here, index of the element identifi e d by the key value ‘E00 1 ’ is retrieved from ‘SLVEMP’.
Retrieving index from a Compound List V ariable using $$Lis t Index
02 : LOG : $$ListIndex:CLVEmp:E001
Here, index value of the elem e nt i d entified by the key value ‘ E 001’ is retrieved from ‘C L VEMP’.
- Fu n ction – $ $ ListCount
The function $$ListCount retrieves the number o f items in the list.
Syntax
$$ListCount : <List Variable Specification>
Where,
<List V a ri a ble S pe c ificatio n> is the Simple List or Compound List Variable speci f ication.
Example:
01 : LOG : $$ListCount:SLVEMP
02 : LOG : $$ListCount:CLVEMP
- Fu n ction – $ $ ListFind
It is used to check if a given key exis t s in the list or n ot. I t r e turns a logic a l fl a g as a result.
Syntax
$$ListFind : <List Variable Specification> : <Key For m ula>
Where,
<List V ar i able S p e cificati o n> is the Simple List or Compound List Variable s p ecification.
<Key F o r m ula> can be a ny e xpression which eval u ates to a string value.
Example:
01 : LOG : $$ListFind:SLVEMP : E001
02 : LOG : $$ListFind:CLVEMP : E001
- Fu n ction – $ $ List V alueF i nd
This function can be used to check if a giv e n v alue exis t s in the lis t . If a given list has more th a n one same value, the index can be used to r etrieve the n’th matc h ing val u e.
Syntax
$$ListValueFind : <List Variable Specification> : <Occurance Specification> : <Value Formula> [:<Member Specification>]
Where,
<List V ar i able S p e cificati o n> is the Simple List or Compound List Variable s p ecification.
<Occurance S pecifi c ation> can be any expression which e valuates to a numb e r.
<V alue Formula> can be any ex p ression w h ich evaluates to a value.
<Member S pe c ificatio n> can be specified if the list eleme n t is compound. It is option al.
Example:
;; Finding value from the Simple List Variable
01 : LOG : $$ListValueFind:SLVEMP:1:RAMESH
;;Finding value from the Compound List Variable with member specification
03 : LOG : $$ListValueFind:CLVEmp:1:PRIYA:Name
The function will return YES if the value exists in the list, e lse it will r e turn NO.
Popula t ing a List from a Collection
- Action – LIST FILL
It is used to fill a list from a c ollecti o n ins t ead of using t he looping co n struct s . The specified collection is walked and the key formula and v a lue f ormula is evalua t ed in the conte x t of each object to create list elemen t s.
Syntax
LIST FILL : <List Variable Specification> : <CollectionName> [:<Key Formula> [:<Value Formula> [:<Member Specification>]]]
Where,
<List V ar i able S p e cificati o n> is the Simple List or Compound List Variable s p ecification.
<Colle c tion N a me> is t h e n ame of the collection from which the valu e s need to be fetched to fill the list Variable.
<Key F o r m ula> can be a ny e xpression which evaluates to st r ing val u e. It is o ptional.
<V alue Formula> c an be any expression w hich returns a value. The data type of the value must be same as th a t of the L ist Variable. V alue form u la is option a l. I f not specified , only KE Y i s s e t f or each added element.
<Member S pe c ificatio n> can be given if the list contains a compound variable
Note: If both key and value are not specified, blank elements are added to the list.
Example
Popu l a ting Asimp l e L i st V ar i able from a Collection
LIST FILL : SLV Emp : Employees : $Name : $Name
All the employee names from the collection ‘Employees’ will b e ad d ed to the Simple List Variabl e , once the action LIST Fill is execute d .
Pop u l a ting a Compo u nd List V a ri a ble f r om a Colle c tion
LIST FILL : CLV Emp : Employees : $Name : $Name
In this example, a ll the employee names from the collection ‘Em p loyees’ will be ad d ed to the first m e mber variabl e , as t here is no member specification.
LIST FILL : CLV Emp : Employees : $Name : $Designation: Designation
In this example, D esignatio n s of all the employees from the collection ‘Employees’ will be added to t h e m e mber variable ‘Designation’.
LIST FILL : CLV EMP[1].Relatives:Employees : $Name : $SpouseName : Name
Spouse name o f all empl o yees from the collecti o n ‘Employees’ will be added to m e mber variable ‘Name’ of Compound List V ariable ‘Relatives’. ‘Relatives’ is a member Variable of ‘CLVEMP’.
Sorting of List Elemen t s
Initially , w hen t h e list variable is create d , it is sorted on the order of inser t ion. TDL provi d es the facility to sort the v a lues in the list varia b le based either on key or on value. The following actions allow changing the sort order:
-
- o List Key S ort
- o List V a lue Sort
- o List Res e t Sort
- Action – LIST KEY S O RT
The action LIST KEY SORT allows the user to sort the elements of the list based on t h e k e y .
Keys are by default of type ‘Stri n g’; so, the absence of key data type specification will consid e r key data type as S tring while s o rting. The user c an overri d e t hi s by speci f ying a k ey d ata type . Keys are option a l for elemen t s . All elemen t s in the list may not have a key . In such cases, comparisons of eleme n ts would be done based on the inser t ion o rder .
Syntax
LIST KEY SORT : <List Variable Specification> [:<Ascending/DescendingFlag> [:<Key Datatype>]]
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
<Ascending/DescendingFlag> can be YES/NO. YES is used to sort the list in ascending order and NO for descending. If the flag is not specified, then the default order is ascending.
<Key Data Type> can be String, Number, etc. It is optional.
Note: The action LIST SORT is an alias for the action LIST KEY SORT .
Example
Sorting Simp l e List b ased on K e y
LIST KEY SORT : SLVEmp : Yes : String ;;Ascending Order
LIST KEY SORT : SLVEmp : No : String ;;Descending Order
Sorting Comp o und List based o n Key
LIST KEY SORT : CLVEmp : Yes : String ;;Ascending Order
LIST KEY SORT : CLVEmp[1].Relatives : No : String ;;Descending Order
- Action – LIST V A LUE SO R T
The action LIST VALUE SORT allows the user to sort the elements of the list based on value.The data are sorted as per the data type specified for the list variable in case of simple list, and the member specification data type in case of compound list. If a compound list is chosen and member specification is not specified, then the list is sorted by value of the first member variable.
If duplicate values are in the list, the key data type passed is considered to sort by key, and then in absence of key, insertion order is used.
Syntax
LIST VALUE SORT : <List Variable Specification> [:<Ascending/Descending Flag> [:<Key Datatype> [:<Member Specification>]]]
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
<Ascending/DescendingFlag> can be YES/NO. YES is used to sort the list in ascending order and NO for descending. If the flag is not specified, then the default order is ascending.
<Key Data Type> can be String, Number, etc. It is optional.
<Member Specification> is the member specification in case of compound list. If not specified, the list is sorted by the value of first member variable.
Example
Sorting Simp l e List b ased on V alue
;;Ascending Order
LIST VALUE SORT : SLVEmp : Yes : String
;;Descending Order
LIST VALUE SORT : SLVEmp : No : String
Sorting Comp o und List based o n V alue
;;Ascending Order
LIST VALUE SORT : CLVEmp : Yes : String
;;Descending Order
LIST VALUE SORT : CLVEmp[1].Relatives : No : String
- Actio n – LIS T RES ET S O RT
This action resets the sorting method of the list and brings it back to the insertion order.
Syntax
LIST RESET SORT : <List Variable Specification>
Where,
<List Variable Specification> is the Simple List or Compound List Variable specification.
Example:
LIST RESET SORT : SLVEMP LIST RESET SORT : CLVEMP
Some Common Functions Used
- Fu n ction – $ $ IsSysNam e V ar
This function checks if the variable has a value which is AsysName like ‘Not Applicable’, ‘End of List’, etc. In case of repeated variables, if any one value is a non-sysname, it returns FALSE.
Syntax
$$IsSysNameVar : <Variable Speci f ication>
Where,
<Variable Specification> is the simple variable path specification.
Example
$$IsSysNameVar:EmpVar
Here, $$IsSysNameVar returns YES if variable EmpVar has Sysname as value, else returns NO.
- Fu n ction – $ $ IsDefaultVar
This function determines if the content of the variable has a “Default” or blank as the value. This function is applicable only for Simple variables. In case of simple repeated variable, if any one value is non-default, then this is not a default variable, and the function returns NO.
Syntax
$$IsDefaultVar : <Variable Speci f ication>
Where,
<V ariable S pecifi c ation> is the simple variable path specification.
Example:
[Field : DefaultVar]
Set as : $$IsDefaultVar:SVValuationMethod
$$IsDefaultVar returns YES if value of SV V aluationMethod is blank or Default, else returns NO.
- Fu n ction – $ $ IsActuals V ar
This fu n ction c h ecks if the con t ent of t h e variable is bla n k or sysname or “ACTUALS”.
Syntax
$$IsActualsVar : <Variable Speci f ication>
Where,
<V ariable S pecifi c ation> is the simple variable path specification.
Example:
$$IsActualsVar:SVBudget
YES is returned if the valu e o f VariablesVBud g et is Blank or Sysname or “ACTUALS”, else NO.
- Fu n ction – $ $ IsCurr e nt V a r
This fu n ction c h ecks if the con t ent of t h e variable is Blank or Sysname or “ S tock in hand”.
Syntax
$$IsCurrentVar : <Variable Specification>
Where,
<Variable Specification> is the simple variable path specification.
Example
$$IsCurrentVar:DSPOrderCombo
YES is returned if value of DSPOrderCombo is Blank or Sysname or Stock-In-Hand, else NO.
- Fu n ction – $ $ ExecVar
This fu n ction ret u rns t h e value of a variable in the p arent report chain.
Syntax
$$ExecVar : <Variable Specification>
Where,
<Variable Specification> is the simple variable path specification.
Example:
$$ExecVar:DSPShowMonthly
Function $$ExecVar returns the value of the variable DSPShowMonthly from the parent report.
- Fu n ction – $ $ FieldVar
This function returns the value of the field which is acting as a variable with the specified name.
Syntax
$$FieldVar : <Variable Specifica t ion>
Where,
<V ariable S pecifi c ation> is the simple variable path specification.
Example:
[Collection : GodownChildOfGodownName]
Type : Godown
Child of : $$FieldVar:DSPGodownName
In this example, $$FieldVar is used to fetch the value of the variable DSPGodownName whose value is modified in a field. This value becomes the value for the ‘ChildOf’ attribute.
- Fu n ction – $ $ ParentField V ar
This function gets the field variable value from its parent report.
Syntax
$$ParentFieldVar : <Variable Spe c ification>
Where,
<Variable Specification> is the simple variable path specification.
Example:
[Field : ParentFieldVar]
Set as : $$ParentFieldVar:SVStockItem
Here, the function returns field variable value from its parent report for the variable “SVStockItem”.
Field Acting as a Variable
The ‘Variable’ attribute in a ‘Field’ Definition is used to make the field behave as a variable, with the specified name. The variable need not be defined as it inherits data type from the field itself. Field can act as a simple variable only, since it can hold only simple value.
Syntax
[Field : <Field Name>]
Variable : <Variable Name>
Where,
<Fie l d Name> is the name of t h e field.
<V ariable Name> is the name of t h e variable.
Example:
[Field : EmployeeName]
Variable : EmpNameVar
Implication of Repeat Variables in Columnar Report
The re p ort in which a number of columns can be added or delet e d as per the user inpu t s, is refe r red to as Col u mnar R eport. In a C olumnar Report, Lines are re p eated vertically and Fields are repeat e d horizon t ally . The Columnar Rep o rt can be a:
- MultiColumn R e port – Column c a n be repeated based on the user inpu t s.
- AutoColu m n R eport – M ultiple columns can b e rep e ated b ased on the user i nput, on the single click of a b utton.
- Autom a tic Auto C olumns – R eport can be started with predefined multi p le columns w it h out user intervention.
The Attribute ‘Repeat’ – V ariable, R e port and Li n e
Let us see the implications of Repeat Attribute of Vari a ble / R eport / Line Definitions in context of Columnar Repor t s.
- 1. Repeat Attribu t e of V ariable definiti o n
Please refer to t h e topic “Varia b le Definition and Attributes”.
- 2. ‘Repeat’ Attribute of Report definition
The Repeat A ttribu t e of ‘Report’ d e finition is us e d specifically in Columnar Repor t s. When we specify ‘Repeat’ attribute with a v ariable name, the report becomes a C olumnar Report and the number of columns depen d s u p on the values st o red in the variab le . Only simple Variables c an be rep e ated. A lso , a report c a n h a ve more than one varia b les rep e ated. In such c ases, the n umber of columns in t h e rep o rt dep e nds o n the maximum value a Repeat V ariable hol d s.
The ‘Rep e at’ attri b ute o f the report is d eclaration cum repeat specific a tion; so Ase p arate declar a tion is not required. Even if a declaration is done usi n g ‘Vari a ble’ attribute, ‘Repe a t’ is considered as a rep e at s p ecification.
Syntax
[Report : <R eport Name>]
Repeat : <Variable Names>
Where,
<Report Nam e> is the n a me of the Rep o rt.
<V ariable Names> is the comm a -separa t ed list of variables.
- 3. Repeat Attribute of Line Def i nition
The ‘Repea t ’ Attri b ute of ‘Line’ Definition is used to repeat the Field h orizontally in columns.
Syntax
[Line : <Li n e Name>]
Repeat : <Field Name>
Where,
<Line Name> is the name of the line.
<Fie l d Name> is the name of the Field which needs to be repeated .
Example:
Let us look into the usage of ‘Repeat’ Attribute at Variable/Re p ort/Line Definitions in designing the Columnar S tock Item-wise Customer-wise Sales Report . In this report , Stock Item names should be repeated vertically and Customer/Party names horizontally . The columns should be automatically available when the report is started.
Repeat Attribute of Variable Definition
[Variable : PName]
Type : String
Repeat : ##DSPRepeatCollection
The variable ‘DSPRepeatCollection’ holds the collection name ‘CFBK Party’. This collection contains a method name ‘PName’. In this case, the variable ‘PName’ would be filled with the method value from each object of the collection “CFBK Party”.
[Collection : CFBK Party]
Source Collection : CFBK Voucher
Walk : Inventory Entries
By : PName : $PartyLedgerName
Aggr Compute : BilledQty : SUM: $BilledQty
Filter : NonEmptyQty
Variable ‘PName’ holds multiple values based on implicit index. Method value of each object of collection ‘CFBK Party’ is picked up and stored in the variable’s 1st index, 2nd index, and so on.
‘Repeat’ Attribute of Report Definition
[Report : CFBK Rep]
Use : DSP Template
Form : CFBK Rep
Variable : DoSetAutoColumn, PName Repeat : PName
Set : DoSetAutoColumn : Yes
Set : DSPRepeatCollection : “CFBK Party”
Set : SVFromDate : $$MonthStart:##SVCurrentDate
Set : SVToDate : $$MonthEnd:##SVCurrentDate
The attribute “Repeat” determines that it is a Columnar Report. The number of columns depends on the number of values available in the variable “PName”.
Repeat Attribute of Line Definition
[Line : CFBK Rep Details]
Fields : CFBK Rep Name, CFBK Rep Party, CFBK Rep Col Total
Repeat : CFBK Rep Party
Total : CFBK Rep Party
Field ‘CFBK Rep Party’ is repeated based o n the no. o f values of varia b le (NumSe t s). So, those many numbers of instanc e s of the field are created. E ach field will have a n implicit index n umber (s t arting fr o m 1). This impli c it index is us e d to evaluate expressi o ns in the cont e xt of the field.
Common Functions used with Columnar Reports
- Function – $ $ NumSets
It returns the number of columns in the report. It does not take any parameter. If the report is an auto report or sub report, it returns the number of columns in the parent of the auto/sub report. Number of set is the maximum number of values a repeated variable can hold in that report.
Syntax
$$NumSets
Example:
[Field : CFBK Rep Col Total]
Use : Qty Primary Field
Set as : $$Total:CFBKRepParty
Border : Thin Left
Invisible : $$Numsets=1
In this example, the ‘Total’ column will be invisible if there is only one column in the report.
- Function – $$ LowValue
This function c a n be used to get the lowest value in a set o f values in the repeated variable.
Syntax
$$LowValue : <Variable Specification>
Where,
<Variable Specification> is a simple variable specification.
Example:
Let us suppose that the Repeat Variables in a Columnar Report are SVFromDate and SVToDate. Consider the following Field Definition in the same report:
[Field : VariableLowValue]
Use : Name Field
Set as : $$LowValue:SVFromDate
$$Lowvalue returns the lowest value in Aset of values in the repeat variable SVFromDate.
- Function – $$HighValue
This function can be used to get the highest value in a set of values in the repeated variable.
Syntax
$$HighValue : <Variable Specification>
Where,
<Variable Specification> is a simple variable specification.
Example:
Suppose that the Repeat Variables in a Columnar Report are SVFromDate and SVToDate. Consider the following Field definition in the same report:
[Field : VariableHighValue]
Use : Name Field
Set as : $$HighValue:SVToDate
$$HighValue returns the highest value in a set of values in the repeat variable SVToDate.
- Function – $$IsCommon
This function is used with repeated variable to check if all the values in the repeat set are same.
Syntax
$$IsCommon : <Variable Specifica t ion>
Where,
<Variable Specification> is a simple variable specification.
Example:
Suppose the Repeat Variable in a columnar report is SVCurrentCompany. Consider the following Field Definition in the same report:
[Field : VariableIsCommon]
Use : Logical Field
Set as : $$IsCommon:SVCurrentCompany
$$IsCommon returns YES if all values in SVCurrentCompany are same, otherwise returns NO.
- Function – $$VarRangeValue
This function gets a list of variable values, separated by the specified separator character. If no separator character is specified, comma (,) is taken as the separator character by default.
Syntax
$$VarRangeValue : <Variable Specification> [:<Separator Character> [:<Start Position> [:<End Position>]]]
Where,
<V ariable S pecifi c ation> is the simple variable sp e cific a tion.
<Se p a r a tor C h a r a cter> is the se p arator char a cter.
<S t art Pos i tion> is the index which de n otes the star t ing p osition.
<End Pos i tion> is the index which denotes the ending position.
Note: Specifying Start and End Positions is optional. If not specified, the function will return all the values of the specified Repeat variable separated by comma(,).
If Start and End Positions are specified, the function will return the values of repeat variable within the Specified index Range. Again, specifying End Position is optional. If the End Position is not specified, the function will return the entire set of values from the starting position.
Example:
$$VarRangeValue:SVFromDate
In this example, the function returns the entire set of values of the Repeat Variable SVFromDate.
$$VarRangeValue:SVFromDate:”,”:1:5
Here, the function returns the value of specified index range (1 to 5) of the Repeat Variable SVFromDate
$$VarRangeValue:SVFromDate:”,”:3
The entire set of values from Starting Index position of the repeat variable SVFromDate are returned.
Variables Usage and Behaviour in Auto Report
A report can be marked as an auto report via AUTO attribute, which indicates the system that the report cannot instantiate its own variables. It will inherit variables from parent scope. It is mainly used for configuration reports which require modifying configuration variables of parent report.
Syntax
[Report : <R eport Name>]
Auto : <Logical Value>
Where,
<Report Name> is the name of the report.
<Logical Value> can be YES / NO. The default value is NO.
Example:
[Report : Voucher Configuration]
Auto : Yes
Title : $$LocaleString:”Voucher Configuration”
This is a default co n figuration report mark e d as Auto rep o rt, t o modify variables of p arent report. A report can be launched in ‘Auto’ mode using Actions Modify Variable and Modify System.
Actions MODIFY VARIABLE and MODIFY SYSTEM
- Action – MODIFY V ARIABLE
It launches the given rep o rt in ‘auto’ mode. Since the launch e d report is in ‘auto’ mode, it cannot have its own instance of Variables and any modification would affect the parent context.
Syntax
MODIFY Variable : <Report Name>
Where,
<Report Name> is the name of the report which is to be launched in ‘AutoMode’.
Example:
[Button : F2 Change Period]
Key : F2
Action : Modify Variables : Change Period
Title : $$LocaleString:”Period”
The Action ‘Modify Variable’ launches the report ‘Change Period’ in ‘Auto’ Mode. The report is having two fields SVFromDate and SVToDate
[Field : SVFromDate]
Use : Short Date Field
Modifies : SVFromDate
Variable : SVFromDate
[Field : SVToDate]
Use : Short Date Field
Format : Short Date, End : #SVFromDate
Modifies : SVToDate
Variable : SVToDate
The variable value changes would affect the parent report context only (i.e., it will affect values of the variables SVFromDate and SVTodate, which are associated to the report, from which the report Change Period is launched in Auto Mode).
- Action – MODIFY SYSTEM
The action MODIFY SYSTEM launches the given report in ‘auto’ mode. Even if the report is called under some other report context, this action makes the new report to get the system context and thereby modify the system scope variables.
Syntax
MODIFY SYS T EM : <Report Name>
Where,
<Report Name> is the name of the report which is to be launched in ‘Auto Mode’.
Example:
[Button: Change System Period]
Key : Alt+F2
Action : Modify System : Change Menu Period
Title : $$LocaleString:“Period”
The Action ‘Modify System’ has launched the report ‘Change Menu Period’ in ‘Auto’ Mode. The report is having two fields SVFromDate and SVToDate.
[Field : SVFromDate]
Use : Short Date Field
Modifies : SVFromDate
Variable : SVFromDate
[Field : SVToDate]
Use : Short Date Field
Format : Short Date, End : #SVFromDate
Modifies : SVToDate
Variable : SVToDate
The value changes would affect the variables at system scope, as the report is launched using the Action ‘Modify System’.
Variable Framework Enhancements
In the prior releases, we have experienced major changes to the Variable Framework in the form of introduction of Compound Variables and List Variables. Continuous enhancements and changes are being made to ensure consistency and uniformity across the TDL framework.
Watch the below videos to understand the enhancements in Variable Framework.
Variable Persistence at ‘Report’ Scope
Variables at ‘report’ scope can now be persisted into a user specified file. This is stored in a standard variable format and also allows reloading the report scope variables from the specified file. The Actions SAVE VARIABLE and LOAD VARIABLE have been introduced for this purpose.
Action – SAVE VARIABLE
The action SAVE VARIABLE is used to persist the Report Scope Variables in a user specified file.
Syntax
SAVE VARIABLE : <FileName> [:<Variable List>]
Where,
<FileName> is the name of the file in which the report scope variables are persisted. The extension .PVF will be taken by default, if the file extension is not specified.
<Variable List> is the list of comma-separated variables that need to be persisted in the file. Specifying the variable list is optional.
Note: If the Variable List is not specified, all the variables at the ‘Report’ scope, which have ‘Persist’ attribute set to YES, will be persisted in the specified file. We need not declare the variable at System level unless it is required to persist the same in the default configuration file tallycfg.tsf.
Example
Let us assume that the variables EmpNameVar and EmpIDVar are declared at the Report Scope, and the same need to be persisted in a user specified file. We can achieve this using the newly introduced actions SAVE VARIABLE and LOAD VARIABLE . The buttons SAVEVAR and LOADVAR are added at the Form Level for the same.
[Button: SaveVar]
Key : Alt + S
Action : Save Variable : SmpVar.pvf : EmpNameVar, EmpIDVar
The action SAVE VARIABLE will persist the values of the variables EmpNameVar and EmpIDVar in the file SmpVar .pvf
Action – LOAD VARIABLE
The action LOAD VARIABLE is used to reload the report scope variables from the specified file.
Syntax
LOAD VARIABLE : <FileName> [:<Variable List>]
Where,
<FileName> is the name of file in which the ‘report’ scope variables are persisted. The extension .PVF will be taken by default, if the file extension is not specified.
<Variable List> is the comma-separated list of variables that need to be loaded from the file. It is optional. In case it is not specified, all the variables saved in the file will be loaded.
Example
In the previous example, we have persisted values of the Report Scope Variables EmpNameVar and EmpIDVar in the file SmpVar.pvf . Now, let us see how to re-load these ‘report’ scope variables from the file.
[Button : LoadVar]
Key : Alt + L
Action : LOAD VARIABLE : SmpVar.pvf : EmpNameVar, EmpIDVar
The action LOAD VARIABLE will load the report scope variables EmpNameVar and EmpIDVar from the file SmpVar.pvf .
Note: Member Variable Specification or Dotted Notation Specification is not allowed for specifying Variable list for both the actions SAVE VARIABLE and LOAD VARIABLE . It has to be a variable name identifier at the current report scope.
Variable Copy
The contents of a variable can now be entirely copied from one instance to another instance.
Action – COPY VARIABLE
The action COPY VARIABLE is used to copy the content from one variable (Source) to another variable (Destination). This action is supported for all types of variables (Simple/Compound/List Variables).
Syntax
COPY VARIABLE : <Destination Variable> : <Source Variable>
Where,
<Destination Variable> is the name of the Simple/Compound/List Variable.
<Source Variable> is the name of the Simple/Compound/List Variable, from which the content has to be copied.
Example: Copying from Simple Variable to Simple Variable
[Function : SimpleVar Copy Function]
VARIABLE : SimpleVar1 : String : “Employee1”
VARIABLE : SimpleVar2 : String
10 : COPY VARIABLE : SimpleVar2 : SimpleVar1
20 : LOG : “Source” + ##SimpleVar1
30 : LOG : “Destination” + ##SimpleVar2
In this example, the variables SimpleVar1 and SimpleVar2 are declared at the Function level. After execution of the action COPY VARIABLE , the content of the variable is copied from SimpleVar1 to SimpleVar2 .
Example: Copying from Compound Variable to Compound Variable
Let us suppose that the following compound variables are defined:
[Variable : Employee1]
Variable : EmpName : String : “Praveen”
Variable : Designation : String : “Manager”
[Variable : Employee2]
Variable : EmpName : String
Variable : Designation : String
In the function below, contents are copied from Compound Variable Employee1 to Employee2:
[Function : Compound Var Copy Function]
VARIABLE : Employee1
VARIABLE : Employee2
10 : COPY VARIABLE : Employee2 : Employee1
20 : LOG : “Source” + ## Employee1.EmpName
30 : LOG : “Source” + ## Employee1.Designation
40 : LOG : “Destination” + ## Employee2.EmpName
50 : LOG : “Destination” + ## Employee2.Designation
Note: The content will be copied from a member variable of a Compound Variable (Source) to another member variable of a compound variable (Destination), based on the member variable names, since more than one member variable may have the same data type.
Example: Copying from List Variable to List Variable
Let us suppose that the following compound variables are defined:-
[Variable : Employee1]
Variable : EmpName : String
Variable : Designation : String
[Variable : Employee2]
Variable : EmpName : String
Variable : Designation : String
In the following function, the compound variables Employee1 and Employee2 are declared as List Variable. We are copying all the elements from the compound list variable Employee1 to the compound list variable Employee2 .
[Function : ListVar Copy Function]
LIST VARIABLE : Employee1, Employee2
10 : LIST FILL : Employee1 : Employees : $Name : $Name
20 : LIST FILL : Employee1 : Employees : $Name : $Designation + :Designation
30 : COPY VARIABLE : Employee2 : Employee1
40 : LOG : “Source Variable – Employee”
50 : FOR IN : KEY VAR : Employee1
60 : LOG : $$LISTVALUE:Employee1:##KEYVAR:EmpName
70 : LOG : $$LISTVALUE:Employee1:##KEYVAR:Designation
80 : END FOR
90 : LOG : “Destination Variable – Employee”
100 : FOR IN : KEY VAR : Employee2
110 : LOG : $$LISTVALUE:Employee2 : ##KEYVAR:EmpName
120 : LOG : $$LISTVALUE:Employee2 : ##KEYVAR:Designation
130 : END FOR
Scope Specification in Variable Dotted Syntax
The Dotted Notation Syntax for Variables (##) has now been enhanced to allow specification of scope / relative scope, etc.
Syntax
.. (DOUBLE DOT) denotes owner scope
… (TRIPPLE DOT) denotes owner’s owner scope and so on
(). denotes a system scope
Where,
<Definition Type> is the name of the definition such as Report, Function, etc., in the current execution chain.
<Definition Name Expression> can be any expression which evaluates to a Definition Name. The Definition Name Expression is optional.
(<Definition Type>, <Definition Name Expression>) can be used for absolute scope specification. The element (<Definition Type>, <Definition Name Expression>) has to be in the current execution chain, else one will not be able to refer to the same.
Example
Let us suppose that the Variable TSPLSMPScopeVar is declared at System Scope.
[Variable : TSPLSMPScopeVar]
Type : String
[System : Variable]
TSPLSMPScopeVar : “System Scope”
The function TSPLSMPScopeSpec is called from a Menu. We have declared the variable TSPLSMPScopeVar in the ‘Function’ scope also.
[Function : TSPLSMP ScopeSpec]
VARIABLE : TSPLSMPScopeVar
01 : SET : TSPLSMPScopeVar : “Function Level”
02 : Display : TSPLSMP ScopeSpec
The following report is displayed from the function TSPLSMP ScopeSpec. We have declared the variable TSPLSMPScopeVar in the ‘Report’ Level also.
[Report : TSPLSMP ScopeSpec]
Form : TSPLSMP ScopeSpec
Variable : TSPLSMPScopeVar
Set : TSPLSMPScopeVar : “Report Level”
Following are the field definitions of the report TSPLSMP ScopeSpec. Let us see the variable values at the field level by specifying the scope in Variable Dotted Syntax.
[Field : TSPLSMP ScopeSpecCurrent]
Use : Name Field
Set As : ##TSPLSMPScopeVar
;;Variable value in this field will be “Report Level” (Current Scope)
[Field : TSPLSMP ScopeSpecOwner]
Use : Name Field
Set As : ##..TSPLSMPScopeVar
Border : Thin Left Right
;;Variable value in this field will be “Function Level” (Owner’s Scope)
[Field : TSPLSMP ScopeSpecSystem]
Use : Name Field
Set As : ##().TSPLSMPScopeVar
Border : Thin Left
;;Variable value in this field will be “System Level” (System Scope)
[Field : TSPLSMP ScopeSpecAbsolute]
Use : Name Field
Set as : ##(Function,“TSPLSMP ScopeSpec”).TSPLSMPScopeVar
Border : Thin Left
;;Variable Value in this field will be “Function Level” (Absolute Specification)
Definition Name and Instance Name of Variable can be different now
A variable can be declared in a scope in two ways, i.e., either by specifying the name of the variable (in this case, a separate variable definition is required) or by specifying the name of the variable and a data type (in this case, a separate variable definition is not required; and hence, is called as inline declaration).
Note: In this chapter, we will go through the ‘Report’ Scope variable declaration, syntax and examples. It is applicable for other scopes also.
Let us look into the variable declaration syntax of Report Scope.
Syntax
[Report : <Report Name>]
;;This syntax expects a separate variable definition in the same name
Variable : <Variable Names>
OR
;;Inline declaration
Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
List Variable : <Variable Names> [:<Data Type>[:<Value>]]
Example
[Report : SMP Report]
Variable : Emp Name
Variable : Emp Relation : String
List Variable : Employee1
List Variable : Employee2 : String : “Prem”
[Variable : Emp Name]
Type : String
[Variable : Employee1]
Variable : EmpName : String
Variable : EmpID : String
Now, the ‘Data Type’ parameter can be pointing to a variable definition; in which case, it will allow one to have a variable which has the instance name and definition name different. This allows flexibility to create two instances of a compound structure in the same scope, with different instance names, without requiring to duplicate the definition. This capability is available at all the scopes where variable declaration is allowed.
Existing Syntax
[Report : <Report Name>]
Variable : <Variable Names>
OR
Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
List Variable : <Variable Names> [:<Data Type>[:<Value>]]
New Enhanced Syntax
[Report : <Report Name>]
Variable : <Variable Names>
OR
Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
List Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
Variable : <Instance Names> : [<Variable Name>]
OR
List Variable : <Instance Names> : [<Variable Name>]
Where,
<Instance Names> is the list of Simple/Compound/List Variables separated by comma (instance variables).
<Variable Name> is the Simple or Compound variable name. A separate variable definition is required. It should not be an inline variable.
Example: 1
Given here is the definition of a Compound Variable “Employee”.
[Variable : Employee]
Variable : EmpName : String
Variable : Designation : String
Now, we can create a variable instance using the definition of another variable. Let us understand this with the help of the following ‘Report’ definition:
[Report : Employee Report]
;;An instance is declared with the name as ‘Prem’ and definition name as ‘Employee’. The variable instance ‘Prem’ will inherit the entire structure of the variable definition ‘Employee’.
Variable : Prem : Employee
;;An instance is declared with the name as ‘Ramesh’ and definition name as ‘Employee’.
Variable : Ramesh : Employee
;;Locally, the instance “Ramesh” is modified to add a member variable.
Local : Variable : Ramesh : Add : Variable : EmpID : String
;; Two instances are declared with the names “Kamal” and “Vimal”, and the definition name as “Employee”
Variable : Kamal, Vimal: Employee
;; A List Variable instance is declared with the name “EmployeeList” and the definition name as “Employee”
List Variable : EmployeeList : Employee
Example: 2
[Report : TSPL SMP Variable Instance]
Variable : Employee : String : “Suresh”
Variable : New Employee : Employee
In this example, we are trying to declare a variable instance ‘New Employee’, which is of the type of another variable ‘Employee’. This will NOT work because the variable ‘Employee’ is declared as inline and an explicit Definition does not exist for the same.
Hence, inline variables cannot be used to declare another variable instance.
Use Case – Multiple Email Configurations
Scenario
ABC Company Ltd., a manufacturing company, is having the Head Office in Bangalore and branch offices in Delhi, Mumbai, Kolkata and Chennai. The company uses Tally.ERP 9 at all the locations.
The Head Office and Branch Offices are using the e-mail capability of Tally extensively to send remainder letters, outstanding statements, etc., to the customers.
The System Administrator at the Head office will be facilitating the Branch office staff for email configurations in Tally. The company is using its own mail server and also another mail server “SIFY”. If there is a change in the mail server, the system admin needs to communicate the information to branch staff, and they will be updating the email configurations in Tally.ERP 9.
Now, the company wants to set the email configurations centrally for all the branches so that the branch staff need not struggle for email configurations, particularly when there is a change in the mail server. This solution provides the facility of saving multiple configurations in multiple file names, and later loading them from the file, based on user selection.
Requirement Statement
Presently in Tally.ERP 9, users need to set email configurations locally & update required details.
Now, the configurations can be created centrally and shared among the locations. Thus, the user need not set email configuration every time. They have to simply load the configuration from the file. This can be achieved using newly introduced actions SAVE VARIABLE & LOAD VARIABLE.
Functional Demo
Before looking into the design logic, we will have a functional demo.
Let us suppose that ABC Company Ltd. is using its own mail server and another mail server Sify in its Head Office and its branch offices.
Saving Email Configurations
Let us suppose that the System Administrator in Head Office wants to save the required email configurations in Tally.ERP 9 for HO and Branches
Gateway of Tally> F12: Configure> E-Mailing . The email configuration screen will appear as follows:
The System Admin needs to save the configurations for mail servers abc and Sify. Hence, he has to specify Email server as “User Defined” and enter the required configuration settings as follows:
Now, the System Admin has to press Alt+S, or click on the Button Save Config. The following screen will appear, where he has to enter the configuration file name:
Once the System Admin accepts this screen, the configuration details will be saved in the file “abc.pvf”. Similarly, he has to create the Configuration for the mail server “Sify”. The files will be created in Tally.ERP 9 application folder, as shown in the following screenshot:
The admin can share these two files to the staff in HO and Branch Offices, and they should place the file in the respective Tally.ERP 9 application folders.
Loading Configurations
Gateway of Tally> F12: Configure> E-Mailing . The e-mail configuration screen will be displayed with the previously set configurations.
Now, the user at HO/Branch wants to load the configurations for the email server “abc”. He has to press Alt+L or click on the Button “Load Config”, and enter the file name, as shown in the figure:
Accept the screen. The Email Configuration Report will display the configuration details loaded from the file “abc”. Accept the configuration screen, and the settings will be applicable to all reports. Suppose the User now wants to mail the report Balance Sheet. He has to select ‘Balance sheet’ and press Alt + M. The following configuration report will appear:
Note that the configuration details are changed as per the selected configuration. Now, the user wants to change the email server as Sify. Go to Gateway of Tally> F12:Configure> E-Mailing . Press Alt + L . Enter the file name as Sify and press Enter . The email configuration screen will have new configurations loaded from the file Sify .
Similarly, we can save/load multiple configurations.
Solution Development
The steps followed to achieve Saving of Multiple Email Configurations are:
Declaring variables at ‘Report’ Level
Variables SVMailServerName, SVMailServer, SVMailFormat, SVMailUseSsl, etc., are declared at ‘Report’ Level. All these variables have the attribute Persistent set as YES at the Definition level.
[#Report : EMail Configuration]
Variable : SVMailServerName, SVMailServer, SVMailFormat, SVMailUseSsl
Variable : SVMailUseSSLOnStdPort, SVMailAuthUserName, SVExportFormat
Saving Configuration
A button is added to the Form, and the action will call a User Defined Function. In a User Defined Function, we are executing a report to accept a File Name from the user. We are persisting all the report scope variables in the specified file through the Action SAVE VARIABLE.
Loading Configurations
A button is added to the Form and on clicking it, the action will call a User Defined Function. In the User Defined Function, we are executing a report to accept the File name from the user. We are reloading the report scope variables from the file through the Action LOAD VARIABLE. Please refer to the following code snippet for Save and Load configurations.
[Function : TSPL Smp SaveLoadVar]
Parameter : IsSaveVar : Logical : Yes
Variable : ConfigNamewithExt : String : Yes
00 : EXECUTE : TSPL Smp SaveLoadConfig
;; Correcting the file name entered with or without extension by the user
06 : IF : ##SaveLoadConfigName CONTAINS “.Pvf”
10 : SET : ConfigNamewithExt : ##SaveLoadConfigName
20 : ELSE
30 : SET : ConfigNamewithExt : ##SaveLoadConfigName + “.pvf”
40 : ENDIF
;; Saving or Loading the variables based on parameter value
50 : IF : NOT $$IsEmpty : ##SaveLoadConfigName
60 : IF : ##IsSaveVar
70 : SAVE VARIABLE : ##ConfigNamewithExt
80 : ELSE
90 : LOAD VARIABLE : ##ConfigNamewithExt
100 : ENDIF
110 : ENDIF
The corresponding field values need to reflect the values of the variables loaded from the file. This is handled by using the following code:
Local : Field : DSPMailServer : Set as : If #DSPMailServerName Contains $$SysName:UserDefined Then ##SVMailServer +
Else If #DSPMailServerName NOT Contains $$SysName:UserDefined Then $$GetMailServerAddr:#DSPMailServerName +
Else ##SVMailServer
Local : Field : DSPMailServerName : Set As : ##SVMailServerName
Local : Field : DSPMailFormat : Set As : ##SVMailFormat
Local : Field : DSPMailUseSsl : Set As : ##SVMailUseSsl
Local : Field : DSPMailUseSSLOnStdPort : Set As : ##SVMailUseSSLOnStdPort
Local : Field : DSPMailAuthUserName : Set As : ##SVMailAuthUserName
Local : Field : DSPFinalExportFormat : Set As : ##SVExportFormat
Also, if the field values are changed, the Report level variables need to be modified with those values. This is handled using the following code:
Local : Field : DSP MailServerName : Modifies : SVMailServerName : Yes
Local : Field : DSP MailServer : Modifies : SVMailServer : Yes
Local : Field : DSP MailFormat : Modifies : SVMailFormat : Yes
Local : Field : DSP MailUseSsl : Modifies : SVMailUseSsl : Yes
Local : Field : DSP MailUseSSLOnStdPort : Modifies : SVMailUseSSLOnStdPort : Yes
Local : Field : DSP MailAuthUserName : Modifies : SVMailAuthUserName : Yes
Local : Field : DSP FinalExportFormat : Modifies : SVExportFormat : Yes
On accepting the Form email configuration, we are calling a User Defined Function to set the System Variable values. Thus, the changed configuration details will be available for all the reports. Please refer to the following Code Snippet:
[Function: TSPL Smp Update System Variables]
10 : SET : ().SVMailServerName : ##SVMailServerName
20 : SET : ().SVMailServer : ##SVMailServer
30 : SET : ().SVMailFormat : ##SVMailFormat
40 : SET : ().SVMailUseSsl : ##SVMailUseSsl
50 : SET : ().SVMailUseSSLOnStdPort : ##SVMailUseSSLOnStdPort
60 : SET : ().SVMailAuthUserName : ##SVMailAuthUserName
70 : SET : ().SVExportFormat : ##SVExportFormat
Event Framework Enhancements
This is a path-breaking enhancement in Tally which will enable scheduled execution of any Action. This has been supported with the introduction of a System Event called Timer. We can have a set of timer events of specified durations and trigger an Action on the same. For example, if we require Synchronization to be triggered at every one hour, we can define a Timer event which triggers the action ‘Sync’. Actions for Starting and Stopping the timer have been provided.
Timer Event
As we are already aware, Events like System Start , System End , Load Company , Close Company , On Form Accept , and so on, introduced earlier as a part of the Event Framework, require user intervention. Automated events which can be used to take timely backups, display automated messages, etc., were not possible earlier. With the breakthrough introduction of Timer Event, performing Timer based automated events is possible now. System Event Timer has been introduced to perform the required set of operations automatically at periodic intervals.
Syntax
[System : Event]
<Timer Name> : TIMER : <Condition> : <Action> : <Action Parameters>
Where,
<Timer Name> is the user defined name for the timer event.
<TIMER> keyword indicates that it is a Time-based event.
<ConditionExpr> should return a logical value.
<ActionKeyword> is any one of the actions.
<Action Parameters> is nothing but the parameters of the action specified.
We can have multiple Event Handlers with unique names which can invoke specific Actions at different intervals. In order to specify the interval for the various Timers and to begin and end the Timers, the associated Actions introduced are ‘Start Timer’ and ‘Stop Timer’.
Actions – Start Timer and Stop Timer
Action – START TIMER
It starts the specified timer and accepts the Timer Name and Duration in seconds as the action parameters.
Syntax
START TIMER : <Timer Name> : Duration in seconds
Where,
<Timer Name> is the user defined name for the timer event.
Action – STOP TIMER
This action stops the specified timer, and it accepts the Timer Name as its parameter.
Syntax
STOP TIMER : <Timer Name>
Where,
<Timer Name> is the user defined name for the timer event.
Following is an example of scheduling automatic backups every hour:
Example
[System : Event]
;; Setting up timer event to call a function
Auto Backup : TIMER : TRUE : CALL : Take Backup Function
;; Starting the Timer when Tally Application Starts
Schedule Backup : System Start : TRUE : START TIMER : Auto Backup : 3600
;; Adding Keys to ‘Company Info’ Menu
[#Menu : Company Info.]
Add : Keys : Stop Backup Timer
;; Declaring a Key to Stop the Timer
[Key : Stop Backup Timer]
Key : Alt + S
Action : Stop Timer : Auto Backup
Title : “Stop Backup”
In this example, following is done:
- Auto Backup, a Timer event is declared under System Event to invoke the function
- Take Backup function at periodic intervals, as specified within the action Start Timer .
- Schedule Backup, a System Start event is declared under System Event to Start the above Timer ‘Auto Backup’ and execute the specified action every 3600 Seconds, i.e., every hour.
- A corresponding Key to Stop the Timer is associated to Menu Company Info, which is defined to Stop the Timer. User can stop the timer if he chooses not to continue taking automatic backups any further.
Timer events can be very useful in many cases like displaying Exception Reports , Negative Balances intimation, Inventory Status below Minimum or Reorder Level, Outstanding Reminders , Auto Sync at regular intervals, and many more.
Release 3.0
Persisting Variables at System Scope in a User Specified File
As announced in Release 2.0, we are aware that the variables at the Report scope can be persisted in a user specified file using the action SAVE VARIABLE. This can be re-loaded as required using the action LOAD VARIABLE.
The latest enhancements in variable persistence allow the user to persist and re-load the variables at System Scope (in a User Specified File) as well.
Action – SAVE VARIABLE
The action SAVE VARIABLE, which is used to persist the Report Scope Variables in a user specified file, now allows us to persist the System Scope Variables also. Syntax of this action remains the same. The desired behaviour is achieved with changes in variable list specification.
Syntax
SAVE VARIABLE : <FileName> [:<Variable List>]
Where,
<File Name> is the name of the file in which the report scope/ system scope variables are persisted. The extension .PVF will be taken by default, if the file extension is not specified.
<Variable List> is the comma-separated list of variables that need to be saved in the file.
Variable List specification changes
- Now ‘*’ can also be used to specify the variable list, which means all at ‘current scope’.
- The current scope can either be ‘System’ or ‘Report’.
- Specifying ‘*’ will ignore the ‘Persist’ flag and save all the variables in the scope, irrespective of “Persist: Yes” at the ‘Variable’ definition level.
- If Variable list is not provided, it will persist all the variables which are set as “Persist: Yes” at the Variable definition level.
- Dotted notation syntax is also supported in the variable list specification for scope specification.
However, this cannot be used for SUB levels. It can be used only for accessing parent scope variables.
- Single Dot “.” refers to current scope, Double Dot “ . .” to parent scope, Triple Dot “ . . . ” to grandparent scope, and so on.
- “ (). ” refers to the System Scope.
Action – LOAD VARIABLE
The action LOAD VARIABLE , which is used to load the Report Scope Variables in a user-specified file, now allows us to load the System Scope Variables also. Syntax of this action remains the same. The desired behaviour is achieved with changes in variable list specification.
Syntax
LOAD VARIABLE : <File Name> [:<Variable List>]
Where,
<File Name> is the name of the file in which the report scope/ system scope variables are persisted. Specifying file extension is mandatory while loading variable values.
<Variable List> is the comma-separated list of variables that need to be loaded from the file.
Variable List specification changes:
- While loading, ‘ * ’ is not relevant and will be ignored.
- While loading, ‘Persist’ flag of the variable is ignored. It is assumed that the variable must have a persist flag OR it is saved forcefully and hence to be loaded.
Example:1
There is a requirement to persist values of all system scope variables in a user specified file and load the values from the file whenever required. Refer to the following code snippet:
[#Menu : Gateway of Tally]
Add : Button : SLSystemScopeSave, SLSystemScopeLoad
;;Buttons SLSystemScopeSave & SLSystemScopeLoad are added at the Gateway of Tally Menu to execute the actions SAVEVARIABLE & LOADVARIABLE.
[Button : SLSystemScopeSave]
Key : Alt + F
Action : SAVE VARIABLE : SLSystemScope.pvf : *
Title : “Save Sys Var”
Values of all system scopevariables will be persisted in the file SLSystemScope.pvf on execution of the action Save VARIABLE.
[Button : SLSystemScopeLoad]
Key : Alt + L
Action : LOAD VARIABLE : SLSystemScope.pvf
Title : “Load Sys Var”
Values of all system scope variables will be loaded from the file SLSystemScope.pvf on execution of the action LOAD VARIABLE.
Example:2
There is a requirement to persist values of all system scope variables which are set as “Persist : Yes” at variable definition level in a user specified file, and load the values from the file whenever required. Refer to the following code snippet:
[#Menu : Gateway of Tally]
Add : Button : SLSystemScopeSave, SLSystemScopeLoad
Buttons SLSystemScopeSave & SLSystemScopeLoad are added at the Gateway of Tally Menu to execute the actions SAVE VARIABLE & LOAD VARIABLE .
[Button : SLSystem ScopeSave]
Key : Alt + F
Action : SAVE VARIABLE : SLSystemScope.pvf
Title : “Save SysVar”
;; Values of all variables at system scope which are set “Persist : Yes” at variable definition level, will be persisted in the file SLSystem- Scope.pvf on execution of the action SAVE VARIABLE.
[Button : SLSystemScopeLoad]
Key : Alt + L
Action : LOAD VARIABLE : SLSystemScope.pvf
Title : “Load Sys Var”
;;Values of all variables will be loaded from the file SLSystemScope.pvf on execution of the action LOAD VARIABLE.
Example: 3
There is a requirement to persist the system scope variables SVSymbolInSign & SVInMillions in a user specified file, and load the values of these variables from the file whenever required. Refer to the following code snippet:
[#Menu : Gateway of Tally]
Add : Button : SLSystemScopeSave, SLSystemScopeLoad
Buttons SLSystemScopeSave & SLSystemScopeLoad are added at the Gateway of Tally Menu to execute the actions SAVE VARIABLE & LOAD VARIABLE.
[Button : SLSystemScopeSave]
Key : Alt+F
Action : SAVE VARIABLE : SLSystemScope.pvf : SVSymbolInSign, SVInMillions
Title : “Save Sys Var”
Values of the system Scope variables SVSymbol InSign & SVInMillions will be persisted in the file SLSystemScope.pvf on execution of the action Save VARIABLE.
[Button : SLSystemScopeLoad]
Key : Alt + L
Action : LOAD VARIABLE : SLSystemScope.pvf : SVSymbolInSign ,SVInMillions
Title : “Load Sys Var”
Values of the system scope variables SVSymbolInSign & SVInMillions will be loaded from the file SLSystemScope .pvf on execution of the action LOAD VARIABLE.
Example: 4
The following report is displayed in ‘Create’ mode from a menu item.
[Report : Smp SLReport]
Form : Smp SLForm
Variable : SaveLoadVar1, SaveLoadVar2
The variables SaveLoadVar1 & SaveLoadVar2 are declared at Report Scope.
[Form : Smp SLForm]
Parts : Form SubTitle, Smp SLPart
Button : Smp SaveVar, Smp LoadVar
Buttons SmpSaveVar & SmpLoadVar are added at ‘Form’ Level to execute the actions SAVE VARIABLE & LOAD VARIABLE.
Let us look into the following scenarios to persist and load System Scope as well as Report Scope Variable values:
- Persist & Load all Report Scope Variables & a specific System Scope Variable
[Button : Smp SaveVar]
Key : Alt + S
Action : SAVE VARIABLE : SLReportCfg.pvf: *,().SVInMillions
Title : “Save Variable”
;; Values of all variables declared at report scope and the value of system scope variable SVInMillions will be persisted in the file SLReportCfg.pvf on execution of the action SAVE VARIABLE. (The variable SVInMillions is prefixed with (). to denote the same as System Scope Variable).
[Button : Smp LoadVar]
Key : Alt + L
Action : LOAD VARIABLE : S LReportCfg.pvf : *,(). SVInMillions
Title : “Load Variable”
Variable list specification * will be ignored. Values of all report scope variables and the value of system scope variable SVInMillions will be loaded from the file SLReportCfg.pvf on execution of the action LOAD VARIABLE.
- Persist and Load a specific Report Scope variable & a specific Syst e m Scope variable
[Button : Smp SaveVar]
Key : Alt + S
Action : SAVE VARIABLE: SLReport Cfg.pvf : SaveLoadVar1 ,().SVInMillions
Title : “Save Variable”
;;Value of Report scope variable SaveLoadVar1 and value of system scope variable SVInMillions will be persisted in the file SLRe- portCfg.pvf on execution of the action SAVE VARIABLE.
[Button : Smp LoadVar]
Key : Alt + L
Action : LOAD VARIABLE : SLReportCfg.pvf : SaveLoadVar1, ().SVInMillions
Title : “Load Variable”
;;Value of Report scope variable SaveLoadVar1 and value of system scope variable SVInMillions will be loaded from the file SLReportCfg.pvf on execution of the action LOAD VARIABLE.
New Events Introduced
As a part of the Language enhancements, in recent past, there have been significant enhancements as a part of the Event Framework. Before this release, events introduced were mostly related to handling the application start up and close, and company loading and unloading. The Object specific events were mainly focused around trapping events while rendering the data on the screen, and printing.
In this Release, events have been introduced to handle user specific requirements on data manipulation during Export and Import of data. With the introduction of the Events Start Import, Import Object and End Import, the programmers have got complete control to manipulate the data prior to importing the same into the company. This can be useful in scenarios like Inter-Branch data transfers; where Delivery Note in a branch gets transformed into Receipt Note in the other, Sales transaction in a Branch gets transformed into Purchase transaction in the other, and so on. Also, an action Import Object has been introduced to begin the Import process.
While exporting Full objects to XML and SDF formats; with the introduction of Export Events Before Export, Export Object and After Export, the user will be able to trap these events and get access to the object being exported, which can be altered as required before export. This can be useful in scenarios like changing required information during export, not displaying price/ amount of the stock item while synchronizing Delivery Note to the branch offices, creating a consolidated sales entry from all the sales transactions of the day, etc.
Import Events
The following events can be used within Import File Definition:
Event – Start Import
Syntax
On : Start Import : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event Start Import executes the actions before beginning the import process. At this stage, the data objects will not be available, since it is prior to gathering the data from the file. This event can be used to communicate any messages to the user like starting the import process, and so on.
Event – Import Object
Syntax
On : Import Object : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition returns TRUE, event Import Object executes the actions after gathering the Objects from File, before importing the same in the current company. At this stage, data objects are available, since it is posted gathering the data from a file. This event is useful to manipulate & transform data from one form to another, i.e., from Receipt Note to Delivery Note, etc.
Syntax
On: Import Object: <Logical Condition> : Import Object
If the Event ‘On Import Object’ is used, it overrides the default Import Object behaviour, as a result of which, we need to explicitly specify to begin importing the objects. After performing the necessary actions prior to importing the objects, the Action Import Object must be specified to instruct the system to continue the import process.
Event – End Import
Syntax
On : End Import : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE , the Event End Import executes the actions after importing the objects. At this stage, the data objects will not be available, since it is posted importing the objects within the current company. This event can be used to communicate any messages to the user like ‘ending the import process’, ‘Import Successful’, and so on.
Example
[#Import File : Vouchers]
On : Start Import : Yes : Call : Start Import
On : Import Object : Yes : Call : Change Values
On : Import Object : Yes : Import Object
On : End Import : Yes : Call : End Import
[Function : Start Import]
00 : MSGBOX : “Status” : “Starting Import Process”
[Function : Change Values]
00 : SET VALUE : Narration : $Narration + “ – Updated by Import Object Event”
10 : SET TARGET : LedgerEntries[1]
20 : SET VALUE : LedgerName : “Branch Ledger”
[Function : End Import]
00 : MSGBOX : “Status” : “Imported data successfully”
In this example, before importing the data, Narration Method is being altered and the first Ledger Name is being altered to Branch Ledger. Before starting and after ending the import process, appropriate messages are being displayed to the user.
Export Events
The following events can be used within Form definition:
Event – Before Import
Syntax
On : Before Export : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event Before Export executes the action before beginning the export. This event can be used to communicate any message to the user.
Event – Export Object
Syntax
On : Export Object : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event Export Object executes the action before the object is exported. The user will get the object being exported, which can be altered as required before export. The form level Export Object is used to get an access to the object associated at the Report Level and manipulate the same before exporting.
Syntax
On : After Export : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event After Export executes the action at the end of Form Export. This event can be used to communicate any message to the user.
The following events can be used within Line Definition:
Event – Export Object in Line Definition
Syntax
On : Export Object : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition returns TRUE, the Event Export Object executes the action before every object is exported. The line-level ‘Export Object’ is used to get access to each object associated at the line level and manipulate the same before exporting.
Example
[Form : ExpEvtForm]
On : Before Export : Yes : Call : Export Start
On : After Export : Yes : Call : Export End
Part : ExpEvtPart
Button : Export Button
Full Object : Yes
[Part : ExpEvtPart]
Line : ExpEvtLine
Repeat : ExpEvtLine : ExpLedger
Scroll : Vertical
[Line : ExpEvtLine]
On : Export Object : Yes : Call : ExportObject:$$Line
Fields : ExpEvtFld1, ExpEvtFld2
Full Object : Yes
[Collection : ExpLedger]
Type : Ledger
Fetch : Name, Parent
[Function : ExportStart]
00 : MSGBOX : “Status” : “Starting Export”
[Function : ExportObject]
Parameter : LineNo : Number
01 : INSERT COLLECTION OBJECT : Name
02 : SET VALUE : Name : “Led” + “-” + $name+“-” + “00” + $$String :##LineNo
[Function : ExportEnd]
00 : MSGBOX : “Status ” : “Ending Export”
In this example, the line is repeated over the Collection ExpLedger which is of type Ledger. The event Export Object at the line level will be triggered before the exporting of every ledger object. The function “Export Object”, which is called on the occurrence of the event, inserts a new object for the collection “Name” and the method Name (alias name) will be set with the new value by concatenating the strings “Led”, Name of the ledger and the line no. prefixed with “00”.
Before starting and after ending the export, appropriate messages are being displayed to the user through the events ‘Before Export’ and ‘After Export’ at ‘Form’ Level.
Release 3.6
Variable – SVPrintOrientation
Variable SVPrintOrientation has been introduced to set the required Printer Orientation, that is, Portrait or Landscape, within a Report. It is recommended to declare a local variable within the function or report and set the variable value, to avoid the system Printer Configuration changes to be effected globally.
This is useful where a Report needs to printed in a different orientation, e.g., Landscape. For e.g., if one needs to print the cheques in ‘Landscape’ mode and other reports in ‘Portrait’ mode, then there is no need to keep switching the printer settings from Portrait to Landscape, and vice versa, based on the report getting printed. For Cheque Printing Report, one can default Landscape Orientation.
Example
[#Report : Balance Sheet]
;; Local Variable Declaration
Variable : SVPrintOrientation : String
Set : SVPrintOrientation : “Landscape”
Since the variable is locally declared and updated within the Report Balance Sheet, the same will not affect the global printer settings.
Release 4.5
Action – DisconnectUser
This action is used to disconnect the users from companies that are accessed from Tally.Server9. It will display a warning message to the clients to close the company within 2 minutes, before forcing a close.
Syntax
DisconnectUser : <Tally Server Name> : <Company Name> : <User Name>
Where,
<Tally Server Name> is the name of the Tally.Server9, from which the companies are being accessed.
<Company Name> is the name of the company to be disconnected. ‘*’ can be used to specify all companies.
<User Name> is the name of the user to be disconnected from the company specified. ‘*’ can be used to specify all the users across companies.
Example
Action : DisconnectUser : “HoServer” : * : “abc@abc.com”
Action – ForceDisconnectUser
It is used to forcefully disconnect users from companies that are accessed from Tally.Server 9.
Syntax
ForceDisconnectUser : <TallyServer Name> : <Company Name> : <User Name>
Where,
<Tally Server Name> is the name of the Tally.Server 9 from which the companies are being accessed.
<Company Name> is the name of the company to be disconnected. ‘*’ can be used to indicate ‘all companies’.
<User Name> is the name of the user to be disconnected from the company specified. ‘*’ can be used to indicate ‘all users across companies’.
Example
Action : ForceDisconnectUser : “HoServer” : * : “abc@abc.com”
Action – StartService
This action is used to start the specified service.
Syntax
StartService : <Service Name>
Where,
<Service Name> can be any expression which evaluates to the name of the service.
Example
Action : Start Service : “Tally.Server 9 – 1”
Action – StopService
This action is used to stop the specified service.
Syntax
StopService : <Service Name>
Where,
<Service Name> can be any expression which evaluates to the name of the service.
Example
Action : Stop Service : “Tally.Server 9 – 1”
Action – WriteINI
This action is used to Add/Alter the value of any parameter in the specified INI file.
Syntax
WriteINI : <PathFileName> : <SectionName> : <Parameter> : [<Value> : [:<Index>]]
Where,
<PathFile Name> is the path and filename of the INI file
<Section Name> is the section name in the INI file
<Parameter> is the name of the parameter whose value is to be set in the INI.
<Value> is the value to be set for the given parameter. In the absence of any value, the existing value will be removed.
<Index> is an optional parameter. It can be used when multiple values are accepted for the same parameter. In the absence of the index parameter, the value of the last index will be updated.
Example
Action : WriteINI : “C:\Tally.ERP9\tally.ini” : ”TALLY” : ”UserTDL” : ”Yes”