TDL or Tally Definition Language and Its Components

TDL or Tally Definition Language is a definition-based language. It is a language that is action-driven. A specific code segment is executed whenever an action is performed by the user. In this blog, you can get an overview and understand the basic functionality of each component used in a TDL program.

What is Tally Definition Language?

Tally Definition Language is the application development language of Tally which emphasizes strongly on re-usability concept. TDL gives users the ability to expand Tally’s default capabilities and integrate them with third-party applications. TDL is used to build the entire user interface of TallyPrime. TDL as a language provides flexibility, power, and extended capabilities for Rapid Development, Rendering, Data Management, and Integration.

It comprises of Interface and Data objects. The behavior of the product in terms of user experience is largely determined by interface objects. In the Tally Database, data objects are primarily used for data persistence. TDL can be learned by any TallyPrime user and build Tally extensions.

About writing a Basic TDL Program

Create a TDL Program Step-by-step

• Launch any ASCII text editor like notepad, or use Tally’s integrated IDE TallyPrime Developer.
• Make a new file.
• Enter TDL statements in the file.
• As required by the editor, save the file with an appropriate name and extension. The file can be saved with the extensions ‘. txt’ or ‘. tdl’ by the editor.
• It is feasible to compile the file into the .tcp extension (Tally Compliant Product). Compiling the file for a specific Tally serial number is possible.
• TallyPrime supports all file types, including.txt,.tdl, and .tcp.

TDL Files Specification:

The TDL code can be implemented in two ways:

1. Using Tally.ini (Configuration Settings File) to specify TDL files.
2. TallyPrime application’s TDL Management configuration allows you to specify TDL files.

1. Using Tally.ini to specify TDL files

TDL program path must be defined in the Tally.ini file using the ‘TDL’ parameter. TallyPrime won’t read any TDL parameters from the Tally.ini file if the ‘User TDL’ parameter is set to NO.

Syntax

TDL User = Yes

TDL = with extension <Path\filename>

Example

OR

TallyPrime searches for a file called ‘BusinessReport.tcp’ or ‘BusinessReport.txt’ in the C:TallyPrime directory. TallyPrime checks and loads into memory each TDL file listed in Tally.ini before presenting the ‘Gateway of Tally’ (first Menu), after loading into memory the default TDL files.

2. Using the TallyPrime application configuration screen to specify a TDL file

Likewise, go to F1: Help >TDLs & Add-Ons and click on F4: Manage Local TDLs to specify the TDL file name in the TDL Configuration screen. Here, set the value for Load selected TDL files on startup to Yes and choose a filename from your system’s respective folders.

The Load parameter is needed to load a Default Company in TallyPrime as follows:

Example

The business folder that resides in TallyPrime\Data is 00002. The parameter ‘Data’ can be used to specify the data path.

Example

Note: If any modification is made in the TDL program, restart TallyPrime to implement the effect.

Using Include Definition to execute Multiple Files

Since TDL can span or operate across files, the ‘INCLUDE’ definition allows you to modularize your application and use one TDL file to specify all of them. It helps the user to incorporate TDL code existing in distinct file/ files, into the current file.

As the name implies, ‘include’ allows one to include another TDL file into a file rather than declaring it separately in Tally.ini.

Syntax

[Include : <path/filename>]

If the TDL file is in the same location, either the name of the file or the whole file path must be specified.

Example

Assume we’re working with two files: test1.txt and test2.txt. We must include test2.txt in test1.txt in order to run both files.

Interfaces of TDL

TDL is a definition-based language, as we know. Menu, Report, Button, and Table are the interfaces that appear on the screen when we start TallyPrime. To create the same specific definitions are provided in TDL.

A report and a menu can independently occur. A Menu is formed by adding items while Form, Part, Line, and Field are used for making the report. These are the definitions that would not be possible without the Report. TDL is based on the idea of an action to be performed and act on the definition. The action triggers the Report.

The Report, Form, Part, Line, and Field as well as the action to conduct the Report, are all included in the TDL program to produce a Report. There can be several Form, Part, Line, and Field definitions in a Report, but at least one must be present.

The following is the hierarchy of these definitions:

• Form is used in the Report.
• Part is used by a Report.
• Line is used by a Report.
• Field is used by Line.
• The content is displayed or entered in a field.

The Report can be reached through a Menu or a Key event.

What is Hello TDL Program?

The ‘Hello TDL’ program illustrates TDL’s fundamental structure. The report is performed from the existing menu ‘Tally Gateway.’ The goal is to: To set up a new Report with the text “Welcome to the world of TDL” from the main menu, select “Gateway Of Tally”.

In the ‘Gateway Of Tally’ menu, this code introduces a new Menu Item First TDL. The Report ‘First TDL Report’ is shown after the Menu Item has chosen the report. Since the action ‘Display’ was mentioned when adding the ‘First TDL menu item,’ the report is in ‘Display’ mode. This report does not accept user input.

TDL Components

Definitions, Attributes, Modifiers, Data Types, Operators, Symbols and Prefixes, and Functions are cover under TDL. Let’s analyze the language’s components now.

Definitions

Tally Specification Language (TDL) is a definition-based non-procedural programming language.  Working with TDL has several advantages, the most important of which is the reusability of definitions. All the definitions are self-contained and can be included in other definitions. TallyPrime must be restarted if a code change has to be replicated in a program. Any definitions begin with an open square bracket and end with a closed one.

Syntax

[<Definition Type> : <Definition Name>]

Where,

<Definition type> is one of the platform’s predefined definition types, such as Collection, Menu, Report, Form, Part, Line, and so on.

<Definition Name> refers to any user-defined name that the user gives to instantiate the definition, i.e., when a definition is formed, a new entity of a specific definition type is created.

Example

In this example, Part is the definition type, and PartOne is the name of the definition.

Definition Types

The following is a list of different TDL definitions:

• Interface Definitions – Menu, Button, Fields, Form, Report, Part, Line, Table
• Data Definitions – Object, Collection, Variable
• Formatting Definitions – Color, Border, Style
• Integration Definitions – Import Object & File
• Action Definitions – Key
• System Definitions

Interface Definitions

Interface definitions are the definitions that are used to create a user interface. Menu, Report, Form, Part, Line, Field, Button, and Table are all these category definitions.

Menu: A list of options is displayed under this. The TallyPrime system defines the action to be taken based on the user’s pick from a Menu Item. A ‘Menu’ is an example of a ‘Gateway of Tally’. Another Menu or Report can be accessed by a Menu.

Report: Report is the basic definition of TDL. The ‘Report’ definition is used to create any screen that appears in TallyPrime, whether it is an input screen or an output screen. One or more Forms make up a Report.

Form: A Form is made up of one or more Parts.

Part: A Part is made up of one or more Lines.

Line: A Line is made up of one or more Fields.

Field: The actual display/entry of data (constant or variable) takes place in this field.

Button: A person can manage action in one of three ways: by choosing a menu object, pressing a key, or by a button click. The ‘Button’ definition enables the user to show a button on the Button bar that, when pressed, performs an action.

Table: The ‘Table’ definition creates a Table to display the list of values. A Table can be used to view data from any collection.

Data Definitions

Data Definitions refer to the definitions that are used to store the data. Object, Variable, and Collection are the categories in these definitions.

Object: This definition includes data as well as associated/related functions that manipulate the data also known as methods. User interface and Info Objects create TDL. Info Objects may be external (defined by the user) or internal (defined by the platform).  The Tally database does not persist external or user-defined objects. Internal Object Definitions cannot be created in TDL; instead, they are platform predefined.

Collection: A group of items is referred to as a collection. Internal or external items may be included in a collection. These may also be focused on multiple collections. Users may make a collection by combining collections at a lower level in the object hierarchy.

Variables: Variables are used to monitor how reports behave and what they contain. During execution, different values can be assumed using variables, and the application will act in accordance with those values. When printing the invoice Plain Paper/Pre-Printed options are variable controlling the report.

Formatting Definitions

Formatting Definitions are definitions that are used in the formatting of a user interface. Border, Style, and Color are the definitions in this category.

Border: This adds a single or double line according to the users’ preference. Pre-defined borders include the Thin Box, Thin Line, and Common Border.

Style: When using a font scheme, the ‘Style’ definition specifies the text appearance to be displayed. The ‘Design’ definition can be used to change/define the font name, font style, and font size. Normal Bold, Normal Italic and Normal Bold Italic are the pre-defined Style definitions in TDL by default.

Color: A color is defined using the ‘Color’ definition. An RGB color value can be given a name. Once an RGB color value has been given a name, it can be represented as an attribute. Crystal Blue and Canary Yellow are the only color names that can be specified in TDL.

Integration Definitions

Integration Definitions are definitions that allow data to be imported using the SDF (Standard Data Format). The two definitions in this category are ‘Import Object’ and ‘Import File.’

Import Object: The type of data being imported into TallyPrime is identified by the Import Object. Groups, Ledgers, Cost Centers, Stock Items, Stock Groups, Vouchers, etc. are some of the types of objects that can be imported.

Import File: The ‘Import file’ definition enables the user to define the layout of each record in the ASCII file being imported. This field width definition is stated as an attribute.

Action Definitions

The user will state an action to be performed when a combination of the key is pressed using the action definitions. It also identifies the object on which the operation is carried out. This is where the definition of ‘Key’ comes.

The ‘Key‘ Definition is used to link an action to a specific key combination. When the corresponding key combination is pressed, the action takes place.

System Definitions

The administrator profile is thought to be the one who creates System Definitions. Any items specified in the System Definitions are accessible throughout the application globally.

TDL allows you to describe system definitions as many times as you want. The defined items are added to the current list. Modification is not possible in this definition.

Variable, System: Formula, System: UDF, and System: TDL Names, are some examples. 

Attributes

Each definition has ‘Attributes‘ which are properties. For each type of description, the platform provides a predefined collection of attributes. The behavior of a definition is stated by the attribute. The attributes vary from one Definition to the next. Several attributes can be associated with a Definition. Each attribute has a predefined ‘Name’ and a value (provided by the programmer) for it.

A value can be directly associated with an attribute or via symbols and prefixes. Aside from a direct value association for the attribute, there are ways to dynamically associate alternative values based on runtime conditions.

Syntax
[<Definition Type> : <Definition Name>]
<Attribute Name> : <Attribute Value>

Where,

< Attribute Name > is the name of an attribute, particular for the definition type.

< Attribute Value > can be a formula or a constant.

Example

Classification of Attributes

Attributes are classified according to the number of values they accept and whether they can be specified several times under the definition, i.e., the number of sub-attributes and values-based.

There are seven different types of attributes:

Single and Single List

An attribute of a single type can only accept one value and cannot be defined more than once. Set As, Width, Style, and others are all of the ‘Single’ type attributes.

Example

Since ‘Set As’ is a ‘Single’ type attribute, the string “TDL” is presented in this field. The last listed attribute’s value will be shown. A Single List type attribute takes only one value that can be listed multiple times. A comma-separated list can also be used for this attribute.

Example

There will be three fields on Line 1 line: Fld 1, Fld 2, and Fld 3.

Dual and Dual List

Dual attributes type can only have two values and cannot be defined more than once. The ‘Repeat’ attribute is an illustration of the ‘Dual’ type.

Example

Attributes type of the Dual List consider two values and can be listed multiple times.

Example

The variables Var 1 and Var 2 are given the values “Hello” and “TDL,” respectively.

Triple and Triple List

Triple type attributes consider three values and cannot be defined more than once.

Example

Three values are accepted by Triple List type attributes, which can be listed multiple times.

Example

The Attribute type ‘Menu item’

The user can add a menu item to the assigned ‘Menu’ definition using the ‘Menu Item’ attribute type.

Example

In the ‘Gateway of Tally’ Menu, the user can include the options ‘Sales Analysis’ and ‘Purchase Analysis.’ The character ‘P’ is specifically defined as a hotkey for the ‘Purchase Analysis’ option.

Attributes of Interface Definitions

This section explains the most commonly used attributes of interface definitions such as Report, Form, Part, Line, and Field.

Report Definition Attributes

Form

Any report needs one or more Forms. If there are multiple forms, the first one will be shown by default.  All of the forms will be printed one by one if one form is in ‘Print’ mode.

Syntax
Form : <Form Name>

Example

Using the form “HW Form” this code states the “HW Report” report. If no Forms are defined for a Report, TallyPrime concludes the Form Name is the same as the Report Name and searches for it. TallyPrime displays, if it exists and if not then TallyPrime will show an error message stating that ‘Form : Report Name> does not exist.’

Title

The attribute ‘Title’ is used to give the Report a meaningful title.

Syntax

Title : <String or Formula>

When a report is invoked from the menu, TallyPrime shows the name of the report as the Title by default. The ‘Title’ attribute overrides the default title if it is defined.

Example

Instead of HWReport, here the title of the Report is shown as “Hello World”.

Form Definition Attributes

Part/Parts

Parts in a Form are described by the attribute ‘Part.’ The synonyms ‘Part’ and ‘Parts’ are of the same attribute. It defines the names of the Form’s Parts. The Parts are vertically aligned by default.

Syntax

Part/Parts : <List of Part Names>

Starting at the top of the Form, two parts are defined by the code segment, HW Title Partition and HW Body Partition vertically aligned.

Example

HW Title Partition and HW Body Partition are explained in this code segment.

Part Definition Attributes

Line/Lines

The Lines in a Part are defined by this attribute.

Syntax

Line/Lines : <list of line names>

Example

Line Definition Attributes

Field/Fields

The ‘Field’ and ‘Fields’ attributes are identical. They begin on the left side of the screen or page, in the order, they are specified.

Syntax

Field/Fields : <List of Field Names>

Example

Set as

This attribute sets the Field a value.

Syntax
Set as : <Text or Formula>

Example

In this case, the report displays the text “Hello TDL.”

Info

The Info attribute is used to set prompts and titles text as display strings. Unlike the attribute “Set as”, this attribute does not permit the cursor to be located on the current field even when placed in Create/ Alter mode. The attributes ‘Set as’ and ‘Info’, on the other hand, work similarly in Display mode.

Syntax
Info : <Text or formula>

Furthermore, if both Set as and Info attributes are defined, the attribute Info takes precedence, and the attribute Info set values take precedence over the value set in the Set As attribute.

Example

Skip

Even if the report is in the mode to ‘Create’ or ‘Alter’, this attribute forces the cursor to skip the specific field, restricting the user from changing the value in the field.

Syntax
Skip : <Logical Formula>

Example

The value in the ‘HW Field’ is set to ‘Hello World’ using this code snippet and the cursor is forced to skip the field. It’s even possible to rewrite it as:

Note: Info attributes at Field blends the Skip and Set As.

Modifiers

Modifiers are applied to a definition or an attribute to perform a particular action. Depending on whether a definition or an attribute is being changed, they are known as Definition Modifiers or Attribute Modifiers. #,! and * are definition modifiers. Use, Add, Delete, Replace/Change, Option, Switch, and Local are all attribute modifiers.

Based on the evaluation mode, the modifiers can also be divided into two types:

• Static/Load time modifiers: Use, Add, Replace/Change, Delete
• Dynamic/Real-time modifiers: Option, Switch, and Local

Static/Load time Modifiers

These modifiers don’t need any run-time conditions. Only at load time evaluation of value is done and throughout the execution, it remains constant. The static modifiers are Use, Add, Delete, and Replace.

Use

In a definition, the USE Keyword is used to reuse an existing Definition.

Syntax

Use : <Definition Name>

Example

The field DSPExplodePrompt acquires all of the properties of the current field definition Medium Prompt.

Add

In a definition, the ADD modifier is applied to add an attribute to the Definition.

Syntax

Add : <Attribute Name> [:<Attribute Position>:<Attribute Name>]:<Attribute Value>

Where,

<Attribute Name> The attribute name specific to a particular type of definition.

<Attribute Position> is any keywords Before, After, At Beginning, and At End. The position is set to At End by default.

<Attribute Value> is a constant or a formula.

Example

A new ChangeItem button is added to the Cost Centre Summary form.

Example

In the part ‘VCH Narration,’ the lines ‘VCH ChequeName’ and ‘VCH AcPayee’ are placed before the line ‘VCH NarrPrompt.’

Delete

In a definition, the ‘Delete’ modifier is used to delete a Definition attribute.

Syntax

Delete : <Attribute Name> [:<Attribute Value>]

Where,

< Attribute Value > is an optional that can be either a constant or a formula. 

If the value of attribute is absent, all of the attribute’s values are moved.

Example

The ‘ChangeItem’ button has been deleted from the ‘Cost Centre Summary‘ form. In the ‘Cost Centre Summary’ form, the functionality of the ‘ChangeItem’ button is no longer accessible. If the name of the Button is not mentioned, all of the buttons on the Form will be removed.

Replace

The ‘Replace’ modifier is used to change the Definition attributes.

Syntax

Replace : <Attribute Name> : <Old Attribute Value> : <New Attribute Value>

Where,

<Attribute Name> is the attribute name specified for a particular type of definition.

<Old Attribute Value> and <New Attribute Value> can be a formula or a constant.

Example

The form “Part1” part “Cost Centre Summary” is substituted by “Part2.” Only the properties of ‘Part2′ are now applicable.

Dynamic/Real-time modifiers

Dynamic modifiers are evaluated based on a condition at run time. These modifiers are applied every time the TDL is run in a Tally case. The Dynamic modifiers are ‘Option,’ ‘Switch,’ and ‘Local’.

Local

The attribute ‘Local’ is used in the definition context to set a local value that is only within the defined scope.

Syntax
Local : <Definition Name> : <Old Attribute Value>: <New Attribute Value>

Example

The new value for the attribute Set As of the field Name Field for this example is the formula value #StockItemName. The value will be as in the field definition anywhere else.

Option

Various definitions may use the attribute option to provide a conditional program outcome. The ‘Option’ attribute is applicable to the ‘Menu,’ ‘Form,’ ‘Part,’ ‘Line,’ ‘Key,’ ‘Field,’ ‘Import File,’ and ‘Import Object’ definitions.

Syntax

Option : <Optional definition> : <Logical Condition>

Where,

<Modified Definition> is the name of an optional definition using the definition modifier.

When the value for ‘Logical’ is set to TRUE, the Optional definition becomes a component of the original definition, and the original definition’s attributes are changed as a result of this definition.

Example

When cond1 is valid, the field FldFirst is triggered. When cond2 is correct, the FldSecond field is triggered. For creating optional definitions this symbol prefix ”! ” is used, as shown below:

Switch – Case

The attribute ‘Switch – Case’ is identical to the ‘Option‘ attribute, but it simplifies the code and strengthens the performance of the TDL Program.

The ‘Option’ attribute evaluates all of the criteria for all of the options in the definition code and only applies those that meet the evaluation conditions.

In cases where assessment is performed only until the first condition is met, the attribute ‘Switch‘ can be used.

Aside from that, a label may be used to group ‘Switch’ statements. As a result, several switch groups can be formed, and each group can apply zero or one of the switch cases.

Syntax
Switch : Label : Desc name : Condition

Example

The sequence of Evaluation – Attributes

The attributes evaluation order is as stated below:

• Use
• Normal Attributes
• Add/Delete/Replace
• Option
• Switch
• Local

 Delayed Attributes

Add/Delete/Replace are known as Delayed attributes because their evaluation is delayed until the end of the static modifier and normal attributes, even though they are defined in the specification at the start.

Actions in TDL

TDL is an action-oriented language. Actions are activators of particular functions that produce a defined outcome. Actions are taken on the ‘Report’ and ‘Menu’ definition types. An originator, requestor, and object are often associated with an action. The Menu, Key, and Button are the source of all actions.

The context in which an action is evaluated is the Requestor and the Object. Usually, TDL actions are started by selecting a menu item or assigning a Key or a Button. Display, Menu, Print, Create, Alter, and so on are examples of actions.

Syntax

Action : <Action Name> [: <Definition/Variable Name> : Formula]

Where,

< Action Name > is the action name that will be carried out. Any of the pre-defined actions can be used.

< Definition/ Variable Name > is the definition/ variable name on which the operation is carried out.

Example

Data Types

TDL’s Data Types determine the type of data that will be stored in the field. Apart from the basic types, TDL, as a business language, supports business data types such as amount, quantity, rate, and so on. Simple Data Types and Compound Data Types are the two types of data.

Simple Data Type

There is only one data type. There is no way to classify these data types into subtypes. This category includes the String, Number, Date, and Logical data types.

Compound Data Type

It’s a combination of several data types. Sub-data types are the data types that make up the Compound Data Type. Amount, Quantity, Rate, Rate of Exchange, and Aggregate are the Compound Data types in TDL.

The Type attribute is used to specify the field definition type.

Syntax
[Field : <Field Name>]
Type : <Data type> : <Sub-type>

Example

Operators in TDL

Operators include special symbols or keywords that carry out operations on one, two, or three operands before returning a result. The following are the four types of operators in TDL:

Arithmetic Operators

Logical Operators

OR, AND, NOT, TRUE/ON/YES and FALSE/OFF/NO are the logical operators used:

Comparison Operators

A Comparison Operator compares the operands and provides a logical value depending on whether the comparison is True. The TRUE or FALSE value is returned by the Comparison Operator. The following Comparison Operators are supported by TDL:

String Operators

String operators offer two strings comparisons. The String operators are as follows:

Functions

A function is a piece of code that takes a set of parameters, performs a task, and then returns the output. Although the function can take zero or more arguments, it always returns a value.

The platform defines and provides the functions in TDL. These functions are intended for TDL programmer use and are precisely designed to meet the TallyPrime platform’s business requirements.

Apart from business-specific tasks, TDL has a function library that can be used to perform operations related to string, date, number, and amount. TDL’s basic functions include $$StringLength, $$Date, $$RoundUp, and $$AsAmount. $$GetPriceFromLevel, $$BillExists, $$ForexValue, and other business-related functions are directly supported by TDL.

Syntax
$$<Function Name> : <Argument List>

Example

If the parameter passed is a TDL reserved string, the function $$SysName returns TRUE.

Conclusion:

TDL is focused on Object-Oriented Programming (OOP) concepts. This language was developed with reusability in consideration. When a definition is developed, it can be reused repeatedly, and the user can add extra features to existing definitions.

TDL has definitions for User Interface Objects such as Reports, Forms, Sections, Lines, and Fields. All TDL Definitions have a single view in TallyPrime, which indicates the TallyPrime executable reads TDL (both user-defined and default) as a single program. For Tally Prime on Cloud Live Demo or any query visit Tallystack.in.

FAQ

What are the major functional areas in Tally?

The major Tally functional areas are:

Order to Payment (Purchase Processes)

Ordering, Receipting, Rejections, Discounts, and other Purchase Processes ranging from simple (cash purchase) to advanced.

Order to Receipt (Sales Processes)

Orders Received, Delivery, Invoicing, Rejections and Receipting, POS Invoicing at Retail with simple (cash sales) to advanced sales processes.

Material to Material (Manufacturing Processes)

Material transformations ranging from simple to multi-step, discrete and process industry cycles, work in progress, and valuations.

Payroll

Payrolls ranging from simple to complex, including dealing with various units of measurement (e.g., job rates), statutory compliances, and their requirements and usage.

MIS

The following is a comprehensive list of reports for business requirements:

Financial, MIS & Analysis, Budgeting & Controls, Inventory with advanced classification and filtering techniques, Group companies and multiple consolidation views, Forex handling, Bank Reconciliation, Cross-Period Reporting, etc. There’s also an Export option for porting data to other applications (such as spreadsheets) for further manipulation.

Statutory Compliance

In TallyPrime, the following are the Compliance Requirements and associated configurations for implementing:

• Direct Taxes: TDS/TCS, FBT
• Indirect Taxes: Excise, Service Tax, VAT, CST

Enabling Environment for Remote – Tally.NET Users

Remote Access Services are managed by Tally Software Services (TSS). It enables you to:

• Remote Access – TallyPrime can now be accessed from any computer device by an authenticated user.
• Tax Audit Tools – Clients will now be able to receive low-cost services that answer their security and privacy issues from the CA community.

What are the various categories of languages available?

The various languages categories available today are as follows:

Low-Level Languages: Low-level languages are those that can communicate with hardware directly in computer-understandable digital code or in a pseudo-code.

Middle-Level Languages: Like high-level languages, middle-level languages have syntax, rules, and features but as part of the code can also implement low-level languages.

High-Level Languages: High-level languages are easy to learn, program, and debug. This can be classified into two categories: Third Generation and Fourth Generation languages.

Third Generation Languages: The majority of High-Level languages are classified as Third Generation Languages. Languages of the Third Generation are procedural.

Fourth Generation Languages: Fourth Generation Languages (4GL) are high-level languages with no clear-cut definition. It significantly fewer instructions for task accomplishment. These are non-procedural languages.

To learn more about Tally On Cloud, you can check out our videos.