Tally Technology – The Overall Perspective

Tally Solutions has been in the business of providing complete business solutions for over 30 years to MSME (Micro, Small and Medium Enterprise) and to a large extent to LE (Large Enterprise) businesses. With over 3 million users in over 100 countries, Tally, the flagship product, continues to be the preferred IT solution for a majority of businesses every year.

Tally, the flagship product (which started as a simple book keeping system, 30 years ago), is today a comprehensive, integrated solution – covering several business aspects of an enterprise. These include Accounting, Finance Management, Receivables/Payables, Inventory Accounting, Inventory Management, BoM-based manufacturing inventory, multi-location/multi-currency/multi- unit handling, Budgets and Controls, Cost and Profit Centres, Job Costing, POS, Group Company consolidations, Statutory Taxes (Excise, VAT, GST, CST, TDS, TCS, FBT, etc), Payroll Accounting, and other major and minor capabilities. 

With the introduction of Remote Access, Remote Authentication, Support Centre, Central Administration and Account Management inherently supported in the product, it can be formally labelled as TallyPrime. With this capability, it is possible that the owner or an authorized user will be able to access all the reports and information from a remote location. Additional capabilities will be delivered to cater to large business enterprises. The major functional areas in Tally are:

Order to Payment (Purchase Processes)

Simple (Cash Purchase) to Advanced Purchase Processes – including Ordering, Receipting, Rejections, Discounts, etc.

Order to Receipt (Sales Processes)

Simple (Cash Sales) to Advanced Sales Processes – including Orders Received, Delivery, Invoicing, Rejections and Receipting, POS Invoicing at Retail.

Material to Material (Manufacturing Processes)

Simple to Multi-step material transformations, Discrete and Process Industry cycles, Work in progress and valuations.

Payroll

Simple to Complex Payrolls – including working with different Units of Measures (For example, Job rates), Statutory compliances, their specifications and usage.

MIS

A complete set of reports for Business requirements are as follows:

Financial, Inventory, MIS & Analysis, Budgeting & Controls with advanced classification and filtering techniques, Group companies and multiple consolidation views, Cross-Period Reporting, Forex handling, Bank Reconciliation, etc. There is also an Export option to port data into other applications (For example, Spreadsheets) for additional manipulation.

Statutory Compliance

The Compliance Requirements and related configurations in TallyPrime are as follows, with regard to the implementation of:

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

Enabling Environment for Remote – Tally.NET Users

Tally Software Services (TSS) is responsible for the Remote Access Services. It allows:

• Remote Access – It is now possible for an authenticated user to access TallyPrime from any computer system.
• Tax Audit Tools – The CA community will now be able to deliver affordable services to client, addressing their Security and Privacy concerns.

Tally Definition Language

Tally Definition Language is the application development language of Tally. TDL has been developed to provide the user with the flexibility and power to extend the default capabilities of Tally, and integrate them with the external applications. TDL provides a development platform for the user. The entire User Interface of TallyPrime is built using TDL. TDL as a language, provides capabilities for Rapid Development, Rendering, Data Management and Integration.

TDL is an Action-driven language based on definitions. It emphasizes strongly on the concept of re-usability. It comprises of Interface and Data objects. Interface objects mainly determine the behaviour of the product in terms of user experience. Data objects are mainly used for data persistence in the Tally Database.

Any TallyPrime user can learn TDL and develop extensions for Tally. The entire source code is available as a part of the Tally Development Environment, i.e., with our product Tally Developer.

Comparison With Other Languages

Today, there are many languages in the world which are used to develop applications. These languages are developed keeping some specific areas of application in mind. Some languages are good for developing front-end applications, while others may be good for writing system programs. The various categories of languages available today are as follows:

Low Level Languages

Low level languages are languages that can interact directly with the hardware. They comprise instructions which are either directly given in computer-understandable digital code or in a pseudo code. These languages require very sound knowledge in hardware. For example, Assembly language or any native machine language.

Middle Level Languages

Middle level languages consist of syntax, rules and features just like the high level languages. However, they can also implement low level languages as part of the code. For example, C, C++, etc.

High Level Languages

High level languages are very much like the English language. They are easy to learn, program and debug. High level programming languages are sometimes divided into two categories: Third Generation and Fourth Generation languages.

Third Generation Languages

Most high level languages fall in the category of Third generation languages. Third generation languages are procedural languages, i.e., the programmer specifies the sequence of execution and the computer strictly follows it. The execution starts from the first line of the code to the last line, taking care of all the control statements and loops used in the program.

Fourth Generation Languages

There is no clear-cut definition for the Fourth Generation Languages (4GL). Normally, the 4GL are high level languages which require significantly fewer instructions to accomplish a task. Thus a programmer is able to quickly develop and deploy the code. Most 4GL are non-procedural languages.

For example, some 4GL are used to retrieve, store and modify data in the database using a single line instruction, whereas other 4GL use report generators to generate complex reports. It is sufficient to specify headings and totals using the language, and the report is generated automatically. Certain 4GL can be used to specify the screen design, which will automatically be created.

On having understood the categorization of computer languages, TDL can be categorised as a fourth generation, high level language. The capabilities which TDL provides to the users is much more than what other 4GL languages provide. This may extend to meeting specific purposes like database management, report generation, screen design, etc.

TDL is a comprehensive 4G language which gives tremendous power in the hands of the programmer by providing data management, complex report generation and screen design capabilities, using only a few lines of code, leading to rapid development. Let us now analyse the features in detail, which help us in understanding and appreciating the capabilities provided by the development language of Tally, i.e., TDL – Tally Definition Language.

The TDL Program – At a Glance

Before we discuss the capabilities and features of TDL in detail, let us have a look at the basic TDL program. The following image describes all the components in a TDL Program.

The description, usage, and detailed explanation of each component will be taken up in the subsequent chapters.

Writing a Basic TDL Program

TDL allows us to define tasks in standard English statements. This simplifies the process of definition, allowing even a person without any programming language background to work on TDL.

The TDL statements required to perform a particular task can be created in a file using IDE provided by Tally, such as Tally Developer. Such a file is called a TDL file.

Steps to Create a TDL Program

• Open any ASCII text editor such as notepad, or use the IDE TallyPrime Developer, provided by Tally.
• Create a new file.
• Type TDL statements in the file.
• Save the file with a meaningful name and extension, as applicable to the editor. The editor can save the file with an extension ‘. txt ’, ‘. tdl’ .
• The file can be compiled into a file with an extension.tcp (Tally Compliant Product). It is possible to compile the file for a particular Tally serial number.
• It is possible to run all files, i.e.,.txt,.tdl and.tcp in TallyPrime.

Specification of TDL Files

There are two ways of implementing the TDL code:

• Specifying the TDL files in Tally.ini (Configuration settings file)
• Specifying the TDL files through TDL Management report in TallyPrime application.

Specifying the TDL Files in Tally.ini

The path of the TDL program has to be included in the Tally.ini file, using a parameter called ‘TDL’. If the parameter ‘User TDL’ is set to NO, TallyPrime will not read any TDL parameters specified in the Tally.ini file.

Syntax

User TDL = Yes

TDL           = <Path file name with extension>

Example

User TDL = Yes

TDL      =  C:/TallyPrime/MyReport.tcp

            OR

TDL       = C:/TallyPrime/MyReport.txt

When TallyPrime starts, it looks for a file named MyReport.tcp or MyReport.txt in the directory C:/TallyPrime. On loading the default TDL files into memory, TallyPrime reads and loads every TDL file mentioned in Tally.ini into memory before displaying the first menu, Gateway of Tally.

Specify TDL File Through TallyPrime Application

Alternatively, the TDL file name can be specified in TDL Configuration screen, by going to F1: Help >TDLs & Add-Ons and clicking on F4: Manage Local TDLs. In this screen, set the value as Yes for Load selected TDL files on startup and select filename from the respective folders of your system. 

When the default company is set in TallyPrime, the values get updated in Tally.ini file as follows:

Example

Default Companies = yes

Load = 00002

Here, 00002 is the company folder that resides in the folder TallyPrime/Data. The data path can be specified with the parameter Data.

Example

Data = C:/TallyPrime/Data

Note: It is recommended to restart TallyPrime whenever there are changes made in the TDL program, so that they can be implemented.

Executing Multiple Files Using Include Definition

Since TDL can span or exist across files, the definition Include provides the convenience of modularising the application and specifying all of them in one TDL file. It allows the user to include TDL code existing in separate file/files, into the current file.

Include, as the name suggests, gives us the ability to include another TDL file into a file, instead of declaring it in Tally.ini separately.

Syntax

[Include : <path/filename>]

In case the TDL file is in the same directory, either the file name or the complete path for the file has to be provided.

Example

Let us assume we are using two files, sample1.txt and sample2.txt. To run both the files, we have to include sample2.txt in sample1.txt.

[Include : sample2.txt]

TDL Capabilities

Rapid Development

TDL is a language based on definitions. It is possible to reuse the existing definitions and deploy them. This is a language meant for rapid development. It is possible to develop complex reports within minutes. The user can extend the default functionalities of the product by writing a code consisting of a few lines.

Multiple Output Capability

The same language can be used to send the output to multiple output devices and formats. Whenever an output is generated, it can be displayed on the screen, printed, transferred to a file in particular format, and finally mailed or transferred to a web-page using Http protocol. All this is made possible just by writing a single line of code. Just imagine the technology used to develop the platform that such a complex task is developed and implemented using only a few lines.

Data Management Capability

As discussed earlier, the data is stored and retrieved as objects. There are a few internal objects predefined by the platform. Using TDL, it is possible to create and manipulate information on these with ease. Suppose, an additional field is required by the user to store information as a part of the predefined object. This capability is also provided in TDL, i.e., by using TDL, the user can create a new field and store a value into it, which can be persisted in the TallyPrime database.

Integration Capability

To meet the challenges of the business environment, it becomes absolutely mandatory to share information seamlessly across applications. Integration becomes a crucial factor in avoiding the duplication of data entry. The TallyPrime platform has a built-in capability of integrating data with other applications. The following are the different types of integrations possible in TallyPrime:

• TallyPrime to TallyPrime using Sync
• TallyPrime to external applications in various data formats
• External DB to TallyPrime using XML, JSON, SDF formats
• TallyPrime DB to external applications using ODBC
• External DB to TallyPrime using ODBC

TDL Features

Definition Language

A definition language provides the users with Definitions that can be used to specify the task to be performed. The user can specify the task to be performed, but has no control over the sequence of events that occur while performing the specified task. The sequence of events is implicit to the language and cannot be changed by the user. TDL works on Named Definitions, which means that every definition should have a name and that name should be unique. TDL has User Interface Objects like Reports, Forms, Parts, Lines and Fields as definitions.

TDL can define Reports, Menus, Forms, and so on, but the Definitions will not have any relevance unless they are used. Definitions are deployed by use, not by existence.

TDL is based on concepts pertaining to Object Oriented Programming. This language has been created for reusability. Once a definition is created, it can be reused any number of times. Besides the reusing capability, the user can also add new features, along with the existing definitions.

TallyPrime has a singular view of all the TDL Definitions, which means that the TallyPrime executable reads TDL (user defined and default) as one program. On invoking TallyPrime, all the default TDL files of tdlserver.dll will be loaded. The user TDLs will be subsequently loaded as specified in Tally.ini.

Non-Procedural Language

Most of our programming experience has been in dealing with a procedural language where we define a sequence of actions to define the sequence of events that take place. The entire control is with the programmer. The programmer is able to determine the start and end-point of the program. The programmer cannot control the sequence. All the sequences are implicit in the program. The programmer cannot write his/her own procedure. The platform provides a set of functions for the TDL programmer.

Action-Driven Language

The programmer can only control as to what happens when a particular event takes place. During interaction, the user can select any sequence of actions. Based on the action, a particular segment of code gets executed.

Rich Language

TDL is a rich language, that refers to a list of functions, attributes, actions, etc., which are provided by the platform. It is possible to develop a complex report or modify the existing one within no time. Imagine how many lines of code would be required if a simple button were to be added using a traditional programming language.

Flexibility and Speed

The architecture of the software and the language provide extraordinary flexibility and speed. Speed in this regard refers to the speed of deployment. With TallyPrime, the deployment is extremely rapid.

TallyPrime is flexible enough to change its functionality based on the customer’s business requirements. Most of the times, the customer-specific requirements may seem like major functional changes that have to be done, but they may only be minor variations of the existing functionality, which can be done within no time.

TDL Interfaces

TDL is a language based on definitions. When we start TallyPrime, the interfaces which are visible on the screen are Menu, Report, Button and Table. In TDL, specific definitions are provided to create the same.

A Report and Menu can exist independently. A Menu is created by adding items to it while a Report is created using Form, Part, Line and Field. These are the definitions which cannot exist without a Report. TDL operates through the concept of an action which is to be performed and Definition on which the action is performed. The Report is invoked based on the action.

TDL program to create a Report contains the definitions Report, Form, Part, Line and Field and action to execute the Report. A Report can have more than one Form, Part, Line and Field definitions, but at least one has to be there.

The hierarchy of these definitions is as follows:

• Report uses a Form
• Form uses a Part
• Part uses a Line
• Line uses a Field
• Field is where the contents are displayed or entered

The Report is called either from a Menu or from a Key event.

Hello TDL Program

The Hello TDL program demonstrates the basic structure of TDL. The Report is executed from the existing Menu Gateway of Tally.

Purpose: To invoke a new Report displaying the text Welcome to the world of TDL from the Menu Gateway Of Tally.

[#Menu: Gateway of Tally]

Item : First TDL : Display : First TDL Report

;;code comments

[Report: First TDL Report]

Form : First TDL Form

[Form: First TDL Form]

Parts : First TDL Part

[Part : First TDL Part]

Lines : First TDL Line

[Line : First TDL Line]

Fields : First TDL Field

[Field : First TDL Field]

Set as : “Welcome to the world of TDL”

This code adds a new Menu Item First TDL in the Gateway Of Tally menu. When the Menu Item has selected the report, the Report First TDL Report is displayed. The report is in Display mode, as the action Display is specified while adding the menu item First TDL. User inputs are not accepted in this report. The text Welcome to the world of TDL is displayed in the Report, since it contains only one field.

TDL Components

The TDL consists of Definitions, Attributes, Modifiers, Data Types, Operators, Symbols and Prefixes, and Functions. Let us now analyse the components of the language.

Definitions

Tally Definition Language (TDL) is a non-procedural programming language based on definitions. TDL works on named definitions. The biggest advantage of working with TDL is its re-usability of definitions.

All the definitions are reusable by themselves and can be a part of other definitions. Whenever a change in code needs to be reflected in a program, TallyPrime must be restarted. All definitions start with an open square bracket and end with a closed bracket.

Syntax

[<Definition Type> : <Definition Name>]

Where,

<Definition Type> is the name of one of the predefined definition types available in the platform, example, Collection, Menu, Report, Form, Part, Line, etc.

<Definition Name> refers to any user-defined name, which the user provides to instantiate the definition, i.e., whenever a definition is created, a new object of a particular definition type comes into existence.

Example

[Part : PartOne]

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

Types of Definitions

The various definitions in TDL are categorized as follows:

• Interface Definitions – Menu, Report, Form, Part, Line, Fields, Button, Resource
• Data Definitions – Object, Variable, Collection 
• Procedural/Action Definitions – Function, COM Interface, QueryBox
• Formatting Definitions – Border, Style, Color
• Integration Definitions – Import Object, Import File
• Action Definitions – Key
• System Definitions

Interface Definitions

Definitions which are used to create a user interface are referred to as Interface definitions. The definitions in this category are Menu, Report, Form, Part, Line, Field, Button and Table.

Menu: A Menu displays a list of options. The TallyPrime application determines the action to be performed on the basis of the Menu Item selected by the user. The ‘Gateway of Tally’ is an example of a ‘Menu’. A Menu can activate another Menu or Report.

Report: This is the fundamental definition of TDL. Every screen which appears in TallyPrime, i.e., any input screen or output screen, is created using the ‘Report’ definition. A Report consists of one or more Forms.

Form: A Form consists of one or more Parts.

Part: A Part consists of one or more Lines.

Line: A Line consists of one or more Fields.

Field: It is the place where data (constant or variable) is actually displayed/entered.

Button: The user can perform an action in three ways, i.e., by selecting a menu item, by pressing a key or by clicking on a button. The ‘Button’ definition allows the user to display a button on the Button bar and execute an action when it is clicked.

Table: The ‘Table’ definition displays a list of values as a Table. Data from any collection can be displayed as a Table.

Data Definitions

Definitions which are used for storing the data are referred to as Data Definitions. The definitions in this category are Object, Variable and Collection.

Object: An object is a definition which consists of data, and the associated/related functions, commonly called as methods that manipulate the data. TDL is made up of User interface and Info Objects. Info Objects can be External (user-defined) or Internal (platform defined). External or user-defined objects are not persistent in the Tally database. It is not possible to create an Internal Object Definition in TDL, i.e., they are predefined by the platform. It is, though, possible to perform modifications on it. A Ledger/Group is an example of an internal object.

An object can further contain an object/objects.

Collection: A Collection is a group of objects. Collections can be made up of internal or external objects. These can be based on multiple collections also. We can create a collection by aggregating the collections at a lower level in the hierarchy of objects.

Variables: Variables are used to control the behaviour of reports and their contents. The variables can assume different values during the execution, and based on those values, the application behaves accordingly. The option Plain Paper/Pre-Printed, while printing the invoice, is an example of a variable controlling the report.

Formatting Definitions

Definitions which are used in formatting a user interface are referred to as Formatting Definitions. The definitions in this category are Border, Style and Color.

Border: This introduces a single/double line as per user specifications. Thin Box, Thin Line and Common Border are all examples of pre-defined borders.

Style: The ‘Style’ definition determines the appearance of the text to be displayed by using a font scheme. The Font name, Font style and Font size can be changed/defined using the ‘Style’ definition. In default TDL, the pre-defined Style definitions are Normal Bold, Normal Italic and Normal Bold Italic.

Color: The ‘Color’ definition is used to define a color. A name can be given to an RGB value of color. Once a name is assigned to an RGB color value, it can be expressed as an attribute. In TDL, the only color names that can be specified are Crystal Blue and Canary Yellow.

Integration Definitions

Definitions which make the import of data available in SDF (Standard Data Format) are referred to as Integration Definitions. ‘Import Object’ and ‘Import File’ are the two definitions classified in this category.

Import Object: This identifies the type of information that is being imported into TallyPrime. The importable objects can be of the type Groups, Ledgers, Cost centre, Stock Items, Stock Groups, Vouchers, etc.

Import File: The ‘Import file’ definition allows the user to describe the structure of each record in the ASCII file that is being imported. The field width is specified as an attribute of this definition.

Action Definitions

The action definitions allow the user to define an action, to take place when a key combination is pressed. It also associates an object on which the action is performed. The ‘Key’ definition falls in this category.

Key: The ‘Key’ Definition is used to associate an action with a key combination. The action is performed when the associated key combination is pressed.

System Definitions

System Definitions are viewed as being created by the administrator profile. Any items defined under System Definitions are available globally across the application.

System Definitions can be defined as any number of times in TDL. The items defined are appended to the existing list.

Examples of System Definitions are System: Variable, System: Formula, System: UDF and System: TDL Names.

Attributes

Each definition has properties, referred to as ‘Attributes’. There is a predefined set of attributes provided by the platform for each definition type. The attribute specifies the behaviour of a definition. Attributes differ from Definition to Definition. A Definition can have multiple attributes associated with it. Each attribute has a ‘Name’ (predefined) and an assigned value (provided by the programmer).

A value can be associated with a given attribute either directly, or through symbols and prefixes. Apart from a direct value association of the attribute, there are ways to associate alternate values dynamically, based on certain conditions prevailing at runtime.

Syntax

[<Definition Type> : <Definition Name>]

<Attribute Name> : <Attribute Value>

Where,

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

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

Example

[Part : PartOne]

Line : PartOne

Classification of Attributes

The classification of attributes is done based on the number of values they accept, and if they can be specified multiple times under the definition, i.e., based on the number of sub-attributes and the number of values.

There are seven types of attributes:

Single and Single List

A Single type attribute accepts only one value and can’t be specified multiple times. The attributes Set As, Width, Style, etc., are all of ‘Single’ type.

Example

[Field : Fld 1]

Set As : “Hello”

Set As : “TDL”

In this field, the string “TDL” is displayed, as ‘Set As’ is a ‘Single’ type attribute. The value of the last specified attribute will be displayed. A Single List type attribute accepts one value, which can be specified multiple times. This attribute also accepts a comma-separated list.

Example

[Line : Line 1]

Field : Fld 1, Fld 2

Field : Fld 3

The line Line 1 will have three fields Fld 1, Fld 2 and Fld 3.

Dual and Dual List

Dual type attributes accept two values, and can’t be specified multiple times. The attribute ‘Repeat’ is an example of ‘Dual’ type.

Example

Repeat : Line 1 : Collection 1

Dual List type attributes accept two values and can be specified multiple times.

Example

Set : Var 1 : “Hello”

Set : Var 2 : “TDL”

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

Triple and Triple List

Triple type attributes accept three values, and can’t be specified multiple times.

Example

Object : Ledger Entries : First : $LedgerName = “Tally”

Triple List type attributes accept three values and can be specified multiple times.

Example

Aggr Compute : TrPurcQty: Sum : $BilledQty

Aggr Compute: TrSaleQty : Sum : $BilledQty

The Attribute type ‘Menu item’

The attribute type ‘Menu Item’ allows the user to add a menu item in the given ‘Menu’ definition.

Example

[#Menu : Gateway Of Tally]

Item : Sales Analysis : Display : Sales Analysis

Item : Purchase Analysis : P : Display : Purchase Analysis

Here, the options ‘Sales Analysis’ and ‘Purchase Analysis’ are added to the ‘Gateway of Tally’ Menu. For the option ‘Purchase Analysis’, the character ‘P’ is explicitly specified as a hotkey.

Attributes of Interface Definitions

Frequently used attributes of interface definitions like Report, Form, Part, Line and Field, are explained in this section.

Report Definition Attributes

Form

Every report requires one or more Forms. If there are more than one forms, then the first form is displayed by default. When one is in ‘Print’ mode, all the forms will be printed one after the other.

Syntax

Form : <Form Name>

Example

[Report : HW Report]

Form : HW Form

This code defines the report ‘HW Report’, using the form HW Form. If one chooses a Report that has no Forms defined, TallyPrime assumes that the Form Name is the same as the Report Name and looks for it. If it exists, TallyPrime displays it. Otherwise, TallyPrime displays an error message ‘Form :<Report Name> does not exists’.

Title

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

Syntax

Title : <String or Formula>

By default, TallyPrime displays the name of the Report as Title, when it is invoked from the menu. If the ‘Title’ attribute is specified, then it overrides the default title.

Example

[Report : HWReport]

Form : HWForm

Title : “Hello World”

Here, “Hello World” is displayed as the title of the Report, instead of HWReport.

Form Definition Attributes

Part/Parts

The attribute ‘Part’ defines Parts in a Form. ‘Part’ and ‘Parts’ are synonyms of the same attribute. It specifies the names of the Parts in a Form. By default, the Parts are aligned vertically.

Syntax

Part/Parts : <List of Part Names>

Example

[Form : HW Form]

Part : HW Title Partition, HW Body Partition

This code segment defines two parts, HW Title Partition and HW Body Partition , which are vertically aligned, starting from the top of the Form.

Part Definition Attributes

Line/Lines

This attribute specifies the Lines contained in a Part.

Syntax

Line/Lines : <list of line names>

Example

[Part : HW Part]

Line : HW Line1, HW Line2

Line Level Attributes

Field/Fields

Both the attributes ‘Field’ and ‘Fields’ are same. They start from the left of the screen or page, in the order in which they are specified.

Syntax

Field/Fields : <List of Field Names>

Example

[Line : HW Line]

Fields : HW Field

Field Level Attributes

Set As

This attribute sets a value to the Field.

Syntax

Set As : <Text or Formula>

Example

[Field : HW Field]

Set as : ”Hello TDL”

Here, the text “Hello TDL” is displayed in the report.

Info

The attribute Info used to set text for prompts and titles as display strings. Even when used in Create/ Alter mode, this attribute does not allow the cursor to be placed on the current field, as against the attribute ‘Set as’. However, in Display mode, the attributes ‘Set as’ and ‘Info’ function similarly.

Syntax

Info : <Text or formula>

Further, if both the attributes (Set as and Info) are specified, the attribute Info gets the precedence, and the value set within the attribute Info overrides the value set within the attribute Set As.

Example

[Field: Name Field]

Use    : Name Field

Set as : “Tally”

Info   : “Tally Solutions”

Skip

This attribute causes the cursor to skip the particular field and hence, the value in the field cannot be altered by the user, even if the report is in ‘Create’ or ‘Alter’ mode.

Syntax

Skip : <Logical Formula>

Example

[Field : HW Field]

Type   : String

Set as : “Hello World“

Skip   : Yes

This code snippet sets the value in the ‘HW Field’ as ‘Hello World’ and forces the cursor to skip the field. It can also be rewritten as:

[Field : HW Field]

Type : String

Info : “Hello World“

The attribute Info at Field combines both Skip and Set As.

Modifiers

Modifiers are used to perform a specific action on a definition or on an attribute. They are classified as Definition Modifiers and Attribute Modifiers, based on whether a definition or attribute is being modified. Definition Modifiers are #, ! and *. Attribute Modifiers are Use, Add, Delete, Replace/Change, Option, Switch and Local.

The modifiers can also be classified into two types, based on the mode of evaluation:

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

Static/Load Time Modifiers

These modifiers do not require any condition at the run time. The value is evaluated at load time only and remains static throughout the execution. Use, Add, Delete, Replace are static modifiers.

Use

The USE keyword is used in a definition to reuse an existing Definition.

Syntax

Use : <Definition Name>

Example

[Field : DSPExplodePrompt]

Use : Medium Prompt

All the properties of the existing field definition Medium Prompt are applicable to the field DSPExplodePrompt.

Add

The ADD modifier is used in a definition to add an attribute to the Definition.

Syntax

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

Where,

<Attribute Name> is the name of the attribute specific to the particular definition type.

<Attribute Position> can be any one of the keywords Before, After, At Beginning and At End. By default, the position is At End.

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

Example

[#Form : Cost Centre Summary]

Add : Button : ChangeItem

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

Example

[#Part : VCH Narration]

Add : Line : Before : VCH NarrPrompt : VCH ChequeName, VCH AcPayee

The lines ‘VCH ChequeName’ and ‘VCH AcPayee’ are added before the line ‘VCH NarrPrompt’ in the part ‘VCH Narration’.

Delete

The ‘Delete’ modifier is used in a definition to delete an attribute of the Definition.

Syntax

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

Where,

< Attribute Value > is optional, and can either be a constant or a formula. If the attribute value is omitted, all the values of the attribute are removed.

Example

[Form : Cost Centre Summary]

Use : DSP Template

Delete : Button : ChangeItem

The button ‘ChangeItem’ is deleted from the form ‘Cost Centre Summary’. The functionality of the button ‘ChangeItem’ is no longer available in the form ‘Cost Centre Summary’. If the Button name is not specified, then all the buttons will be deleted from the Form.

Replace

The ‘Replace’ modifier is used in a definition to alter an attribute of the Definition.

Syntax

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

Where,

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

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

Example

[Form : Cost Centre Summary]

Use     : DSP Template

Replace : Part : Part1 : Part2

The part ‘Part1’ of the form ‘Cost Centre Summary’ is replaced by the part ‘Part2’. Now, only the properties of ‘Part2’ are applicable.

Dynamic/Real-time modifiers

Dynamic modifiers get evaluated at the run time based on a condition. These modifiers are run every time the TDL is executed in an instance of Tally. Option, Switch, Local, and Set By Condition are the Dynamic modifiers.

Local

The Local attribute is used in the context of the definition to set the local value within the scope of that definition only.

Syntax

Local : <DefinitionType1> : <DefinitionName1> [: <DefinitionType2> : <Definition Name2> : … ] : <Attribute> : <Value>

Where,

< Definition Type > can be a Form, a Part, a Line or a Field.

< Definition Name > is the name of the definition type.

< Attribute > is the attribute of the Definition of which, the value needs to be altered, and

< Value > is the value assigned to this attribute within the current Report or Form or Part or Line.

Example: 1

[Report: Custom Report]

Local : Line : TitleLine : Local : Field : AmtField :Set as : “Sales Amount”

The field Amt Field is localized at the report Custom Report , by using nested locals.

Example: 2

Local : Field : Name Field : Set As : #StockItemName

Value of the formula #StockItemName is now the new value for the attribute Set As of the field Name Field applicable only for this instance. Elsewhere, the value will be as in the field definition.

Option

The attribute option can be used by various definitions, to provide a conditional result in a program. The ‘Option’ attribute can be used in the ‘Menu’, ‘Form’, ‘Part’, ‘Line’, ‘Key’, ‘Field’, ‘Import File’ and ‘Import Object’ definitions.

Syntax

Option : <Optional definition> : <Logical Condition>

Where,

<Optional Definition> is the name of a definition, defined as optional definition using the definition modifier !.

<Logical Condition> is any type of  expression which returns a logical value.

If the ‘Logical’ value is set to TRUE, then the Optional definition becomes a part of the original definition, and the attributes of the original definition are modified based on this definition.

Example

[Field : FldMain]

Option : FldFirst : cond1

Option : FldSecond : cond2

The field FldFirst is activated when cond1 is true. The field FldSecond is activated when cond2 is true. Optional definitions are created with the symbol prefix ” ! ” as follows:

[!Field : FldFirst]

[!Field : FldSecond]

Switch – Case

The ‘Switch – Case’ attribute is similar to the ‘Option’ attribute, but reduces the code complexity and improves the performance of the TDL Program.

The ‘Option’ attribute compulsorily evaluates all the conditions for all the options provided in the description code and applies only those which satisfy the evaluation conditions.

The attribute ‘Switch’ can be used in scenarios where evaluation is carried out only until the first condition is satisfied.

Apart from this, ‘Switch’ statements can be grouped using a label. Therefore, multiple switch groups can be created, and zero or one of the switch cases could be applied from each group.

Syntax

Switch : Label : Desc name : Condition

Example

[Field : Sample Switch]

Set as : “Default Value”

Switch : Case1 : Sample Switch1 : ##SampleSwitch1

Switch : Case1 : Sample Switch2 : ##SampleSwitch2

Switch : Case1 : Sample Switch3 : ##SampleSwitch3

Switch : Case2 : Sample Switch4 : ##SampleSwitch4

Set By Condition

The attribute Set By Condition is similar to a conditional Set at Field level. If multiple Set By Condition are mentioned under a Field, then the last satisfied Set By Condition will be executed.

Syntax

Set By Condition : <Condition> : <Value>

Where,

< Condition > is any logical formula.

< Value > is any string or a formula.

Example:

[Field : Sample SetbyCondition]

Set as           : “Default Value”

Set by Condition : ##Condition1 : “Set by Condition 1”

The Field Sample SetbyCondition will contain the value Set by Condition1 if the expression Condition1 returns TRUE, else the Field will contain the value Default Value.

The Sequence of Evaluation – Attributes

The order of evaluation of the attributes is as specified below:

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

Delayed Attributes

Add/Delete/Replace are referred to as Delayed attributes because even if they are specified within the definition, in the beginning, their evaluation will be delayed till the end, within the static modifier and normal attributes.

Actions in TDL

TDL is an action-driven language. Actions are activators of specific functions with a definite result. Actions are performed on two principal definition types, ‘Report’ and ‘Menu’. An action is always associated with an originator, requestor and an object. All the actions originate from the Menu, Key and Button.

An action is evaluated in the context of the Requestor and Object. Typically, actions are initiated through the selection of a menu item or through an assignment to a Key or a Button. Examples of actions are: Display, Menu, Print, Create, Alter, etc.

Syntax

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

Where,

< Action Name > is the name of the action to be performed. It can be any of the pre-defined actions.

< Definition/Variable Name > is the name of definition/variable, on which the action is performed.

Example

Action: Create: My Sample Report

Data Types

The Data Types in TDL specify the type of data stored in the field. TDL, being a business language, supports business data types like amount, quantity, rate, etc., apart from the other basic types. The data types are classified as Simple Data Types and Compound Data Types.

Simple Data Type

This holds only one type of data. These data types cannot be further divided into sub-types. String, Number, Date and Logical data types fall in this category.

Compound Data Type

It is a combination of more than one data type. The data types that form the Compound Data Type are referred to as sub-data types. The Compound Data types in TDL are: Amount, Quantity, Rate, Rate of exchange and Aggregate.

Data Types	Sub-Types
Simple Data Types
Number
String
Date
Logical
Compound Data Types
Amount	Base/Direct Base
	Forex
	Rate Of Exchange
	DrCr
Quantity	Number
	Primary Units/Base Units
	Secondary Unit/Alternate Uni t s/Tail Units
Rate	Price
	Unit Symbol
Rate of Exchange

The type for the field definition is specified using the Type attribute.

Syntax

[Field : <Field Name>]

Type : <Data type> : <Sub-type>

Example

[Field: Qty Secondary Field]

Type : Quantity : Secondary Units

Note: For the Date data type, valid dates are in the range 1-1-1901 to 31-12-2098. Dates outside this range can be stored in string fields to perform the required calculations using user-defined functions.

Operators in TDL

Operators are special symbols or keywords that perform specific operations on one, two or three operands and then return a result. The four types of operators in TDL are as follows:

Arithmetic Operators

+	Addition
–	Subtraction
/	Division
*	Multiplication

Logical Operators

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

OR	Returns TRUE if either of the expressions is True.
AND	Returns TRUE when both the expressions are True.
NOT	Returns TRUE, if the expression value is False and FALSE, when expression value is True.
TRUE/ON/YES	Can be used to check if the value of the expression is TRUE.
FALSE/OFF/NO	Can be used to check if the value of the expression is FALSE.

Comparison Operators

A Comparison Operator compares its operands and returns a logical value based on whether the comparison is True. The Comparison Operator returns the value as TRUE or FALSE. TDL supports the following Comparison Operators:

= /Equal/Equals	Checks if the values of both the expressions are equal.
</LessThan/Lesser Than/Lesser	Checks if the value of <expression 1> is less than the value of <expression 2>.
>/Greater Than/More	Checks if the value of <expression 1> is greater than the value of <expression 2>.
In	Checks if the value is in the List of comma-separated values.
Null	Checks whether the expression is Empty.
Between …. And	Checks if the expression value is in the range.

String Operators

String operators facilitate the comparison of two strings. The following are the String operators:

Contains/Containing	Checks if the expression contains the given string.
Starting With/Beginning With/Starting	Checks if the expression starts with the given string.
Ending With/Ending	Checks if the expression ends with the given string.
Like	Checks if the expression matches the given string pattern.

Special Symbols

The Symbol Prefix in Tally Definition Language (TDL) has different usage and behaviour when used with different definitions and attributes of definitions.

Special Symbols used in TDL are $, $$, @, @@, #, ##, ;, ;;, ;;;, /* */, + , ! , * and _ . Each of these symbols is used for a specific purpose. The usage of each of these symbols will be discussed in detail in the subsequent chapters.

Functions

A function is a small code which accepts a certain number of parameters, performs a task and returns the result. The function may accept zero or more arguments but returns a value.

The functions in TDL are defined and provided by the platform. These functions are meant to be used by the TDL programmer and are specifically designed to cater to the business requirement of the TallyPrime application.

TDL has a library of functions which allows performing string, date, number and amount related operations apart from the business-specific tasks. Some of the basic functions provided by TDL are $$StringLength, $$Date, $$RoundUp, $$AsAmount. TDL directly supports a variety of business-related functions such as $$GetPriceFromLevel, $$BillExists, $$ForexValue, etc.

Syntax

$$<Function Name> : <Argument List>

Example

$$SysName:EndOfList

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

Tally Architecture – Overview

The entire Tally architecture can be conceptualized as being divided into three layers:

• The Application Layer
• The TDL Language and Interpreter Layer
• The Platform Layer/Engine 

The Application Layer

The application layer forms the topmost layer of the product architecture. All the user interactions take place at this layer. It is through this interface that the user exploits complete functionalities offered to them. The product exploits the capabilities of the operating system using the intermediate layers between the application and the OS.

The TDL Language and Interpreter Layer

The heart of Tally, this layer forms the key link between the application and the platform layer consisting of:

• Tally Definition Language
• TDL Interpreter

Tally Definition Language is developed to provide the user with flexibility and power to extend the default capabilities of Tally and integrate with external applications. TDL provides a development platform for the user. The entire user interface of Tally is built using TDL. TDL as a language provides capabilities for rapid development, rendering, data management and integration.

TDL works in an interpreted environment. In TDL, definitions are deployed by use and not by mere existence. An action performed by user will trigger a particular segment of code to get executed. The TDL Interpreter examines each line and throws an error when encountered.

Platform Layer/Engine

The capabilities which TDL offers are due to the strong platform capabilities of Tally. This is the lowermost layer of Tally which interacts with the OS and ultimately the file system.

The various components of the platform layer are:

• DB Engine
• ODBC Engine/Driver
• Language Parser
• Output/Rendering Engine
• Function Library
• User Interface/ Business Logic
• Memory Management

All the retrieval and manipulation requests to the database by the application program are handled by the Database Engine. Tally database is a true OODBMS (Object Oriented Database Management System). It is possible to store data as objects and retrieve data as objects. In other traditional OODBMS, data pertaining to an object is internally converted into disparate files and stored, but in Tally database data for an object is stored as it is as a block. This allows faster retrieval of data.

Object oriented recursive management system follows the concept of flexi-length record, flexi-field, self-indexed weighted file structure for a extremely compact and fast database. Fault tolerance is built in the system i.e., it uses the CRC(Cyclic Redundancy Check) mechanism to achieve this. Transaction support is provided by using roll forward capability i.e., it is extremely robust in case of power failure. It provides concurrent access in a multi-user environment.

Tally File System consists of data files (master, transaction, link masters), Msgfiles (transaction management) and State Files (concurrency control and exclusivity control).It follows the concept of embedded and weighted Indexes. In other traditional databases, separate index file is maintained. In Tally, indexes are built into the data files. This facilitates faster retrieval of data.

ODBC Engine/Driver handles the ODBC calls from external applications to Tally database or from Tally to external databases using Structured Query Language. Tally can act as a client accessing data from external databases and as server it allows the data access from Tally to external applications.

TDL works in an interpreted environment. The Language Parser consisting of syntax and formula parser enables the parsing of syntax and semantics of the statements and expression parsing. Whenever a statement containing a formula is encountered by the interpreter the formula identifies the type of the formula i.e., method, function,
expression, formula, etc., which is determined by the type of symbol prefix i.e., $, $$, @, etc.

Managing multiple output types from Tally and rendering it based on the output environment is the capability of the Output Engine. TDL has the capability to output to screen, printer, file (XML, SDF), mail, and HTTP using this engine. If we talk specifically about display, Tally has a unique capability to accommodate the entire contents into the screen. It also shrinks the data to fit within the specified width of the field. The mechanism using which data is made to fit the screen is taken care by the screen management algorithm. Scrolling, pagebreak, etc., are provided as functionalities.

Some capabilities, which required by the application, based on business type it caters to build into the system as business logic. The Business Logic/UI engine takes care of validation techniques and checking of business rules. If the capabilities and validations provided in the TDL layer, it would consume a large amount of time for processing. Bundling this at the platform layer enables an increase in application speed and ensures integrity of data. For e.g., some validation mechanisms like matching the debit credit totals can never be bypassed even if data is pushed from an external application to Tally.

Function Library provides a wide range of functions for performing various activities. These functions execute by accepting a predefined set of parameters returning a value to the calling expression from the TDL layer. All the memory requirements of the application when it is running are taken care by Memory Management component. This takes care of interactions with the operating system on the memory requirements of the application. This will take care of allocating a chunk of memory from the OS and managing it. From time to time, the common activities such as garbage collection, compacting and releasing the unused memory aids in optimal use of computer memory. All of these platform components are developed in a language which can interact with the operating system directly.

These internally make use of various algorithms, OS calls (system calls) and data structures for the interactions. The platform developers interact at this layer and provide new functions and TDL language capabilities to be used by the programmers.

Tally Technology – Capabilities

The following are the capabilities of Tally technology:

• Solutions & customization
• Multiple output capability
• Data management capability
• Integration

Solutions & Customization

TDL is a powerful tool in the hands of the programmer which enables customization and solution capability in the product. TDL is platform independent, i.e., the TDL programs remain the same irrespective of which operating system/ network environment one uses.

TDL automatically takes care of all developmental features of a solution, be it entries, reports, printing, data export in various formats with a single unified program. There is no requirement of resources with varied technical expertise to build these diverse functionalities unlike other technologies which may require a database programmer, an application programmer, a systems programmer, etc.

Multiple Output Capability

Same language can be used to output multiple output devices and formats. Whenever an output is generated this can be displayed on the screen, printed, transferred to a file in a particular format, mailed or transferred to a web page using HTTP protocol.

Data Management Capability

As we have discussed earlier data is stored and retrieved as objects. There are a few internal objects predefined by the platform. Using TDL it is possible to create and manipulate these information with ease. If an additional field is required by the user to store information as a part of the predefined object that capability is also provided i.e. by using TDL the user can create a new field and store value into the same which can be persisted in Tally database.

Integration

Tally has been designed to provide extensive integration capability which enables the developer community to exploit and deliver cross platform solutions thereby allowing seamless interoperability among multiple applications with the Power of Simplicity. Tally  is endowed with limitless possibilities due to its capability to interface with other applications, devices and the internet. Tally allows export and import of data in various formats like CSV, Excel and so on.

It can act as a back end (server) for various web-applications built on platforms like ASP, PHP etc. or other applications accessing data using ODBC. Using TDL data can be accessed from any external ODBC database. TDL’s procedural capabilities perform various tasks including batch jobs, scheduled events etc. It can also be made a part of a larger system process.

Tally provides different API’s (Application Programming Interfaces) to integrate data:

•  XML
• ODBC
•  DLL

These interfaces allow seamless integration between application/database in two modes:

Online Mode

• Tally to Tally using synchronization
• Tally to external application and vice versa using the interfaces available
• Tally to web service using HTTP interface

Offline Mode

• Tally to external applications using Export
• Data from external application in XML using Import

To know more about Tally Technology watch the below given video:

Tally Development Environment

We will now focus on the technology support provided for Solution and Integration ability of TallyPrime. The entire set of services is available in Tally Development Environment (TDE). This environment comprises of:

• Tally Definition Language(TDL) integrated with TallyPrime platform
• The Tally Development Suite productized as TallyPrime Developer (TPD)
• Set of tools – Integrated with the development suite
• Associated support – for TDL and TPD

Tally Definition Language (TDL) is a domain specific development language of Tally and is integrated with TallyPrime platform. It enables the programmer to develop solutions in and around Tally. It is a powerful instrument in the hands of the TDL programmer to extract maximum benefits from Tally.
TallyPrime Developer is a comprehensive development suite designed specifically for programming in TDL(Tally Definition Language). TallyPrime Developer comes with its unique features in terms of:

• Easy programming by syntax coloring, tagging and navigation of code, auto completion, Project Management and so on
• Ease of debugging with error listing and diagnosis
• Build, compilation/validation/execution of code from within the product
•  Authorization techniques for TCP(Tally Compliant Product) ensuring IP protection, control license usage and minimize revenue leakage.
• Easy distribution mechanism using licensing and subscription renewals
• Easy customer serial management
• Access to the complete Tally source code as a reference
• Ability to load multiple versions of the source code
• Instant references to TDL Language API’s such as schema, definition and attributes, functions, actions and so on
• Ability to extend multilingual support to the product, customization, modules in localized languages with the powerful dictionary manager tool
• Rich set of TDL language documentation and programming samples
• Tools that help to develop and test external application’s integration with tally (Tally connector)