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:

1. Action List
2. ActionEx
3. 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:

1. Report Level       – commonly referred to as Local Variables 
2. System Level       – commonly referred to as Global Variables.
3. 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:

1. 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.
2. 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

1. Adding an element to Compound List Variable CLV Emp with a Key.

LIST ADD : CLVEmp : “E001”

2. 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.

3. 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.

4. 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 con­sidered 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:

1. Auto Backup, a Timer event is declared under System Event to invoke the function
2. Take Backup function at periodic intervals, as specified within the action Start Timer .
3. 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.
4. 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:

1. 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.

2. 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”