One of the most important aspects when it comes to company data is the security and Tally Prime’s security and access control management covers this by being able to create users and assign rights to them, in the user roles screen. This screen lists all the report families to which rights can be given for the users. The list is derived from the Family names specified in the report definitions using the Family attribute. 

The Family attribute is used to group related reports under a common family name for Security Control. Once a report is assigned a family, the family name appears in the Reports list while configuring user security. Administrators can then grant or deny access to the entire family instead of configuring permissions for each report individually. 

When a particular family is selected in the User Roles screen: 

• The chosen permission level (Full Access, Display, Print, Export, etc.)  
• Gets uniformly applied to all reports belonging to that family 

From a technical standpoint, the report list seen in the User Roles Screen is essentially a collection of objects of Type: Report, where the Name is the method that returns the Family name. 

When you want your report to appear in this list: 

• Simply specify the Family attribute in your report definition  
• Assign it either:  
• An existing family name → to group it with related reports  
• A new family name → to create a new grouping in the User Roles screen 

In essence, the ‘Family’ attribute acts as a logical bridge between report and access control—making security both structured and efficient. 

Syntax 

Family: <String Value> 

<String Value> accepts the string value as ‘family’ name. 

Example  

[Report : TSPL Sales Summary]  

Family : Custom Sales Reports  

[Report : TSPL Sales Register]  

Family : Custom Sales Reports  

[Report : TSPL Sales Analysis]  

Family : Custom Sales Reports  

[Report : TSPL Sales Comparison]  

Family : Custom Sales Reports  

The above example shows that there are custom reports created TSPL Sales Summary, TSPL Sales Register, TSPL Sales Analysis, TSPL Sales Comparison grouped under the same family name Custom Sales Reports via the attribute Family. When the administrator opens User Roles Screen in TallyPrime, the Custom Sales Reports family appears in the list of reports. Granting permission to this family automatically gives the user access to all reports that belong to it. 

Have you noticed how in many default columnar reports of TallyPrime like Stock Summary, Balance Sheet are displayed, has an option to add/alter columns based on user’s input, aiding to easier comparison of data. One of the important attributes that makes this possible is the report attribute Column Report.  

The Column Report attribute specifies the report that collects the user inputs required to create or alter a column. The report specified in this attribute presents an input screen where the user enters the comparison criteria such as period. Based on these inputs, TallyPrime generates a new column or modifies an existing one in the columnar report. 

How does Column Report work? 

The Column Report attribute is one part of the framework that enables dynamic column creation. It works together with the Repeat attribute of the Report, Part, and Line definitions to render multiple columns. 

The complete flow is as follows: 

1. The report specified in the Column Report attribute displays an input screen to the user. The fields in this report are associated with system variables that store values such as period. These variables define the characteristics of the column to be created. 
2. The variables captured in the column report are specified in the Repeat attribute of the main report. 
3. Further, the Part definition contains a Line that repeats over the objects of a Collection, thereby generating the rows of the report. The Line contains the Field that displays the actual data. This Field is repeated using the Repeat attribute of the Line, enabling the data for each row to be displayed across multiple columns. 
4. Now when the button action ‘Create Column’ or ‘Alter Column’ gets executed on this report via the relevant buttons, system automatically opens the report mentioned in ‘Column report’ attribute. After the user provides the required inputs, the values are stored in the associated variables. The framework then uses the Repeat attributes of the Report, Part, and Line definitions to generate or update the corresponding column in the report. 

Syntax 

Column Report : <Report Name> 

<Report Name> is the name of the report that gets triggered to capture user inputs when ‘New Column’ or ‘Alter Column’ button is pressed 

Example 

[Report: TSPL MulCol Trial Balance] 

ColumnReport : MyMultiColumns 

Repeat : SVCurrentCompany, SVFromDate, SVToDate 

The example shows that the report TSPL MulCol Trial Balance uses the report MyMultiColumns mentioned in the attribute ColumnReport  to capture user inputs of company name and period which is stored in variables SVCurrentCompany, SVFromDate, SVToDate, also repeated in the Repeat attribute of the report. 

Imagine printing an invoice for a customer. You may need one copy for the customer, another for your records, and a third for the accounts department. Instead of printing the same report repeatedly, wouldn’t it be convenient to specify the number of copies just once? 

This is exactly what the Copies attribute does. 

The Copies attribute specifies the number of copies to be printed for all the Forms under a Report. When the Report is sent for printing, TallyPrime prints the specified number of copies automatically, eliminating the need to initiate the print operation multiple times. 

While there is already a configuration available in TallyPrime to enter number of copies while printing, if you need to hardcode the number programmatically, for a particular report, then use this attribute. The value set in the attribute overrides the configuration value. 

Syntax  

Copies: <Number Expression> 

<Number Expression> is any expression that evaluates to a number. 

Example 

[Report: TSPL Report] 

Form: TSPL Form 1, TSPL Form 2         

Copies: 3 

The example shows that the report TSPL Report has 2 forms – TSPL Form 1, TSPL Form 2. Since Copies attribute is set to 3, when the report is printed, 3 copies of each form will be printed in the output. 

How would you feel when all your favourite food items are there on a single table at the same time? That’s the feeling a business owner would get when he witnesses a dashboard type of report on TallyPrime giving all the necessary business information in a single interface. A Dashboard Type of report renders various genres of information in the form of tiles. 

To differentiate a dashboard report from the regular one, the attribute Dashboard Type is used. When this attribute is set to yes, the report is not rendered as Report-form-Part-Line-Field, it is rendered using the attributes that specifies the details of tiles to be shown like the Default Tiles attribute of report.  

Syntax  

Dashboard Type : <Logical expression> 

<Logical expression> is expression that evaluates to Yes or No 

Example 

[Report: TSPL Dashboard] 

Dashboard Type: Yes 

The example shows that the report TSPL Dashboard is a dashboard type of report as specified by the attribute Dashboard Type 

When a report is exported in JSON format, empty fields are ignored by default.  

The Export Empty Fields attribute ensures that all visible fields, including those with empty values, are included in the JSON export. By default, when a report is exported in JSON format—either to build a request or to export data to a file—only fields with values are included in the output.  

Including empty fields becomes important when the structure of the data is as important as the data itself. Many integrations expect a fixed and predictable JSON structure and omitting empty fields can cause the structure to vary between responses. Exporting empty fields preserves the complete report schema, simplifies parsing and validation in consuming systems, and supports scenarios such as template-based processing, period-wise comparisons, and integrations that rely on the presence of keys rather than values.  

To export the full report structure along with empty values, set Export Empty Fields to Yes in the Report definition.  

Syntax 

[Report: <Report Name>]  

Export Empty Fields : <Logical Expression>  

Where,  

<Report Name> is the name of the report.  

<Logical Expression> can be any expression which evaluates to logical value YES/NO. By default, the value will always be No.  

Example 

[Report: TSPL JSON Report] 

Export Empty Fields : Yes 

In the example, when the report TSPL JSON Report is exported in JSON format, all the fields will be exported including the empty fields, as the attribute Export Empty fields is set to yes. 

When TallyPrime sends an HTTP request to a third-party application, it may be necessary to include HTTP headers as part of the request. While the JSON or XML request payload is constructed using the Report structure, the Export Header attribute is used to define and send the required HTTP headers along with the request. 

Syntax 

[Report: <Report Name>]  

Export Header: <String Expression>  

<Report Name> is the name of the Report which is used to send POST Request payload in the Remote Request attribute of the Collection.  

<String Expression>is a valid expression that evaluates to a string.  

Example 

[Report: TSPL JSON Request] 

Export Header     : ”content-type:application/json” 

The example shows that when the report TSPL JSON Request is request in JSON format over HTTP, HTTP header “content-type:application/json” is as the http header, as specified by the attribute Export Header. 

Imagine you’re preparing for a presentation and know you’ll need the same reference document several times. Instead of walking back to your desk every few minutes to retrieve it, you keep a copy with you before the presentation begins. This saves both time and effort. 

The Fetch Collection attribute works in a similar way. 

The Fetch Collection attribute allows a Collection to be pre-fetched at the Report level, making it readily available throughout the Report. This is particularly useful when the same Collection is accessed multiple times, such as when: 

• A Line repeats over the Collection’s objects.  
• Multiple functions use the same Collection.  
• Different parts of the Report require data from the same Collection.  

When a Report accesses the same Collection multiple times, each access may require the Collection to be evaluated again. In a local environment, this may have little impact. 

However, in a remote access environment, the Collection data resides on the server. Every repeated access can result in another request being sent from the client to the server, increasing network traffic and slowing down the Report. 

By using the Fetch Collection attribute, the Collection is fetched once at the beginning of the Report. The fetched data is then reused for all subsequent operations, avoiding repeated requests to the server. 

Syntax 

Fetch Collection: <Collection 1>, <Collection2>,…. 

<Collection 1> is the collection whose objects need to be prefetched at Report. 

Example  

[Report: TSPL Employee BankDetails] 

Form: TSPLEmployee BankDetails 

Fetch Collection: All Banks of Company 

The example shows that the collection All Banks of Company is fetched at the report level TSPL Employee BankDetails for repeated use in the report. 

Imagine you’re researching a person for a presentation. Instead of calling them every time you need a different piece of information – their address, phone number, designation, or email – you collect all the required details in one conversation and keep them with you. Whenever you need any of those details later, you simply refer to your notes instead of contacting them again. 

The Fetch Object attribute works in the same way. 

The Fetch Object attribute is used to pre-fetch one or more business objects of the same type at the Report level. Once fetched, all the required methods of those objects are readily available throughout the Report, eliminating the need to repeatedly retrieve the same object whenever one of its methods is accessed. 

Without the Fetch Object attribute, every time the Report evaluates a method of an object, TallyPrime may have to retrieve that object again. 

While this repeated access may have little impact in a local environment, it becomes significant in Remote Access scenarios, where the object resides on the server. 

Internally, fetching an object generates an XML request that is sent to the Tally Server. If the same object is accessed multiple times, multiple XML requests may be generated, resulting in unnecessary network communication. 

By using the Fetch Object attribute, the object is fetched once when the Report is loaded. All subsequent method evaluations use the already fetched object, avoiding repeated requests to the server and improving the Report’s performance. 

Syntax 

Fetch Object : <Object Type> : <Expression> : <List of methods> 

Where, 

<Object Type> denotes the type of the Object. 

<Expression> can be any of the string expression. 

<List of methods>List of methods to be fetched from the Object. 

Example 

[Report: TSPL Report] 

Fetch Object : Ledger : ##Ledger Name : Name, Parent, Closing Balance 

In this example, Ledger Name is the variable which stores the name of the Ledger Object whose methods need to be fetched at the Report TSPL Report using Fetch Object attribute. Since the Object name is an expression, we need to prefix the variable name with ##. Name, Parent, Closing Balance are the methods fetched. 

Have you ever wondered how TallyPrime knows which user interface to display when a report is opened? Whether it’s the Voucher Creation screen, Ledger Alteration screen, or Stock Summary, every report appears with its own unique layout. 

This is achieved using the Form attribute. 

The Form attribute specifies the Form definition that the report should display. When a report is invoked, TallyPrime renders the Form specified in this attribute. Since a Form defines the visual layout of a report through its Parts, Lines, and Fields, the Form attribute acts as the link between the report’s logic and its user interface. 

Not just that, multiple forms can be specified in a report. When the report is displayed or mailed, only the first Form definition is considered, But, in case of Print/Export, every form specified gets printed one after the other, making it easier to print related formats together like alongwith invoice printing, gatepass also needs to be printed. 

Syntax  

Form: <Form Definition1>:<Form definition 2>:…. 

Example 

[Report: TSPL Report] 

Form: TSPL Report, TSPL Cover Report 

The example shows that the report TSPL Report has 2 forms specified using the Form attribute – TSPL report and TSPL Cover Report. When the report is mailed or displayed only the first form definition mentioned i.e. TSPL Report is considered. When the same report is printed or exported, both the forms are rendered in the output one after the other in the specified order.

By default, when a report is exported in xml format, the xml tags are converted into upper case. But what if you are dealing with a case sensitive system? You have to tread carefully. i.e. you can no longer stick to the default approach.  

To cater to such cases, the attribute Keep XML Case is used. This ensures that the tag names are exported exactly as specified in the TDL using the XML Tag attribute.  

Syntax  

Keep XML Case : <Logical Expression>  

Where,  

<Logical Expression> can be any expression which evaluates to logical value YES/NO. By default, the value will always be No.  

Example  

[Report: TSPL Sample Report]  

Keep XML Case : Yes 

….. 

….. 

[Field: TSPL Sample Field] 

XMLTAG : “TSPL Sample Field”  

When this report TSPL Sample Report is exported in XML format, the xml tag corresponding to the field TSPL Sample Field will be exported in the given case as it is, i.e. <TSPL Sample Field> </TSPL Sample Field>, as the attribute Keep XML Case is set to yes. If in case, this attribute was not specified or was set to No, then the XML output would contain the XML tag is upper case like this – <TSPL SAMPLE FIELD> </ TSPL SAMPLE FIELD>

Variable, the binder who brings it all together in any operation. When you want a temporary container that holds multiple values, list variable is used. When the list variable needs to be declared at the scope of the report, so that it lives and dies within the report and remains accessible only from the report itself and all the TDL elements which are executed from within this report such as another report, function, etc., then the attribute List Var is used. 

Inline declaration is possible for a simple list variable, i.e. variable that holds multiple values of single data type which can be specified in line by specifying the name of the variable, data type and default value. The same is not possible for a compound list variable. Which means, to declare a compound list variable in a report scope, it needs to be already defined using the Variable definition. 

Report variables get their default value from definition specification, or from the declaration specification, or the values are inherited from the owner scope, if the variable is marked as Volatile. 

Report allows two special attributes SET and PRINT SET to set/override the values of the variable during the startup of the report in Display / Print mode respectively. 

Form definition also has a SET attribute, which overrides the variable’s value during startup creation and subsequent re-creation of the form during any refresh/regeneration. 

Do look into other List Variable manipulation methods to get a complete understanding of how it works. 

Syntax 

List Var: <List Variable Names> [:<Data Type> [:<Value>]]  

Example 

[Report: TSPL Report] 

List Var: lvSubjects:String 

List Var: lvStudentsInfo 

[Variable: lvStudentsInfo] 

Variable: Name : String  

Variable: DOB : Date 

The report TSPL Report has 2 list variables declared using the attribute List Var– lvSubjects which uses the inline declaration where it is defined as simple list variable holding multiple values of String data type and lvStudentsInfo a compound list variable declared in the report scope and defined outside using variable definition. 

Let’s say you are maintaining a record of students, and you need to update details of the entire class. Your only option is to go through each student profile and update the details. Annoying, isn’t it? How easy it would be if you had an option to update details for the entire class on a single interface?  

That’s what the attribute Multi objects does. It takes the collection of objects as parameter, that will be modified in the report, thereby linking them to the report. Now whether it is to modify multiple ledgers or vouchers, specify this attribute with appropriate collection. It is required specifically in case of multi master creation or alteration. 

Your job is only half done now, of course to modify the objects, the part line and field need to do the work. One of the ways is to repeat the line over the collection, where each line gets associated with an object and use storage attribute in the field, to store the values in appropriate methods.   

You can also specify whether the process of modification should continue or not if an error in processing an object is encountered. 

Syntax  

MultiObjects: <Collection Name>: <Logical Expression> 

   Where, 

 <Collection Name> is the name of the Collection for which modifications are to be done. 

<Logical Expression> This is the Skipping on error condition. If it evaluates to yes, then, the error is ignored and rest of the objects are processed else, stops and shows the report with an error message. Objects created before the error remain, while the remaining ones are not processed. 

Example 

[Report; TSPL Report] 

MultiObjects    :  TSPL MO Stk Collection  :  Yes 

The report TSPL Report is associated with the objects of the collection TSPL MO Stk Collection with the attribute MultiObjects. So here in case there is an error while updating TSPL MO Stk Collection then the error will be skipped and the rest of the objects in the collection will be processed. 

A Report is normally associated with an object. By default, it inherits this object context from the Report that invoked it. If no object is passed from the calling Report or if this is a standalone report, the Report is associated with an anonymous object. 

However, there may be scenarios where the Report needs to work with a different object instead of the one inherited from the caller. To support this, the Object attribute allows you to override the default object association. It also accepts an optional Object Identifier Formula, which uniquely identifies the object to be associated with the Report. 

This enables the Report to explicitly establish its object context. 

Every master and voucher creation and alteration reports uses this attribute.  

Syntax

Object : <ObjectType> [: <ObjectIdentifierFormula>] 

Where, 

< ObjectType > is a Type of Primary Object. 

< ObjectIdentifierFormula > is an optional value and refers to any formula which evaluates the name of Primary Object. 

Example 

[Report: TSPL Report] 

Object : Ledger : “Cash” 

The Ledger ‘Cash’ is associated to the Report TSPL Report using the attribute Object. Now components of a TSPL Report, inherit this ledger object association.

This attribute is like a secret box where a lot of work goes on but for a user it just feels like a simple report interaction. Be it to update variables, or display a report before print of the report, this attribute does it all. The ON attribute lets you define a list of actions that should automatically run when a specific event takes place in the context of the report, making your application smarter and more responsive. 

Syntax  

On: <Event>: <Logical Condition>:<Action> 

<Event> The event keyword that acts as a trigger for the action to take place 

<Logical Condition> Condition on which needs to be satisfied along with the event for the action to take place 

<Action> The action that needs to be executed 

Example  

[#Report: Printed Invoice] 

On  : Before Print  : @@IsSales : Display  : Stock Summary 

The default report Printed Invoice is modified with On attribute, where if the invoice is sales, then before its printed, stock Summary report is displayed.

Have you noticed that before a report is printed in TallyPrime, a screen appears allowing you to review print configurations and perform actions such as Preview, Configure, and Print? Instead of sending the report directly to the printer, TallyPrime first presents this intermediate screen so that you can verify and adjust the print settings. How does TDL know which report to display for this print preview and configuration? 

This is controlled by the Print attribute. 

The Print attribute specifies the Print Report that should be invoked before the current Report is printed. Typically, this report is designed to set or review configurations and perform next set of actions. 

Syntax 

Print : <Report Name> 

Example 

[Report: TSPL Report] 

Print : VCH Print Configure 

When the report TSPL Report is printed, the configuration report VCH Print Configure is displayed before printing the report TSPL Report, as specified by the attribute Print. 

Doesn’t things simpler when extra and additional stuff is removed? That’s what this attribute does. Imagine you’re sending JSON/XML data to another application. While formatted JSON is easier for humans to read, machines don’t require the extra spaces and line breaks. In fact, they only make the payload larger. When a compact JSON/XML output is preferred, the Plain JSON/Plain XML attribute can be used. 

The Plain JSON/ Plain XML attribute instructs TallyPrime to export the Report’s JSON/ XML output in plain (minified) format, without any indentation or formatting, resulting in a smaller payload that is ideal for integrations with third-party applications. 

Syntax 

[Report: <Report Name>]  

Plain JSON: <Logical Expression>   

Where,  

<Report Name> is the name of the report.  

<Logical Expression> can be any expression that evaluates to a logical value.  

Example 

[Report : TSPL Trial balance] 

Form: TSPL Trial balance 

Title: “Trial Balance” 

Plain XML:  YES 

The report TSPL Trial Balance when exported in JSON or XML format is exported in plain format as mentioned by the attribute Plain XML

Imagine you plan to make an omelettes for breakfast and you are actually out of eggs, but you do not know that. Ideal scenario would have been to check if ingredients exist and then decide the breakfast. But, let’s say a system exists where the moment you decide a breakfast, you immediately are notified about the missing ingredients and also a way to procure them so that you can still continue to make the breakfast that you planned. Such a system makes life easier isn’t it? That’s what the attribute Pre Load Check does.  

 In case if the customer wants to open the report only when a specific condition is satisfied, then the condition is used where the action statement is mentioned. For example, the cost category report can be opened only when the cost category configuration of the company is enabled. 

The attribute Preload Check used to specify a condition to be checked before launching the report. If the condition satisfies the report is launched else specified query is displayed for resolution of the failed condition. 

Syntax 

[Report: <Report Name>] 

Preload Check : <Logical Expression> : <Query Report> : <Query String> : <QueryParam> [:<QueryHelpId>: <Action : Parameters>] 

Where, 

<Logical Expression> any expression that evaluates to a logical value. 

<Query Report > is the Report Name used to display the Query and its choices. 

<Query String> can be any expression that returns a string. This is passed to the query report, where it is accessible with $$InfoString. This can be further used in the report to display the query text. 

<Query Param> any expression that results in a string and passed to the query report, where it is accessible with $$InfoParam. This can be further used to control the look and feel of the choices of the query report. 

<QueryHelpId> any expression that results in long and passed to the query box report as it is associated HelpId for the Help-page to come up. This is passed to the query report, where it is accessible with $$InfoHelpId. This can be further used in the report to display the query box help id. 

<Action /parameters> standard action and parameters, that need to be executed when the system name ‘Yes’ is returned to the platform from the query report. This is optional. 

Example 

[#Report: Voucher]   

Set : svVoucherType : “Sales” 

Pre Load Check  : ($$Numitems:InvSalesLedgersVchExtract=0)  : SV User Query  : @@EnableSalesLedger    : “” : “” : Call : CreateSalesLedger

[System: Formula] 

EnableSalesLedger : “There are no Sales Ledger! Create a Sales Ledger?”

[Function: CreateSalesLedger] 

100 : New Object : Ledger 

110 : Set Value : Name : “Sales” 

120 :  Set Value : Parent : “Sales Accounts” 

130 : Create Target 

Before opening a sales voucher, with the help of the Preload check attribute, a validation is made to check if there are sales ledgers present in the company. If this condition passes, then sales voucher is opened. If it fails, then a query box asking “There are no Sales Ledger! Create a Sales Ledger?” is shown with yes or No actions. Yes, leads to creation if sales ledger. No quits the opening of the report.  

Pre Load Control is like those information message that says ‘hey you do not have enough funds to buy this product’ when you try to pay for something that costs more than what you have in your account. That is what a PreLoad Control attribute does. 

The attribute Preload Control is used to open a message box with a message and prevent opening the report if the first parameter is true. It takes the condition as its 1st parameter followed by the message box Help ID. 

This attribute is like the preload check, but instead of taking a query box followed by action, it just shows a message box with the passed string based on the condition. 

The attribute Preload Control is used to open a message box with a message and prevents opening the report if the first parameter is true. 

Its widely used in TallyPrime to validate if a user has access to a open a report and if not, a message saying, “No Access Allowed!” is shown. 

Syntax 

[Report: <Report Name>] 

Preload Control : <Logical Expression> :  <Message String>  :<MessageHelpId> 

Where, 

<Logical Expression>  can be any expression that evaluates to a logical value. 

<Message String> can be any string expression whose value is to be set in the message box. This is passed to the query report, where it is accessible with $$InfoParam. This can be further used in the report to display the message box text. 

<MessageHelpId> can be any expression that results in Long and passed to the message box report as it is associated with Help Id for the Help page to open. This is passed to the query report, where it is accessible with $$InfoHelpId. This can be further used in the report to display the message box help id. 

Example  

[#Report: VCH Print Configure]  

PreLoadControl: ($$IsEmpty:$Amount): “Blank Voucher. Not allowed to Print!” 

The example shows that the default report Vch Print Configure is modified with PreloadControl where a blank voucher is restricted from printing. The validation condition checks if the amount is empty and if it is, then the opening of report fails with a message “Blank Voucher. Not allowed to Print!“.

Just as you might have a few clothes reserved only for special occasions, there are times when a report needs to behave differently only when it is printed, exported, or emailed. This is where the Print Set attribute comes into play. 

Unlike the Set attribute, which assigns an initial value to a variable whenever the Report is loaded, the Print Set attribute assigns the specified value as initial value only when the Report is in Print, Export, or Email mode. 

This allows you to customize the appearance or behavior of a Report specifically for these output modes, without affecting how it appears on the screen. For example, you can: 

• Display a different report title when printing.  
• Set a different background colour for the printed or exported report.  
• Modify variables that control the layout or formatting exclusively for Print, Export, or Email.  

Since the attribute works by assigning values to variables, any report behavior driven by those variables can be tailored for the output mode. 

The Print Set attribute is extensively used in TallyPrime reports.  

Syntax 

Print Set : <Variable Name>: < Value> 

Example  

[Report: TSPL Report] 

Variable : vReportTitle: String  

Title          : ##vReportTitle 

Set            : vReportTitle : $$LocaleString:”Display Mode” 

PrintSet  : vReportTitle : $$LocaleString:”Print Mode” 

The example shows that, the report TSPL Report has a report variable declared and defined – vReportTitle. The value of the same is set in the Title attribute of the report. Which means the title of the report is governed by the value of this variable. The Set attribute sets the value of the variable as Display Mode and this value is overridden for print mode using the PrintSet attribute. Thus, the report is shown with the title Print Mode when the report is printed/exported/emailed and Display Mode when the report is displayed or altered.

Variables are undoubtedly one of the superpowers of TDL. But simply declaring a variable isn’t enough—it becomes useful only when it holds a value. One of the simplest ways to assign an initial value to a variable in the Report scope is through the Set attribute. 

The Set attribute assigns the specified value to a variable every time the Report is loaded, regardless of whether the Report is opened for display, printing, exporting, or emailing, unless the value is subsequently overridden. 

Whether it’s initializing system variables such as the reporting period, or setting variables that drive the data displayed in the Report, the Set attribute serves as the starting point for defining the Report’s execution context. 

Since many report behaviors are controlled through variables, the Set attribute is extensively used in TallyPrime to initialize these variables before the Report begins processing or rendering. 

Syntax 

Set : <Variable Name>: < Value> 

Example  

[Report: TSPL Report] 

Variable : vReportTitle: String  

Title          : ##vReportTitle 

Set            : vReportTitle : $$LocaleString:”Display Mode” 

PrintSet  : vReportTitle : $$LocaleString:”Print Mode” 

The example shows that, the report TSPL Report has a report variable declared and defined – vReportTitle. The value of the same is set in the Title attribute of the report. Which means the title of the report is governed by the value of this variable. The Set attribute sets the value of the variable as Display Mode and this value is overridden for print mode using the Print Set attribute. Thus, the report is shown with the title Print Mode when the report is printed/exported/emailed and Display Mode when the report is displayed or altered. 

Do you have a widely spaced columnar report where relating data columns feels like a hassle because of too much information in one report? How about distinguishing the rows with stripes on alternate rows? Makes the data much more relatable isn’t it. The Stripe View feature allows users to easily relate data across widely spaced columns without moving the cursor to each line. To enable this feature, TDL attribute called Stripes is introduced within the Report, Form, Part, and Line definitions. 

If you enable the master configuration (Help > Settings > Display > Enable stripes view for report: Yes) and use scrolling in the report, you don’t need to manually apply the Stripes attribute at the Report, Form, Part, or Line level. The report automatically displays in stripe view. But, in this case you can set stripe attribute to No if you do not want the report to have the stripe view. 

However, if you do not use scrolling in the report, you must apply the Stripes attribute at the Report, Form, Part, or Line level based on your specific requirements. 

When Stripe view is enabled, following are the behaviours that applies to the Line. 

Stripes Automatically Apply to Lines 

• Repeated Lines with Scroll: The system automatically applies stripes to lines when scroll is enabled. 
• Simple Lines with Scroll (Fixed: No): The system automatically applies stripes to simple lines when scrolling is enabled, and they are not marked as fixed. 

Stripes Do Not Automatically Apply to Lines 

• Simple Lines: Without scroll, the system does not apply stripes by default. 
• Repeated Lines Without Scrolls: The system does not apply stripes to repeated lines without scrolling. 
• Fixed Lines: The system does not apply stripes to lines marked as fixed. 

Stripes Do Not Automatically Apply to Parts 

• Fixed Parts: When you mark parts as fixed, the system does not apply stripes. It excludes parts and lines associated with fixed parts from the stripe view. 

Stripes Do Not Automatically Apply to Empty Lines 

• Lines Associated with Empty Objects: The system does not apply stripes to lines linked to empty objects, as opposed to master objects. 
• Fixed Fields: The system does not include fields marked as fixed in stripes. 

Additional Notes 

• You can set the Fixed attribute at the Part, Line, and Field levels. When you mark Parts and Lines as fixed, they follow the behaviour concerning stripes as mentioned above. When you mark a Part or Field as Fixed, the platform internally sets the associated Line as fixed. 
• The platform processes the Fixed attribute for Fields after processing the Lines. As a result, it internally sets a Line’s Fixed status after the explosion of the Part mentioned in the Line. Before drawing and during Line processing for stripes, if you consider a Line as fixed, the platform does not include the exploded Part and its Lines in the Stripe View by default. 
• Due to this, if you need the exploded Part and its Lines included in the Stripe View, you must explicitly set the Part using the Stripes attribute. 

Syntax 

Stripe:<Logical Expression> 

<Logical Expression> is a logical value or an expression that evaluates to a logical value 

Example 

[Report: TSPL Report] 

Stripe : No 

The Stripe view is disabled for the Report TSPL Report with Stripe attribute set to No, even if it is enabled in the Help ->Settings -> Display in the product. But if the Form, Part or Line belonging to the Report has Stripe attribute set to yes, then the report will have stripes enabled as per the scope.

There are situations where a Report needs to behave differently based on certain conditions. For example, the Report may need to use a different Form, Object, Collection, or other Report-level settings depending on the current company, user role, export format, or any other runtime condition. 

One way to achieve this is by using the Option attribute. However, when multiple options are defined, every option’s condition is evaluated, and all the options whose conditions evaluate to True are applied. This often requires writing additional negative conditions to ensure that only one option is selected. 

The Switch attribute provides a more efficient alternative. 

The Switch attribute evaluates the specified conditions sequentially and stops as soon as the first condition evaluates to True. Only the corresponding optional Report definition is applied, eliminating unnecessary evaluations and simplifying the code. 

A useful feature of the Switch attribute is that switch statements can be grouped using labels. 

Each label represents an independent switch group. 

Within a group: 

• Conditions are evaluated sequentially.  
• The first matching optional Report is applied.  
• Remaining cases in the same group are ignored.  

If multiple switch groups exist, the first matching case from each group is applied independently. 

Just like the Option attribute, Switch works with optional Report definitions. 

The Report referenced in the switch statement must be defined as an optional Report by prefixing the definition name with !. 

Syntax  

Switch : <Label> : <Optional Field Name> : <Condition> 

<Option Field Name> is the Optional field definition  

<Logical Condition> is a logical value or an expression that evaluates to a logical value 

Example 

[Report: TSPL Report]

Title: “In Display Mode” 

Switch: Case Title: TSPLPrintTitle: $$InPrintMode 

Switch: Case Title : TSPLExportTitle: $$InExportMode 

Switch: Case Title : TSPLMailTitle: $$InMailMode

[!Report: TSPLPrintTitle]  

Title : “In Print Mode”

[!Report: TSPLExportTitle] 

Title : “In Export Mode”
 

[!Report: TSPLMailTitle] 

Title : “In Mail Mode” 

The example shows a report TSPL Report that has 3 switch statements with same label Case Title to determine the title of the report in Print mode, Export Mode and Mail mode. In other modes the Title ‘In Display Mode’ is applicable.

Imagine walking through a library. Every book has a title on its cover that tells you what it’s about, even before you open it. In the same way, every Report in TallyPrime has a title that helps users immediately identify the information being displayed. 

This is achieved using the Title attribute. The Title attribute specifies the text displayed as the title of a Report.  

In the absence of the attribute, the report definition name is applied as the report title. 

Syntax 

Title : <String > 

Example 

[Report: TSPL Balance Sheet] 

Title           : $$LocaleString:”Balance Sheet” 

The example shows that the report TSPL Report is displayed with the title Balance Sheet when the report is opened

Think of a Report as a backpack for a hike. Before starting the journey, you decide what items to carry—water, a map, a compass, and snacks. Throughout the hike, whenever you need one of these items, you simply take it out of the backpack. 

Similarly, the Variable attribute tells the Report which variables it should carry throughout its execution. The Variable attribute specifies the list of variables that should be available within the Report. Once the Report is loaded, these variables travel with it and are readily available to every Form, Part, Line, and Field whenever needed. 

Simply defining a variable in TDL (unless defined in system scope) does not make it available everywhere. A Report must explicitly include the variables it intends to use through the Variable attribute. This creates the variable instances when the Report is loaded, allowing them to be modified and share values throughout the Report. 

Report variables get their default value from definition specification, or from the declaration specification, or the values are inherited from the owner scope, if the variable is marked as Volatile. 

Report allows two special attributes SET and PRINT SET to set/override the values of the variable during the startup of the report in Display / Print mode respectively. 

Form definition also has a SET attribute, which overrides the variable’s value during startup creation and subsequent re-creation of the form during any refresh/regeneration. 

Syntax 

Variable: <Variable Names> [:<Data Type> [:<Value>]]  

Example 

[Report: TSPL Report] 

List Var: vGroup: String 

List Var: vType 

[Variable: vType] 

Type: String 

The report TSPL Report has 2 variables declared using the attribute Variables– vGroup which uses the inline declaration where it is defined as variable holding value of String data type and vType a variable declared in the report scope and defined outside using variable definition.