Explore Categories

 

Actions in TDL

TDL is an event-driven language. Events can be triggered through a Keyboard shortcut or a Mouse click. In an event, some predefined actions get executed. For example:

  • The Ctrl+A key pressed from a voucher, it accepts the entry screen.
  • Clicking on the F1 Button from the Gateway of Tally menu results in the pop up of the Company Selection screen.

Actions are activators of a specific task with a definite result. An action always originates from a User Interface Object like Menu, Form, Line or Field.

Release 6 enhancement – Do If

Watch the below video to know about basic Actions in TDL.

Watch the below videos to know about Action Attributes and Event Framework.

Categories of Actions

Actions can be classified into two broad categories, viz

  • Global Actions
  • Object Specific Actions

Figure_7.1_Action_Categorization.jpg

Global Actions are not specific to any User Interface Object. For example, Display, Create, Execute, Alter, etc., are Global Actions. They perform the action specified, irrespective of the UI Object. Global Actions are performed on a Report or a Menu.

Object Specific Actions are actions which can act only upon specific UI Objects. For example, ‘Line Down’ is a Part-Specific Action, since Part owns multiple lines and an individual Line cannot move the current focus to the subsequent line. Only the Part can move the focus to the subsequent line. Object Specific Actions are performed on relevant User Interface Objects.

Global Actions

Object Specific Actions

Global Actions are not specific to any User Interface Object

These Actions are specific to a User Interface Object

Can be originated by a Menu, Button/Key or a Field

Can be originated by a Menu, Form, Line or a Field

Performed on a Report or a Menu

Performed on the relevant Interface Object

Example: Create, Display, Alter, Print, Print Report, Modify Object, Display Collection, etc.

Example: Line Up, Line Down, Explode (‘Line’ Object), Form Accept, Form Reject (‘Form’ Object), etc.

Action Association

Actions can be associated at various levels.

Action Association at Menu Definition

Action association at Menu definition is done through the Menu Item. Every Menu Item except Quit is associated with an Action. If an Item is added without any action, then the default action associated is to exit from the current Menu.

Syntax

[Menu : <Menu Name>]

Add : Key Item : [Position] : <Display Item> : <Unique Key> :<Action Keyword> : <Action Parameter>

Where,

<Action Keyword> can be any Global Action.

<Action Parameter> is decided by the Action Keyword. If the Action Keyword is Menu, then the Action Parameter necessarily has to be a Menu Name, else it has to be a Report Name.

Example:

[Menu: Commonly Used Reports]

Add : Key Item : Trial Balance : T : Display : Trial Balance

Add : Key Item : At Beginning : Outstandings : O : Menu : Outstandings

In this example, a Menu Commonly Used Reports is defined with 2 Items, viz.,

  1.  An Item Trial Balance is added displaying the default report Trial Balance. Here, the action is display, so the Action Value has to be a Report Name.
  2. An Item Outstandings is added at the beginning to activate another Menu Outstandings. The action here is Menu, so the Action Value required is a Menu Name.

Action Association at Button/Key Definition

Action Association at Button/Key definition is done using the attribute Action , followed by the Action Keyword, with the parameters, if required.

Syntax

[Button : <Button Name>]

Action : <Action Keyword> [: <Action Parameters>]

Where,

<Action Keyword> can be any Global or Object Specific Action.

<Action Parameters> is decided by the Action Keyword. If the Action Keyword is Menu, then the Action Parameter necessarily has to be a Menu Name, else it has to be a Report Name.

Example: Actions with Parameters

[Button : Outstandings]

Key : F5

Action: Menu: Outstandings

[Button : Trial Balance]

Key : F6

Action : Display : Trial Balance

Action Menu requires a Menu Name as Parameter and Actions Create, Display,  Alter, etc., require a Report Name.

Example: Actions without Parameters

[Button : Printing Button]

Action : Print Report

[Button : Exporting Button]

Action : Export Report

Action Parameters for the Actions Print Report and Export Report are not mandatory. If the Action Parameter is specified, then it prints the specified Report, else it prints the current Report.

Action Association at ‘Field’ Definition

Action Association at Field is done using Action Keyword with parameters and optional condition.

Syntax

[Field : <Field Name>]

<Action Keyword> : <Action Parameters>[: <Condition>]

Where,

<Action Keyword> can be both Global or Object Specific Actions.

<Action Parameters> can be the Value on which these Actions could be performed.

<Condition> is optional. It restricts the action to be performed only if the condition returns TRUE.

Example

[Field : My Trial Balance]

Display : Group : $$IsGroup

Display : Ledger : $$IsLedger

In this example, the Field Trial Balance has 2 statements, viz.,

  1. Displaying a Group, if the current object in context is a Group
  2. Displaying a Ledger, if the current object in context is a Ledger

 

Components of Actions

Any Action is always executed with respect to two contexts:

  • Originator
  • Executor

The Originator is one that originates the Action, viz., Menu, Form, Line, or Field, e.g., a Down Arrow Key pressed. The event is passed from the current Report to the associated Form, Parts, Lines, or Fields. Keys could be associated in Menu, Form, Line or Field. If the activated Key is found in Form, it searches further for Line Association and then continues till Field. The Lowest Level Key Association gets the highest precedence. If the Key is associated at Form as well as Field, the Key Association at Field Level gets executed. In this case, the Field is the Originator.

The Executer is one on which the action is executed. For example, Form Accept Key, though attached at Field Level, is a Form Action. Hence, Form is the executer of the action. In case of execution, it searches from Report to the Field for the action to be executed. Line Down is a Part Level Action. Though associated at the Form, it will be executed by the Part to move the current focus to the subsequent line. Hence, Part is an executer of the Action Line Down.

Originator

Executer

The Originator initiates the action by associating the Key or a Button

The Executer executes the action associated with the Key or Button, initiated by originator

Global Actions can be originated by Menu, Button/ Key or a Field, and Object Specific Actions by a Menu, Form, Line or a Field

Global Actions are executed by the originator object. However, Object Specific Actions can be executed by Objects other than originator

The sequence followed to gather all Keys originating within a Report is Top to Bottom, i.e., from Report to Field definition. The lowest in the hierarchy gets highest precedence, e.g., if the same key is associated at both Form and Field definitions, the Key at Field Definition is considered for execution.

The sequence followed to consume the Keys originated is from Bottom to Top, i.e., from a Field to a Report Definition. In other words, the lowest in the hierarchy gets the highest preference, e.g., if the same key is relevant for both Part and Line definitions, the Key will be executed in context of the Line Definition.

Example 1

[Key: Create Ledger]

Key : Alt + C

Action : Create : Ledger

[Field: CST Supplier Ledger]

Key : Create Ledger

Associating the Key with the Field, Field is the originator as well as exe­cuter here.

Example 2

[Key: Part Display PgUp]

Key : PgUp

Action : Part PgUp

[System: Form Keys]

Keys : Part Display PgUp

Key Part Display PgUp is originated by Form, but its executer is the Part.

Global Actions

As discussed, Global Actions are Actions that are not specific to any UI Object. Global Action provides an indication to the TDL Interpreter as to which specific task should be executed to fulfill the user requirements. Global Actions are mainly performed on three principal definition types, namely Report, Collection, and Menu. Some frequently used Global Actions are discussed below:

Action – Menu

The Action ‘Menu’ acts only on the ‘Menu’ Definition, and vice versa. The value of the ‘Menu’ Action must be a Menu Name. This Menu has to be further defined to list the Items displaying another Menu or a Report. A Menu Definition continues until all the Items are used to display Reports, and there are no further Menu Actions assigned to the final Menu Items.

Example: 1

;; The following code demonstrates the usage of the Action ‘Menu’, along with further Menu Definitions

[#Menu : Gateway of Tally]

Add : Key Item : Sample Item : F : Menu : Sample Final Accounts

;; Menu Definition for the Menu to be displayed when the above Item is activated

[Menu : Sample Final Accounts]

Add : Key Item : Trial Balance : T : Display : Trial Balance

Add : Key Item : Profit & Loss : P : Display : Profit and Loss

Add : Key Item : Balance Sheet : B : Display : Balance Sheet

In this example, the Default Menu Gateway of Tally is altered to add a new Item Sample Item, with the ‘Menu’ action displaying the Sample Final Accounts Sub Menu. Sub Menu Sample Final Accounts will display all components of Final Accounts, i.e.,

  • Trial Balance
  • Profit & Loss
  • Balance Sheet

All the Items here use the ‘Display’ Action. Hence, no further Menu Definition is required.

Note : As seen in the previous topic Objects, Methods and Collections, the action Display takes the Report Name as its parameter, and is used to display the reports, as is specified.

Example: 2

;; The following code demonstrates the usage of Menu and Display Actions and also the relevance of their association in Menu and

;; Reports (through Form)

;; Button Definition to activate a Menu

[Button : Final Accounts]

Key : F5

Action : Menu : Sample Final Accounts

/* Since the above Button activates a Menu, it can be acted only upon a Menu It cannot be associated to a Report */

[#Menu : Gateway of Tally]

Buttons : Final Accounts ;; attaching a button to the menu

[#Form : Group Summary]

Buttons : Final Accounts

;; Above is an incorrect association as Buttons triggering Menu Action cannot be attached to a Form.

;; Button Definition to Display a Report

[Button : Balance Sheet]

Key : F6

Action : Display : Balance Sheet

/* Since the above Button activates a Report, it can be associated to both a Menu and a Report */

[#Form : Group Summary]

Button : Balance Sheet ;; attaching a button to the report

[#Menu : Display Menu]

Button : Balance Sheet ;; attaching a button to the menu

In this example:

  • A new Button Final Accounts is added to activate a Menu Sample Final Accounts, which is attached to the default Menu ‘Gateway of Tally’.
  • The Button Final Accounts cannot be attached to a Report, since a Menu cannot be acted upon in a Report. In the example, the Button Final Accounts is attached to Form ‘Group Summary’, which is incorrect since the Menu cannot be called from a Report.
  • Another Button Balance Sheet is added to display Report Balance Sheet which is enabled in all Reports, using Form Group Summary, and also in the Menu Display Menu.
  • The Button Balance Sheet can be attached to a Report as well as to a Menu, since the Report can be acted upon by a Report as well as a Menu.

 

Action – Modify Object

This action alters the methods of an Object at any level in Object Hierarchy. It supports modifying multiple values of an Object by specifying a comma-separated list of Method: Value pairs.

Syntax

Action : Modify Object : <PrimaryObjectSpec>.<SubObjectPathSpec>. MethodName : Value>[,Method Name : <Value> , …] [,<SubObjectPathSpec>. MethodName : <Value>, …..]

The specifications given for < PrimaryObjectSpec >, < SubObjectPathSpec >, Method Name remain same as described in the New Method syntax section in the topic Objects and Collections .

A single Modify Object Action cannot modify methods of multiple primary Objects, but can modify multiple values of an Object.

Modify Object is allowed to have Primary Object Specification only once, i.e., for the first value. Further values permissible are optional in the Sub Object and Method Specification only.

From the second value onwards, Sub Object specification is optional. If Sub Object Specification is specified, the context is assumed to be the Primary Object specified for first value. In absence of sub-object specification, the previous value specification’s leaf object is considered as the context.

Example: 1

[Key : Alter My Object]

Key : Ctrl + Z

Action : Modify Object : (Ledger,”MyLedger”).BillAllocations [First, $Name=”MyBill”].OpeningBalance : 100,Address[Last].Address :”Bangalore”

The existing ledger My Ledger is being altered with new values for the Opening Balance for the existing bill and Address . The key Alter My Object can be attached to any Menu or Form.

Example: 2

[Key : Alter My Object]

Key : Ctrl + Z

Action : Modify Object :(Ledger,”MyLedger”).BillAllocations[1].OpeningBalance :1000,Name: ”My New Bill”,+

..Address[First].Address :”Hongasandra Bangalore”, Opening Balance:5000

The existing ledger My Ledger is being altered with new values for the Opening Balance applicable on the existing bill, Opening Balance of the ledger, and the first line of the Address . The key Alter My Object can be attached to any Menu or Form.

A button bearing the action Modify Object, if associated at Menu definition, requires a primary object specification as Menu, which is not in the context of any Data Object.

Example:

[#Menu : Gateway of Tally]

Add : Button : Alter My Object

The following points should be considered while associating a key with the action Modify Object:

  • Since the Menu does not have any Info Objects in context, specifying Primary Object becomes mandatory.
  • Since Menu cannot work on scopes like Selected, Unselected, and so on, the scopes specified are ignored.
  • Any formula specified in the value and evaluated, assumes Menu Object as requestor.
  • Even Method values pertaining to Company Objects can be modified.
  • A button can be added in the Menu to specify the action Modify Object at the Menu level.

Action – Browse URL

The action Browse URL is used to provide a link to any web browser, with a URL formula passed as a parameter.

Syntax

Action : Browse URL : <URL Formula>

Example: Field acting as a hyperlink

[Key : Execute Hyperlink]

Key : Left Click

Action : Browse URL : “www.tallysolutions.com”

[Field : Hyperlink Company]

Color : Blue Border : Thin Bottom

Key : Execute Hyperlink

Set as : “Tally Solutions Pvt. Ltd”

Local : Key : Execute Hyperlink : Action : Browse URL: http://www.tally.co.in

Actions – Create and Alter

The actions Create and Alter act only upon the report definition. These actions activate the report in Create or Alter mode. In other words, the report is started in the Edit mode. In the case of Create action, the user enters the report in order to add values, whereas in the case of Alter, the user enters the report to modify the already created values.

These actions help the user to key in the relevant values. The values thus entered may or may not be stored. The treatment of values depends on need. The values thus entered in the Report by the user, if required to be retained, can be stored as a part of Tally Database or Configuration File.

  • As discussed in the topic on Variables, all the persistent variable values can be stored in a Configuration File tallysav.TSF for subsequent sessions.
  • The values entered in the Report can also be stored as a part of the Tally database.

To store the values as a part of Tally database, the Report must be associated with a Data Object. For example, Group, Ledger, Voucher, etc., are some of the Data objects available in Tally.

For instance, in order to design an interface to create a Ledger:

  • The Object ‘Ledger’ must be associated to the Report using Report Attribute ‘Object’
  • Values entered by the user in the Fields within the Report must be stored in relevant Methods using Field Attribute ‘Storage’

Example:

/* The following code demonstrates the usage of Action ‘Create’ and Attribute ‘Storage’ at Field Definition to store the values entered within the relevant Object associated at Report Level*/

[#Menu : Gateway of Tally]

Add : Key Item : Ledger Creation : L : Create : Create Ledger

[Report : Create Ledger]

Form : Create Ledger Object : Ledger

;; Object Association done at Report Level

[Form : Create Ledger]

Parts : Create Ledger

[Part : Create Ledger]

Lines : Store LedgerName, Store LedgerGroup

[Line : Store LedgerName]

Fields : Short Prompt, Name Field

Local : Field : Short Prompt : Info : “Name :”

Local : Field : Name Field : Storage : Name

/* Storing value entered by user in Internal Method Name available within Object associated at Report*/

[Line : Store LedgerGroup]

Fields : Short Prompt, Name Field

Local : Field : Short Prompt : Info : “Under :”

Local : Field : Name Field : Storage : Parent

Local : Field : Name Field : Table : Group

/* Similarly, Parent Method is stored with the user entered value which is considered as the Group of the Ledger created. Also Group is a default Table/Collection to display all the default as well as the user defined Groups. Field Attribute Table helps to restrict the user input to a predefined list*/.

In this example:

  • The default menu Gateway of Tally has been altered to add a new Item Ledger Creation, which allows the user to create a Ledger.
  • Report Create Ledger associates the Object Ledger to it, which indicates that the Report is meant for creating an instance of the Object ‘Ledger’.
  • Name and Group of the Ledger are stored in Internal Methods Name and Parent.

Example:

;; The following code demonstrates the usage of ‘Alter’ Action at Button

[Button : My Reco Button]

;; Button meant to do Bank Reconciliation

Key : Alt + F5

Action : Alter : Bank Recon

;; ‘Alter’ Action to trigger Bank Recon Report in ‘Alter’ Mode

Title : “Reconcile”

;; Associating the Button to the Report

[Form : My Bank Vouchers]

Button : My Reco Button

In this example:

  • Button My Reco Button is defined with Alter action to alter the report Bank Recon on pressing the Alt + F5 key. It is used for entering dates in the report Bank Reconciliation.
  • The button My Reco Button is associated with the Form My Bank Voucher.

 

Example:

;; The following code demonstrates the usage of Alter Action at Field

[#Menu : Gateway of Tally]

Add : Key Item : Ledger Display : L : Display : My Ledger

[Report : My Ledger]

Form : My Ledger

[Form : My Ledger]

Parts : My Ledger Height : 100% Page Width : 100% Page

[Part : My Ledger]

Lines : My Ledger

Repeat : My Ledger: Ledger

;; Ledger is a default collection of Ledger Objects

Scroll : Vertical

[Line : My Ledger]

Fields : My Ledger

Key : Line Object Enter Alter, Line Click Object Enter Alter

;;The above default Keys act upon Line Definition and the action Alter Object is associated with the Keys, provided the current Report is in Display Mode

[Field : My Ledger]

Set As : $Name

Variable : Ledger Name

;;Variable ‘Ledger Name’ retains the Ledger selected by the user for the subsequent report

Alter : Create Ledger

;; ‘Alter’ Action is used to activate the Report in ‘Alter’ Mode

;; ‘Create Ledger’ is a user defined Report defined while Ledger Creation

In the example,

  • Two default keys are associated to a Line definition, that allows a selection of any of the lines, from the set of repeated lines.
  • Action associated with these keys is Alter object, which means that on hitting the key, the object associated with the current Line must be altered.
  • Mode: Display specified in the keys signifies that current report must be in Display mode.
  • Alter action used at the Field definition prompts the report from being activated on the current field, which must be in Alter mode.

 

Actions – Create Collection , Display Collection and Alter Collection

Action – Create Collection

A Menu Item can be used to create Objects in a Collection with the action Create Collection. This action is generally used for creation of Masters such as Groups, Ledgers, Stock Items, Voucher Types, etc. Create Collection fetches a report through the defined Collection. A report displayed through this action is displayed in Create mode.

Example:

;; The following code demonstrates the usage of ‘Create Collection’ action

[#Menu : Gateway of Tally]

Add : Key Item : Ledger : L : Create Collection : Ledger

;; where a Ledger is a predefined Collection in DefTDL

One can also use the action Create in place of Create Collection, to create Objects in a collection. The only difference is that Create explicitly calls a Report and Create Collection requires a collection. ‘Create Collection’ executes the same report through the defined Collection.

Action – Display Collection

A Menu Item or a Button can be used to display a popup of Object names in a Collection, which in turn, can trigger a Report. On choosing an Object from the popup, a report in Display mode is triggered by the action Display Collection. This action can be used for displaying the Masters or Repors pertaining to Groups, Ledgers, StockItems, etc.

Example:

;; The following code demonstrates the usage of ‘Display Collection’ Action

[#Menu : Gateway of Tally]

Add : Key Item : Ledger : L : Display Collection : Ledger

;; where Ledger is a predefined Collection in DefTDL.

Though the action name is Display Collection, Display is meant for the subsequent Report, which will be displayed on the selection of an Object. Here, the Report is in Display mode.

Action – Alter Collection

The action Alter Collection is similar to Display Collection , but it triggers the Report in Alter mode. This action is generally used to alter the masters such as Groups, Ledgers, Stock Items, Voucher Types, and so on.

Example:

;; The following code demonstrates the usage of ‘Alter Collection’ Action

[#Menu : Gateway of Tally]

Add : Key Item : Ledger : L : Alter Collection : Ledger

;; where Ledger is a predefined Collection in DefTDL

Though the action is Alter Collection, Alter is meant for the subsequent report, which will be displayed on the selection of an Object. Display Collection, Create Collection and Alter Collection routes the final report through a Collection. Let us understand some critical attributes required to achieve these actions.

Collection Attributes – Trigger, Variable and Report

The Collection attributes Trigger, Variable and Report support the actions Create Collection, Display Collection and Alter Collection, respectively.

[Collection : My Ledger]

Type : Ledger

Trigger : LedList Select

Report : Selected Ledger

Display Variable : Ledger Name

Attribute – Trigger

The Collection attribute Trigger is used to popup the Object names from a Collection. For example, a List of Items pop up when you choose the default menu item Stock Item.

Syntax

[Collection : <Collection Name>]

Trigger : < R eport Name>

< Report Name > is the interface used to display the Object names in a Collection.

Attribute – Report

The collection attribute Report displays a Report based on the Object selected. For example, Item Monthly Summary is a default report being displayed when you choose a particular stock item.

Syntax

[Collection : <Collection Name>]

Report : <Report Name>

where,

< Report Name > is the final report displayed, when an Object is selected from the Collection.

Attribute – Variable

The collection attribute Variable stores the name of the selected Object. This attribute is used with actions – Display Collection and Alter Collection.

Syntax

[Collection : <Collection Name>]

Variable : < Variable Name>

where,

< Variable Name > is the variable storing the Object name for the subsequent Report to be displayed.

Example

[Collection : Stock Items in Display Collection]

Type : Stock Item

Trigger : Stock Item Selection Interface

Report : Stock Item Final Report

Variable : Stock Item Name

Object Specific Actions

Some of the Object Specific actions are discussed in this section:

Menu Actions – Menu Up, Menu Down, Menu Reject

The actions Menu Up, Menu Down, Menu Reject, etc., act upon Menu. They are associated to all Menus (Default as well as User Defined TDL) through the declaration [System: Menu Keys].

Example

[Key : Menu Up]

Key : Up

Action : Menu Up

[Key : Menu Down]

Key : Down

Action : Menu Down

[Key : Menu Reject]

Key : Esc

Action : Menu Reject

[System : Menu Keys]

Key : Menu Down, Menu Up, Menu Reject

[System: Menu Keys] declares a list of Keys commonly required for a Menu. Since all common menu operations like Scroll Up, Scroll Down, Drill down, etc., are declared here, a new Menu added does not require these keys to be associated, as they are inherited from above declaration.

Form Actions – Form Accept, Form Reject, Form End

Actions Form Accept, Form Reject, Form End, etc., act upon Form. They are associated to all Forms (Default as well as User Defined TDL) through the declaration [ System: Form Keys ].

  • Action Form Accept saves the current Form.
  • Action Form Reject rejects the current Form, i.e., the current form is quit without saving.

Example

[Key : Form Accept]

Key : Ctrl + A

Action : Form Accept

Mode : Edit

[Key : Form Display Reject]

Key : Esc

Action : Form Reject

Mode : Display

[Key : Form End]

Key : Ctrl + End

Action : Form End

[System : Form Keys]

Key : Form Accept, Form Display Reject, Form End

[ System: Form Keys ] declares a list of keys commonly required for a Report. Since all common Form operations like Save Form, Reject Form, Form End, etc., are declared here, a new Form added does not require these keys to be associated, as they are inherited from above declaration.

Part Actions – Part Home, Part End, Part Pg Up

The actions Part Home, Part End, Part Pg Up, etc., act upon a Part. These keys are associated with all the Forms (Default TDL codes as well as User Defined TDL codes) through the declaration [ System: Form Keys ].

  • Action Part Home positions the cursor to the beginning of the current Part.
  • Action Part End positions the cursor to the end of the current Part.
  • Action Part PgUp is used to quickly scroll the page to view the previous page.

Example

[Key : Part DisplayHome]

Key : Home

Action : Part Home

Mode : Display

[Key : Part Display End]

Key : End

Action : Part End

Mode : Display

[Key : Part Display PgUp]

Key : PgUp

Action : Part PgUp

Mode : Display

[System : Form Keys]

Key : Part Display Home, Part Display End, Part Display PgUp

[ System: Form Keys ] declares a list of keys commonly required for a Part. Since all common Part operations like Part Home, Part End, Part PgUp, etc., are declared here, a new Part added does not require these keys to be associated, since they are inherited from the above declaration.

Line Actions – Explode, Display Object, Alter Object

Line Actions – Explode, Display Object, Alter Object, etc., act upon a Line.

  • Action Explode explodes a line further to display all the explode details specified in the Line attribute Explode.
  • Action Display Object is used to display the Object in context of the current line.
  • Action Alter Object is used to alter the Object in context of the current line.

Example

[Key : Line Explode]

Key : Shift + Enter

Action : Explode

[Key : Line Object Display]

Key : Enter

Action : Display Object

Mode : Display

[Key : Line Object Alter]

Key : Ctrl + Enter

Action : Alter Object

Mode : Display

[System : Form Keys]

Key : Line Explode

Key : Line Object Display, Line Object Alter

[ System: Form Keys ] declares a list of keys commonly required for a Line. Since all common Line operations like Explode, Display Object, Alter Object, etc., are declared here, a new Line added does not require these keys to be associated, as they are inherited from the above declaration.

Field Actions – Field Copy, Field Paste, Field Erase, Calculator

The actions Field Copy, Field Paste, Field Erase, Calculator, etc., act on Fields.

  • Action Field Copy copies the current field (Field where the cursor is positioned) contents in the OS clipboard, which will be available later.
  • Action Field Paste pastes the clipboard contents to the current Field.
  • Action Field Erase is used to erase the contents of the current Field at a stretch, without hitting the Backspace or Delete Key.
  • Action Calculator is used for Fields that require some computation, the result of which is to be returned to the Field. Fields taking Amounts/Numbers as value require this action.

Example:

[Key : Field Copy]

Key : Ctrl + Alt + C

Action : Field Copy

[Key : Field Paste]

Key : Ctrl + Alt + V

Action : Field Paste

[Key : Field Erase]

Key : Esc

Action : Field Erase

Mode : Edit

[Key : Calculator]

Key : Alt + C

Action : Calculator

Mode : Edit

[Field : NumDecimals Field]

Key : Calculator

[System : Form Keys]

Key : Field Erase

Key : Field Copy, Field Paste

[ System: Form Keys ] declares a list of Keys that are commonly required for any Field. Since all the common Field operations like Field Copy, Field Paste, Field Erase, etc., are declared here, a new Field added does not require these keys to be associated, since they are inherited from the above declaration. The Action ‘Calculator’ is not required for all the Fields; hence, it has not been declared in Form Keys usage List. It has been associated to the Fields where it is required. In the above example, NumDecimals Field is a numeric field that may require calculations. Therefore, the Calculator key, associating the action Calculator, is attached to the Field.

Action – Do If

The action Do If which was used only as procedural action has been enhanced to support conditional action execution in other definitions like Button. Do If is a system action and it executes the given action when the condition evaluates to True.

Syntax

Do If: <Condition>: <Action Keyword>[:<Action Parameters>]

Where,

<Condition> is any value or expression that can be evaluated to true or false.

<Action Keyword> can be any global or object-specific action except the function-specific actions.

<Action Parameters> are the list of parameters as required by the action specified, separated by a colon. Depending on the specified action keyword this parameter can be optional.

Example 1: Do If in function definition

[Function: MastersCount]

……..

001 : Do If: (##MasterType = “Group”):Increment : GroupCount

002 : Do If: (##MasterType = “Ledger”):Increment: LedgerCount

Example 2: Do If in button definition

[Button: CreateMaster]

Title : $$LocaleString:”Create Master”

Key: Alt+F4

ActionEx: Group : Do If:(##MasterType = “Group”) : Create : Group

ActionEx: Ledger: Do If:(##MasterType = “Ledger”): Create : Ledger

In this example, if the value of the variable MasterType is Group it opens the default group creation screen, otherwise it opens the ledger creation screen.

Prior to Do If, the conditional action execution was possible using Switch/Option in button definition. Using the action Do If, reduces the number of lines in the code.

Example: Conditional action using Option

[!Form: Contra Color]

Local: Button: Print Button: Option: Vch Print: $$InCreateMode

Local: Button: Print Button: Option: Vch Chq Print: $$InAlterMode

[!Button: Vch Print]

Action: Print Report

[!Button: Vch Chq Print]

Action : Call : Voucher Printing

Example: Conditional actions using ActionEx

[!Form: Contra Color]

Local: Button: Print Button: Add: ActionEx: CreateMode:Do If: $$InCreateMode:Print Report

Local: Button: Print Button: Add: ActionEx: AlterMode:Do If: $$InAlterMode:Call:Voucher Printing

 

Action Enhancements in Tally.ERP 9 Releases

Release 1.5

Dynamic Actions

A new capability has been introduced with respect to Action framework, where it is possible to specify the Action keyword and Action parameters as expressions. This allows the programmer to execute actions based on dynamic evaluation of parameters. The ‘Action’ keyword can as well be evaluated dynamically. Normally, this would be useful for specifying condition-based action specification in the menu, key/button, etc. In case of functions, as the function inherently supports condition-based actions via IF-ELSE, etc., this would be useful when one required to write a generic function, which takes a parameter and later passes that to an action (as its parameter), which does not allow expressions and expects a constant. This has been achieved with the introduction of a new keyword “Action”.

‘Action’ Keyword

The ‘Action’ keyword allows the programmer to execute actions based on dynamic evaluation of parameters. The syntax for specifying the same is as given below:

Syntax

Action : <Action Keyword Expression> : <Action Parameter Expression>

Where,

<Action> is the keyword Action to be used for Dynamic Actions usage.

<Action Keyword Expression> is an expression evaluating to an Action Keyword.

<Action Parameter Expression> is an expression evaluating to Action Parameters.

We can specify and initiate an Action from the following:

  • Menu Item
  • Key Definition
  • In a User Defined Function

At present, the capability is valid for:

  • Global Actions like Display, Alter, etc.
  • Global Actions inside User-Defined Functions

Example

Dynamic Actions in Key/Button Definition

[Button : Test Button]

Key : F6

Action : Action : Display : @@MyFor

;; The Button Test Button initiates a dynamic Action which takes the parameter as a formula.

[System : Formula]

MyFor : if ##SVCurrentCompany CONTAINS “ABC” Then “BalanceSheet” else “TrialBalance”

Note: Observe the usage of Action keyword twice in this example. The first usage is the attribute “Action” for ‘Key’ definition. The second is the keyword “Action” introduced specifically for executing Dynamic Actions.

Dynamic Actions in User Defined Functions

[Button : Test Button]

Key : F6

Action : Call : TestFunc : “Balance Sheet”

[Function : Test Func]

Parameter : Test Func : String

01 : Action : Display : ##TestFunc

;;The function Test Func executes a dynamic action, which takes Action parameter as the parameter passed to the function.

New Actions

Two new actions – LogObject and LogTarget have been introduced to log the object, its method and collection contents.

Action – Log Object

The action Log Object has been introduced as a Global action. It accepts a filename as the parameter. In this file, the context object, its method and collection are logged.

Syntax

Log Object [:<pathfilename> [:<Overwrite Flag>]]

Where,

<path/filename> is optional. It accepts the name of the file, along with the path in which the log is created. If no filename is specified, the contents of the object are logged in “TDLfunc.log” when logging is disabled, otherwise, it logs into the Calculator pane.

<Overwrite Flag> is used to specify whether the contents should be appended or overwritten. The default value is NO, which appends the content in the file. If set to YES, the file is overwritten.

Example

[Function : FuncLedExp]

       |

Object : Ledger

       |

10 : Log Object : LedgerObj.txt

Action – Log Target

The action Log Target is a function-specific action. It accepts a filename as a parameter. In this file, the log of the object, its method and collection are created for the target object.

Syntax

Log Target [:<pathfilename> [:<Overwrite Flag>]]

Where,

<path/filename> is optional. It accepts the name of the file along with the path in which the log is created. If no filename is specified, the contents of the object are logged in “TDLfunc.log” when logging is disabled, otherwise, it logs into the Calculator pane.

<Overwrite Flag> is used to specify whether the contents should be appended or overwritten. The default value is NO, which appends the content in the file. If set to YES, the file is overwritten.

Example

[Function : FuncLed Exp]

       |

05 : Set Target

        |

10 : Log Target : LedgerObj.txt

 

Release 1.6

Programmable Configuration for Actions – Print, Export, Mail, Upload

In Tally.ERP 9, the actions Print , Export , Mail and Upload depend upon various parameters like Printer Name, File Name, Email To, etc. Prior to execution of these actions, the relevant parameters are captured in a Configuration Report. These parameters are persisted as system variables, so that the next time, these can be considered as default settings.

There are situations when multiple reports are being printed or mass mailing is being done in a sequence. Subsequent to each Print or Email Action, if a configuration report is popped up for user inputs, this interrupts the flow, thereby requiring a dedicated person to monitor the process, which is time-consuming too. This issue has been addressed in the recent enhancements in Tally.ERP 9, where the configuration report can be suppressed by specifying a logical parameter. Also, the variables can be set prior to invoking the desired action. Before exploring the new enhancements, let us see the existing behaviour of the actions Print, Email, Export and Upload.

Existing behavior of Actions – Print, Export, Mail, Upload

Presently, in Tally.ERP 9, whenever any of these actions is invoked, a common Configuration report SVPrintConfiguration is displayed to accept the user inputs. The user provides the details in the configuration screen, based on the action being executed. The action gets executed based on the values provided in the configuration report.

The existing syntax of these actions was:

Syntax

<Action Name>: <Report Name>

Where,

<Action Name>can be any of Mail, Upload, Print or Export.

<Report Name>is the name of the Report.

For successful execution of these actions, along with the Report Name, additional action-specific parameters are also required. These action-specific parameters are passed by setting the values of variables through the configuration report – ‘SVPrintConfiguration’.

The default configuration report ‘SVPrintConfiguration‘ is invoked only when the Report specified does not contain the Print attribute in its own definition. The ‘Print’ attribute allows the user to specify his own configuration settings, whenever any of these Actions is invoked.

Example

Mail : Balance Sheet

The action Mail needs information regarding the To e-mail ID, From e-mail ID, CC e-mail ID, Email server name, etc., which are provided through the Configuration report.

For example, a report needs to be mailed to multiple e-mail IDs in one go. Currently, for every mail, the configuration screen is displayed, and every time, the user has to manually provide To email ID, From email ID, etc. So, whenever any of the above actions is executed, a configuration report is displayed, which requires user inputs. In some scenarios, this behaviour is not desirable. Configuration settings can be specified once, and the user should be able to use it multiple times.

The action syntax has been enhanced to avoid the display of configuration screen repeatedly.

Changes in the Actions for Programming Configurations

The global actions Print, Export, Mail and Upload have been enhanced to suppress the Configuration Screen. These actions now accept an additional logical parameter. Based on the value of the logical parameter, the configuration report is suppressed.

The new enhanced syntax of these actions is:

Syntax

<Action Name>: <Report Name>: <Logical Value>

Where,

<Action Name>can be any of Mail , Upload , Print or Export .

<Report Name>is name of the Report.

<Logical Value>can be TRUE, FALSE, YES or NO .

With the new syntax, it is possible to configure the values of the report only once and then mail it to the specified e-mail addresses, without repeated display of the configuration report.

Example

10 : MAIL : Ledger Outstandings : TRUE

As the Configuration Report is not displayed, the values of the mail action specific variables like ‘SVPrintFileName‘ , ‘SVOutputName‘ , and so on, must be specified for the successful execution of these actions.

The action MailEx is also used to mail the specified report to recipients. When you use the action MailEx, you can pre-configure the mailing information. It accepts only one parameter.

Following are the action-specific variables and their acceptable values:

The Configuration Variables – Action Specific

The action-specific Variables can be classified into four categories based on their usage.

Common Variables

SVOutputType – The value of this variable is one of the predefined button type keywords like Print Button, Export Button, Upload Button and Mail Button. The variables’ value is used by the functions $$InMailAction , $$InPrintAction , $$InUploadAction and $$InExportAction to determine the execution of the correct option in the form ‘SVPrintConfiguration’. For example, if the value of ‘SVOutputType’ is ‘Print Button’, then the optional form ‘SV PrintConfig’ in the report ‘SVPrintConfiguration’ is executed.

SVPrintFileName – This variable accepts the output location as value. The value of this variable is specific to each action. The usage of each action is explained in detail, along with the action.

SVExportFormat – The value of this variable is the name of the format to be used with the actions Mail, Upload and Export. The values are SDF, ASCII, HTML, EXCEL, XML, AnsiSDF, AnsiASCII, AnsiXML, AnsiHTML and AnsiExcel, which are set using $$SysName.

Example

01 : SET : SVExportFormat : $$SysName:Excel

SVExcelExportUpdateBook – This is a logical value and can be used only if the ‘Excel’ format is used. If the value is set to YES, then the existing file is overwritten; otherwise, it will ask for “Overwrite” confirmation.

SVBrowserWidth , SVBrowserHeight – These variables are used to set the width and height of the page when the format is HTML.

Variables Specific to Action – Print

As soon as the user executes a Print action, the following screen is displayed:

This screen captures the user inputs such as the “Printer Name”, “No. of Copies” to be printed, etc. The various action specific variables required by the ‘Print’ action are modified, based on the user inputs. Following variables are used by Print action:

SVPrintMode – This variable used by ‘Print’ action accepts the printing mode as the value. The Print mode can be ‘Neat’, ‘DMP’ or ‘Draft’, which are system names. The default mode is Neat mode.

SVPrintFileName – This variable is applicable for ‘Print’ action, only if ‘Print To File’ option is selected by the user while printing in DOT Matrix or Quick/Draft format. In this case, the variable ‘SVPrintFileName’  accepts filename using function $$MakeExportName, to add right extensions.

SVPrintToFile – This is a logical value which determines if the print output should be saved in a file. If the value is TRUE, the output is saved in the file specified in the variable ‘SVPrintFileName’. If the vale is FALSE, then the variable ‘SVPrinterName’ must contain a valid printer name.

SVPrinterName – It accepts a printer name as a value for the printing. The default value is taken from the system settings available in Control Panel for Printers and Faxes.

SVPreview – This is a logical variable and is applicable only for ‘Print’ action with ‘Neat’ mode format. If the value is set to YES, then the preview of the report is displayed. Otherwise, the report is printed, without displaying the preview.

SVPrintCopies – It is applicable only for ‘Print’ action. It accepts a number to print multiple copies.

SVPrePrinted – The variable is applicable only for ‘Print’ action, and it specifies whether pre-printed stationery or plain paper is to be used for printing.

SVPrintRange – It is applicable only for Print action. It determines the range of pages to be printed.

SV Draft Split Names – It accepts a logical value to determine if the long names should be split into multiple lines.

SV Draft Split Numbers – It accepts a logical value to determine if the long numbers should be split into multiple lines.

SVPrintStartPageNo – It is applicable only for Print action. It allows specifying starting page no. SVPosMode – It determines if POS mode is to be used. The default value of this variable is NO.

Variables Specific to Action – Export

The following screen is displayed when the user executes ‘Export’ action.

 

This screen captures the user inputs such as “Export Format”,”Output File Name”, etc. The action ‘Export’ uses the variables ‘SVExportFormat‘ , ‘SVPrintFileName‘ and so on.

SVPrintFileName – For the Export action, the value of this variable is the output file name. The path can be specified directly, or the function $$MakeExportName can be used to create the output path. The function $$MakeExportName suffixes the extension based on the export format if only the file name is passed as a parameter.

Syntax

$$MakeExportName : <String Formula>: <Export format>

Where,

<String Formula>is a string formula which evaluates to the path \  filename.

<Export format>is the name of the format which has to be used while exporting.

Example

$$MakeExportName : “C:\Tally.ERP\abc.xls” : Excel

Variables Specific to Action – Mail

When the user executes ‘Mail’ action, the following screen is displayed to capture the mailing details:

For the successful execution of ‘Mail’ action, the user has to enter the above details. The URL is then created using the function $$MakeMailName, and the value is stored in variable ‘SVPrintFileName’.

SVPrintFileName – This variable accepts the URL location as value. Function $$ MakeMailName is used to construct the URL. The mail is sent to specified mail addresses using the given server.

Syntax

$$MakeMailName :<ToAddress>:<SMTP Sever name>:<From Address>:<CC Address>:<Subje c t>:<Username>:<Password>:<Use SSL flag>

Where,

<ToAddress>is the e-mail id of the receiver.

<SMTP Server Name>is the name of the server from which the mail is sent.

<From Address>is the send e r’s e-mail id.

<CC Address>is the email-id where the copy of the mail is to be sent.

<Subject>is the subject of the mail.

<User Name>is the user id on the secured server.

<Password>is the password for the user id on the secured server.

<Use SSL Flag>can be TRUE / FALSE OR YES / NO. If the Use SSL flag is set to TRUE, then the Username and Password must be specified, i.e., they can’t be empty.

Example:

$$MakeMailName:”xyz@xyz.com”:”smtp.gmail.com”:”abc”+”<“+”abc@abc.com”+”>”:”Your outstanding payment”:abc@gmail.com:abc123:True

Variables Specific to Action – Upload

The following screen is displayed to capture details of the folder where the report is to be uploaded:

Figure_4._Upload_Screen_(1.6).jpg

Based on the information entered by the user, the URL of the upload site is created using the function $$MakeHTTPName or $$MakeFTPName, and the value is stored in variable ‘SVPrintFileName’. SVPrintFileName – It accepts the URL of upload site. The URL is constructed using the functions $$MakeHTTPName or $$MakeFTPName, depending on protocol selected by the user for upload. Function $$MakeFTPName is used for creating the file transfer protocol, based on specifications.

Syntax

$$MakeFTPName : <FtpServer>: <FtpUser>: <FtpPassword>: <FtpPath>

Where,

<FtpServer>is the FTP server name.

<FtpUser>is the FTP user name.

<FtpPassword>is the FTP password.

<FtpPath>is the full path of the folder on the FTP server.

Example:

$$MakeFTPName:”ftp://ftp.microsoft.com”:””:””:”dbook.xml”

Function $$MakeHTTPName is used for creating the HyperText Transfer Protocol for the specified security features.

Syntax

$$MakeHTTPName : <HttpUrl>: <HttpIsSecure>: <HttpUserName>: <HttpPassword>: <CompanyName>

Where,

<HttpUrl>is the HTTP URL name.

<HttpIsSecure>is a logical attribute which checks whether the HTTP is secure or not.

<HttpUserName>is the HTTP user name.

<HttpPassword>is the HTTP password.

<CompanyName>is the name of the Company.

Example

$$MakeHTTPName:”https://www.abc.com”:Yes:”guestuser”:”pswd99″:”ABC Company Ltd”

Use Case Scenario:

Report “Bill-wise details” is to be mailed to each party with their respective Bill Details. However, mails to all parties should be sent at one keystroke, without the e-mail configuration screen popping up multiple times. As of now, a user has to manually enter email IDs for each ledger.

Solution : Following steps need to be implemented

Step 1 : Create Function

[Function : FuncEmailingOutstanding]

Variable : LedgerName : String

Step 2 : Create Local Formulae for enhanced readability of code

Local Formula : FromAddress : “abc” + “<abc@abc.com>”

Local Formula : ToAddress : if $$IsEmpty:$Email then “abc@abc.com” else $Email

Local Formula : Subject : ##LedgerName + “(Bill-wise Details)”

Step 3 : Set the values of common variables used in ‘Mail’ action

03a : SET : SVExportFormat : $$SysName:HTML

Step 4 : Walk the Ledger Collection to retrieve the email-id of the ledger

01 : WALK COLLECTION : SDLedger

Step 5 : Set the values of the variables used in ‘Mail’ action

02 : SET : LedgerName : $Name

03b : SET : SVMailEmbedImage : @@AsAttach

03c : SET : ExplodeFlag : “Detailed”

03d : SET : SVPrintFileName : $$MakeMailName:@ToAddress:“smtp.gmail.com”:@FromAddress:”admin@tallysolutions.com”:@Subject :”” :””:FALSE

Step 6 : Call the action

04 : MAIL : Ledger Outstandings : TRUE

;; TRUE is meant to suppress the configuration report

06 : END WALK

       |

       |

08 : RETURN

 

Release 1.8

Invoking Actions on Event Occurrence – with System and Printing Events Introduced

In any language, event handling is one of the powerful features, as it allows the developer to perform some operation based on some implicit action. In order to detect the events and to perform some action based on the event, a proper Event Framework is required.

Prior to this release, the Events Form Accept and Focus had been introduced. In this release, there has been a major enhancement in Event Framework as a whole. We will see in detail the events supported in TDL. Let’s start with an overview of Event Framework and types of events.

Event Framework Overview

When the user does something, an event takes place. Events are actions which are detected by a program and can change the state of system or execution flow. Events can occur based on user actions or can be system-generated. In TDL, the Key Framework is mainly used to handle user actions like keyboard and mouse events. This can be considered as a part of the Event Framework.

We know that TDL is a definition language which does not have any explicit control on the flow of execution. The programmer has no control over what will happen when a particular event occurs. There are certain attributes like SET/PRINTSET, used to initiate some action on the occurrence of event/change of state (like report construction, and so on.). In this scenario, there is a need of a generic Event Framework, which allows the programmer to trap the events and initiate an action/set of actions in the state when the event has occurred.

The event framework allows the specification of an Event Handler, where it is possible to specify an event Keyword, a Condition to control event handling and the Action to be performed. The process of detecting an event and executing the specified action is called as Event handling.

Types of Events

When the user operates the application, different types of events are generated. The events are classified as System Events or Object-Specific Events, based on their origin.

System events are for which no object context is available when they occur.

Example

Tally application launch.

Object Specific events are performed only if the specific object context is available.

Example

Form Accept is a Form-specific event.

System Events

In TDL, a new type ‘Events’ has been introduced in the System definition. All the system events are defined under this definition. As of now, TDL event framework supports the following four system events, viz. System Start, System End, Load Company and Close Company.

Syntax

[System : Events]

Label : <EventKeyword> : <ConditionExpr> : <ActionKeyword> : <Action Parameters>

Where,

<Label> is a name assigned to the event handler. It has to be unique for each event handler.

<EventKeyword> can be one of System Start, System End, Load Company or Close Company.

<ConditionExpr> should return a logical value.

<ActionKeyword> can be any one of the actions.

<Action Parameters> are parameters of the action specified.

The events System Start and System End are executed when the user launches or quits Tally application, respectively. The events Load Company and Close Company are executed when the user loads or closes a company, respectively.

Example

[System : Events]

AppStart1 : System Start : TRUE : CALL : MyAppStart

The function MyAppstart is called as soon as the Tally application is launched.

Object Specific Events

Objects specific events can be specified for the associated object only.

Example

Before Print event is specific to ‘Report’ object. The attribute ON is used to specify the object specific events as follows:

Syntax

ON : EventKeyword : <ConditionExpr> : <ActionKeyword> : <Action Parameters>

Where,

<EventKeyword> can be any one of ‘Focus’, ‘Form Accept’, ‘Before Print’ and ‘After Print’.

<ConditionExpr> should return a logical value.

<ActionKeyword> can be any one of the actions.

<Action Parameters> are parameters of the action specified.

ON is a list type attribute, so a list of actions can be executed when the specific event occurs.

Event – FORM ACCEPT

The event Form Accept is specific to ‘Form’ object; hence, can be specified only within Form definition. A list of actions can be executed when the form is accepted, which can also be based on some condition. After executing the action Form Accept, the current object context is retained. So all the actions that are executed further, will have the same object context.

The event ‘Form Accept’, when specified by the user, overrides the default action Form Accept. So, when ‘Form Accept’ event is triggered, the Form will not be accepted until the user explicitly calls the action ‘Form Accept’.

Example

[Form : TestForm]

On : FormAccept : Yes : HTTPPost : @@SCURL : ASCII : SCPostNewIssue : SC NewIssueResp

Action HTTP Post is executed when the event ‘Form Accept’ is encountered. But, the form will not be accepted until the user explicitly calls the action Form Accept on event Form Accept as follows:

On : FormAccept : Yes : Form Accept

Now, after executing the action HTTP Post , Tally will execute the action Form Accept as well.

Event – FOCUS

The event Focus can be specified within the definitions Part, Line and Field. When Part, Line or Field receives focus, a list of actions get executed, which can also be conditionally controlled.

Example

[Part : TestPart2]

On : FOCUS : Yes : CALL : SCSetVariables : $$Line

Event – BEFORE PRINT

The event Before Print is specific to ‘Report’ object; so it can be specified only within ‘Report’ definition. The event ‘Before Print’ is triggered when the user executes the ‘Print’ action. The action associated with the event is executed first, and then the report is printed.

A list of actions can be executed before printing the report, based on some condition.

Example

[Report : Test Report]

On : BEFORE PRINT : Yes : CALL : BeforeRepPrint

The function BeforeRepPrint is executed first and then the report Test Report is printed.

Event – AFTER PRINT

The event After Print can be specified for Report, Form, Part and Line definitions. It first prints the current interface object and then executes the specified actions for this event. A list of actions can be executed after printing the report based on some condition. Print is an alias for After Print.

Example

[Line : LV AccTitle]

On : After Print : Yes : CALL : SetIndexLV : #LedgerName

The function SetIndexLV is called after printing the line LV AccTitle. So, if there are 10 lines to be printed, the function will be called ten times.

Release 2.0

New actions have been introduced in this release, viz. Refresh Data, Copy File and Sleep.

Action – Refresh Data

In Tally, whenever any report is being viewed, it contains the most recent updates till the last entry. If any report is left open and subsequently viewed later, possibly few more entries would have gone in the system entered by various other users on the Network. Hence, the report which is currently being viewed is older. To view the updated report, the user has to exit the report and once again, enter the Report. To solve this problem, a new action ‘Refresh Data’ has been introduced, which refreshes the data in memory automatically, as and when required.

Syntax

REFRESH DATA

Refresh Data can be used along with Timer Event and every few seconds, the Report can be refreshed automatically to display the updated information.

Example

[System : Event]

Refresh Timer : TIMER : TRUE : Refresh Data

[#Form : Balance Sheet]

Add : Keys : Enable Refresh

[Key : Enable Refresh]

Key : Alt + R

Action : Start Timer : Refresh Timer : 300

In this example, Refresh Timer , a Timer event is declared under System Event to invoke the Action Refresh Data at periodic intervals. A key Enable Refresh is added in the Balance Sheet Report, which will be used to Start the Timer Refresh Timer every 5 minutes.

Note: The action ‘Refresh Data’ is a Company Report – Specific Action. It will always require a Report in memory to Refresh the Data.

Action – SLEEP

Action SLEEP has been introduced to specify time delays during the execution of the code. For few seconds, the system will be dormant or in suspended mode.

Syntax

SLEEP : <Duration in Seconds>

<SlEEP> is the action which halts the functioning of the Application for a few seconds as specified in <Duration in>.

Example:

[#Menu : Gateway of Tally]

Add : Item : Trial Balance after 10 secs : CALL : TBafterSleep

[Function : TBafterSleep]

00 : SLEEP : 10

10 : DISPLAY : Trial Balance

In this example, the system will halt for 10 seconds and display the Trial Balance subsequently.

Action – Copy File

A new action ‘Copy File’ has been introduced, which allows:

  • Copying from one location to another within the same System
  • Uploading of Files from a given Path to a FTP Site
  • Downloading of File from FTP Site to the specified location/folder

Syntax

Copy File : <Destination File Path> : <Source File Path>

Where,

<Destination File Path> can be any expression evaluating to a valid local/FTP path.

<Source File Path> can be any expression evaluating to a valid local/FTP path.

Example

CopyFile : ##MyDstFilePath : ##MySourceFilePath

If any of the File path is an FTP path, the same can be constructed using functions like $$MakeFTPName. It accepts various parameters like servername, username, password, etc. The following code snippet sets the value of the variable MyDstFilePath using the function $$MakeFTPName.

SET : MyDstFilePath : $$MakeFTPName:##SVFTPServer:##SVFTPUser:##SVFTPPassword:@SCFilePathName

The function $$MakeFTPName uses the various parameters which are System Variables captured from the default configuration reports.

Release 3.6

Action – Execute TDL

TDL action Execute TDL has been introduced to programmatically load TDL, perform some actions and subsequently, unload the TDL or keep the TDL loaded for the current Tally session.

This can prove to be very useful in cases where the user needs to programmatically associate a TDL on the fly, for performing some operations.

Syntax

EXECUTE TDL : <TDL/TCP File Path>[: <Keep TDL Loaded Flag> : <Action>: <Action Parameters>]

Where,

<TDL/TCP File Path> specifies the path of the TDL/TCP File to be loaded dynamically.

<Keep TDL Loaded Flag> is the Logical Flag to determine if the TDL should be kept loaded after the action is executed. If the value is set to YES, then the TDL will continue to be loaded, else the Executed TDL will be unloaded after the execution of the specified action.

<Action> specifies the global Action to be performed, i.e., Display, Alter, Call, etc.

<Action Parameters> are the parameters on which the Action is performed. For example:

  • If the action is Call, the Action Parameters contain the Function name along with the Function parameters, if any.
  • If the action is Display, Alter, etc., then the Parameter should be the Report Name.

Example: 1

[Function : TDL Execution with Keep TDL Loaded enabled]

00 : Execute TDL : “C:\Tally.ERP9\BSTitleChange.TDL” :Yes : Display : Balance Sheet

10 : Display : Balance Sheet

The file BSTitleChange.TDL contains the following lines of code:

[#Report: Balance Sheet]

Title : “TDL Executed Programmatically”

In this example, the TDL BSTitleChange.TDL , which is used to change the Title of the report Balance Sheet, is loaded dynamically by executing the action Execute TDL. The Keep TDL Loaded Flag is set to YES in the above code snippet. Based on the subsequent action Display: Balance Sheet, the Balance Sheet report will be shown with a new Title. The next statement also displays the Balance sheet. The title for this will again be the same, i.e., the changed title, as the dynamic TDL is still loaded, even after the action Execute TDL has completed its execution.

Example: 2

[Function : TDL Execution with Keep TDL Loaded enabled]

00 : Execute TDL : “C:\Tally.ERP9\BSTitleChange.TDL” : No : Display : Balance Sheet

10 : Display : Balance Sheet

Here, the report Balance Sheet would be displayed twice and the title of the first report is “TDL Executed Programmatically”, i.e., the changed title as per BSTitleChange.TDL ; whereas, in the second report, the title is Balance sheet, since the attribute Keep TDL Loaded Flag is set to NO.

Release 3.61

Action – BrowseURLEx

As we are aware, there is an action Browse URL/Execute Command used to open a web page or invoke an external application. There may be cases where subsequent actions are dependent on the completion of the previous action, i.e., the closure of external application. For example, the current action is used to execute an external file, which unzips/ extracts various other files. The subsequent actions use these extracted files to process further. In such cases, Browse URL, when used, will trigger the requested application and continue executing the subsequent actions.

Hence, in order to bring sync between the calling and the called application, a new action Browse URL Ex/Execute Command Ex has been introduced. The Action Browse URL Ex, when triggered, waits till the external application is closed, and then allows the application to resume with the subsequent action. Similar to ‘Browse URL’, the Action ‘ BrowseURLEx ’ can be used to:

  • Open a web Page in the browser
  • Open an external file with its associated application
  • Run an executable application
  • Open a folder in explorer

Note: BrowseURLEx is useful for URL, folder and executable without extension (e.g., tally instead of tally.exe), and it has similar behaviour as Browse URL.

Syntax

BrowseURL Ex : <URL/File path/executable file path/folder path> [:<Command line Parameters>]

Where,

<URL/File path/executable file path> can be:

  • A URL, which can be opened in a browser
  • A file, which is to be opened with its associated application
  • An executable file, which is to be run/executed
  • A folder, which is to be opened in the explorer

<Command line Parameters> is an optional parameter. For example, Zip application may need parameter d to decompress, c to compress, etc.

Example:1

To open a URL in browser:

Action : Browse URL Ex : “http://google.com”

Example: 2

To open a pdf file in pdf reader:

Action : BrowseURL Ex : “C:\report.pdf”

In this example, report.pdf will be opened in default PDF reader of the system. This can be useful while reading a report, which is exported in PDF format.

Example:3

To open an executable file and wait for it to complete:

Action : BrowseURL Ex: “C:\7zip.exe”: “D:\software.7z”

In this example, 7zip is opened and the application waits until it finishes, i.e., the running application first waits for 7zip.exe to finish decompressing of software.7z, and then it proceeds further.

Example:4

To open a folder:

Action : BrowseURL Ex : “C:\abc”

Release 4.7

Event ‘NatLangQuery’ Introduced

As we are already aware, Tally has a natural language processing capability which accepts queries either from the Calculator Pane or from SMS Request. Tally has the intelligence of parsing received/ given commands, in order to process the same. This parsed information is used by the system to process the query and deliver the result. However, in certain cases, queries received might not be understood by the system. There have also been requirements in the market to support data updation queries like Ledger, Voucher Creation, etc.

In order to cater to the above requirements, a new System Event NatLangQuery has been introduced. This event gives complete control in the hands of the TDL Developer, thereby enabling him to process the query received and do the needful. If the query is ignored by TDL, then the System continues to process it and provide the response as usual.

Syntax

[System : Event]

<Event Name> : NatLangQuery : <Condition> : <Action> : <Action Parameters>

Where,

<Event Name> can be any unique name, indicating the purpose of the eve n t.

<Condition> if evaluated to TRUE on receiving a query , an action will be executed.

<Action> is the Action Call which can be used for processing the Query received/given.

<Action Parameters> can be a Function Name and its required Parameters.

Example

[System: Event]

Ledger Creation: NatLangQuery: @@IsLedgerinQuery: Call: Create Ledger

Whenever a Query is received, Tally checks the logical condition @@IsLedgerinQuery. If it evaluates to TRUE, then the function ‘Create Ledger’ is invoked.

Note: In the given syntax, <Action> can be any global Action like Display, Alter, Print, etc. However, NatLangQuery being a query from a remote location, it is not advisable to populate any report in the User Interface of Tally at the Server end.

In order to support the event “ NatLangQuery ”, the following System Variables, along with a Built-in TDL Function $$ NatLangInfo , have been introduced.

System Variables Introduced

SVNatLangFullRequest

This is a String Variable bearing the complete request / query string when a Query is received.

SVNatLangRequest

This is a String Variable bearing the part of the query that is not understood by the system.

SVNatLangResponse

This is a String Variable which carries the response back to the requestor. After processing the Query, this variable needs to be set with an appropriate response that is sent back to the requestor by Tally.

SVNatLangRequestProcessed

This is a Logical Variable which denotes the status of the Query Processed. After processing the Query, this variable needs to be set to YES to indicate if the Query was processed by TDL successfully.

  • Update YES to indicate that the Query is processed by TDL and the response is prepared.
  • Update NO to indicate that the Query is not processed/understood by TDL.

If updated as YES , then only the system will send the response specified in TDL. If updated as NO , the System processes the Query and sends the appropriate response.

Built-In TDL Function ‘$$NatLangInfo’ Introduced

A Built-In TDL Function $$NatLangInfo has been introduced to provide certain information like Company Name, User Name, From Date, To Date , and so on, from the Query received.

Syntax

$$NatLangInfo : <InfoType>

The valid values for <InfoType> are as follows:

  • Company
  • UserName
  • FromDate
  • ToDate
  • ObjectName

Example

$$NatLangInfo :Company returns the current Company Name.

$$NatLangInfo :UserName returns the Name of the User from whom the Query is received.

  • If the request is from Calculator Pane, Tally responds with the current logged in user name.
  • If the request is initiated through an SMS Query, Tally responds with the name of the Tally.NET User from whose device, the request is received.

$$NatLangInfo:FromDate returns the From Date of the period, based on the received query or from the recent context.

$$NatLangInfo:ToDate returns the To Date of the period, based on the received query or from the recent context.

$$NatLangInfo:ObjectName returns the Name of the Object, based on the received query or in the recent context. For example, if Query received is – “Sales for April 2013”, then NatLangInfo will return the following:

Object Name- Sales

From Date – 1-April-2013

To Date – 30-April-2013

Example to Demonstrate “NatLangQuery” event

Create Ledger RadheShyam SundryDebtors

Requirement

The requirement here is to create a Ledger with the name ‘RadheShyam’, under the Group ‘Sundry Debtors’.

Implementation

  1. Firstly, we need to write a system event to trap the query received and perform the necessary action.

[System : Event]

Create Ledger : NatLangQuery : @@IsCreateLedger : Call : Create Ledger

  1. If the Request contains ‘Create Ledger’, then only the above action is to be performed, so the following system formula needs to be declared to check the value of the variable SVNatLangFullRequest.

[System : Formula]

IsCreateLedger : ##SVNatLangFullRequest CONTAINS “Create Ledger”

  1. When the action is being executed, firstly we need to tokenize the words from the string:

[Function : TokenizeQuery]

000 : List Delete Ex : SMSStrings

010 : For Token : TokenVar : ##SVQueryRequest : ” “

020 : List Add Ex : SMSStrings : ##TokenVar

030 : End For

[System : Variable]

List Var : SMSStrings : String

  1. Finally, create the ledger with the Action ‘New Object’

[Function : CreateLedger]

000 : Call : TokenizeQuery

010 : New Object : Ledger : ##SMSStrings[3] : Yes

020 : Set Value : Name : ##SMSStrings[3]

030 : Set Value : Parent : ##SMSStrings[4]

040 : Save Target

  1. Send the Response to the source of the query

050 : Set : SVNatLangResponse : “Ledger Created”

060 : Set : SVNatLangRequestProcessed : Yes

Similarly, the NatLangQuery Event can also be used to customize the interpretation of the queries being sent, and act accordingly.

Note

We have used Space as a delimiter for Tokenizing Query Strings in the given example. One can specify any delimiter like Inverted quotes, comma, etc., to separate different strings.

If customized with the help of Tokens, the Query Signature must be retained exactly in the same order and with the delimiters specified. In the given example, if the Query ‘Create Ledger Keshav under SundryDebtors’ is specified, the code will fail, as the function expects the 4th Word to be a Group Name. Hence, the Programmers must communicate the Query Signa­ture clearly with the end users.

ZIP – UNZIP

ZIP is an archive file format that supports compression of data without any loss. A Zipped file may contain one or more files or folders in compressed form. The ZIP file format permits a number of compression algorithms. Originally created in 1989 by Phil Katz, the ZIP format is now supported by a number of software utilities.

The need for supporting this format in Tally.ERP 9 has been felt in various offline Integration projects. Data Exchange takes place between branches and their Head Offices, Distributors and the Principal Companies, etc., where the Head Offices/ Principal Companies having Tally or any other ERP would require the data from Branches/ Distributors for performance visibility. Usually, Principal Companies require the Item-wise Sales Information of the distributors, which helps them in planning their Stocks.

For integration purpose, Head Offices/ Principal Companies generally get Tally.ERP 9 installed at Branches/ Distributors’ locations. The day-to-day Transactions like Sales, Purchase Orders, etc., are then exported from Tally.ERP 9 and integrated by copying the appropriate XML files to FTP, which is consumed by the Head Offices/ Principal Companies.

At locations where the volume of transactions is large, the XML File becomes too bulky to upload to FTP, and subsequently, downloading from FTP takes a long time, thereby causing performance issues. Hence, zipping the file before uploading to FTP was necessary. This would save time both while uploading the File and while downloading it at the other end. Hence, the concept of Compression, i.e., Zip-Unzip has been introduced in Tally.ERP 9.

Along with the actions for Zip/Unzip capability, wildcards * and ? are also supported, as a part of folder/file specification. Asterisk(*) represents zero or more characters in a string of characters. For example, t*.doc considers all files starting with ‘t’, bearing the extension .doc, e.g., Tally.doc, Tallyzip.doc, etc. Question Mark (?) represents any one character. For example, TDLDebug?.* considers all the files starting with ‘TDLDebug’, followed by any variable single character, and bearing any extension, e.g., TDLDebug1.xlsx, TDLDebug2.xlsx, TDLDebug1.log, etc.

ZIP Action

Zip action can be used to archive a set of folders/ files.

  • System Action – ZIP

System action Zip is useful when a single File or Folder Source needs to be zipped into a Target file.

Syntax

Zip : <Target File> : <Source Path> [:<Password> [:<Overwrite> [:<Include Sub-directory> [:<Show Progress Bar>]]]]

Where,

<Target File> is the name of the Zip File to be created, along with the Path.

<Source Path> is the path of the Folder/File(s), which is to be zipped. It can be a folder, or a file path (with or without wildcard characters).

<Password> is the password assigned to the Target zipped file.

<Overwrite> is the Logical Flag to specify the behaviour of the Action, if the Target File already exists. If YES is specified, the file will be overwritten. If ‘NO’ is specified, the file will not be overwritten and will remain as it is. The default value is ‘NO’.

<Include Sub-directory> is the Logical Flag to specify whether to include sub directories available in the specified source path or not. If the Source Path ends with a Folder, the entire Folder along with its Sub-Folders will be zipped, irrespective of this parameter. If the Source Path ends with a File Name Pattern, i.e., with wild cards, this parameter will be considered. If a ‘YES’ is specified, all the files/sub-folders matching the wild card pattern will be included for Zipping. If ‘NO’ is specified, they will not be included. The default value is ‘NO’.

<Show Progress bar> is the Logical Flag to specify if the Progress Bar needs to be shown during the Zipping Process. If ‘YES’ is specified, the Progress Bar will be shown, and if ‘NO’ is specified, it will not be shown. If no value is specified, the default value will be assumed as ‘NO’.

Note: Wild Cards * and ? are supported only for the last information in the path. For example, C:Wor?Cust*.txt is invalid whereas C:\WorkCust*.txt is valid.

Example: 1

ZIP : “.Target.zip” : “tally.ini”: “Tally” : No

With the above Action, the following will be achieved:

  1. The file tally.ini from the current Tally Application/Working Folder will be zipped to the File Target.zip in the Tally Application Folder itself.
  2. The resultant Zip File will contain the password Tally.
  3. If the file Target.zip exists in the current application folder, it will not be overridden.

Example: 2

To Zip all text files in work folder .

ZIP: “D:\Target.zip”: “D:Work*.txt”: “Tally”: No: Yes: Yes

With the above Action, the following will be achieved:

  • All the text files from the folder D:\Work will be zipped to the File Target.zip in D:\.
  • The resultant Zip File will contain the password Tally.
  • If the file Target.zip exists in D:\, it will not be overridden as the 4th Parameter is set to No.
  • All the text files within the Sub-directories will be included under the Folder D:\Work, as the 5th Parameter is set to Yes.
  • The Progress Bar will be shown during Zipping of the Files, as the 6th Parameter is set to Yes.

Procedural Actions – Start Zip, Zip Add Path, Zip Exclude Path and End Zip

Procedural Actions Start Zip, Zip Add Path, Zip Exclude Path and End Zip are very useful in cases where Multiple Folders/Files need to be zipped into / excluded from a Target File.

Syntax

Start Zip : <Target File> [: <Overwrite>]

Zip Add Path : <Source Path> [: <Include sub-directory>]

                  |

                  |

Zip Exclude Path : <Exclude Path>

                 |

                 |

End Zip [: <Password> [: <Show Progress Bar>]]

Where,

<Target File> indicates the name of the resultant Zip File , and also includes the Folder Path .

<Overwrite> is the Logical Flag to specify the behaviour of the Action, if the Target File already exists. If YES is specified, the file will be overwritten. If ‘NO’ is specified, the file will not be overwritten, and will remain as it is. The default value is ‘NO’ .

<Source Path> is the path of the Files or Folders, which are to be zipped. It can be a folder or a file path (with or without wildcard characters).

<Include Sub-directory> is the Logical Flag to specify whether to include sub directories available in the specified source path or not. If the Source Path ends with a Folder, the entire Folder along with its Sub-Folders will be zipped, irrespective of this parameter. If the Source Path ends with a File Name Pattern, i.e., with wild cards, this parameter will be considered. If a ‘YES’ is specified, all the files/sub-folders matching the wild card pattern will be included for Zipping. If ‘NO’ is specified, they will not be included. The default value is ‘NO’.

<Exclude Path> is the path of the Files/ Folders which need to be excluded from the Target Zip .

<Password> is the password assigned to the Target zipped file.

<Show Progress Bar> is the Logical Flag used to specify if the Progress Bar needs to be shown during the Zipping Process. If ‘YES’ is specified, then the Progress Bar will be shown, and if ‘NO’ is specified, it will not be shown. If no value is specified, the default value will be assumed as ‘NO’.

Example: 3

Start ZIP : “Target.zip” : Yes

/* Overwrite the File Target.zip, if it exists */

Zip Add Path : “tally.ini”

End Zip

The outcome of this example will be similar to the outcome of Example: 1. The only difference is that it is set to overwrite the target file Target.Zip , if it exists in the current application folder (as the <Overwrite> Parameter of the Action ‘Start Zip’ is set to Yes).

Example: 4

Start Zip : “Target.zip” : Yes

Zip Add Path : “.Tally.ini”

Zip Add Path : “D:\Documents*.doc” : Yes

/* Include Sub-Folders also */

Zip Add Path : “C:\Work”

/* The Folder Work and the Files within this folder will be included in the Zip File */

End Zip

In this example, there are 3 Source Paths, which are required to be zipped:

  • First Path indicates that the file Tally.ini from the current application folder is to be zipped.
  • The Second Path indicates that the PDF files from within the D:\Documents Folder, including the Sub-Folders, need to be zipped.
  • The Third Path indicates that the entire folder C:\Work needs to be zipped.

The above source files would be zipped to the target file Target.zip, which is specified in the Action Start Zip.

Example: 5

Start Zip : “Target.zip” : Yes

/* Overwrite the existing file in the target location */

Zip Add Path : “.Tally.ini”

Zip Add Path : “D:\Documents*.doc” : Yes

/* Include Sub-Folders also */

Zip Add Path : “C:\Work”

Zip Exclude Path : “*.txt”

End Zip

In this example, apart from using Action Zip Add Path to specify the first 3 source paths, the subsequent Action Zip Exclude Path is used to specify the exclusion of Folders or Files with the extension .txt. Thus, all the text files from the above specified source paths will be excluded.

UNZIP Action

The Unzip action can be used to extract the original files from the zipped files.

System Action – UNZIP

System Action Unzip is useful when all the folders/ files in the Source Zip File need to be completely unzipped, as they are. (This Action cannot be used in case of partial Unzip.)

Syntax

Unzip : <Target Folder>: <Source File> [: <Password> [: <Overwrite> [:<Show Progress Bar>]]]

Where,

<Target Folder> is the path of the Target folder where the Unzipped Files need to reside.

<Source File> is the name of the Zip File to be unzipped.

<Password> is the Zip File Password. A Zip File bearing a Password cannot be extracted without the Password.

<Overwrite> is the Logical Flag to specify the behaviour if the Files being unzipped already exist in the Target Folder. The default value is ‘NO’.

<Show Progress Bar> is the Logical Flag to specify if Progress Bar needs to be shown during the Extracting (Unzipping) Process. If YES is specified, the Progress Bar will be shown and if NO is specified, the Progress Bar will not be shown. The default value is ‘NO’ .

Example: 1

Unzip : “.” : “D:\Target.zip” : “Tally”

In this example, the file D:\Target.zip will be unzipped entirely in the current Tally Application Folder. Since the Zip File bears a password Tally, same is being passed as the 3rd Parameter.

Example: 2

Unzip : “Documents” : “D:\Target.zip” : “Tally”

In this example, all the folders/ files within the Zip File D:\Target.zip will be extracted to the folder Documents in the current Tally Application folder.

Procedural Actions – Start Unzip, Extract Path, Unzip Exclude Path and End Unzip

The Procedural Actions Start Unzip , Extract Path , Unzip Exclude Path and End Unzip are very useful in case of partial Unzip . Using the Action ‘Extract Path’, one can specify the Folder/ File Path to be marked for extracting. The action ‘Unzip Exclude Path’ can help to exclude the specified Folders/ Files from the Zip File and extract the rest. These actions can be used in both the cases, i.e., for partial unzip as well as for total unzip.

Syntax

Start Unzip : <Source File> [: <Password>]

Extract Path : <Folder/ File Path>

|

|

Unzip Exclude Path : <Folder/ File Path>

|

|

End Unzip : <Target folder> [:<Overwrite> [:<Show Progress Bar>]]

Where,

<Source File> is the path of the Zip File which needs to be zipped.

<Password> is the password to access the Target zipped file.

<Extract Path> is the File/ Folder which need to be extracted from the Zip File.

<Unzip Exclude Path> is the path of Files/ Folders, which need to be excluded from the unzipping operation.

<Target Folder> is the path of the Target folder, where the Unzipped Files need to reside.

<Overwrite> is the Logical Flag to specify the behaviour if the Files being unzipped already exist in the Target Folder. The default value is ‘NO’.

<Show Progress Bar> is the Logical Flag to specify if Progress Bar needs to be shown during the Extracting (Unzipping) Process. If YES is specified, the Progress Bar will be shown and if NO is specified, the Progress Bar will not be shown. The default value is ‘NO’.

Example: 3

Start Unzip: “D:\Target.zip”

End Unzip : “D:\Unzipped” : Yes

/* Overwrite the existing files, if any, in the Target Folder */

These actions will unzip all the folders/ files within D:\Target.zip to the folder D:\Unzipped and if any file already exists, the same will be overwritten (as the second parameter of the Action End Unzip is set to Yes.)

Example: 4

To extract only .txt and .doc files from the zip file.

Start Unzip : “D:\Target.zip”

Extract Path : “*.txt”

Extract Path : “*.doc”

End Unzip : “.”

In this example, only the *.txt and *.doc files from D:\Target.zip will be unzipped to the current Tally Application Folder.

Example: 5

Start Unzip : “D:\Target.zip”

Extract Path : “SamplesSupporting Files”

Unzip Exclude Path : “*.xls”

End Unzip : “.”

In this example, from D:\Target.zip , all the Files and SubFolders within the folder ‘Supporting Files’ under ‘Samples’ will be unzipped to the current Tally Application Folder, as the target folder is specified as a dot (.). Also, all the files with extension .xls will not be zipped.

Note: A file which has been zipped from Tally.ERP 9 can be extracted by using any standard third party archiving tools like Winzip, Winrar, etc., and vice-versa.

Limitations of Zip/Unzip in Tally.ERP 9:

In the following cases, Zip/Unzip action will fail:

  • If the number of files being Zipped is greater than 65535
  • If the Size of the Zip File is greater than or equal to 4 GB
  • If the Size of any File within the Zip File is greater than or equal to 4 GB

Release 4.8

Events Introduced

System Events – for Object Deletion and Cancellation

Event Framework has undergone significant changes during the recent past with the introduction of System Events ‘System Start’, ‘System End’, ‘Load Company’, ‘Close Company’ and ‘Timer’.

In this Release, four new System Events viz., two Events for Object Deletion and two for Voucher Cancellation, have been introduced. With the introduction of these Events, whenever an Object is subject to Deletion or Cancellation, these events get triggered, which allows the TDL Programmer to take some appropriate action. Only on confirmation of Deletion or Cancellation, these events are triggered. In other words, only when the user confirms the deletion or cancellation of the object by responding with a YES, the relevant events get triggered.

Irrespective of the Source of Deletion or Cancellation, i.e., from an external XML Request, Tally User Interface, Remote Tally User Interface, etc., the appropriate events get triggered. Any Object deletion or cancellation event gets triggered only at the Server end. Let us understand these System Events in detail.

Delete Object Events – ‘Before Delete Object’ and ‘After Delete Object’

Two new System Events Before Delete Object and After Delete Object have been introduced in this release. These events get triggered whenever any of the primary Objects defined in Tally Schema is deleted. For example, Object Company, Voucher, Ledger, etc.

As the names suggest, the Events Before Delete Object and After Delete Object are triggered before and after the deletion of the Object, respectively. The Current Object context would be available in both these Events. Triggering of the Event After Delete Object confirms the successful Deletion of the Object.

Syntax

[System : E v ents]

<Label> : Before Delete Object : <Logi c al Condition Expr>: <Action Keywor d > : <Action Paramet e rs>

<Label> : After Delete Object : <Logical Condition Expr> : <Action Keywor d > : <Action Paramet e rs>

Where,

< Label > is a Unique and Meaningful Name assigned to the System Event handler.

< Logical Condition Expr > is a Logical Expression, which when evaluates to TRUE, executes the given Action.

< Action Keyword > is the Action to be taken once the System Event is triggered.

< Action Parameters > are the parameters required for the particular Action.

Both these even t s are mutually exclusive. In other words, the System Event ‘ Before Delete Object ’ need not be necessarily triggered in order to trigger the System Event ‘ After Delete Object ’, and vice versa.

Example

[System : Event]

BeforeStockItemDeletion : Before Delete Object : $$IsStockItem:Call:BeforeDeleteObjectFunc

AfterStockItemDeletion  : After Delete Object : $$IsStockItem:Call:AfterDeleteObjectFunc

[Function : BeforeDeleteObjectFunc]

00 : Log : “Before Delete Object Event starts here”

10 : Log : $Name + “under the Stock Group” + $Parent + “is being deleted by ” + $$CmpUserName

20 : Log : $MasterID

30 : Log : “Before Delete Object Event ends here”

[Function : AfterDeleteObjectFunc]

00 : Log : “Stock Item ” + $Name + “ Deleted”

In this example, the events are invoked only when the Stock Item Object is actually being deleted. Since the object context is available both before and after the object deletion, the object details such as Name, MasterID and Parent can be logged in either of the events. The Event ‘After Delete Object’ confirms the Object Deletion.

Cancel Object Events– Before Cancel Object and After Cancel Object

Similar to Delete Object Events, two new System Events Before Cancel Object and After Cancel Object have been introduced. Cancellation is applicable only to the Object ‘Voucher’. As the names suggest, the Events Before Cancel Object and After Cancel Object are triggered before and after cancellation the of the ‘Voucher’ object, respectively. The Current Object context would be available in both these Events. Triggering of the Event After Cancel Object confirms the successful Cancellation of the ‘Voucher’ Object.

Syntax

[System : Events]

<Label> : Before Cancel Object : <Logical Condition Expr> : <Action Keyword> : <Action Parameters>

<Label> : After Cancel Object : <Logical Condition Expr> : <Action Keyword> : <Action Parameters>

Where,

< Label > is a Unique and Meaningful Name assigned to the System Event handler.

< Logical Condition Expr > is a Logical Expression, which when evaluates to TRUE , executes the given Action.

< Action Keyword > is the Action to be taken once the System Event is triggered.

< Action Parameters > are the parameters required for the particular Action.

Both these System Events are mutually exclusive, i.e., the Event ‘Before Cancel Object’ need not be necessarily trigged in order to trigger the Event ‘After Cancel Object’, and vice versa.

Example

[System : Event]

BeforeVchCancellation: Before Cancel Object : Yes : Call : BeforeCancelObjectFunc

AfterVchCancellation: After Cancel Object : Yes : Call : AfterCancelObjectFunc

[Function : BeforeCancelObjectFunc]

Local Formula : StrMasterID: $$String:$MasterID

00 : Log : “Before Cancel Object Event ” + @StrMasterID + “starts here”

10 : Log : $VoucherNumber

20 : Log : $VoucherTypeName

30 : Log : “Before Cancel Object Event ” + @StrMasterID + “ends here”

[Function : AfterCancelObjectFunc]

Local Formula : StrMasterID : $$String:$MasterID

01 : Log : “Voucher with MasterID ” + @StrMasterID + “ cancelled”

In this example, the System Events Before Cancel Object and After Cancel Object are triggered the moment any voucher is cancelled. Since the object context is available both before and after the cancellation of the object, the details such as Voucher Number, Voucher Type Name, Master ID and Date of the cancelled voucher can be logged through both the user defined functions. The Event After Cancel Object confirms the Voucher Object Cancellation.

Points to remember

  • The System Events for Object Deletion or Cancellation will be triggered when an Object gets deleted or cancelled from any Source, viz.,from an External Third Party Request, from the Tally User Interface or from Remote Tally.
  • In case multiple vouchers are selected, and subsequently cancelled or deleted:
  • The Event is triggered as many times as the number of vouchers selected. For instance, if five Vouchers are selected for Deletion in Daybook, the System Events for Deletion would be triggered five Times, once for each Voucher.
  • Only the methods fetched in the Collection used in the Report displaying the list of Vouchers would be available in the Deletion or Cancellation Context. For instance, if multiple Vouchers are selected in Daybook, only the methods fetched in the Collection used in Daybook would be available in the current context. However, the entire Voucher Object context (including all the methods) can be associated by using the Object Association Syntax within the User Defined Function, i.e., Object : Voucher : ”ID :” + ($$String:$MasterID), and all the methods will be available in the context.
  • In case of Remote Login, when the remote user deletes or cancels an object, these events are triggered at the server.

Introduction of new Object-Specific Events

We are aware of object-specific events like ‘Focus’, ‘ Form Accept ’, ‘ Before Print ’ and ‘ After Print ’, which were introduced in previous releases at various User Interface Objects.

In this Release, four new object-specific events viz., the Event Load at Report, the Event Reject at Form, the Event Accept at Field and the Event After Import Object at ‘ Import File ’ definition, have been introduced to provide control in the hands of the TDL developer to perform any desired action, whenever these events are triggered.

Let us understand these Object-Specific Events in detail.

Event ‘Load’ – at Report Definition

The Event Load has been introduced at the ‘Report’ Definition. This event is triggered before the Report is displayed to the user. In other words, when this event is triggered, the Report is constructed and updated with variables, object context and the data. The Event ‘Load’ provides control to the TDL Layer, before Tally gets into wait loop, where the user will start operating on the Report. It may allow storing of the current state, etc.

Syntax

ON: Load : <Condition Expr> : <Action Keyword> : <Action Parameters>

Where,

< Logical Condition Expr > is a Logical Expression, which when evaluates to TRUE, executes the specified Action.

< Action Keyword > is the Action to be executed, once the System Event is triggered.

< Action Parameters > are the parameters required for the given Action.

Example

[#Report: ProfitandLoss]

On : Load : @@IsLossIncurred : CALL : ShowMsgifLossEncountered

In this example, once the user loads or displays the report ProfitandLoss, the ‘Load’ event invokes the Function ShowMsgifLossEncountered, if the System Formula IsLossIncurred evaluates to TRUE.

Event ‘Reject’ – at Form Definition

The Event Reject has been introduced at the ‘Form’ Definition. This event gets executed in the Edit Mode, when the user quits the current Form without accepting or saving it. It allows the Programmer to perform the desired action on rejection of the Form. Once the Event ‘Reject’ is used at the Form Definition, the default Action ‘Form Reject’ is overridden, as a result of which, the action Form Reject has to be explicitly specified.

Syntax

ON : Reject : <Condition Expr> : <Action Keyword> : <Action Parameters>

ON : Reject : <Condition Expr> : Form Reject

Where,

< Logical Condition Expr > is a Logical Expression, which when evaluates to TRUE, executes the given Action.

< Action Keyword > is the Action to be taken, once the System Event is triggered.

< Action Parameters > are the parameters required for the given Action.

Example

[#Form : Accounting Voucher]

On : Reject : Yes : Call : TDLRejectFunc

On : Reject : Yes : Form Reject

[Function : TDLRejectFunc]

00 : Msg Box : Status : “The form is rejected”

In this example, when the form is rejected, the Function TDLRejectFunc is invoked, which displays the message “The form is rejected”. Once the execution of the function is over, the form gets rejected due to the explicit Action ‘Form Reject’.

Event ‘Accept’ – at Field Definition

The Event ‘Accept’ has been introduced at the Field Definition. This event gets executed the moment an editable Field is accepted. Once the Event ‘Accept’ is used at the Field Definition, the default Action ‘Field Accept’ is overridden, as a result of which, the action ‘Field Accept’ to accept the Field contents, has to be explicitly specified.

When a Field is accepted, the event sequence runs in the following order:

  • The Field value is validated through the ‘Validate’ attribute
  • The ‘Modifies’ Variable is modified/updated.
  • The Event ‘Accept’ is executed
  • The Sub-Form is invoked

Note: If the validation fails, then this event will not be executed, as it will result in an error to the user.

Syntax

ON : Accept : <Condition Expr> : <Action Keyword> : <Action Parameters>

ON : Accept : <Condition Expr> : Field Accept

Where,

< Logical Condition Expr > is a Logical Expression, which when evaluates to TRUE, executes the given Action.

< Action Keyword > is the Action to be taken, once the System Event is triggered.

< Action Parameters > are the parameters required for the given Action.

Example

[#Field : Qty Primary Field]

On : Accept : @@IsNegativeClosQty : Call : MsgBoxforNegative

On : Accept : @@IsNegativeClosQty : Field Accept

Here, the event Accept is triggered on accepting the Field Qty Primary Field, which in turn, invokes the function MsgBoxforNegative . Once the function terminates, the field is accepted.

Event ‘After Import Object’ – at Import File Definition

A new Event ‘After Import Object’ has been introduced to empower the TDL programmers to perform some action every time an Object is imported. This Event helps to create appropriate logs after Importing each Object, or terminate the Import Process based on some condition.

Note: For more details about the Event ‘After Import Object’, including the syntax and example, refer to the first topic ‘Data Importing Enhancements’.

Action Enhancements

Function Actions

Batch Posting Actions – START BATCH POST and END BATCH POST

The introduction of User Defined Functions in TDL has empowered the TDL Programmers with one of the most important needs, i.e., Automation of Data Entry. Irrespective of the data source, one can make use of User Defined Functions to update the database without much user intervention. However, in comparison to Import of Data through XML/SDF Files, updation of data through User Defined Functions takes a much longer time. A performance lag has been observed while updating data with User Defined Functions, as compared to updating data of a similar size by the Import method. In order to give a uniform user experience and better performance, the approach followed in data import has now been extended to data updation through User Defined Functions.

Importing of Data implicitly follows a Batch Posting approach, wherein the data to be incorporated in the database is updated in batches, thereby improving the performance. This approach has now been extended to data updation through User Defined Functions, with the introduction of two new Actions, namely START BATCH POST and END BATCH POST . Batch Posting Mode accumulates sets of Objects into batches, and pushes a whole batch of data into the database at a time, which optimizes the performance. Batch Posting Mode also requires the size of the Batch, which can be set as a parameter to the Action START BATCH POST .

Actions – START BATCH POST and END BATCH POST

The Actions START BATCH POST and END BATCH POST are procedural actions which can only be used within User Defined Functions. These Actions indicate that all the Data Updation Actions falling between the Actions START BATCH POST and END BATCH POST must be updated to the database in Batches. Instead of the data being directly updated to the database, the data is updated to a temporary file, and once the Batch Size limit is reached, the entire data is flushed from the temporary file into the database.

A Batch is a set of objects, wherein the batch size can be specified by the TDL Programmer as an optional parameter to the Action START BATCH POST. In the absence of this parameter, the default size of the batch is considered as 100 Objects. On encountering the batch size limit, the temporary file posts/flushes the data into the Tally database. On completion of the posting of the previous batch of data, the subsequent batch posting iteration takes place, and this cycle continues till the entire data is updated to the database. The bigger the batch size, the lesser the total number of batches, and the better the performance. The operation will be accomplished faster if the Batch Size specified is optimal. A very high Batch Size, beyond a particular point, may also deteriorate the performance. Hence, striking the right balance and specifying the optimal batch size is important to achieve the best performance.

Syntax

START BATCH POST [:<Batch Size>]

NEW OBJECT: <Object Type>: <Object Name> : <Forced Update Flag>

Action 1

Action 2

:

:

Action n

SAVE TARGET

END BATCH POST

Where,

<Batch Size> is the size of each batch.

Note: In the absence of Action END BATCH POST , the End of the User Defined Function is assumed as the end of Batch Posting. However, it is recommended to specify END BATCH POST , especially in presence of nested loops/ large volume of data.

Example

[Function : Create Ledgers]

Parameter : pNumberofLedgers : Number : 1000

000 : START BATCH POST : 500

010 : For Range : i : Number: 1: ##pNumberofLedgers

020 : New Object : Ledger

030 : Set Value : Name : “Customer ” + $$String:##i

040 : Set Value : Parent : “Sundry Debtors”

050 : Create Target

060 : End For

070 : END BATCH POST

In this example, when the Function “Create Ledgers” is invoked, 1000 Ledgers, ranging from “Customer 1” to “Customer 1000”, are created under the group ‘Sundry Debtors’. If the Batch Posting feature was not used, the database files would get locked and released for updating every object, and this would continue till all the Objects were updated. Thus, 1000 cycles would take place, affecting the performance adversely. However, with Batch Posting approach, these Objects are updated in 2 batches of 500 Objects each, i.e., the database is locked and released only twice, thus improving the performance vastly. The impact of this enhancement can be observed during updation of data of large volume. For instance, the following table shows the statistics of time taken for creating 1000 ledgers using the given code, but with different Batch Size:

Particulars 

Batch Size

Approx. time taken

Without Actions START BATCH POST and END BATCH POST

NA

3 Minutes 29 Seconds

With Actions START BATCH POST and

END BATCH POST

100

4 Seconds

500

2 Seconds

1000

1 Second

Table 1. Batch Posting Statistics

As seen in the table, with the usage of the Actions START BATCH POST and END BATCH POST, the time taken reduces significantly. Also, it is noticed that with increase in the Batch Size, the performance keeps improving. The operation will be accomplished faster if the specified Batch Size is equal to the total number of Objects being updated, i.e., in this case, specifying the Batch Size as 1000 will give optimal performance as 1000 objects will be posted to the database at a time.

Limitation

Greater the Batch Size, better the performance of data updation. However, the database files are locked from the beginning till the end of the write operation of each Batch. This results in unavailability of the Database for data updation from other sources executing parallelly, like data entry in a Multi-User Environment, Data Synchronization, etc. Thus, a higher value of Batch Size will improve the performance, but will slow down the simultaneous updation of Data. Hence, determining the Optimal Batch Size is necessary to strike the right balance for getting the best performance. A very high Batch Size, beyond a particular point, may deteriorate the performance.

Points to remember

  • Actions START BATCH POST and END BATCH POST are not be used in a nested manner. If used so, only the first instance is considered, while the remaining ones are ignored.
  • A Batch can only be ended or closed in a Function where it is initiated. If the user misses the closing part, the System will END the batch implicitly.
  • One must backup the data prior to using the Batch Posting Feature, as incorrect usage of the same may lead to corruption/loss of data.
  • For Import of Data also, we have a parameter similar to Batch Size, i.e., Import Batch Size, which can be used to improve the performance while Importing Data. This parameter can be specified in Tally.INI, in the absence of which, it is set to 100 by default. Setting this parameter to a higher value will decrease the time taken for Import, but will increase the wait time for other simultaneous data updation operations. Setting it to -1 will disable the Batch Posting feature for Import of Data, which means that the Data Import would consume a longer time, as every Object would need to be updated to the database individually.

Asynchronous Message Box Actions – START MSG BOX and END MSG BOX

These are asynchronous message boxes, i.e., the message box continues to appear till the action ‘End Msg Box’ is encountered or the function is terminated, whichever is earlier. Unlike action ‘Msg Box’, this action is executed asynchronously, i.e., it does not expect a key press from user. When executed, it displays the message box, and continues to execute the subsequent Actions.

Syntax

Start MSG BOX : <Title Expression> : <Message Expression>

<Action 1>

:

<Action n>

End MSG BOX

Where,

< Title Expression > is the value that is displayed on the title bar of the message window.

< Message Expression > is the actual message displayed in the box. It can be an expression as well, i.e., the variable values can be concatenated and displayed in the display area of the box.

Example

[Function : M sgBox A ctions]

Variable : C o unter : Num b er

Variable : TotalCount : Num b er : 100

Returns : N u mber

Local Formula : StrTotalCou n t : ($$S t ring:##TotalCo u nt)

Local Formula : StCounter : ($$String:##Counter)

00 : Start M sg Box : Stat u s : “T h is Fun c tion cr e ates” + @St rTotalC o unt + Ledgers”

10 : Sta r t Progr e ss : # # TotalCo u nt : # # SVCurre n tCompa n y : “Cre a ting Le d gers” : “Please wait”

20 : W hile : # #Count e r < ##T o talCou n t

30 : New O b ject : Ledger : “L e dger” + @StrC o unter : Y es

40 : S e t Value : Name : Ledger” + @St r Counter

50 : S e t Value : Par e nt : Sundry D ebtors”

60 : Save T arget

70 : Incre m ent : Count e r

80 : Show P rogres s : ##Cou n ter

90 : E nd While

100 : End Progress

110 : End Msg Box

Here, the action ‘Start Msg Box’ invokes the message box and retains it till action ‘End Msg Box’ is encountered. Thus, the message box will continue to appear from label 00 to 110. In absence of ‘End Msg Box’, the msg box is automatically terminated when the Function MsgBox Actions ends.

Note: If nested Start Msg Box is executed, then the previous Message box is overwritten. At any time, only one Message Box can be displayed.

System Actions

Action – Load TDL

An Action ‘ Execute TDL ’ was introduced in Release 3.6 to load a TDL dynamically, execute some action, and then unload the TDL or keep it, depending on the Logical Value. With this Action, the TDL would get loaded. However, the execution of action was mandatory. In Release 4.8, an action ‘Load TDL’ has been introduced to load the TDL/TCP dynamically for only the current session of Tally. However, if the TDL File is already loaded due to being specified in Tally.INI, or through previous execution of the Action ‘Load TDL’/‘Execute TDL’, it will not be loaded again. On closing the current session of TallyPrime, the dynamically loaded file(s) will not be available for the subsequent Tally Session.

Syntax

LOAD TDL : <TDL/TCP File Path Expression>

Where,

<TDL/TCP File Path Expression> evaluates to the path of the TDL/TCP File to be loaded dynamically.

Example

[Button : Load Dynamic TDL]

Key    : Alt + L

Action : Load TDL : @@TDLFilePath

[System : Formula]

TDLFilePath : “C:Tally.ERP9TDLSamples.tcp”

In this example, on triggering the button ‘Load Dynamic TDL’, the action ‘Load TDL’ loads the TDL from “C:Tally.ERP9TDLSamples.tcp”. If this TDL is already loaded due to being specified in Tally.INI, or previous execution of the Action ‘Load TDL’, then the same will not be loaded again.

Note: Local TDLs will be loaded at the Remote End if ‘Allow Local TDLs’ is enabled to the user logged in.

Action – Unload TDL

To unload the TDL dynamically from the current Tally Session, the Action ‘Unload TDL’ has been introduced. With this Action, the local TDL File(s), including the ones added through Tally.ini and those added dynamically using Actions ‘Load TDL’ or ‘Execute TDL’, can be unloaded. However, they would be unloaded only for the current Tally Session, and in the subsequent session, all the TDL/TCP files specified in Tally.INI will be loaded once again. Using this action, the Files can be unloaded by specifying either the TDL /TCP file name or the GUID of the TCP File.

Syntax

UNLOAD TDL : <TDL/TCP File Path Expression or GUID Expression>

Where,

< TDL/TCP File Path Expression or GUID Expression > evaluates to the path of the TDL/TCP File or GUID of the TCP File to be unloaded dynamically.

Example

[Button : Unload Dynamic TDL]

Key    : Alt + U

Action : Un l oad TDL : @@TCPFileGU I D

[System : Fo r mula]

TCPFileGUID : “c29 0 1088-3 4 9b-434b 946c-9 a da601fd 6 b7”

In this example, on triggering the button ‘Unload Dynamic TDL’, the Action ‘Unload TDL’ unloads the Compiled TDL with the GUID “c2901088-349b-434b-946c-9ada601fd6b7”. If the particular TDL is not found to be loaded, then the same is ignored. If the TCP File was dynamically loaded, then the same is removed from the List of TDL Files. However, if the TCP File was available in Tally.INI, then the same is removed temporarily and reloaded in the subsequent session of Tally.

Note: 

Account/Remote TDL file(s) cannot be unloaded using Action ‘Unload TDL’.

Once a TDL is unloaded explicitly, if one attempts to load such TDL file(s) by changing the TDL Configuration, the file(s) will not be loaded in that session.

 

Release 5.3

Action – Exec Excel Macro

The action Exec Excel Macro invokes the available macros defined in the Excel.

Syntax

Exec Excel Macro : <Macro Name> [:<Parameter list>]

Where,

< Macro Name > is the name of the macro.

< Parameter list > can be n number of parameters that correspond to the parameters required by the Excel macro.

Example

On : After Export : Yes : Exec Excel Macro : MacrotoComputeGraphs : PieChart

In the above example, when the macro MacrotoComputeGraphs is executed, it displays the values in Excel as a pie chart.

Release 5.3.8

As we are aware, File Input/Output capability is used to support read/write operations in an Excel or Text file.

Currently, if we write any value to an excel file using File I/O approach, the appropriate column has to be adjusted manually based on the cell width after completion of the task. Now, a new capability is introduced to update the Cell Properties, Width and Text Wrap.

These properties can be set in TDL using the action, Format Excel Sheet.

Action – Format Excel Sheet

Action Format Excel Sheet is used to set the cell properties of Excel sheet. It accepts two parameters.

Syntax

Format Excel Sheet : <PropertyName> : <PropertyParms>

where,

< PropertyName > is a system keyword for an Excel cell property, viz.,ColumnWidth or CellTextWrap.

< PropertyParms > is a list of required parameters for the specified PropertyName and the number of parameters vary based on the PropertyName.

Example

[Function: FileIOExcel]

Variable : InputFile : String : “D:SampExcel.xls”

010 : Open File: ##InputFile : Excel : Write

020 : Format Excel Sheet: CellTextWrap : 5 : 6 : Yes

030 : Format Excel Sheet: ColumnWidth: 1 : 30

040 : Close Target File

In the above example, CellTextWrap is the PropertyName and “5: 6: Yes” is the parameter required for the CellTextWrap property.

Supported Properties

ColumnWidth

Syntax

ColumnWidth: <ColumnNumber> : <Width>

where,

< ColumnNumber > is used to specify the column number whose width is to be modified.

< Width > is the number used to set the new width of the column. Unit of measurement used for this parameter is Points.

CellTextWrap

Syntax

CellTextWrap:<RowNumber>:<ColumnNumber>[:<Enablewrapping>]

where,

< RowNumber > is used to specify the row number of the cell.

< ColumnNumber > is used to specify the column number of the cell.

< Enablewrapping > is an optional parameter which specifies whether to wrap the text or not. The default value of this parameter is Yes.

Note: An expression can also be specified in any of the parameters for the action.

Release 5.5.2

Action – Browse URL

The action Browse URL is enhanced to accept a logical value as an optional fourth parameter to open the URL in Admin mode.

Syntax

Action: Browse URL: <URL Formula>: [<Command Line Parameters>:<Logical Expression1>: <Logical Expression2>]

Where,

< URL Formula > is an expression which evaluates to a link to a website or a folder path.

< Command Line Parameters > is the list of command-line parameters separated by space. It is an optional parameter.

< Logical Expression 1 > can be any expression which evaluates to a logical value. When this parameter is set to yes, it executes the given action in hidden mode. It is an optional parameter.

< Logical Expression 2 > can be any expression which evaluates to a logical value. When this parameter is set to yes, it executes the action in admin mode. It is an optional parameter.

Post a Comment