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 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.
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.
TDL User = Yes
TDL = with extension <Path\filename>
User TDL = Yes
TDL = C:\TallyPrime\BusinessReport.tcp
TDL = C:\TallyPrime\BusinessReport.txt
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:
Default Companies = yes
Load = 00002
The business folder that resides in TallyPrime\Data is 00002. The parameter ‘Data’ can be used to specify the data path.
Data = C:\TallyPrime\Data
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.
[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.
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”.
[#Menu: Gateway of Tally]
Item : First TDL : Display : First TDL Report
[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”
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.
Definitions, Attributes, Modifiers, Data Types, Operators, Symbols and Prefixes, and Functions are cover under TDL. Let’s analyze the language’s components now.
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.
[<Definition Type> : <Definition Name>]
<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.
[Part : PartOne]
In this example, Part is the definition type, and PartOne is the name of the definition.
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 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 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 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 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.
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.
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.
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.
[<Definition Type> : <Definition Name>]
<Attribute Name> : <Attribute Value>
< Attribute Name > is the name of an attribute, particular for the definition type.
< Attribute Value > can be a formula or a constant.
[Part : PartOne]
Line : PartOne
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.
[Field : Fld 1]
Set As : “Hello”
Set As : “TDL”
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.
[Line : Line 1]
Field : Fld 1, Fld 2
Field : Fld 3
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.
Repeat : Line 1 : Collection 1
Attributes type of the Dual List consider two values and can be listed multiple times.
Set : Var 1 : “Hello”
Set : Var 2 : “TDL”
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.
Object : Ledger Entries : First : $LedgerName = “Tally”
Three values are accepted by Triple List type attributes, which can be listed multiple times.
Aggr Compute : TrPurcQty: Sum : $BilledQty
Aggr Compute: TrSaleQty : Sum : $BilledQty
The Attribute type ‘Menu item’
The user can add a menu item to the assigned ‘Menu’ definition using the ‘Menu Item’ attribute type.
[#Menu : Gateway Of Tally]
Item : Sales Analysis : Display : Sales Analysis
Item : Purchase Analysis : P : Display : Purchase Analysis
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
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.
Form : <Form Name>
[Report : HW Report]
Form : HW Form
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.’
The attribute ‘Title’ is used to give the Report a meaningful title.
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.
[Report : HWReport]
Form : HWForm
Title : “Hello World”
Instead of HWReport, here the title of the Report is shown as “Hello World”.
Form Definition Attributes
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.
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.
[Form : HW Form]
Part : HW Title Partition, HW Body Partition
HW Title Partition and HW Body Partition are explained in this code segment.
Part Definition Attributes
The Lines in a Part are defined by this attribute.
Line/Lines : <list of line names>
[Part : HW Part]
Line : HW Line1, HW Line2
Line Definition Attributes
The ‘Field’ and ‘Fields’ attributes are identical. They begin on the left side of the screen or page, in the order, they are specified.
Field/Fields : <List of Field Names>
[Line : HW Line]
Fields : HW Field
This attribute sets the Field a value.
Set as : <Text or Formula>
[Field : HW Field]
Set as : ”Hello TDL”
In this case, the report displays the text “Hello TDL.”
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.
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.
[Field: Name Field]
Use : Name Field
Set as : “Tally”
Info : “Tally Solutions”
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.
Skip : <Logical Formula>
[Field : HW Field]
Type : String
Set as : “Hello World“
Skip : Yes
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:
[Field : HW Field]
Type : String
Info : “Hello World“
Note: Info attributes at Field blends the Skip and Set As.
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.
In a definition, the USE Keyword is used to reuse an existing Definition.
Use : <Definition Name>
[Field : DSPExplodePrompt]
Use : Medium Prompt
The field DSPExplodePrompt acquires all of the properties of the current field definition Medium Prompt.
In a definition, the ADD modifier is applied to add an attribute to the Definition.
Add : <Attribute Name> [:<Attribute Position>:<Attribute Name>]:<Attribute Value>
<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.
[#Form : Cost Centre Summary]
Add : Button : ChangeItem
A new ChangeItem button is added to the Cost Centre Summary form.
[#Part : VCH Narration]
Add : Line : Before : VCH NarrPrompt : VCH ChequeName, VCH AcPayee
In the part ‘VCH Narration,’ the lines ‘VCH ChequeName’ and ‘VCH AcPayee’ are placed before the line ‘VCH NarrPrompt.’
In a definition, the ‘Delete’ modifier is used to delete a Definition attribute.
Delete : <Attribute Name> [:<Attribute Value>]
< 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.
[Form : Cost Centre Summary]
Use : DSP Template
Delete : Button : ChangeItem
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.
The ‘Replace’ modifier is used to change the Definition attributes.
Replace : <Attribute Name> : <Old Attribute Value> : <New Attribute Value>
<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.
[Form : Cost Centre Summary]
Use : DSP Template
Replace : Part : Part1 : Part2
The form “Part1” part “Cost Centre Summary” is substituted by “Part2.” Only the properties of ‘Part2′ are now applicable.
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’.
The attribute ‘Local’ is used in the definition context to set a local value that is only within the defined scope.
Local : <Definition Name> : <Old Attribute Value>: <New Attribute Value>
Local : Field : Name Field : Set As : #StockItemName
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.
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.
Option : <Optional definition> : <Logical Condition>
<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.
[Field : FldMain]
Option : FldFirst : cond1
Option : FldSecond : cond2
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:
[!Field : FldFirst]
[!Field : FldSecond]
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.
Switch : Label : Desc name : Condition
[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
The sequence of Evaluation – Attributes
The attributes evaluation order is as stated below:
- Normal 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, 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.
Action : <Action Name> [: <Definition/Variable Name> : Formula]
< 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.
Action: Create: My Sample Report
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.
Simple Data Types
Compound Data Types
Base/ Direct Base
Rate Of Exchange
Primary Units/Base Units
Secondary Unit/Alternate Uni t s/Tail Units
Rate of Exchange
The Type attribute is used to specify the field definition type.
[Field : <Field Name>]
Type : <Data type> : <Sub-type>
[Field: Qty Secondary Field]
Type : Quantity : Secondary Units
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:
OR, AND, NOT, TRUE/ON/YES and FALSE/OFF/NO are the logical operators used:
If either of the expressions is True, TRUE is returned.
When both expressions are True, TRUE is returned.
If the expression value is False, it returns TRUE; otherwise, when the expression value is True, it returns FALSE.
TRUE/ ON/ YES
Can be used to see if the expression's value is TRUE.
FALSE/ OFF/ NO
Can be used to see if the expression's value is FALSE.
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:
= / Equal/ Equals
Verifies if both expressions' values are the same.
</ LessThan/ Lesser Than/ Lesser
Verifies if the <expression 1> value is less than the <expression 2> value.
>/ Greater Than/ More
Verifies if the <expression 1> value is greater than the <expression 2> value.
Verifies in the List of comma-separated values if the value is present.
Checks if the expression is empty.
Between …. And
Checks if the value of the expression is within the range.
String operators offer two strings comparisons. The String operators are as follows:
Checks if the given string is present in the expression.
Starting With/Beginning With/Starting
Checks if the expression begins with the specified string.
The expression is checked to see if it ends with the specified string.
Checks if the given string pattern matches the expression.
When used with distinct definitions and attributes of definitions, the Tally Definition Language (TDL) Symbol Prefix has different use and behavior.
$, $$, @, @@, #, ##, ;, ;;, ;;;, /* */, +,!, *, and _ are some of the special symbols used in TDL. Each of these symbols has a specific function.
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.
$$<Function Name> : <Argument List>
If the parameter passed is a TDL reserved string, the function $$SysName returns TRUE.
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.
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.
Payrolls ranging from simple to complex, including dealing with various units of measurement (e.g., job rates), statutory compliances, and their requirements and usage.
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.
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.