Part
A Form in TDL represents the overall layout presented to the user. However, complex forms are rarely built as a single unit. They are typically divided into smaller logical sections, each responsible for displaying a specific set of information. Part is a definition used to create these individual sections within a Form. By dividing a Form into multiple Parts, developers can organize information into logical sections such as headers, body, footer, summaries, totals, or other functional areas. This modular approach makes Forms easier to design, maintain, and reuse across multiple reports and applications.
When a Part is specified using the Parts attribute of a Form, it is rendered as a Vertical Part by default. Additional layout attributes can subsequently be used to arrange Parts horizontally, if required.
A Part acts as a container for one or more Parts or Lines, allowing complex layouts to be built hierarchically by nesting Parts within Parts. At the lowest level of this hierarchy, every Part must eventually contain one or more Lines, which in turn contain Fields responsible for displaying information or accepting user input. Since each Part can independently control properties such as repetition, scrolling, borders, spacing, background, and alignment, it serves as the fundamental building block for designing flexible and well-structured user interfaces in TDL.
Syntax
[Part: <Part Name>]
➥ Download the Part Samples
| Sample Files | Attributes |
| AccessNameAttribute | Access Name, ObjectEx, Border, Line, Local, Set, Space Top, Use |
| ButtonAttribute | Button, Border, Height |
| DisplayXAxisLegendAttribute | Display X Axis Legend, Line, Repeat, Border, Graph Type, Local, Set, Background |
| EnableGraphCursorAttribute | Enable Graph Cursor, Line, Repeat, Border, Graph Type, Local, Set, Background |
| ExcelAutoFitAttribute | Excel AutoFit, Line, Repeat, Scroll, Float, Local, Set, Border, Height, Width, Use |
| ExcelSheetName | Excel Sheet Name, Line, Repeat, Scroll, Float, Local, Set, Border, Height, Width, Stripe, Use |
| FloatAttribute | Float, Common Border, Bottom Line, Line, Repeat, Scroll, Border, Local, Set, Width, Use |
| GraphDisplayNumRowsAttribute | Graph Display Num Rows, Enable Graph Cursor, Graph Type, Line, Repeat, Border, Local, Set, Background |
| GraphTypeAttribute | Graph Type, Line, Repeat, Border, Local, Set, Background |
| ImageAttribute | Image, Line, Border, Set, Use |
| JSONTag | JSONTag, Line, Repeat, Scroll |
| Object & Object Ex Attribute | Object, ObjectEx, Line, Repeat, Scroll, Local, Border, Vertical, Part (nested Part), Set, Use |
| PageBreakAttribute | Page Break, Common Border, Float, Line, Repeat, Scroll, Border, Set, Width, Use |
| SetAlwaysAttribute | Set Always, Line, Repeat, Break On, Scroll, Border, Width, Use |
| CombineorTotalAttribute | Combine (Alias Name: Total) / Total, Bottom Line, Repeat, Scroll, Common Border, Float, Border, Line, Local, Set, Use, Width |
Attributes
Large applications often contain multiple Parts that are reused, modified, or accessed dynamically during execution. In such scenarios, referring to a Part solely by its definition name can make the application difficult to maintain. Access Name is an attribute used to assign a unique runtime identifier to a Part. This identifier acts as an alternate name through which the Part can be located, accessed, or manipulated by other TDL definitions or functions. By separating the runtime identifier from the definition name, developers can create more flexible and maintainable solutions, especially when Parts are reused across multiple Forms or generated dynamically. The Access Name must be unique within its scope to ensure that the intended Part can be identified unambiguously during execution. The Access Name is typically referenced using the $$AccessObj function. This function accepts the definition type, the Access Name, and the value or method to be evaluated, allowing the associated object of the identified definition to be accessed during runtime.
For example, consider a reusable Header Part that displays the company name and report title. The same Part may be used in multiple reports, while its definition name or implementation changes over time. By assigning an Access Name such as ReportHeader, other definitions can consistently refer to the header using this identifier without depending on the actual Part definition name. This provides a stable reference point and reduces the impact of future changes, making the application easier to maintain.
Syntax
[Part : <Part Name>]
Access Name : <Access Name Formula>
Example
[Part: TSPL AccessObj1]
Lines : TSPL AccessObj
AccessName : “Cash”
ObjectEx : (Ledger, “Cash”)
In this example, the Part TSPL AccessObj1 is assigned the Access Name “Cash” and is associated with the Cash ledger using the ObjectEx attribute. Instead of referring to the Part by its definition name (TSPL AccessObj1), the field AO Part TSPL AccessObj1 uses the function $$AccessObj to access the object associated with the Part through its Access Name. The expression $$AccessObj:Part:”Cash”:#TSPLAccessObj locates the Part identified by the Access Name “Cash”, retrieves the object associated with that Part, and displays the required value in the field. This demonstrates how Access Name provides a stable runtime identifier that can be used by TDL functions such as $$AccessObj to access a Part and its associated object without depending on the actual Part definition name.
Different sections of a report or form often need to be visually distinguished to improve readability and emphasize important information. Background is an attribute used to specify the background color or pattern for a Part. The specified background is applied to the entire Part, allowing developers to visually separate sections such as headers, summaries, totals, or data regions from the rest of the form. By assigning an appropriate background, developers can create well-organized and aesthetically consistent user interfaces without affecting the content displayed within the Part. The background can be specified using a predefined Color definition or any supported background specification.
Since a Part act as a container for one or more Parts or Lines, the background specified at the Part level is applied uniformly to all the content rendered within that Part unless overridden at a lower level. This makes the Background attribute particularly useful for highlighting logical sections of a report while maintaining a consistent appearance throughout the application.
Syntax
[Part : <Part Name>]
Background : <Color Name Definition Name>
Example
[Part: TSPL BGAttribute]
Line: TSPL BGAttribute
Background: Yellow
In this example, the Background attribute assigns the color Yellow as the background for the Part TSPL BGAttribute. Since the Part contains the line TSPL BGAttribute, the yellow background is applied to the entire area occupied by the Part, including its contained Line. As a result, all content displayed within this Part appears against a yellow background unless a child definition overrides the background. This demonstrates how the Background attribute can be used to visually distinguish specific sections of a form, such as headers, summaries, warning messages, or highlighted information, thereby improving the overall readability and appearance of the user interface.
Borders are commonly used to visually separate sections of a user interface and improve the readability of information. Border is an attribute used to specify the type of border to be applied around a Part. Similar to the Border attribute at the Form level, it uses a predefined Border definition to determine the appearance of the border. However, at the Part level, the border is applied only to the boundaries of the specific Part rather than the entire Form. Since a Part represents a logical section of a Form, this attribute is particularly useful for highlighting or enclosing individual sections such as headers, summaries, grouped information, or data regions, making them visually distinct from the rest of the interface.
Syntax
[Part : <Part Name>]
Border : <Border Definition Name>
Example
[Part: TSPL BorderAttribute]
Line : TSPL BorderAttribute
Border: Thin Box
In this example, the Part TSPL BorderAttribute is assigned the predefined border Thin Box using the Border attribute. Since the Part contains the line TSPL BorderAttribute, a thin box border is drawn around the entire area occupied by the Part and its contents. This visually encloses the section, making it distinct from the surrounding content. Such borders are commonly used to separate report headers, summaries, grouped information, or important sections, improving the readability and organization of the user interface.
The content of a Part is, by default, displayed starting from the top. However, there are scenarios where the content needs to remain aligned with the bottom of the Part, regardless of the available vertical space. Bottom Lines is an attribute used to align the Lines of a Part to its bottom edge based on the height specified for that Part. When enabled, the Lines are positioned from the bottom instead of the top, leaving any unused space above the content. This attribute is particularly useful for designing layouts where information such as totals, signatures, declarations, or footer sections must always appear at the bottom of a fixed-height Part, ensuring a consistent and well-aligned presentation regardless of the amount of content displayed.
Syntax
[Part : <Part Name>]
Bottom Line : <Line Definition Name>
Example
[Part: TSPL BottomLineAttribute]
Bottom Line: TSPL BottomLineAttribute
In this example, the Bottom Line attribute specifies TSPL BottomLineAttribute as the Line that should be positioned at the bottom of the Part. If the Part has a height greater than the space occupied by its contents, the specified Line is aligned with the bottom edge of the Part instead of starting from the top. Any remaining vertical space is therefore left above the Line. This is particularly useful when designing fixed-height sections such as report footers, signature blocks, declarations, or total sections, where the content must consistently appear at the bottom of the Part regardless of the amount of unused space.
A Part can contain multiple child Parts to create hierarchical and well-structured layouts. By default, these child Parts are displayed sequentially from the top of the parent Part. Bottom Part is an attribute used to specify one or more child Parts that should be positioned at the bottom of the parent Part instead of following the normal top-to-bottom layout. When a height is defined for the parent Part, the specified Bottom Part remains aligned with its bottom edge, while the remaining child Parts occupy the space above it. If multiple Bottom Parts are specified, their arrangement is controlled by the Vertical attribute. When Vertical is set to Yes, the Bottom Parts are stacked one below the other; otherwise, they are arranged horizontally. This attribute is particularly useful for positioning sections such as totals, declarations, signature blocks, or footers so that they consistently appear at the bottom of a fixed-height Part, regardless of the amount of content displayed above them.
Syntax
[Part : <Part Name>]
Bottom Part : <Part Name>
Example
[Part: TSPL BottomPartAttribute]
Bottom Part : TSPL BottomsubPart2
In this example, the Bottom Part attribute specifies TSPL BottomsubPart2 as the child Part that should be positioned at the bottom of the parent Part TSPL BottomPartAttribute. If the parent Part has a defined height, TSPL BottomsubPart2 is aligned with the bottom edge of the parent Part, while any other child Parts are displayed in the remaining space above it. This ensures that the specified Part consistently appears at the bottom of the layout, irrespective of the amount of content in the upper section. Such an arrangement is commonly used for sections like totals, declarations, signature blocks, or footers that should always remain anchored to the bottom of a fixed-height Part.
Repeating Lines are commonly used to display collections of data such as vouchers, ledgers, inventory items, or transactions. By default, the Line is repeated for every object in the associated collection. Break (alias: Break After) is an attribute used to specify a logical condition that determines when the repetition of a Line should terminate. The condition is evaluated after each repeated Line is processed. When it evaluates to Yes, the current Line is displayed and no further repetitions are performed, even if additional objects exist in the collection. This allows developers to control the amount of data displayed based on business requirements, such as displaying only a limited number of records, stopping after a summary or total line, or terminating the display when a specified business condition is met.
Unlike the Break On attribute, which continues repeating Lines and is primarily used to group data whenever the value of a specified method changes, Break stops the repetition altogether. In simple terms, Break controls when the display of repeated Lines should end, whereas Break On controls where groups of repeated Lines should begin and end without interrupting the repetition.
Syntax
[Part : <Part Name>]
Break : <Logical Expression>
Example
[Part: TSPL BreakAttribute]
Line: TSPL BreakAttributeTit,TSPL BreakAttribute
Repeat: TSPL BreakAttribute : TSPLSalesmanAggr
Scroll: Vertical
Float : No
Break : $$Line=5
In this example, the Part TSPL BreakAttribute repeats the Line TSPL BreakAttribute for each object in the collection TSPLSalesmanAggr. The Break attribute specifies the condition $$Line = 5, which is evaluated after each repeated Line is displayed. When the fifth Line is rendered, the condition evaluates to Yes, causing the repetition to terminate. As a result, only the first five records from the collection are displayed, even if additional objects are available. This demonstrates how the Break attribute can be used to limit the number of repeated Lines displayed based on a logical condition, providing better control over the presentation of data.
Repeating Lines often display data that needs to be grouped based on a common value, such as vouchers by date, ledgers by group, or items by category. Break On is an attribute used along with the Repeat attribute to specify the method or expression on which the repeated Lines should be grouped. During repetition, Tally evaluates the specified expression for each object. Whenever its value changes, a break is identified, indicating the end of one group and the beginning of the next. This grouping mechanism is commonly used to print group headers, subtotals, or summaries while continuing to display all the records in the collection. Unlike the Break attribute, which terminates the repetition when a condition is satisfied, Break On continues the repetition and simply identifies where one group ends and another begins.
Syntax
[Part : <Part Name>]
Break On : <Logical Expression>
Example
[Part: TSPL BreakOnAttribute]
Line: TSPL BreakOnAttributeTit,TSPL BreakOnAttribute
Repeat: TSPL BreakOnAttribute : TSPLSalesmanAggr
Scroll: Vertical
Float : No
Break On: $$IsEmpty:$TSPLName
In this example, the Line TSPL BreakOnAttribute is repeated for each object in the collection TSPLSalesmanAggr. The Break On attribute evaluates the expression $$IsEmpty:$TSPLName for every repeated object. Whenever the expression evaluates to Yes—that is, when the value of $TSPLName is empty—a break is identified at that point in the repeated data. This break can then be used by TDL to separate groups, trigger group-level processing, or display group headers, footers, or subtotals while continuing the repetition of the remaining records. Unlike the Break attribute, which stops the repetition altogether, Break On simply marks the boundary between groups without interrupting the display of the collection.
Forms often provide actions that users can perform, such as creating, altering, deleting, printing, or navigating through data. While buttons are commonly associated with the entire Form, there are scenarios where actions need to be available only within a specific section of the interface. Button is an attribute used to specify one or more buttons that should be displayed within a Part. These buttons, commonly referred to as inline buttons, appear in the context of the Part rather than the Form, allowing users to perform actions relevant to that section. This helps create a more intuitive user interface by placing frequently used or context-specific actions close to the data they operate on, while avoiding unnecessary buttons elsewhere in the Form.
Syntax
[Part : <Part Name>]
Button : <Button Definition Name>
Example
[Part: TSPL ButtonAttribute]
Button: ShowDayBook, ShowProfitandLoss
In this example, the Button attribute associates the predefined buttons ShowDayBook and ShowProfitandLoss with the Part TSPL ButtonAttribute. These buttons are displayed inline within the Part, allowing users to invoke the corresponding actions directly from that section of the interface. Instead of navigating to the Day Book or Profit & Loss report through menus, users can access these reports from the context of the current Part, making navigation quicker and improving usability. This demonstrates how the Button attribute can be used to provide context-specific actions that are closely associated with the information displayed within a Part.
Reports often display repeated numeric values such as amounts, quantities, or rates, where it is useful to calculate totals or subtotals without manually iterating through the data. Combine (aliases: Total and Totals) is an attribute used to specify one or more Fields within the same Part whose values need to be accumulated during repetition. As the Part renders its repeated Lines, Tally automatically calculates the total and, where applicable, the subtotal for the specified Fields. These computed values are not displayed automatically; instead, they can be accessed using the built-in functions $$Total and $$SubTotal, typically from Fields within the same Part. Since the attribute operates on Fields belonging to the current Part, only Field names defined within that Part can be specified. When used together with attributes such as Break On, $$SubTotal provides group-wise totals, while $$Total returns the overall accumulated value for the Part.
Syntax
[Part : <Part Name>]
Combine : <Field Definition Name>
Example
[Part: TSPL CombineAttribute]
Line : TSPL LedgerTitles,TSPL LedgerDetails
Bottom Line : TSPL LedgerTotals
Repeat : TSPL LedgerDetails : List of Ledgers
Scroll : Vertical
Total : TSPLLedgerOp, TSPLLedgerCl
In this example, the Total attribute specifies that the values displayed in the fields TSPLLedgerOp and TSPLLedgerCl should be accumulated as the Line TSPL LedgerDetails is repeated for each object in the List of Ledgers collection. During repetition, Tally automatically calculates the overall totals for these fields. The Bottom Line attribute specifies TSPL LedgerTotals, where these accumulated values can be displayed using the $$Total function. This eliminates the need to manually calculate totals within TDL and ensures that the displayed totals always reflect the values rendered in the repeated Lines.
In reports and forms, each Line can have its own border, resulting in separate borders around individual Lines. Common Border is an attribute used to specify whether these individual Line borders should be merged into a single border surrounding the entire Part. When enabled, Tally extends the border across all the Lines in the Part, creating a continuous outline instead of multiple disconnected borders. This gives the Part a cleaner and more structured appearance, particularly when displaying tabular data, grouped information, or summaries. In scenarios where the border should not extend beyond a specific Field, the SubTitle : Yes attribute can be specified for that Field to prevent the border from extending upward from that point, allowing finer control over the border layout.
Syntax
[Part : <Part Name>]
Common Border : <Logical Value>
Example
[Part: TSPL RepeatAttribute]
Line : TSPL LedgerTitles,TSPL LedgerDetails
Repeat : TSPL LedgerDetails : List of Ledgers
Scroll : Vertical
Common Border : Yes
Float : No
Border : Thin Box
In this example, the Part TSPL RepeatAttribute displays the repeated Line TSPL LedgerDetails for each object in the List of Ledgers collection, enclosed within a Thin Box border. By setting Common Border : Yes, Tally extends the Thin Box border across the entire Part instead of drawing a separate border around each repeated Line. As a result, all the repeated ledger records appear within a single continuous border, giving the report a cleaner and more organized tabular appearance. Without Common Border, each repeated Line would be enclosed by its own individual border, making the layout appear fragmented. This demonstrates how the Common Border attribute helps create a unified visual boundary for all the content displayed within a Part.
When a Part displays multiple repeated Lines, the system normally places the cursor or selection on the first available Line. Default Line is an attribute used to specify the logical condition that determines which Line should be selected by default when the Part is displayed. The condition can use any method of the object associated with the repeated Line, allowing the default selection to be determined dynamically based on the underlying data. When the condition evaluates to Yes for a particular Line, that Line receives the initial focus and is highlighted using the system’s default selection style. This attribute is particularly useful for restoring the user’s last position, automatically selecting a relevant record, or directing the user’s attention to a specific Line when the report or form opens.
Syntax
[Part : <Part Name>]
Default Line : <String Expression>
Example
[Part: TSPL DefaultLineAttribute]
Line : TSPL DefaultLineAttributeTit,TSPL DefaultLineAttribute
Repeat : TSPL DefaultLineAttribute : TSPLLedgerColl
Default Line: $Name = “Customer ABC”
In this example, the Line TSPL DefaultLineAttribute is repeated for each object in the collection TSPLLedgerColl. The Default Line attribute evaluates the condition $Name = “Customer ABC” for every repeated Line. When the Line corresponding to the ledger Customer ABC is encountered, it is automatically selected and receives the initial focus when the Part is displayed. Instead of positioning the cursor on the first record in the collection, the report opens with Customer ABC as the default selected Line. This provides a better user experience by directing the user’s attention to a specific record, such as a frequently accessed customer, the last selected entry, or any other business-relevant record.
Reports and documents that are printed or exported may require a digital signature to establish their authenticity and integrity. Digital Sign is an attribute used to specify whether a digital signature should be displayed within a Part. When enabled, the Part reserves space for and displays the digital signature, provided a valid digital signature is available and applicable to the report or document. When disabled, the digital signature is omitted from that Part. This attribute allows developers to control the placement of digital signatures within specific sections of a report, making it particularly useful for invoices, certificates, statutory documents, and other business documents that require authenticated digital signing.
Syntax
[Part : <Part Name>]
DigitalSign : <Logical expression>
Example
[Part: TSPL DigitalSignAttribute]
Line : Dummy Line
DigitalSign: Yes
In this example, the Part TSPL DigitalSignAttribute has the DigitalSign attribute set to Yes, indicating that a digital signature should be displayed within this Part. When the report or document is printed or exported and a valid digital signature is available, Tally reserves the required space in this Part and renders the digital signature. If no valid digital signature is available, enabling this attribute alone does not display a signature. This demonstrates how the DigitalSign attribute controls the placement of the digital signature within a specific Part, allowing developers to position it appropriately in business documents such as invoices, certificates, or statutory reports.
Charts often include axis legends to help users understand what each axis represents. Display X Axis Legend is an attribute used to specify whether the legend for the horizontal (X) axis should be displayed in a graph. The X-axis legend typically describes the categories or values plotted along the horizontal axis, such as months, dates, item names, or other business dimensions. By default, this attribute is set to No (False), and the legend is not displayed. When enabled, the legend appears below the X-axis, making the chart easier to interpret. This attribute is applicable only for graph-based Parts, which must be configured using the Graph Type attribute. Additionally, the parent Report must be defined as a dashboard using the Dashboard Type attribute. If either Graph Type or Dashboard Type is not specified, the Part is treated as a normal Part and this attribute is ignore.
Syntax
[Part : <Part Name>]
Display X Axis Legend : <Logical expression>
Example
[Part: TSPL DisplayXAxisLegendAttribute]
Line : TSPL DisplayXAxisLegendAttribute
Repeat : TSPL DisplayXAxisLegendAttribute : TSPL Indirect Expenses collection
Border : Thin Box
Graph Type : Yes
DisplayXAxisLegend: Yes
In this example, the Part TSPL DisplayXAxisLegendAttribute is configured as a graph by setting Graph Type : Yes, which enables graph rendering for the Part. The DisplayXAxisLegend : Yes attribute instructs Tally to display the legend for the horizontal (X) axis of the graph. As a result, the chart displays a descriptive label for the values or categories plotted along the X-axis, helping users understand what the horizontal axis represents. Since this Part repeats data from the TSPL Indirect Expenses collection, the X-axis typically represents the category associated with each plotted value. Without Graph Type : Yes, the Part would not be treated as a graph, and the DisplayXAxisLegend attribute would have no effect. Likewise, this example assumes that the parent Report is configured as a dashboard using the Dashboard Type attribute.
Dashboard reports often contain graphs that users need to analyse interactively rather than just view. Enable Graph Cursor is an attribute used to specify whether users can navigate through the graph using the keyboard (Left, Right, Up, and Down arrow keys) or mouse clicks. When enabled, a cursor moves across the graph, shifting the focus from one data point, bar, or row to another and highlighting the selected value. This enables users to inspect individual data points and better understand the information presented in the graph. When disabled, the graph is displayed as a static visual without cursor-based interaction. This attribute is applicable only to graph-based Parts, which must be configured using the Graph Type attribute. Additionally, the parent Report must be defined as a dashboard using the Dashboard Type attribute. For meaningful navigation, the graph should also have its data mapped using graph-related Field attributes such as Graph Label and Graph Value. If these prerequisites are not met, enabling the Graph Cursor has no effect.
Syntax
[Part : <Part Name>]
Display X Axis Legend : <Logical expression>
Example
[Part: TSPL DisplayXAxisLegendAttribute]
Line : TSPL DisplayXAxisLegendAttribute
Repeat : TSPL DisplayXAxisLegendAttribute : TSPL Indirect Expenses collection
Border : Thin Box
Graph Type : Yes
DisplayXAxisLegend: Yes
In this example, the Part TSPL DisplayXAxisLegendAttribute is configured as a graph by setting Graph Type : Yes, and the graph is populated using data from the repeated collection TSPL Indirect Expenses collection. By specifying DisplayXAxisLegend : Yes, Tally displays the legend for the horizontal (X) axis of the graph. The X-axis legend describes the categories represented along the horizontal axis—for example, the names of the indirect expense ledgers plotted from the collection—making it easier for users to understand what each bar or data point represents. If DisplayXAxisLegend is not specified or is set to No, the graph is displayed without the X-axis legend. This example also assumes that the parent Report is configured as a dashboard using the Dashboard Type attribute, without which the graph-related attributes would have no effect.
When data is exported to Excel, the length of the content in each cell may vary, causing text to appear truncated or requiring users to manually resize columns. Excel AutoFit is an attribute used to specify whether the width of Excel cells should automatically adjust to fit their contents during export. When set to Yes, Tally automatically resizes the columns so that the complete contents of the exported fields are visible without manual intervention. This improves the readability and presentation of the exported worksheet, especially when fields contain variable-length values such as ledger names, item descriptions, addresses, or remarks. Developers typically enable this attribute when the exported workbook is intended for end-user viewing or reporting, where a neatly formatted spreadsheet is preferred over a fixed layout. However, when exporting data into a predefined Excel template with fixed column widths or a carefully designed layout, developers may choose to keep this attribute disabled to preserve the template’s formatting.
The Excel AutoFit attribute is meaningful only during Excel export and is typically used in conjunction with following :
- Resource (Form Definition) – References the Excel template (Resource Type : MSEXCEL) used for export.
- Cell Write (Form/Field Definition) – Commonly used when exporting data into individual Excel cells. Although Excel AutoFit does not strictly require Cell Write : Yes, it is most beneficial when data is written cell by cell, as each column can then be resized based on the values written.
Resource Type : MSEXCEL (Resource Definition) – Ensures that the export target is an Excel workbook, where AutoFit functionality is applicable.
Syntax
[Part : <Part Name>]
Excel AutoFit : <Logical Value>
Example
[Part: TSPL ExcelAutofitAttribute]
Line : TSPL ExcelAutofitTitle,TSPL ExcelAutofitDetails
Repeat : TSPL ExcelAutofitDetails : TSPL LedgerCollection
Scroll : Both
Float : No
Excel AutoFit : Yes
In this example, the Part TSPL ExcelAutofitAttribute displays ledger data by repeating the Line TSPL ExcelAutofitDetails for each object in the TSPL LedgerCollection. By specifying Excel AutoFit : Yes, Tally automatically adjusts the width of the corresponding Excel columns during export so that the contents of each cell are fully visible. This is particularly useful when the collection contains values of varying lengths, such as ledger names or descriptions, as it eliminates the need for users to manually resize columns after opening the exported workbook. If this attribute is not specified or is set to No, the exported worksheet retains the default or template-defined column widths, which may result in longer values appearing truncated. This attribute is especially beneficial when the exported Excel file is intended for direct viewing or analysis rather than for use with a fixed-layout Excel template.
Excel workbooks can contain multiple worksheets, each representing a different set of data. Excel Sheet Name is an attribute used to specify the name of the worksheet into which Tally exports the data. When the report is exported, the specified name is assigned to the Excel sheet, making it easier for users to identify and navigate the exported information. Developers typically use this attribute to provide meaningful sheet names such as Sales Register, Purchase Summary, or Outstanding Receivables, especially when generating reports that contain multiple worksheets or when exporting data into an existing Excel workbook. If this attribute is not specified, Tally assigns the default worksheet name during export.
The Excel Sheet Name attribute is applicable only during Excel export and is commonly used with:
- Resource (Form Definition) – When exporting to a predefined Excel template (Resource Type : MSEXCEL), the specified sheet name should match the worksheet present in the template if the data is intended to be written to that sheet.
- Resource Type : MSEXCEL (Resource Definition) – Indicates that the export target is an Excel workbook.
Unlike attributes such as Excel AutoFit or Cell Write, Excel Sheet Name does not control how data is written. It simply identifies the worksheet within the Excel workbook where the exported data should be placed.
Syntax
[Part : <Part Name>]
Excel SheetName : <Sheet Name Value>
Example
[Part: TSPL ExcelSheetNameAttribute]
Line : TSPL ExcelAutofitTitle,TSPL ExcelAutofitDetails
Repeat : TSPL ExcelAutofitDetails : TSPL LedgerCollection
Scroll : Both
Float : No
Excel SheetName : “Ledger Details”
In this example, the Part TSPL ExcelSheetNameAttribute displays ledger information by repeating the Line TSPL ExcelAutofitDetails for each object in the TSPL LedgerCollection. The attribute Excel SheetName : “Ledger Details” specifies that, during Excel export, the data generated by this Part should be written to a worksheet named Ledger Details. If the workbook already contains a worksheet with this name (for example, in an Excel template), Tally exports the data to that sheet. Otherwise, a worksheet with the specified name is created during export. Assigning a meaningful sheet name helps users easily identify the exported data, particularly when a workbook contains multiple worksheets or different reports.
A Part may contain one or more Bottom Lines, typically used to display totals, summaries, or footer information. Float is an attribute used to specify how these Bottom Lines should be positioned within the Part. When set to Yes, the Bottom Lines are displayed immediately after the last visible Line, moving upward as the amount of displayed data changes. This prevents unnecessary blank space and allows the layout to adjust dynamically based on the content. When set to No, the Bottom Lines remain fixed at the bottom of the Part, regardless of the amount of data displayed, preserving a consistent layout even if there is empty space above them. Developers typically use Float : Yes for reports with variable amounts of data where a compact layout is preferred, and Float : No for forms and reports where totals or footer information should always appear at a fixed position on the screen or page. The default value of the Float attribute is Yes.
The Float attribute is meaningful only when the Part contains Bottom Line or Bottom Part definitions. If no Bottom Line or Bottom Part is specified, changing the value of Float does not produce any visible effect. It is commonly used together with the Height attribute, since fixing Bottom Lines at the bottom of a Part becomes noticeable only when the Part has a defined height.
Syntax
[Part : <Part Name>]
Float : <Logical Value>
Example
[Part: TSPL RepeatAttribute]
Line : TSPL LedgerTitles,TSPL LedgerDetails
Bottom Line : TSPL LedgerTotals
Repeat : TSPL LedgerDetails : List of Ledgers
Scroll : Vertical
Common Border : Yes
Float : No
Border : Thin Box
In this example, the Part displays the repeated Line TSPL LedgerDetails for each object in the List of Ledgers collection and displays the summary Line TSPL LedgerTotals as a Bottom Line. Since Float is set to No, the Bottom Line remains fixed at the bottom of the Part regardless of the number of ledger records displayed. If the collection contains only a few records, empty space is maintained between the last repeated Line and the Bottom Line, ensuring that the totals always appear at a consistent position. This layout is particularly useful for reports where summary information should always remain at the bottom of the screen or page.
Dashboard graphs often contain multiple data points, making it useful for users to view the exact value associated with the currently selected point. Graph Display Cursor Label is an attribute used to specify whether a value label should be displayed for the data point currently under the graph cursor. When enabled, a small label appears as the user navigates the graph using the keyboard or mouse, displaying the value of the selected bar, line point, or graph element. This provides immediate feedback without requiring users to interpret the graph visually, making analysis easier and more precise. Developers typically enable this attribute in dashboards designed for interactive data analysis, where users need to inspect individual values, compare data points, or identify peaks, lows, and trends. For simple presentation dashboards intended only for visual summaries, the attribute may be left disabled to reduce on-screen clutter.
For the Graph Display Cursor Label attribute to function, the following prerequisites must be met:
- Report Definition
- Dashboard Type : Yes – The parent Report must be configured as a dashboard.
- Part Definition
- Graph Type : Yes – The Part must be configured as a graph.
- Enable Graph Cursor : Yes – The graph cursor must be enabled; otherwise, there is no active cursor for which the label can be displayed.
- Field Definition
- Graph Label – Specifies the category or label for each plotted data point.
- Graph Value – Specifies the numeric value displayed in the graph and shown by the cursor label.
Without these prerequisites, enabling Graph Display Cursor Label has no visible effect because there is no interactive graph cursor or graph data to display.
Syntax
[Part : <Part Name>]
Graph Display Cursor Label : <Logical expression>
Example
[Part: TSPL GraphDisplayCursorLabelAttribute]
Line : TSPL GraphDisplayCursorLabelAttribute
Repeat: TSPL GraphDisplayCursorLabelAttribute : TSPL Indirect Expenses collection
Border: Thin Box
Graph Type : Yes
Graph Display Cursor Label: Yes
Enable Graph Cursor: Yes
In this example, the Part TSPL GraphDisplayCursorLabelAttribute is configured as a graph by setting Graph Type : Yes and displays data from the TSPL Indirect Expenses collection. The Enable Graph Cursor : Yes attribute allows users to navigate through the graph using the keyboard or mouse, while Graph Display Cursor Label : Yes instructs Tally to display a label showing the value of the currently selected data point. As the graph cursor moves from one bar or data point to another, the corresponding value is displayed automatically, enabling users to inspect individual values without estimating them from the graph. This makes the graph more interactive and is particularly useful in analytical dashboards where users need to compare values or examine specific data points. This example also assumes that the parent Report is configured as a dashboard using the Dashboard Type attribute, and the graph data is mapped using the appropriate graph-related Field attributes such as Graph Label and Graph Value.
Dashboard graphs may contain more data points than can be displayed within the available screen width. Graph Display Num Rows is an attribute used to specify the maximum number of graph rows or data points that should be visible at a time. When the number of plotted data points exceeds this limit, Tally displays only the specified number initially and allows users to navigate horizontally to view the remaining data using the graph cursor. This helps maintain a readable and uncluttered graph, particularly when visualising large datasets. Developers typically use this attribute in analytical dashboards that display numerous categories, such as monthly sales, ledger-wise balances, item-wise stock, or expense analysis, where displaying all data points simultaneously would make the graph crowded and difficult to interpret. For graphs containing only a few data points, this attribute is generally unnecessary.
For the Graph Display Num Rows attribute to function correctly, the following prerequisites must be met:
- Report Definition
- Dashboard Type : Yes – The parent Report must be configured as a dashboard.
- Part Definition
- Graph Type : Yes – The Part must be configured as a graph.
- Enable Graph Cursor : Yes – Cursor navigation must be enabled to allow users to move across data points beyond the initially displayed rows.
- Field Definition
- Graph Label – Specifies the category or label for each data point.
- Graph Value – Specifies the numeric value plotted on the graph.
Without these prerequisites, Graph Display Num Rows has no effect because the Part is either not rendered as a graph or does not support interactive navigation.
Syntax
[Part : <Part Name>]
GraphDisplayNumRows : <Number expression>
Example
[Part: TSPL GraphDisplayNumRowsAttribute]
Line : TSPL GraphDisplayNumRowsAttribute
Repeat: TSPL GraphDisplayNumRowsAttribute : TSPL Indirect Expenses collection
Border: Thin Box
Graph Type : Yes
Enable Graph Cursor: Yes
Graph Display Cursor Label: Yes
Graph Display Num Rows: 3
In this example, the Part TSPL GraphDisplayNumRowsAttribute is configured as a graph by setting Graph Type : Yes and displays data from the TSPL Indirect Expenses collection. The attributes Enable Graph Cursor : Yes and Graph Display Cursor Label : Yes enable interactive navigation and display the value of the selected data point. By specifying Graph Display Num Rows : 3, the graph displays a maximum of three data points (graph rows) at a time. If the collection contains more than three records, the remaining data points are not displayed simultaneously. Instead, users can navigate horizontally through the graph using the graph cursor to view the additional data points. This helps maintain a clean and readable graph when working with large datasets, while still allowing users to access all the available information interactively.
Different types of data are best represented using different graphical formats. Graph Style is an attribute used to specify the visual style in which a graph should be displayed. Depending on the selected style, the same dataset can be presented as a Bar Graph or a Line Graph, allowing developers to choose the most appropriate representation for the information being analysed. Bar graphs are typically used to compare values across discrete categories, such as sales by region or expenses by ledger, whereas line graphs are more suitable for displaying trends or changes over time, such as monthly sales or yearly revenue. By selecting an appropriate graph style, developers can improve the readability of dashboard reports and help users interpret the data more effectively.
This attribute is applicable only to graph-based Parts configured using the Graph Type attribute. Additionally, the parent Report must be configured as a dashboard using the Dashboard Type attribute. The graph must also have data mapped through graph-related Field attributes such as Graph Label and Graph Value. If these prerequisites are not met, the Graph Style attribute has no effect.
There are two styles that are supported. They are
- Bar Graph – Displays the data as vertical bars. Best suited for comparing values across categories.
- Line Graph – Displays the data as a connected line. Best suited for showing trends or changes over a sequence, such as time.
When to use
- Use Bar Graph when comparing values across different categories, for example:
- Sales by Branch
- Expenses by Ledger
- Stock by Godown
- Use Line Graph when analysing trends or movement over time, for example:
- Monthly Sales
- Quarterly Revenue
- Daily Cash Balance
Syntax
[Part : <Part Name>]
Graph Style : <String expression>
Example
[Part: TSPL GraphStyleAttribute]
Line : TSPL GraphStyleAttribute
Repeat: TSPL GraphStyleAttribute : TSPL Indirect Expenses collection
Border: Thin Box
Graph Type : Yes
Graph Style : ##DBGraphType
In this example, the Part TSPL GraphStyleAttribute is configured as a graph by setting Graph Type : Yes and displays data from the TSPL Indirect Expenses collection. The attribute Graph Style : ##DBGraphType specifies the visual style in which the graph should be rendered. Instead of assigning a fixed style such as Bar Graph or Line Graph, the style is determined dynamically using the variable ##DBGraphType. This allows the same graph to switch between different visual representations at runtime based on user selection or application logic, without modifying the Part definition. Such an approach is useful in interactive dashboards where users may want to analyse the same data in different formats—for example, viewing indirect expenses as a bar graph for category-wise comparison or as a line graph to observe trends. This example also assumes that the parent Report is configured as a dashboard using the Dashboard Type attribute and that the graph data is mapped using the appropriate graph-related Field attributes such as Graph Label and Graph Value.
Graph Type is an attribute used to specify that a Part should be displayed as a graph instead of a regular Part. When set to Yes, Tally renders the data contained in the Part as a graph. By default, the graph is displayed as a Bar Graph, making it easy to compare values across different categories such as sales by branch, expenses by ledger, or stock by godown. The graph is typically generated from a repeated collection, where one Field specifies the category labels using the Graph Label attribute and another Field specifies the numeric values using the Graph Value attribute. This enables business data to be presented visually, allowing users to quickly identify patterns, compare values, and analyse trends.
With the introduction of Dashboard support in TallyPrime release 4.0, the capabilities of Graph Type were significantly enhanced. While it continues to define a Part as a graph, it can now be used along with additional graph-related attributes such as Graph Style, Enable Graph Cursor, Graph Display Cursor Label, Graph Display Num Rows, Display X Axis Legend, and other dashboard attributes. These enhancements allow developers to build richer, interactive graphs with multiple visual styles, cursor-based navigation, axis legends, and improved data analysis capabilities, while maintaining backward compatibility with existing graph implementations.
To render a graph correctly, the following attributes are typically used:
Part Definition
- Graph Type : Yes – Enables graph rendering.
- Repeat – Supplies multiple data points for plotting (recommended).
Field Definition
- Graph Label : Yes – Specifies the category labels displayed on the X-axis.
- Graph Value : Yes – Specifies the numeric values plotted on the Y-axis.
When the parent Report is configured as a dashboard using the Dashboard Type attribute, the graph can be further enhanced using attributes such as:
- Graph Style
- Enable Graph Cursor
- Graph Display Cursor Label
- Graph Display Num Rows
- Display X Axis Legend
- Display Y Axis Legend
Syntax
[Part : <Part Name>]
GraphType : <Logical Value>
Example
[Part: TSPL GraphTypeAttribute]
Line : TSPL GraphTypeAttribute
Repeat: TSPL GraphTypeAttribute : TSPL Indirect Expenses collection
Border: Thin Box
Graph Type : Yes
In this example, the Part TSPL GraphTypeAttribute is configured as a graph by setting Graph Type : Yes. The Part displays data by repeating the Line TSPL GraphTypeAttribute for each object in the TSPL Indirect Expenses collection. Since no Graph Style is specified, Tally renders the data as a Bar Graph, which is the default graph style. Each repeated object in the collection is represented as a separate bar, allowing users to compare the values of different indirect expense categories visually. This graphical representation makes it easier to identify high and low values, analyse the distribution of expenses, and recognise patterns that may not be immediately apparent in a tabular report. If required, the graph can be further enhanced by using additional graph-related attributes such as Graph Style, Enable Graph Cursor, Display X Axis Legend, and Graph Display Cursor Label, which provide richer visualisation and interactive capabilities.
Every Part occupies a certain amount of space within a Form. Height is an attribute used to specify the vertical space allocated to a Part. When a fixed height is specified, the Part occupies exactly that amount of space regardless of the amount of content it contains. If the content exceeds the specified height, users can view the remaining content through scrolling (when Scroll is enabled). If the content is less than the specified height, the remaining area is left blank, allowing other elements such as Bottom Line or Bottom Part to be positioned consistently. When the Height attribute is not specified, the Part automatically adjusts its height based on the number of Lines it contains. Developers typically define a fixed height when creating forms or reports with multiple Parts, dashboards, or side-by-side layouts, where maintaining a consistent and well-aligned interface is important.
The Height attribute can be used independently. However, it is commonly used with:
- Scroll – Allows users to navigate content that exceeds the specified height.
- Float – Controls whether Bottom Line or Bottom Part remains fixed at the bottom of the specified height or moves immediately after the displayed content.
- Bottom Line / Bottom Part – Their positioning becomes more apparent when a fixed height is defined.
Without a fixed Height, the Part expands automatically to accommodate all its Lines, making attributes such as Float less noticeable in many scenarios.
Syntax
[Part : <Part Name>]
Height : <Number expression>
Example
[Part: TSPL HeightAttribute]
Line : TSPL HeightAttribute
Border: Thin Box
Height: 2 cms
In this example, the Part TSPL HeightAttribute contains a single Line and applies a border around the Part using Border : Thin Box. By specifying Height : 2 cms, the Part is allocated a fixed height of 2 centimetres, regardless of the amount of content it contains. Since the Part contains only one Line, any remaining space within the 2 cm height is left empty, resulting in a consistent layout. This approach is useful when multiple Parts need to maintain uniform dimensions or when space must be reserved for additional elements such as Bottom Line or Bottom Part. If the Height attribute were omitted, the Part would automatically shrink to fit the height required by its Line, occupying only the minimum space necessary.
Every Part is displayed within the available space of a Form. Horizontal Align is an attribute used to specify the horizontal position of a Part within that available space. It determines whether the Part is aligned to the left, centre, or right of its parent container, allowing developers to control the overall layout and presentation of the interface. This attribute is particularly useful when designing forms with multiple Parts, headers, logos, summary sections, or dashboard panels where proper alignment improves readability and visual balance. If the attribute is not specified, the Part is aligned according to the default layout of the parent container.
The Horizontal Align attribute can be used independently. However, its effect is most noticeable when:
- The Part has a defined Width, allowing it to occupy less than the available horizontal space.
- The parent Form or Part provides sufficient horizontal space for alignment to take effect.
- It is used alongside attributes such as Vertical, Right Part, or Bottom Part to create structured and visually balanced layouts.
If the Part already occupies the entire available width, changing the Horizontal Align attribute may not produce any visible difference.
| Permissible Values | Explanation |
| Left/Top | Aligns the Part to the left when it is a Horizontal Part, or to the top when it is a Vertical Part. |
| Centre | Aligns the Part at the centre of the available space. For a Horizontal Part, it is centered horizontally; for a Vertical Part, it is centered vertically. |
| Right/Bottom | Aligns the Part to the right when it is a Horizontal Part, or to the bottom when it is a Vertical Part. |
Note: The effect of Horizontal Align depends on the orientation of the Part. For Horizontal Parts, it controls left, centre, or right alignment. For Vertical Parts, the same values determine top, centre, or bottom alignment within the available space.
Think of placing a picture on a page in a word processor. If the picture is smaller than the page width, you can choose to place it against the left margin, in the centre, or against the right margin. The Horizontal Align attribute works in the same way for a Part; it controls where the Part is positioned horizontally within the available space, without changing its size.
Syntax
[Part : <Part Name>]
Horizontal Align : <Align Value>
Example
[Part: TSPL HorizontalAlignAttribute]
Line : TSPL HorizontalAlignAttribute
Border: Thin Box
Horizontal Align: Right
In this example, the Part TSPL HorizontalAlignAttribute contains a single Line and applies a border using Border : Thin Box. By specifying Horizontal Align : Right, the entire Part is positioned towards the right side of the available space within its parent container. The contents of the Part remain unchanged; only the position of the Part itself is affected. If sufficient horizontal space is available, the Part appears aligned to the right rather than at the default position. This attribute is particularly useful when positioning elements such as logos, summary sections, action panels, or other Parts that need to appear at a specific horizontal location within a Form. If the Part occupies the full available width, the effect of Horizontal Align may not be visible.
A Part can contain not only Lines but also visual elements such as images. Image is an attribute used to specify the Resource definition whose image should be displayed within the Part. When the Part is rendered, Tally retrieves the referenced Resource and displays the corresponding image at that location. This enables developers to incorporate company logos, icons, signatures, product images, and other graphical elements into reports and forms without embedding image details directly in the Part.
The Image attribute references a Resource definition rather than an image file itself. The Resource definition determines where the image is obtained from and how it should be loaded. This separation allows the same image resource to be reused across multiple Parts, Forms, and Reports while centralising image management.
The Image attribute also accepts an optional keyword as its second parameter to control how the image is rendered. Currently, the supported keyword is FitWidth, which scales the image to fit the available width of the Part while maintaining its aspect ratio. This is particularly useful when displaying images of varying widths, such as company logos or banners, ensuring that they fit neatly within the allocated space without overflowing or requiring manual resizing.
The Image attribute depends on a valid Resource definition.
The referenced Resource definition should specify:
- Resource or Source – to identify where the image is located or should be obtained.
- Resource Type – specifying a supported image type such as BMP, JPEG, PNG, GIF, or Icon.
Think of the Image attribute as a picture frame inside a Part. The frame itself doesn’t contain the picture; it simply tells Tally which Resource (picture) to display. The actual image is stored and managed separately in the Resource definition, allowing the same picture to be reused wherever it is needed.
Syntax
[Part : <Part Name>]
Image : <Resource Definition Name> [:<Keyword>]
Example
[Part: TSPL ImageAttribute]
Line : TSPL ImageAttribute
Border: Thin Box
Image : ImageResource : FitWidth
[Resource: ImageResource]
Resource Type: Jpeg
Source : D:\tallylogo.jpg
In this example, the Part TSPL ImageAttribute displays the image referenced by the Resource definition ImageResource. The Resource definition specifies Resource Type : JPEG and Source : D:\tallylogo.jpg, indicating that the image should be loaded from the file tallylogo.jpg. When the Part is rendered, Tally retrieves the image through the Resource definition and displays it within the Part.
The second parameter, FitWidth, instructs Tally to automatically scale the image so that it occupies the full width available within the Part while preserving its original aspect ratio. This eliminates the need to manually resize images of different dimensions and ensures a consistent appearance across reports and forms. The image is enlarged or reduced only to fit the Part’s width; its proportions are maintained to prevent distortion.
A Part is normally displayed whenever its parent Form or Part is rendered. Invisible is an attribute used to specify whether a Part should be hidden from the user based on a logical condition. When the attribute evaluates to Yes, the Part is not displayed, and its contents including all nested Parts, Lines, Fields, and images remain invisible. When it evaluates to No, the Part is displayed normally. Since the attribute accepts a logical expression, developers can dynamically control the visibility of an entire section of the interface based on user selections, application variables, security rights, configuration settings, or business data. This helps create cleaner and more context-sensitive user interfaces by displaying only the information that is relevant to the current scenario.
Syntax
[Part : <Part Name>]
Invisible : <Logical Expression>
Example
[Part: TSPL InvisibleAttribute]
Line : TSPL InvisibleAttribute
Invisible : Yes
In this example, the Part TSPL InvisibleAttribute contains the Line TSPL InvisibleAttribute, but the attribute Invisible : Yes instructs Tally not to display the Part. Since the entire Part is hidden, all of its contents, including the Line and any nested Parts, Fields, Buttons, or Images, are also hidden from the user. Although the Part is defined in the code, it does not occupy any visible space in the interface. This is useful when certain sections of a form or report should be suppressed based on business requirements or configuration settings. In practical scenarios, instead of specifying the constant value Yes, developers typically use a logical expression so that the Part is shown or hidden dynamically at runtime.
When exporting reports in the new JSON format, every field is represented as a JSON property consisting of a name and a value. By default, the property name is derived from the internal field name or the JSON tag associated with the field. JSON Tag As Desc Name is an attribute used to specify whether the JSON Tag should also be used as the descriptive name of the field in the generated JSON output. When enabled, the JSON export uses the tag specified through the JSON Tag attribute as the field’s descriptive identifier, resulting in a cleaner, more meaningful, and API-friendly JSON structure.
This attribute is particularly useful when the exported JSON is intended to be consumed by external applications, REST APIs, middleware, or third-party systems that expect specific property names. Instead of exposing TDL-specific field names or automatically generated identifiers, developers can define business-friendly and standardised names using the JSON Tag attribute and instruct Tally to use those names during export. This improves interoperability, makes the JSON payload easier to understand, and reduces the need for additional mapping or transformation in consuming applications.
The attribute is effective only when:
- The report is exported using the new JSON export format.
- Appropriate JSON Tag attributes are defined for the fields whose names need to appear in the JSON output.
Without a JSON Tag, enabling this attribute has no practical effect because there is no alternate descriptive name available to use.
Syntax
[Part : <Part Name>]
JSON Tag As Desc Name : <Logical Value>
Example
[Part: TSPL CustomerDetailsPostXMLJSON]
Lines : TSPL CustomerDetailsPostXMLJSON
Repeat : TSPL CustomerDetailsPostXMLJSON : TSPL CustomerDetailsPost
CommonBorder: Yes
Scroll : Vertical
JSON Tag As Desc Name : No
[Line: TSPL CustomerDetailsPostXMLJSON]
Fields : TSPL Customer Led No
JSONTag : “Customer Details”
[Field: TSPL Customer Led No]
Set as : $$Line
Width : 3
JSONTag : “Customer No.”
In this example, the Part TSPL CustomerDetailsPostXMLJSON exports data from the collection TSPL CustomerDetailsPost. The Line and Field define custom JSON tags using the JSONTag attribute—”Customer Details” for the Line and “Customer No.” for the Field. However, the Part specifies JSON Tag As Desc Name : No, which instructs Tally not to use these custom JSON tags as the descriptive names in the generated JSON output. Instead, Tally uses its default descriptive names while generating the JSON structure.
If the attribute is changed to JSON Tag As Desc Name : Yes, the behaviour changes. During JSON export, Tally uses the values specified in the JSONTag attributes as the descriptive names. In this example, the JSON output groups the data under “Customer Details”, and the field is identified as “Customer No.” instead of the default descriptive name. This produces a more meaningful and self-descriptive JSON structure that is easier for external applications, APIs, and developers to understand and consume.
When a Report is exported in JSON or XML format, the output is organised into a hierarchy of elements or objects. JSON Tag alias XML Tag is an attribute used to specify the name of the JSON object or XML element corresponding to a Part in the exported output. Instead of using a system-generated name or omitting the Part altogether, developers can assign a meaningful tag that clearly identifies the data contained within that Part. This helps create a well-structured and self-descriptive JSON or XML document, making it easier for external applications, APIs, middleware, or integration solutions to parse and consume the exported data.
Developers typically use the JSON Tag attribute when designing reports intended for data exchange or system integration, where the exported structure must comply with a predefined schema or API contract. If the attribute is not specified, the Part itself does not contribute a named object or element to the exported JSON/XML structure, and its data is exported without a Part-level tag. Do not confuse this with JSON Tag As Desc Name. JSON Tag defines the name of the Part object or XML element in the exported structure whereas JSON Tag As Desc Name determines whether the JSON Tag values defined for the Part, Line, and Field are also used as the descriptive names in the new JSON export format.
Syntax
[Part : <Part Name>]
Json Tag : <Value>
Example
[Part: TSPL Ledger Register Part]
Line : TSPL Ledger Register Line
Repeat : TSPL Ledger Register Line : TSPL Ledger Collection
Scroll : Vertical
JSONTag : “Customer Details”
[Line : TSPL Ledger Register Line]
Field : TSPL Customer Number, TSPL Customer Name
[Field : TSPL Customer Number]
Set as : $LedgerMobile
JSON Tag: “CustomerNo”
[Field : TSPL Customer Name]
Set as : $Name
JSON Tag: “CustomerName”
In this example, the Part TSPL Ledger Register Part exports data from the TSPL Ledger Collection. The attribute JSONTag : “Customer Details” assigns the name Customer Details to the Part in the exported JSON/XML structure. As a result, all the data generated by this Part is grouped under the Customer Details object instead of being exported without a Part-level identifier.
Within the Part, the Line contains two Fields. Each Field specifies its own JSON Tag attribute ; CustomerNo for the customer number and CustomerName for the customer name. These tags become the property names for the respective values in the exported output.
If the JSON Tag attribute is omitted at the Part level, the enclosing object Customer Details is not generated. In that case, only the data corresponding to the repeated Lines and their Fields is exported, resulting in a flatter JSON structure. Developers typically define a Part-level JSON Tag when they want to group related data under a meaningful object or element name, making the exported JSON or XML easier to understand and compliant with predefined integration schemas.
A Part may contain one or more child Parts , allowing complex layouts to be built by combining multiple reusable sections. Left Part is an attribute used to specify one or more child Parts that should be placed within a Part. By default, these child Parts are arranged horizontally incase it is called from a vertical Part from left to right, making it suitable for creating side-by-side layouts such as a logo beside a report, multiple dashboard panels, or summary sections displayed next to each other.
The behaviour of the Left Part attribute also depends on the value of the Vertical attribute. When Vertical : Yes is specified for the Part, the layout changes from horizontal to vertical. In this case, the Left Part attribute behaves as Top Part, and the specified child Parts are arranged from top to bottom instead of from left to right. This is why the attribute has aliases such as Top Part, Left Parts, Top Parts, and Part.
Syntax
[Part : <Part Name>]
Left Part : <Part Definition Name>
Example
[Part: TSPL LeftPartAttribute]
Left Part: TSPL subPart1,TSPL subPart2
Vertical : No
In this example, the Part TSPL LeftPartAttribute contains two child Parts: TSPL subPart1 and TSPL subPart2. The attribute Left Part specifies that these child Parts should be included within the parent Part. Since Vertical : No is specified, the parent Part uses a horizontal layout, causing TSPL subPart1 to be displayed first, followed by TSPL subPart2, with the Parts arranged from left to right.
If the same example is modified to Vertical : Yes, the behaviour of the Left Part attribute changes automatically. The child Parts are no longer arranged horizontally; instead, the attribute behaves as Top Part, and TSPL subPart1 and TSPL subPart2 are displayed from top to bottom within the parent Part. This demonstrates how the Vertical attribute controls the orientation of the child Parts while the Left Part attribute continues to specify which child Parts should be included.
A Part can contain either one or more child Parts or one or more Lines, but not both. Child Parts are used to divide a complex layout into smaller, reusable sections, while Lines represent the individual rows displayed within a Part. Line is an attribute used to specify one or more Lines that should be included within a Part. Each Line acts as a row and typically contains one or more Fields responsible for displaying or accepting data.
A Part can either directly contain Lines or contain child Parts, which in turn may contain additional child Parts or Lines. Regardless of the level of nesting, every branch of the hierarchy must eventually terminate with one or more Lines, as only Lines can contain Fields. Without a Line, a Part cannot display any data.
The Line attribute has aliases such as Lines, Top Line, and Top Lines.
Syntax
[Part : <Part Name>]
Line : <Line Definition name>
Example
[Part: TSPL LineAttribute]
Line : TSPL LineAttribute, TSPL LineAttribute2
In this example, the Part TSPL LineAttribute directly contains two Lines: TSPL LineAttribute and TSPL LineAttribute2. Since a Part that contains Lines cannot contain child Parts, these Lines become the immediate contents of the Part. When the Part is rendered, Tally displays TSPL LineAttribute first, followed by TSPL LineAttribute2, with each Line appearing as a separate row. Any Fields defined within these Lines are displayed in their respective rows.
Although the Line attribute has aliases such as Lines, Top Line, and Top Lines, the layout of Lines is always top to bottom. Unlike attributes such as Left Part, the Vertical attribute has no effect when a Part directly contains Lines, because Vertical is applicable only when arranging child Parts within a parent Part.
When a Part contains more Lines than can be displayed on the screen, developers can enable vertical scrolling using the Scroll : Vertical attribute. Number Of Display Lines In Scroll is an attribute used to specify how many Lines should be visible at a time within the scrollable Part. If the Part contains additional Lines, they are not displayed immediately but can be viewed by scrolling.
This attribute is considered only when Tally determines the height of the Part automatically. It is applicable only when:
- Scroll : Vertical is specified for the Part.
- The Part does not have a fixed Height.
- The containing Form does not have a fixed Height.
- The containing Form is not configured with Full Height.
Under these conditions, Tally calculates the height of the Part based on the number specified in Number Of Display Lines In Scroll. This allows developers to control the visible portion of a large dataset without explicitly specifying the Part’s height. It is particularly useful when displaying long lists such as ledgers, vouchers, stock items, or reports where only a fixed number of rows should be visible while allowing users to scroll through the remaining data.
The attribute is effective only when all of the following conditions are satisfied:
- Scroll : Vertical is specified for the Part.
- The Part does not specify the Height attribute.
- The containing Form does not specify the Height attribute.
- The containing Form is not configured with Full Height.
If any of these conditions are not met, the Number Of Display Lines In Scroll attribute is ignored because the Part’s height is determined by the explicitly defined height or the Form layout.
Typically, you should use this attribute when you want to:
- Display only a limited number of rows without calculating the Part’s height manually.
- Create compact reports that occupy a predictable amount of screen space.
- Allow users to scroll through large collections while keeping the overall layout clean and consistent.
It is used in reports, which have multiple parts and those parts have repeated lines. Example like Dashboard report and Stock Query.
Syntax
[Part : <Part Name>]
Number of Display Lines In Scroll : <Numberic formula>
Example
[Part: TSPL Indirect Expenses part]
Line: TSPL Indirect Expenses Line
Repeat: TSPL Indirect Expenses Line : TSPL Indirect Expenses collection
Scroll: Vertical
Number Of Display Lines In Scroll : If $$InFocusMode Then 10 Else 8
In this example, the Part TSPL Indirect Expenses Part displays the Lines from the TSPL Indirect Expenses collection with vertical scrolling enabled. The Number Of Display Lines In Scroll attribute determines how many Lines are visible within the Part before scrolling is required. Instead of specifying a fixed value, the attribute uses the formula If $$InFocusMode Then 10 Else 8.
When the report is opened and when the focus is on that part, the formula evaluates to 10, allowing ten expense records to be displayed at a time. Otherwise, it evaluates to 8, displaying only eight records. Any remaining records in the collection can be accessed by scrolling vertically. Since neither the Part nor its containing Form has a fixed height, Tally automatically calculates the height of the Part to accommodate the evaluated number of display Lines.
A Part normally inherits the object context from its parent definition i.e. Report. Object is an attribute used to change the object context of a Part by associating it with a secondary object related to the current object. Once the object context is changed, every child definition within the Part including Lines and Fields is evaluated in the context of the associated object. This enables developers to directly access the methods of the secondary object without repeatedly navigating to it in every Field or Line definition.
The Object attribute is particularly useful when a report needs to display information belonging to a related object. For example, while processing a Voucher, a developer may need to display details of one of its Ledger Entries, Inventory Entries, or Bill Allocations. Instead of changing the object context individually for each Field, the Part can associate itself with the required secondary object once, allowing all definitions within the Part to work directly with that object.
Syntax
[Part : TSPL VchPart Obj Led]
Object : <Secondary Object>
Example
[Report : TSPL VCH LED Details]
Object : Voucher
[Part: TSPL VCH LEDSuppleRefVchDetails]
Line : VCH LEDSuppleRefVchDetails
Repeat : VCH LEDSuppleRefVchDetails : RefVoucherDetails
Object : LedgerEntries : First
In this example, the report is evaluated in the context of a Voucher. The Part TSPL VCH LEDSuppleRefVchDetails is responsible for displaying information related to the voucher’s ledger entries. By specifying ‘Object : LedgerEntries : First’ the Part associates itself with the first LedgerEntries object belonging to the current Voucher. From this point onwards, the entire Part—including its Line VCH LEDSuppleRefVchDetails and all the Fields within that Line—is evaluated in the context of this LedgerEntries object.
This means that methods and sub-objects of the LedgerEntries object, such as $LedgerName, $Amount, and Bill Allocations, become directly accessible within the Part TSPL VCH LEDSuppleRefVchDetails. Because the object context is established once at the Part level, all Lines and Fields within the Part automatically work in the context of the selected LedgerEntries object, resulting in simpler, cleaner, and more maintainable TDL code.
A Part normally inherits the object context from its parent definition. ObjectEx is an attribute used to associate a primary object with a Part using an enhanced method formula. Unlike the Object attribute, which associates a secondary object related to the current object, ObjectEx establishes a new primary object for the Part. Once the primary object is associated, all child definitions within the Part—including child Parts, Lines, and Fields—are evaluated in the context of that object.
The use of an enhanced method formula provides greater flexibility in identifying the required object. Instead of relying on the conventional object association syntax, developers can use methods, functions, variables, constants, or expressions to dynamically determine the primary object at runtime. This makes ObjectEx particularly useful when the object to be associated cannot be identified using a simple object reference.
Developers typically use ObjectEx when a Part needs to display or process information from a completely different primary object while retaining the surrounding report structure.
Syntax
[Part : <Part Name>]
ObjectEx : (<PrimaryObjectType>,<ObjectIdentifier>)
Example
[Report : TSPL Print Vch Details]
Form : TSPL Print Vch Details
Object : Voucher
[Form: TSPL Print Vch Details]
Part : TSPL Print Cmp Details, TSPL Print Vch LedDtls, TSPL Print Vch
[Part : TSPL Print Cmp Details]
ObjectEx : (Company,##SVCurrentCompany)
Line : TSPLCmpName, TSPLCmpAdd
Repeat : TSPLCmpAdd : Address
|
|
In this example, the report TSPL Print Vch Details is evaluated in the context of the Voucher object. However, the Part TSPL Print Cmp Details is intended to display Company information such as the company name and address, which are not methods of the Voucher object. To achieve this, the Part uses ‘ ObjectEx : (Company,##SVCurrentCompany). ’
The ObjectEx attribute associates the Part with the Company object identified by the system variable ##SVCurrentCompany. This establishes Company as the primary object for the Part. Consequently, all child definitions within the Part—including the Lines TSPLCmpName and TSPLCmpAdd, and the repeated Address sub-object—are evaluated in the context of the selected Company object. As a result, methods such as $Name, $MailingName, and sub-objects like Address can be accessed directly within the Part without navigating from the Voucher object. The object context established by ObjectEx is inherited by all child definitions, making it easier to design Parts that display information from a completely different primary object.
A Part is responsible for displaying a logical section of a report or form. During its processing, certain events such as receiving focus or completing printing may occur and an action may be needed. ON is an attribute used to associate one or more actions with these events. When the specified event occurs, Tally evaluates the given condition and, if the condition is satisfied, executes the associated action automatically.
The ON attribute enables developers to implement event-driven behaviour within a Part. It can be used to initialise or modify variables, invoke functions, execute TDL actions, refresh data, or perform other processing whenever the specified event is triggered. Since ON is a list-type attribute, multiple actions can be associated with the same event, and they are executed sequentially in the order in which they are defined.
Developers typically use the ON attribute to perform processing that should occur automatically in response to a Part-level event, eliminating the need to invoke the same actions explicitly from individual Lines or Fields.
The permissible event types are as follows:
| Event | Triggered When | Usage |
| After Export | The Part has been exported successfully. | Execute actions after exporting the Part, such as updating variables, invoking a function, or performing post-export processing. |
| After Print | The Part has been printed successfully. | Perform post-print processing, update variables, invoke functions, or execute clean-up logic after printing the Part. |
| Before Print | Immediately before the Part is printed. | Initialise variables, prepare data, or perform processing required before printing the Part. |
| Focus | The Part receives input focus. | Initialise variables, invoke functions, refresh data, or execute actions before the user interacts with the Part. It is applicable when the Part becomes the active section of the interface. |
| Triggered during the printing of the Part. | Execute actions related to the printing process. This event is typically used for print-specific processing. The exact behaviour of Print depends on the action being performed and should not be confused with After Print. Print is raised during the printing process, whereas After Print is raised only after the Part has been completely printed. |
Syntax
[Part : <Part Name>]
On : <Event Name> : <Logical Condition> : <Action> : <Action Parameters>
Example
[Part: TSPL Nature of Sales]
On : Focus : $$InAlterMode : CALL : TSPL ModifyStockItemExist
In this example, the ON attribute is associated with the Focus event. Whenever the Part TSPL Nature of Sales receives focus, Tally evaluates the condition $$InAlterMode. If the current report is opened in Alter Mode, the condition evaluates to Yes, and the function TSPL ModifyStockItemExist is invoked using the CALL action. If the report is not in Alter Mode, the condition evaluates to No, and no action is performed.
When printing a report, the content of a Part may span multiple pages. Page Break is an attribute used to specify how the content of a Part should continue when a page break occurs. It defines the Closing Page Line, which is printed as the last Line on the current page, and the Opening Page Line, which is printed as the first Line on the next page. This helps maintain continuity across pages by displaying appropriate information, such as subtotals, carry-forward values, repeated headings, or continuation messages.
The Page Break attribute is particularly useful in reports that contain large amounts of repeating data and are likely to extend beyond a single printed page. Instead of allowing the page to break abruptly, developers can use this attribute to control the transition between pages, making printed reports easier to read and understand.
The Page break attribute should be use for the following purposes :
- Display a closing Line (such as a subtotal or “Continued…” message) at the bottom of a page.
- Display an opening Line (such as repeated headings or “Brought Forward” totals) at the top of the next page.
- Improve the readability and continuity of multi-page printed reports.
- Maintain a consistent report layout across page boundaries.
The Page Break attribute is applicable only during printing. It has no effect while viewing the report on the screen or during export to formats such as Excel, XML, or JSON.
Syntax
[Part : <Part Name>]
Page Break : <Closing Page Line>, <Opening Page Line>
Example
[Part: TSPL PageBreakAttribute]
Line : TSPL LedgerTitles,TSPL LedgerDetails
Repeat : TSPL LedgerDetails : List of Ledgers
Scroll : Vertical
Common Border: Yes
Float : No
Border : Thin Box
Page Break: TSPL ClosingPageLine, TSPL OpeningPageLine
In this example, the Part TSPL PageBreakAttribute displays a repeating list of ledgers from the collection List of Ledgers. If the list grows beyond the printable area of the current page, Tally automatically inserts a page break. The attribute ‘Page Break : TSPL ClosingPageLine, TSPL OpeningPageLine ’ specifies that the Line TSPL ClosingPageLine should be printed as the last Line on the current page before the page break occurs, while the Line TSPL OpeningPageLine should be printed as the first Line on the following page. This enables developers to display information such as carry-forward totals, “Continued…” messages, brought-forward balances, or repeated headings at page boundaries, ensuring that multi-page reports remain clear, continuous, and easy to read.
Business documents such as invoices, letterheads, delivery challans, cheques, or statutory forms are printed on stationery that already contains fixed information like the company logo, address, borders, or standard text. Pre Printed is an attribute used to specify whether the contents of a Part should be printed on such pre-printed stationery. When the attribute is set to Yes, Tally assumes that the information represented by the Part is already available on the stationery and therefore skips printing that Part. When it is set to No, the Part is printed normally. This attribute works in conjunction with the Preprinted/Plain option available in the Print Configuration screen and is applicable only during printing. Developers typically use it to avoid printing information that already exists on the stationery, ensuring that only the required variable data is printed.
Syntax
[Part : <Part Name>]
Pre Printed : <Logical Value>
Example
[Part: TSPL CompanyDetails]
Line : TSPL CompanyName, TSPL CompanyAddress
Repeat : TSPL CompanyAddress : Company Address
Border : Thin Box
Pre Printed : Yes
In this example, the Part TSPL CompanyDetails displays the company name and address. By specifying Pre Printed : Yes, Tally assumes that these details are already available on the pre-printed stationery. Therefore, when the Preprinted option is selected in the Print Configuration screen, the contents of this Part are not printed, preventing duplicate printing of the company information. If the Plain option is selected instead, the Part is printed normally, allowing the company details to appear on plain paper. This approach is commonly used for documents printed on company letterheads, invoice stationery, or other pre-designed forms where only the transaction-specific information needs to be printed.
Business documents such as invoices, purchase orders, delivery challans, letterheads, and statutory forms are often printed on stationery that already contains decorative or predefined borders. Pre Printed Border is an attribute used to specify whether the border defined for a Part should be printed when using such pre-printed stationery. When the attribute is set to Yes, Tally assumes that the border is already available on the stationery and therefore does not print the border for that Part when the Preprinted option is selected in the Print Configuration screen. This prevents the border from being printed twice, ensuring a clean and professional-looking document. If the Plain option is selected, the border is printed normally, allowing the same report design to be used for both plain paper and pre-printed stationery. This attribute is applicable only during printing and is typically used together with the Border and Pre Printed attributes when designing reports that support both printing modes.
Syntax
[Part : <Part Name>]
Pre Printed Border : <Logical Value>
Example
[Part: TSPL CompanyDetails]
Line : TSPL CompanyName, TSPL CompanyAddress
Repeat : TSPL CompanyAddress : Company Address
Border : Thin Box
Pre Printed Border : Yes
In this example, the Part TSPL CompanyDetails displays the company name and address enclosed within a Thin Box border. By specifying ‘Pre Printed Border : Yes’, TallyPrime assumes that the border is already available on the pre-printed stationery. Therefore, when the Preprinted option is selected in the Print Configuration screen, the Thin Box border defined for the Part is not printed, while the contents of the Part continue to be printed normally. This prevents the border from being printed twice on stationery that already contains a pre-designed border. If the Plain option is selected, Tally prints the border along with the Part contents, allowing the same report to be used for both plain paper and pre-printed stationery.
While designing data entry screens, there are situations where information entered in a Part needs to be copied, transformed, or synchronised with another object before the Part is accepted. Preaccept Object Map is an attribute used to execute an Object Map immediately before the accept operation of the Part. This ensures that the required object mapping is completed and the destination object contains the latest values before the data is validated and accepted. By performing the mapping at this stage, developers can ensure that subsequent processing works with the updated object data, resulting in consistent and accurate information. This attribute is particularly useful when data entered in one object needs to be transferred to another object as part of the acceptance process, eliminating the need for additional mapping logic after the Part has been accepted. To use this attribute, a valid Object Map must already be defined, as the attribute simply invokes the specified Object Map before acceptance. If no Object Map is defined or referenced, the attribute has no effect.
Syntax
[Part : <Part Name>]
Pre accept Object Map : <Object Map Definition Name> [:<Logical condition>]
Example
[Part : TSPL LedgerDetails]
Line : TSPL LedgerLine
Repeat : TSPL LedgerLine : TSPL Ledger Collection
Pre Accept Object Map : TSPL LedgerObjectMap : $$InCreateMode
In this example, the Part TSPL LedgerDetails displays data from the TSPL Ledger Collection. Before the Part is accepted, Tally evaluates the logical condition $$InCreateMode. If the report is opened in Create Mode, the condition evaluates to Yes, and the Object Map TSPL LedgerObjectMap is executed before the Part is accepted. If the report is opened in any other mode, such as Alter Mode or Display Mode, the condition evaluates to No, and the Object Map is not executed. This allows developers to perform object mapping only when required, ensuring that data is transferred or synchronised before the Part is accepted.
While printing a report, you may want certain sections to stand out from the rest of the content. Print BG is an attribute used to specify the background colour of a Part only in the printed output. The specified colour is not displayed when the report is viewed on the screen; it is applied only during printing. If the report is printed on a colour printer, the background appears in the selected colour. If it is printed on a black-and-white printer, Tally automatically prints the background in an appropriate shade of grey. Developers typically use this attribute to highlight important sections, separate different areas of a report, or improve the overall appearance of printed documents such as invoices, statements, and certificates. The Print BG attribute is applicable only during printing and has no effect on the on-screen display or when exporting the report to formats such as Excel, XML, or JSON. To use this attribute, a valid colour value must be specified.
Syntax
[Part : <Part Name>]
PrintBG : <Color Definition Name>
Example
[Part: TSPL PrintBGAttribute]
Line : TSPL PrintBGAttribute
Print BG : Red
Background : Yellow
In this example, the Part TSPL PrintBGAttribute uses both the Background and Print BG attributes to demonstrate how the appearance of a Part can differ between the screen and the printed output. When the report is viewed on the screen, the Part is displayed with a Yellow background as specified by the Background attribute. However, when the report is printed, the Print BG attribute takes effect and the Part is printed with a Red background instead. This shows that the Background attribute controls only the on-screen appearance, whereas the Print BG attribute controls only the printed appearance. Using both attributes together allows developers to define different background colours for screen viewing and printing, ensuring that the report is visually suitable for both environments.
QR codes are widely used to provide quick access to information such as website URLs, payment details, invoice information, contact details, and product identifiers. QR Code is an attribute used to generate a scannable QR code from the text or expression specified in the attribute. During report generation, Tally converts the supplied value into a QR code and displays or prints it as part of the report. Users can then scan the QR code using a compatible scanner or mobile device to access the encoded information without manually typing it. Developers typically use this attribute while designing invoices, receipts, vouchers, certificates, and other business documents that require machine-readable information. The attribute accepts any text or formula that evaluates to a string, allowing QR codes to be generated dynamically based on the current object or transaction data.
Syntax
[Part : <Part Name>]
QRCode : <String Expression>
Example
[Part: TSPL QRCodeAttribute]
Line : TSPL QRCodeAttribute
QRCode: @@ItemQRCode
[System: Formula]
ItemQRCode : $Name + $Parent + ($$String:$ClosingBalance)
In this example, the QRCode attribute generates a QR code using the value returned by the system formula @@ItemQRCode. The formula combines three pieces of information—the item name ($Name), its parent ($Parent), and the closing balance ($ClosingBalance) converted into a string using $$String. When the report is generated, Tally evaluates the formula, concatenates these values into a single text string, and encodes the resulting text as a QR code. Instead of encoding a fixed value, this approach creates a dynamic QR code whose contents change automatically based on the current object being processed. This is particularly useful when each item, ledger, or transaction needs to have its own unique QR code containing relevant business information.
A report often needs to display multiple records of the same type, such as a list of ledgers, vouchers, stock items, bill allocations, or inventory entries. Repeat is an attribute used to display or print a Line or a Part repeatedly based on a specified collection. For every object available in the collection, Tally creates a new instance of the Line or Part and evaluates it in the context of that object. This enables developers to present multiple records using a single definition instead of creating separate definitions for each record. Although Repeat can be used for both Lines and Parts, it is most commonly used with Lines to display tabular data in reports. In scenarios where a report needs to display hierarchical or grouped information, such as ledger-wise bill outstanding details, voucher-wise inventory allocations, or batch-wise stock details, Repeat can be applied to a Part so that each repeated Part can contain multiple Lines and child Parts representing the related information. The Repeat attribute can also be used without specifying a collection by repeating a definition based on variables or other runtime conditions, making it useful for creating dynamic and flexible report layouts. Since a repeated Part or Line can display a large number of records, it is recommended to use the Scroll attribute along with Repeat so that users can comfortably navigate through the repeated content instead of having it compressed within the available space.
Syntax
[Part : <Part Name>]
Repeat : <Line/Part Definition Name> : <Collection Name> [:<Parent Collection Name>: <Index>[:<Condition>]]
Example 1
[Part: TSPL RepeatAttribute]
Line : TSPL LedgerTitles,TSPL LedgerDetails
Repeat : TSPL LedgerDetails : List of Ledgers
Scroll : Vertical
In this example, the Part TSPL RepeatAttribute contains two Lines: TSPL LedgerTitles, which displays the column headings, and TSPL LedgerDetails, which displays the ledger information. The Repeat attribute instructs Tally to repeat the TSPL LedgerDetails Line for every object available in the List of Ledgers collection. During report generation, Tally iterates through each ledger in the collection, creates a new instance of the TSPL LedgerDetails Line, and evaluates it in the context of the current ledger object. As a result, the report displays a list of all ledgers using a single Line definition, while the TSPL LedgerTitles Line is displayed only once as the header. Since Scroll : Vertical is specified, users can vertically scroll through the repeated ledger records when the number of ledgers exceeds the visible area of the Part.
Example 2
[Report : TSPL DBVoucher]
Object : Voucher
|
|
[Part: DBFirstBIL Explosion]
Line : VCHBILLExplLine
Repeat : VCHBILLExplLine : Bill Allocations : All Ledger Entries : First
Scroll : Vertical
In this example, the report is evaluated in the context of the Voucher object. The Part DBFirstBIL Explosion is designed to display the Bill Allocations associated with a ledger entry. However, the collection Bill Allocations is not directly available from the Voucher object; it belongs to the All Ledger Entries collection. Therefore, the Repeat attribute specifies All Ledger Entries as the parent collection and First as the index, instructing Tally to first navigate to the first Ledger Entry in the voucher and then repeat the VCHBILLExplLine Line for each object in its Bill Allocations collection. This enables the report to display all bill allocation details associated with the first ledger entry of the voucher. This pattern is commonly used when the collection to be repeated belongs to a nested object rather than the current object context, allowing developers to navigate to the required parent object before repeating its child collection.
Example 3
[Part: TSPLLedBILL Body]
Part : TSPLLedBILL BodyTitle
Repeat : TSPLLedBILL BodyTitle : LedgerwiseBills
Scroll : Vertical
[Part: TSPLLedBILL BodyTitle]
Part : TSPLLedBILL Title, TSPLLedBILL Details
Vertical : Yes
|
|
[Part: TSPLLedBILL Details]
Line : TSPLBILL Detail
Repeat : TSPLBILL Detail : TSPLCmpLedRec
In this example, the Repeat attribute is applied at two different levels to display hierarchical data. The Part TSPLLedBILL Body repeats the Part TSPLLedBILL BodyTitle for each object in the LedgerwiseBills collection, so each ledger gets its own section in the report. The repeated Part TSPLLedBILL BodyTitle contains two child Parts, TSPLLedBILL Title and TSPLLedBILL Details, which are arranged vertically using Vertical : Yes. Within TSPLLedBILL Details, the Repeat attribute is used again to repeat the TSPLBILL Detail Line for every object in the TSPLCmpLedRec collection. As a result, for each ledger in the LedgerwiseBills collection, Tally first displays the ledger heading and then lists all the bill records associated with that ledger.
When a Part contains multiple Lines or repeated data, users often move between different Parts while working on a report. By default, when they return to the original Part, the focus may be reset, requiring them to navigate back to the Line they were previously working on. Retain Focus is an attribute used to preserve the last focused Line within a Part. When this attribute is set to Yes, the Part remembers the Line that had focus before the user moved to another Part. As a result, when the user returns to that Part, the focus is automatically restored to the same Line instead of starting from the beginning. This provides a smoother navigation experience, especially in reports containing multiple Parts or long lists of repeated data. Developers typically use this attribute in interactive reports and data entry screens where users frequently switch between different sections, ensuring that they can continue their work from the same position without having to locate the previously selected Line again. The Retain Focus attribute is meaningful only when the Part contains multiple Lines or repeated data and users can navigate between different Parts. It is commonly used together with the Repeat attribute and Parts that support user interaction.
Syntax
[Part : Part Defintion]
Retain Focus : <Logical Value>
Example
[Part: TSPLLed Details]
Lines : TSPLLed Title, TSPLLed Info
Repeat : TSPLLed Info : Ledger
Scroll : Vertical
Common Borders : Yes
Option : TSPLRetainFocus LedDet: ##RetainFocus
[!Part: TSPLRetainFocus LedDet]
Retain Focus : Yes
In this example, the Part TSPLLed Details displays a list of ledgers by repeating the TSPLLed Info Line for every object in the Ledger collection. Since the Part can contain multiple repeated records, Scroll : Vertical allows users to navigate through the list, while Common Borders : Yes draws a single border around the entire Part. The Option attribute conditionally applies the Part TSPLRetainFocus LedDet when the variable ##RetainFocus evaluates to Yes. This Part overrides the original definition by specifying Retain Focus : Yes, causing the Part to remember the last selected Line even after the user moves to another Part. When the user returns to this Part, the cursor is automatically restored to the same Line instead of starting from the beginning.
A Part often contains repeated Lines or child Parts that display data from a collection. When the amount of data exceeds the visible area of the Part, it cannot be displayed completely on the screen at the same time. Scroll is an attribute used to specify how users can navigate through the contents of a Part when the displayed information extends beyond its visible boundaries. Instead of compressing or truncating the content, the Scroll attribute enables scrolling so that users can access all the data while maintaining a clear and readable layout. Depending on the report design, scrolling can be enabled vertically, horizontally, in both directions, or in flow mode. Developers typically use this attribute in Parts containing repeated Lines or Parts, large tables, dashboards, and reports with extensive data, ensuring that users can comfortably navigate through the information without affecting the overall layout of the report. The Scroll attribute is applicable only at the Part definition. It is most useful when the Part contains repeated Lines or Parts or displays more data than can fit within the available area. Scrolling becomes effective when the content exceeds the visible size of the Part or Form.
The permissible values are:
| Value | Description | Usage |
|
Vertical |
Enables vertical scrolling, allowing users to move up and down through the contents of the Part. | Lists, registers, vouchers, ledger reports, and any report containing repeated rows. |
| Horizontal | Enables horizontal scrolling, allowing users to move left and right to view content that extends beyond the available width. | Reports with a large number of columns or wide data fields. |
| Both | Enables both vertical and horizontal scrolling within the same Part. | Dashboards, matrices, or reports containing many rows and columns. |
| Flow | Displays the content in a continuous flowing manner instead of restricting it to the visible dimensions of the Part. The content flows naturally, and scrolling is managed accordingly. |
Dynamic layouts where the content size varies and should flow naturally rather than being confined to a fixed display area. |
Syntax
[Part : <Part Name>]
Scroll : <Keywords>
Example
[Part: TSPL ScrollAttribute]
Line : TSPL LedgerTitles,TSPL LedgerDetails
Repeat : TSPL LedgerDetails : List of Ledgers
Scroll : Vertical
Common Border: Yes
In this example, the Part `TSPL ScrollAttribute` displays a list of ledgers by repeating the `TSPL LedgerDetails` Line for every object in the `List of Ledgers` collection. Since the number of ledgers can exceed the visible area of the Part, the attribute `Scroll : Vertical` enables vertical scrolling, allowing users to move up and down through the list without affecting the layout of the report. The `TSPL LedgerTitles` Line is displayed once at the top as the column header, while the repeated ledger details can be viewed by scrolling. This combination of `Repeat` and `Scroll` is commonly used in reports that display long lists of data, ensuring that all records remain accessible while maintaining a clean and readable interface.
When a Part contains more information than can fit within the available space, users can scroll to view the remaining content. In such cases, it is helpful to indicate that additional content is available and to show the user’s current position within the scrollable area. Scroll Indicator Style is an attribute used to control the appearance of the scroll indicator displayed in a Part. By changing the style of the scroll indicator, developers can make it more visible or align it with the overall design of the report, thereby improving the user’s navigation experience. This attribute is applicable only when scrolling is enabled for the Part using the Scroll attribute and the content exceeds the visible area, causing a scroll indicator to be displayed. Developers typically use this attribute in Parts containing long lists of repeated records, wide tables, dashboards, or other reports with scrollable content, where a clear visual indication of the scroll position helps users navigate the data more efficiently.
Syntax
[Part : <Part Name>]
Scroll Indicator Style: <Style Definition Name>
Example
[Part: TSPL Indirect Expenses part]
Line : TSPL Indirect Expenses Line
Repeat : TSPL Indirect Expenses Line : TSPL Indirect Expenses Led collection
Scroll : Vertical
Scroll Indicator Style: Tiny
In this example, the Part TSPL Indirect Expenses Part displays a list of indirect expense ledgers by repeating the TSPL Indirect Expenses Line for every object in the TSPL Indirect Expenses Led Collection. Since the number of ledgers can exceed the visible area of the Part, Scroll : Vertical enables users to scroll through the list. The attribute Scroll Indicator Style : Tiny specifies that the scroll indicator should be displayed in the Tiny style. As users navigate through the repeated records, the compact scroll indicator provides a visual cue that additional records are available beyond the visible area and indicates the current scroll position, while occupying minimal screen space.
A Part may contain Lines that users can interact with, such as selecting a record to view, alter, delete, or perform other operations. Select is an attribute used to control whether the Lines within a Part can be selected by the user. By default, this attribute is set to Yes, which means users can move the cursor to the Lines in the Part and select them for further interaction. When the attribute is set to No, the Lines remain visible but cannot receive focus or be selected, making the Part display-only. This is useful for Parts that are intended only to present information, such as report headers, summaries, totals, instructions, or other read-only sections where user interaction is not required. Developers typically use this attribute to distinguish between interactive and non-interactive areas of a report, resulting in a cleaner and more intuitive user experience. The alias for the Select attribute is Selectable.
Syntax
[Part : <Part Name>]
Select : <Logical Value>
Example
[Part: TSPL SelectAttribute]
Line : TSPL SelectAttribute
Repeat: TSPL SelectAttribute : Ledger
Scroll: Vertical
Border: Thin Box
Select: Yes
In this example, the Part TSPL SelectAttribute displays a list of ledgers by repeating the TSPL SelectAttribute Line for every object in the Ledger collection. The Scroll : Vertical attribute allows users to navigate through the list when the number of ledgers exceeds the visible area of the Part, while Border : Thin Box provides a border around the Part for better visual separation. By specifying Select : Yes, the repeated Lines become selectable, allowing users to move the cursor to any ledger in the list and select it for further interaction, such as viewing or performing actions associated with that record. Since Yes is the default value for the Select attribute, explicitly specifying it is optional, but doing so makes the behaviour of the Part clear and improves the readability of the code.
A Part may contain one or more Lines, but in some situations you may want to display only a limited number of them at a time. Set is an attribute used to specify the number of Lines that should be visible within a Part. It controls the visible height of the Part by determining how many Lines are displayed simultaneously. If the Part contains more Lines than the number specified, only the specified number of Lines are displayed. The remaining Lines can be viewed only if scrolling is enabled using the Scroll attribute; otherwise, they remain hidden. Developers typically use the Set attribute in Parts displaying repeated data, such as lists of ledgers, vouchers, or stock items, to create a compact and well-organised layout while allowing users to navigate through additional records when required. The alias for the Set attribute is Set As.
Syntax
[Part : <Part Name>]
Set : <Numberic Expression>
Example
[Part: TSPL SetAttribute]
Line : TSPL SetAttribute
Repeat: TSPL SetAttribute : TSPLSetAggr
Break On: $$IsEmpty:$TSPLSetUDF
Scroll: Vertical
Border: Thin Box
Set : If ##vTSPLIsLocalParty Then 4 Else 5
In this example, the Set attribute controls how many Lines are visible within the Part at any given time. Instead of specifying a fixed number, it uses the expression If ##vTSPLIsLocalParty Then 4 Else 5, which is evaluated at runtime. If the variable ##vTSPLIsLocalParty is Yes, the Part displays 4 Lines; otherwise, it displays 5 Lines. This demonstrates that the Set attribute can dynamically adjust the visible height of a Part based on runtime conditions rather than using a fixed value.
A Part may display values that depend on variables, methods, formulas, or other data that can change while the report is open. By default, these values are refreshed only when the Part is redisplayed. Set Always is an attribute used to ensure that the values displayed in the Fields of a Part are recalculated and updated whenever the underlying data they depend on changes. This eliminates the need to manually refresh or reopen the report to see the latest values. Developers typically use this attribute in interactive reports and data entry screens where calculations, totals, balances, or other displayed values must always remain in sync with user input or runtime changes, ensuring that the information shown in the Part is always current and accurate.
Syntax
[Part : <Part Name>]
Set Always : <Logical Value>
Example
[Part: TSPL SetAlwaysAttribute]
Line : TSPL SetAlwaysAttribute
Repeat: TSPL SetAlwaysAttribute : TSPLSetAggr
Break On: $$IsEmpty:$TSPLSetUDF
Scroll: Vertical
Border: Thin Box
Set Always: Yes
In this example, the Part TSPL SetAlwaysAttribute displays records by repeating the TSPL SetAlwaysAttribute Line for every object in the TSPLSetAggr collection. By specifying Set Always : Yes, Tally ensures that the values displayed in the Fields of the repeated Lines are recalculated whenever the underlying data changes, instead of waiting for the Part to be redisplayed. As a result, users always see the most up-to-date values while interacting with the report. This is particularly useful in interactive reports where field values depend on variables, formulas, methods, or other data that may change during runtime, ensuring that the displayed information remains accurate without requiring the user to refresh or reopen the report.
Charts often display values that can become very large, making the labels on the Y-axis difficult to read and occupy more space than necessary. Shorten Y Axis Label is an attribute used to display large numeric values on the Y-axis in a shorter and more readable format. When this attribute is set to Yes, values greater than a certain threshold are automatically abbreviated using units such as thousands (K), lakhs (L), millions (M), or other applicable units, depending on the value. A corresponding legend is also displayed to help users understand the abbreviated scale. By default, this attribute is set to No (or False), which means the complete numeric values are displayed on the Y-axis. Developers typically enable this attribute in charts containing large numerical values to improve readability, reduce clutter, and make the chart easier to interpret without affecting the accuracy of the displayed data. The Shorten Y Axis Label attribute is applicable only to chart Parts that display a Y-axis with numeric values. It has no effect on non-chart Parts or charts that do not contain a Y-axis. The attribute becomes useful only when the values plotted on the Y-axis are large enough to be abbreviated; for smaller values, the labels are displayed in their original format regardless of the attribute setting.
Syntax
[Part : <Part Name>]
Shorten Y Axis Label : <Logical Value>
Example
[Part: TSPL EnableGraphCursorAttribute]
Line : TSPL EnableGraphCursorAttribute
Repeat : TSPL EnableGraphCursorAttribute : TSPL Indirect Expenses collection
Border : Thin Box
Graph Type : Yes
Enable Graph Cursor : Yes
Graph Display Cursor Label : Yes
Shorten Y Axis Label : Yes
In this example, the Part TSPL EnableGraphCursorAttribute is configured to display the data from the TSPL Indirect Expenses Collection as a graph by specifying Graph Type : Yes. The attribute Enable Graph Cursor : Yes allows users to move a cursor over the graph and interact with individual data points. As the cursor moves across the graph, the corresponding data point is highlighted, making it easier to identify and analyse specific values. Since Graph Display Cursor Label : Yes is also specified, the value associated with the selected data point is displayed as a label, providing immediate feedback without requiring users to interpret the graph manually. Additionally, Shorten Y Axis Label : Yes ensures that large numeric values on the Y-axis are displayed in a shortened and more readable format.
A report or data entry screen may contain multiple Parts through which users navigate using the keyboard. Skip Forward is an attribute used to control the cursor movement when navigating between these Parts. When this attribute is set to Yes, the Part is skipped while moving forward using the Right Arrow or Down Arrow keys, allowing the cursor to move directly to the next eligible Part. However, the Part is not skipped during backward navigation. If the user presses the Left Arrow or Up Arrow key from the subsequent Part, the focus returns to the skipped Part. This behaviour is useful when a Part contains optional or less frequently used information that users do not need to visit during normal forward navigation but should still be able to access when navigating backwards. Developers typically use this attribute to create a smoother and more efficient keyboard navigation flow in reports and data entry screens. This attribute works in conjunction with multiple Parts in a Form. If there is only one Part, this attribute has no effect. It applies only to keyboard navigation using the Right, Left, Up, and Down arrow keys. The commonly used together with navigation-related attributes such as Skip, Retain Focus, Select, and Invisible to customise the user’s navigation experience. The Part should be visible and enabled. If the Part is hidden using Invisible : Yes or is otherwise inaccessible, the behaviour of Skip Forward is not applicable.
Syntax
[Part : <Part Name>]
Skip Forward : <Logical Value>
Example
[Part: TSPL Skip Forward Second Part]
Line : TSPL Skip Forward SP Line
Skip forward : Yes
Height : 5
Scroll : Both
Border : Thick box
In this example, the Part TSPL Skip Forward Second Part contains the Line TSPL Skip Forward SP Line and has the attribute Skip Forward : Yes. This instructs Tally to skip this Part when the user navigates forward using the Right Arrow or Down Arrow keys, allowing the focus to move directly to the next eligible Part. However, if the user navigates backward using the Left Arrow or Up Arrow keys, the focus returns to this Part, making it accessible whenever required.
A Part may need some empty space around it to improve the overall layout and readability of a report. Space Bottom is an attribute used to specify the amount of empty space that should be left below a Part. This creates a gap between the current Part and the Part or Line that follows it, preventing the report from appearing crowded. Developers typically use this attribute to separate logical sections of a report, improve visual presentation, and make printed or displayed reports easier to read. This attribute is commonly used together with Border, Height, Width, Space Top, Space Left, and Space Right to create a well-spaced report layout. It is useful when multiple Parts are displayed one below another.
Syntax
[Part : <Part Name>]
Space Bottom : <Numberic Expression>
Example
[Part : TSPL SpaceBottomAttribute]
Line : TSPL CompanyDetails
Border : Thin Box
Space Bottom : 2
In this example, Space Bottom : 2 leaves two units of empty space below the TSPL SpaceBottomAttribute Part. As a result, the next Part or Line begins after this gap, making the report sections visually distinct and easier to read.
A report often contains multiple Parts arranged one below another. Space Top is an attribute used to specify the amount of empty space that should be left above a Part. This creates a gap between the current Part and the preceding Part, making the report appear less cluttered and improving readability. Developers commonly use this attribute to visually separate headings, summaries, and report sections. This attribute is commonly used together with Border, Height, Width, Space Bottom, Space Left, and Space Right. It is useful when Parts are stacked vertically.
Syntax
[Part : <Part Name>]
Space Top : <Numberic Expression>
Example
[Part : TSPL SpaceTopAttribute]
Line : TSPL CompanyDetails
Border : Thin Box
Space Top : 2
In this example, Space Top : 2 leaves two units of empty space above the TSPL SpaceTopAttribute Part. This creates a clear separation from the preceding Part, improving the visual organisation of the report.
Sometimes a Part needs to be positioned slightly away from the left edge of the report or aligned with other Parts. Space Left is an attribute used to specify the amount of empty space that should be left on the left side of a Part. This shifts the Part towards the right without changing its contents, making it useful for indentation, grouping related information, or improving alignment within the report. The attribute is commonly used together with Width, Border, Align, Space Right, Space Top, and Space Bottom to control the layout of a report. It is useful when Parts are arranged horizontally or require indentation.
Syntax
[Part : <Part Name>]
Space Left : <Numberic Expression>
Example
[Part : TSPL SpaceLeftAttribute]
Line : TSPL CompanyDetails
Border : Thin Box
Space Left : 5
In this example, Space Left : 5 leaves five units of empty space on the left side of the TSPL SpaceLeftAttribute Part. As a result, the Part is positioned slightly towards the right, creating an indented layout that improves the visual structure of the report.
A Part may require some empty space on its right side to maintain proper alignment or prevent it from appearing too close to adjacent Parts. Space Right is an attribute used to specify the amount of empty space that should be left on the right side of a Part. This helps create balanced layouts, especially when multiple Parts are displayed next to each other. Developers typically use this attribute to improve spacing, alignment, and the overall appearance of reports. The attribute is commonly used together with Width, Border, Align, Space Left, Space Top, and Space Bottom. It is useful when multiple Parts are placed side by side.
Syntax
[Part : <Part Name>]
Space Right : <Numberic Expression>
Example
[Part : TSPL SpaceRightAttribute]
Line : TSPL CompanyDetails
Border : Thin Box
Space Right : 5
In this example, Space Right : 5 leaves five units of empty space on the right side of the TSPL SpaceRightAttribute Part. This ensures that sufficient spacing is maintained between the current Part and any adjacent Part, resulting in a cleaner and more balanced report layout.
Reports containing a large number of repeated records can be difficult to read, especially when users need to distinguish one row from another. Stripe is an attribute used to enable or disable alternating row colours within a Part. When stripes are enabled, alternate rows are displayed with different background shades, making it easier to scan the report and follow information across rows. By default, Stripe is set to Yes, which means striped formatting is enabled. Developers can override this behaviour in child Parts or Lines by specifying the Stripe attribute at those levels, allowing different sections of a report to have different striping behaviour. This attribute is commonly used in reports containing repeated data, such as ledgers, vouchers, stock items, and registers, where improved row separation enhances readability.
Syntax
[Part : <Part Name>]
Stripe : <Logical Value>
Example
[Part: TSPLStripeLine]
Line : TSPLStripeLine
Border : Column Titles
Common Border : Yes
Stripe : Yes
In this example, the Part TSPLStripeLine contains the TSPLStripeLine Line and enables striped formatting by specifying Stripe : Yes. As a result, when the Part displays multiple rows, alternate rows are shown with different background shades, making it easier for users to distinguish one record from another and improving the readability of the report. The Border : Column Titles attribute applies a predefined border style to the Part, while Common Border : Yes ensures that a single border is drawn around the entire Part instead of individual Lines.
Reports sometimes contain multiple Parts that display related information side by side or one below another. When users scroll through one Part, it is often desirable for the related Part to scroll simultaneously so that the displayed information remains aligned. Sync is an attribute used to synchronise the scrolling behaviour of a Part with another Part. When this attribute is set to Yes, the Part scrolls in coordination with the associated Part, ensuring that both Parts remain aligned during navigation. This is particularly useful in reports where one Part displays labels or headings while another displays corresponding details, or when multiple Parts need to remain visually aligned. By default, the Sync attribute is set to No, which means each Part scrolls independently. The alias for the Sync attribute is Synchronize. The Parts being synchronised should have a similar layout, such as the same number of rows or corresponding repeated data, to maintain proper alignment.
Syntax
[Part : Part Definition]
Sync : <Logical Value>
Example
[Form: TSPL SyncAttribute]
Parts : FormSubTitle, TSPL SyncAttribute
Buttons : Print Button, TSPL Sync Button
Height : 100% Screen
Width : 100% Screen
Local : Field : Form Sub Title : Set As : “Sample demonstrating Sync Attribute at Part Definition”
Local : Field : Form Sub Title : Style : Normal Italic
Option : TSPLSync Parts: ##vSync
[!Form: TSPLSync Parts]
Local : Part : TSPL SyncAttribute : Sync : Yes
In this example, the Form TSPL SyncAttribute contains the Part TSPL SyncAttribute. The Option attribute conditionally applies the Form TSPLSync Parts when the variable ##vSync evaluates to Yes. Within this optional Form definition, the Sync : Yes attribute is applied to the Part TSPL SyncAttribute using the Local attribute. As a result, the Part becomes synchronised with other scrollable Parts in the Form, causing them to scroll together instead of independently. This ensures that related information displayed across multiple Parts remains aligned while users navigate through the report.
A Part can contain one or more child Parts, and the Vertical attribute is used to control how these child Parts are arranged within the parent Part. When Vertical : Yes is specified, the child Parts are placed one below another, creating a vertical layout. When Vertical : No is specified, the child Parts are placed side by side, creating a horizontal layout.
By default, TDL automatically alternates the arrangement of child Parts as the user interface hierarchy grows. A Form arranges its child Parts vertically. If one of these vertical Parts contains child Parts, they are arranged horizontally by default. If those horizontal Parts contain further child Parts, they are again arranged vertically, and this alternating pattern continues throughout the hierarchy. This automatic behaviour helps create well-structured user interfaces without requiring developers to explicitly specify the layout at every level.
However, there are many situations where the default alternating behaviour does not match the desired layout. For example, a vertical Part may need to contain another set of vertical Parts instead of the default horizontal arrangement, or a horizontal Part may need to continue displaying its child Parts horizontally. In such cases, the Vertical attribute can be used to override the default behaviour. Specifying Vertical : Yes forces the child Parts to be arranged vertically, while Vertical : No forces them to be arranged horizontally, regardless of the platform’s default layout. This gives developers complete control over the arrangement of Parts and helps in designing complex report and screen layouts. The attribute is ignored if Part has Line attribute specified as line are arranged from Top to Bottom.
Syntax
[Part : <Part Name>]
Vertical : <Logical Value>
Example
[Part: TSPL VerticalAttribute]
Part : TSPL VerticalAttribute1, TSPL VerticalAttribute2
Vertical : Yes
In this example, the Part TSPL VerticalAttribute contains two child Parts: TSPL VerticalAttribute1 and TSPL VerticalAttribute2. By specifying Vertical : Yes, the child Parts are arranged one below the other, creating a vertical layout. Without this attribute, the platform would arrange the child Parts according to its default alternating layout, which may place them horizontally depending on the hierarchy. By explicitly setting Vertical : Yes, the developer overrides the default behaviour and ensures that both child Parts are stacked vertically.
A Part is displayed within the available area of its parent Form or Part. Vertical Align is an attribute used to control the vertical position of a Part within this available space. Instead of changing the size of the Part, it determines where the Part should be placed vertically at the top, centre, or bottom of its parent container. This attribute is particularly useful when the parent Form or Part has more vertical space than the Part requires, allowing developers to position the Part appropriately and create well-balanced report layouts. By default, Parts are aligned at the Top unless another alignment is specified.
The permissible values are:
| Value | Description |
| Top / Left | Aligns the Part at the top of the available vertical space. This is the default behaviour. |
| Centre | Aligns the Part at the centre of the available vertical space. |
| Bottom / Right | Aligns the Part at the bottom of the available vertical space. |
Syntax
[Part : <Part Name>]
Vertical Align : <Alignment Keyword>
Example
[Part: TSPL VerticalAlignAttribute]
Part : TSPL VerticalAlignAttribute1, TSPL VerticalAlignAttribute2
Vertical Align : Left
Border : Thin Box
Height : 60% Screen
In this example, the Part TSPL VerticalAlignAttribute contains two child Parts: TSPL VerticalAlignAttribute1 and TSPL VerticalAlignAttribute2. The attribute Vertical Align : Left positions the child Parts at the top of the available vertical space within the parent Part. Here, Left is an alias for Top and behaves exactly the same as Vertical Align : Top. Since the Part has a height of 60% of the screen, there is additional vertical space available, making the effect of the alignment visible. The Border : Thin Box attribute draws a border around the Part, allowing the placement of the child Parts within the available area to be observed more clearly.
A Part occupies a certain amount of horizontal space within its parent Form or Part. Width is an attribute used to specify how wide a Part should be. The width can be defined as a fixed measurement (such as millimetres) or as a relative value, such as a percentage of the available width. By controlling the width of a Part, developers can organise multiple Parts side by side, allocate more space to important information, or create balanced report layouts. If the content within the Part exceeds the specified width, the behaviour depends on other attributes such as scrolling or text wrapping. The Width attribute is commonly used to create responsive and well-structured report and form layouts. When the content exceeds the specified width, attributes such as Scroll, or Full Width (where applicable) influence how the content is displayed.
Syntax
[Part : <Part Name>]
Width : <Numberic Expression> [unit of measure]
Example
[Part: TSPL WidthAttribute]
Line : TSPL CompanyDetails
Border : Thin Box
Width : 60% Page
In this example, the Width attribute sets the width of the TSPL WidthAttribute Part to 60% of the available page width. As a result, the Part occupies only a portion of the horizontal space, leaving the remaining area available for other Parts or blank space. The Border : Thin Box attribute draws a border around the Part, making the specified width clearly visible. This demonstrates how the Width attribute controls the horizontal size of a Part and helps developers design well-balanced report layouts by allocating the required amount of space to each Part.
Charts often display category names or descriptions along the X-axis. When these labels are long, they may overlap with each other or extend beyond the available space, making the graph difficult to read. X Axis Label Word Wrap is an attribute used to control whether long X-axis labels should wrap onto multiple lines. When this attribute is set to Yes, labels that exceed the available width are automatically split into multiple lines, allowing the complete text to be displayed without overlapping adjacent labels. When set to No, each label remains on a single line, which may result in truncated or overlapping text if the labels are too long. This attribute is applicable only to graph Parts created using Graph Type : Yes and works in conjunction with attributes such as X Axis, X Axis Label Angle, X Axis Label Font, Width, and Height, which together determine how labels are displayed and positioned on the graph. It becomes effective only when the X-axis contains labels that are long enough to require wrapping. Developers typically enable this attribute in charts with lengthy category names to improve readability while maintaining a clean and organised graph layout.
Syntax
[Part : <Part Name>]
X Axis Label Word Wrap : <Logical Value>
Example
[Part: TSPL XAxisLabelWordWrap]
Line : TSPL XAxisLabelWordWrap
Repeat : TSPL XAxisLabelWordWrap : TSPL Indirect Expenses collection
Border : Thin Box
Graph Type : Yes
Enable Graph Cursor : Yes
Graph Display Cursor Label : Yes
Shorten Y Axis Label : Yes
X Axis Label Word Wrap : Yes
In this example, the Part TSPL XAxisLabelWordWrap is configured to display the TSPL Indirect Expenses Collection as a graph by specifying Graph Type : Yes. The attribute X Axis Label Word Wrap : Yes enables word wrapping for the labels displayed on the X-axis. If any category name is too long to fit within the available horizontal space, Tally automatically displays it on multiple lines instead of a single line, preventing the labels from overlapping and making the graph easier to read. The graph also includes interactive features through Enable Graph Cursor : Yes and Graph Display Cursor Label : Yes, allowing users to move the cursor over individual data points and view their corresponding values. Additionally, Shorten Y Axis Label : Yes displays large numeric values on the Y-axis in a shortened format for better readability. Together, these attributes produce a well-formatted and user-friendly graph where both the axis labels and data values remain clear and easy to interpret.
XMLAttr is an attribute used to add one or more XML attributes to an XML tag when exporting data from TDL in XML format. It allows developers to specify custom attribute–value pairs that become part of the generated XML tag, enabling the exported XML to conform to the structure expected by external applications or integration systems. This attribute is applicable only in definitions that participate in XML export and works in conjunction with attributes such as XML Tag, XML Tag Namespace, XML Object Path, and XML Object, which together define the structure and hierarchy of the generated XML document. Developers typically use XMLAttr when the receiving application expects additional information to be represented as XML attributes rather than child elements, ensuring that the exported XML adheres to the required schema or integration specification.
Syntax
[Part : <Part Name>]
XMLAttr : <Attribute Name> : <Value Expression>
Example
[Field : TSPL LedgerName]
Set As : $Name
XML Tag : Ledger
XMLAttr : “Action” : “Create”
In this example, the XML Tag attribute creates an XML element named <Ledger>. By specifying XMLAttr : Action : “Create”, an attribute named Action with the value Create is added to the opening XML tag. As a result, the generated XML appears as:
<Ledger Action=”Create”>
…
</Ledger>
Instead of creating a separate child element, the value is stored as an attribute of the Ledger tag. This approach is commonly used when integrating with applications or XML schemas that require metadata, such as an action, type, status, or identifier, to be represented as XML attributes.
