PDF

Writing Remote Compliant TDL Reports

Enabling access to your organisational data anytime, anywhere, and yet being truly usable, is what TallyPrime is capable of. With remote access, it will be possible for the owner or any authorized user to access TallyPrime data from anywhere. With this capability, they will be able to access all the reports and information from a remote location.

All this has been made possible by adopting Client/Server architecture in the product. The underlying principle of any client/server environment is the communication between client and server in a request/response fashion. The request/response is in the form of XML. Client sends request and the server responds.

TallyPrime family, the default product delivers the capability to access any TDL reports from anywhere. There have been significant enhancements in Tally platform at the Collection, Report and Function Levels for delivering this capability. The way TDL Reports have been changed in default TDL to optimise the performance and seamlessly work without clogging the network is the focus of this chapter. The idea is to reduce the server calls for accessing the data. The same concepts can be followed for making the customized Reports Remote Compliant.

Watch the below video to know about writing a remote compliant TDL reports.

Given below is the overall enabled environment using Tally.NET Server.

We will begin our discussion with an overview of client/server environment in general, and then move on to Tally Client/Server, and the role of Tally.NET Server in such a scenario. The topics covered henceforth will focus on understanding the execution of TDL reports and optimising the code for executing in this environment.

Client/Server Architecture – An Overview

Clients and Servers are separate logical entities that work together over a network to accomplish a task. A client is defined as a requester of services and a server is defined as the provider of services.

Some of the advantages of client/server architecture are as follows:

Centralization – Resources and data security are controlled through the server.
Scalability – Entire system can be scaled horizontally or vertically.
Accessibility – Server can be accessed remotely.

Tally Client/Server Architecture using Tally Software Services

TSS (Tally Software Services) is a framework which provides a number of services to the TallyPrime users. The TSS architecture is derived from client/server architecture. In this architecture, TallyPrime Client is connected to TallyPrime server via middle-ware, i.e., Tally.NET Server. Following are the major components of the TSS architecture.

Tally.NET Server
TallyPrime Server
TallyPrime Client

Tally.NET Server

The communication between TallyPrime Server and TallyPrime Client is being handled by Tally.NET Server. It provides the Routing services for Tally. It is through Tally.NET Server that we are able to provide an entire range of services, which we commonly refer to as TSS features. The user can utilize Tally.NET Server to Synchronize data, access online help and support and manage licenses across locations, while the auditor can use it to scrutinize the client’s data from a remote location. All this can be done in a secured environment.

The system administrator can create users with the rights to access or audit data from a remote location and assign controls based on their security level for the required company only. The remote users accessing the company data behave as clients on Tally.NET Server. Tally.NET Server takes care of user authentication when a remote user tries to connect to the TallyPrime Server.

TSS Features

Register and Connect companies from TallyPrime
Create and maintain Remote Users
Remote availability of Auditor’s License
Synchronize data
Remote access of data by any user
Use online help and support capability from within Tally or browser
Application Management (across Multi-serial, Multi-Location, etc.) via Tally or browser

TallyPrime Server

TallyPrime Server is a typical Tally application which hosts the Tally Company and is always connected to the Tally.NET Server. User creation, authorization, connecting the company to Tally.NET Server, etc., is handled at this end.

TallyPrime Client

TallyPrime Client is a typical Tally application. Tally client can remotely access the Tally Company which is hosted by Tally server. Authenticated users connect to enabled companies from this end.

Setting up Tally.NET Server for Remote Access

Following are the steps which need to be executed to setup the Tally.NET Server:

Step 1 : Enable Security control to avail TSS features.

Go to Gateway of Tally > Company > Alter

Step 2 : Configuring TSS features.

Go to Gateway of Tally > Company

Step 3 : Authorizing the Remote Users.

Go to Gateway of Tally > Company > Users and Passwords.

Users classified under the security level Tally.NET User and Tally.NET Auditor should be created individually by the system administrator.

Allow Remote Access should be set to YES only if the client wants his Tally.NET Auditor/Tally.NET User to access data remotely.

If Allow Local TDLs is set to YES, then the client can load Local TDLs, in addition to remote TDLs. If it is set to NO, the client cannot load Local TDLs.

Step 4: Connecting Companies to Tally.NET Server.

Go to Gateway of Tally > Company > Connect

Setting Up the Client Tally

The users classified as Tally.NET User or Tally.NET Auditor can access data by logging in from a remote location. The user has to execute the following steps to login as a remote user:

Step 1 : Get connected to Tally.NET Server

Step 2 : Provide the Tally.NET ID and Password

After entering the details, Tally displays screen to select the remote company.

Step 3 : Load the Remote company

The remote screen displays the list of companies to which the remote user has access. First, all the Online companies are listed, followed by the list of offline companies.

TDL – In a Client/Server Environment

In a client/server environment, data resides in the server. A typical client will have only user interface. Whenever the client requires data, it has to send a request to the server with credentials, and the server will respond with the data.

In TSS environment, the server and the client exchange the request/response in encrypted XML format. When the client is Tally application, it will have only the user interface and needs to get data from the server on demand. A typical Tally application is developed using TDL. In TDL language, definitions are broadly classified as Data Objects and Interface Objects. Interface objects define the user interface and Data objects store the values in Tally primary or secondary database. Tally client will have only Interface Objects locally and the Data Objects need to be fetched from the server on request.

It is the TDL Programmer’s responsibility to fetch the required data from the Tally server to Tally Client.

TDL programmer can optimize the performance of the Remote compliant TDL by minimizing the server request calls. Mentioned below are the guidelines to optimize the Remote Compliant TDL Reports.

Fetching the Single Object

When an entire Report requires multiple methods of a single Object, then the Object can be pre-fetched with the required methods. In this approach, only one server call is made to fetch all the required methods.

Example

[Report: Final Led Report]

Form : Final Led Report

Fetch Object : Ledger : LedgerName : Name,Ledger Contact,Ledger Phone,TBalOpening, TBalClosing

Repeating Lines Over a Collection

The following techniques are used to optimize the performance, when a line is repeated over a collection in a report to be displayed on the client.

Fetching the Methods

Whenever a collection is referred to in a Report, the required methods need to be explicitly fetched from the server. It is mandatory to specify Fetch in the Collection for all the methods which are used in the fields. If ‘Fetch’ is not used, then the data will not be displayed in the field.

[Part : Led Report]

Line : LedReport Details

Repeat : LedReport Details : Ledger

Scroll : Vertical

[Line : Led ReportDetails]

Fields : Led Name

Right Field : LedClosing Balance

[Field : Led Name]

Use : Name Field

Set as : $Name

[Field : Led ClosingBalance]

Use : Amount Forex Field

Set as : $ClosingBalance

[#Collection: Ledger]

Fetch : Name, Closing Balance

Function inside the ‘Repeat’

When Lines are repeated over a Collection and a function is used at the field level, then each ‘Repeat’ will trigger an additional server request for function call. In this scenario, the entire function call logic can be moved to ‘Compute’ of the repeated Collection. The later approach will do only one server request. Hence, performance is drastically improved.

[Part : Led Report]

Lines : LedReport Details

Repeat : LedReport Details : Ledger

Scroll : Vertical

[Line : LedReportDetails]

Fields : Led Name

Right Fields: LedClosingBalance, LedSalesTotal

[Field : Led Name]

Use : Name Field

Set as : $Names

[Field : LedClosingBalance]

Use : Amount Forex Field

Set as : $ClosingBalance

[Field : LedSalesTotal]

Use : Amount Forex Field

Set as : $LedgerSalesTotal

[#Collection : Ledger]

Fetch : Name , Closing Balance

Compute : Ledger SalesTotal : $$AsReqObj:$$FilterAmtTotal:Ledouchers:MyParty:$Amount

Repeating Over Period Collection

In Reports where lines are repeated over Period Collection and values of each column is calculated over a period for the required object, e.g., in Sales Register, value of each column is calculated based on a period and object Voucher Type. In this scenario, an additional computational method needs to be added to the Period Collection to fetch the values for each column.

[#Collection : Period Collecti o n]

Compute : TBalDebits : $TBalDebits : VoucherType : #VoucherTypeName

Compute : TBalCredits : $TBalCredits : VoucherType : #VoucherTypeName

Compute : TBalClosing : $TBalClosing : VoucherType : #VoucherTypeName

Using the same Collection in more than one Report

When more than one Report requires different methods of the Objects of the same Collection, then using the same collection with all the methods fetched in it reduces the performance. This can be improved in the following ways:

Fetching the required methods locally at Report

In the following code snippet, Sample Report1 requires Opening Balance of a Ledger whereas Sample Report2 requires Closing Balance. Instead of modifying the Collection to fetch both Opening Balance and Closing Balance, the same is localized in respective Reports.

[Report : Sample Report1]

Local : Collection : Ledger : Fetch : Opening Balance

[Report : Sample Report2]

Local : Collection : Ledger : Fetch : Closing Balance

Separate Collections for fetching different methods

In the following code snippet, two Collections are created for fetching the opening balance and the closing balance. Later, the first Collection can be utilized in Sample Report1 and the second one in Sample Report2.

[Collection : Fetch Opening Balance]

Type : Ledger

Fetch : Opening Balance

[Collection : Fetch Closing Balance]

Type : Ledger

Fetch : Closing Balance

TDL Usage in Remote Environment

TDL language has been used with the client/server capability. We have a few collection and report related attributes to make server calls. These capabilities have taken place in the platform for the execution of Functions and Actions.

Collection Attributes

In TDL, Collection definition is a data repository which contains the data objects. Whenever Tally Client uses a Collection, it has to fetch the objects from the Remote server. But a Tally Client need not require the all the methods of an Object. Also fetching the entire Object may be costly in terms of network bandwidth.

The required methods of an object(s) at the Tally Client are fetched using the Collection attribute Fetch. In addition to ‘Fetch’ attribute, methods doing aggregation or computation using Aggr Compute & Compute are also brought to the Tally Client.

Internally fetching a method will generate an XML fragment, which will be sent to the Tally Server as a request.

Fetch

Syntax

Fetch : Existing-Method-Name-in-Source, …

Where,

< Existing-Method-Name-in-Source > are the internal methods of the Object which needs to be fetched to the Client.

Compute

Syntax

Compute : Method-Name : Method-Formula

Where,

< Method-Formula > is any computational method, and

< Method-Name > denotes the name of the method.

Example: Fetching Name & Closing Balance of Ledger Object

Step 1 : Fetching Name and Closing Balance methods of Ledger object.

[Collection : Ledgers]

Type : Ledger

Fetch : Name, Closing Balance, Parent

Compute : PClosingBalance : $ClosingBalance : Group : $Parent

Format : $Name, 15

Step 2 : Utilizing the fetched methods

As a Table

[Field : Sample Field]

Table : Ledgers

Show Table : Always

In ‘Repeat’ at Part Level

[Part : Sample Part]

Line : Sample Line

Repeat : Sample Line : Ledgers

[Line : Sample Line]

Fields : Sample Fld1, Sample Fld2, Sample Fld3

[Field : Sample Fld1]

Use : Name Field

Set as : $Name

[Field : Sample Fld2]

Use : Amount Field

Set as : $ClosingB a lance

[Field : Sample Fld3]

Use : Amount Field

Set as : $Closing Balance

Sample Request Format XML file to fetch the internal methods and Compute method:

<TALLYREQUEST>EXPORT</TALLY REQUEST>

<TYPE>COLLECTION</TYPE>

<ID>Ledger</ID>

</HEADER>

<BODY>

<DESC>

<SVEXPORTFORMAT>BinaryXML</SVEXPORTFORMAT>

<SVCURRENTCOMPANYTYPE=”String”>DemoCompany</SVCURRENTCOMPANY>

<SVTODATETYPE=”Date”>31-Mar-2009</SVTODATE>

<SVCURRENTKBLANGUAGEID TYPE=”Number”>1033

</SVCURRENTKBLANGUAGEID>

</STATICVARIABLES>

<TDL>

<TYPE>Ledger</TYPE>

<METHOD>PClosingBalance:$ClosingBalance:Group:$Parent</METHOD>

<NATIVEMETHOD>Parent</NATIVEMETHOD>

<NATIVEMETHOD>ClosingBalance</NATIVEMETHOD>

</COLLECTION>

</TDLMESSAGE>

</TDL>

</DESC>

</BODY>

Report Attributes

Fetching the Object

Report Level

When multiple methods of a Single Object/Multiple Objects of the same type are required, then that Object can be fetched at Report, Form, Field and Function levels. For this purpose, Report attribute Fetch Object is used. Internally fetching an object will generate an XML fragment which will be sent to the Tally Server as a request.

At Report level this attribute is useful in case of remote access since the data has to come from the server and the client need not send the request again and again.

Syntax

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

Where,

<Object Type> denotes the type of the Object.

<Expression> can be any of the string expression.

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

Example: Pre-fetching Ledger Object with methods ‘Name’ & ‘Closing Balance’

[Report: Simple Report]

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

In this code snippet, Ledger Name is the variable which stores the name of the Ledger Object whose methods need to be fetched at the Report. Since the Object name is an expression, we need to prefix the variable name with ##. Sample Request Format XML file to fetch the object:

<TALLYREQUEST>EXPORT</TALLYREQUEST>

<TYPE>OBJECT</TYPE>

<SUBTYPE>Ledger</SUBTYPE>

</HEADER>

<BODY>

<DESC>

<SVCURRENTCOMPANY>Demo Company</SVCURRENTCOMPANY>

<SVEXPORTFORMAT>Binary XML</SVEXPORTFORMAT>

<SVCURRENTKBLANGUAGEIDTYPE=”Number”>1033

</SVCURRENTKBLANGUAGEID>

<SVCURRENTUILANGUAGEIDTYPE=”Number”>1033

</SVCURRENTUILANGUAGEID>

</STATICVARIABLES>

<FETCH>Parent</FETCH>

<FETCH>Closing Balance</FETCH>

</FETCHLIST>

</DESC>

</BODY>

</ENVELOPE>

Form Level

This attribute is used when multiple forms are available at a report and for each form the methods pertaining to different objects are to be fetched.

Syntax

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

Example

[!Form : AccoutingViewVoucher]

Switch : AccVoucherView : NormalAccoutingViewVoucher : NOT$$IsAttendance : ##SVVoucherType

Switch : AccVoucherView : AttdAccoutingViewVoucher : $$IsAttendance:##SVVoucherType

[!Form : AttdAccoutingViewVoucher]

Fetch Object : AttendanceType : @@AttdEntryList : AttendanceProductionType, AttendancePeriod, BaseUnits

[!Form : NormalAccoutingViewVoucher]

FetchObject : Ledger : @@AllLedEntryList : Name, Parent, ReserveName

Fetch Object

Field level

This attribute is used to Fetch Object values dynamically based on current field values. For example, the field may be associated with a Table of ledgers. Based on the ledger selected, the corresponding methods of the Object require to be fetched. In such cases, this attribute will be useful.

Syntax

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

Example

[Field : LED VAT Class]

Fetch Object : TaxClassification : $$Value:FirstAlias, RateofVAT, TaxType

Function level

There may be scenarios where the method values need to be fetched based on the Object name passed as a parameter to the function. In such cases, Fetch Object at the function level is required.

If we have already fetched the object methods at the ‘Report’ or ‘Field’ level, the same will be propagated to the called function. In case it is not fetched earlier, the same can be fetched at the ‘Function’ level as well. This enables dynamic fetching of Objects.

Syntax

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

Example

[Function : FillUsingTrackingObj]

Parameter : pTrackKey : String

Fetch Object : Tracking Number : ##pTrackKey : *.*

Attribute – Fetch Values

This attribute allows the computation of user defined methods based on the current object Context.

Syntax

Fetch Values : <List of methods>

Where,

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

Example

[Report : VAT Classification]

Object : Tax Classification

Fetch Values : MasterID, CanDelete

Attribute – Multi Objects

This attribute is required to be specified in case multiple objects of the same collection are being added/modified in a Report. It is required specifically in case of multi master creation or alteration.

Syntax

MultiObjects : <Edit Collection>

Where,

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

Example

[Report : Multi Ledger]

Multi Objects : Ledger Under MGroup

Attribute – Modifies

This attribute is used to update/modify the value of the variable . The variable value can be modified either based on the field’s acceptance or form’s acceptance.

Syntax:

Modifies : <Variable Name> : <Logical Value> : <Expression>

Where,

<Variable Name> is the name of the variable.

<Logical Value> is any expression which evaluates to a logical value.

<Expression> can be used to modify the variable value within the field.

Example

[Field : BatchesInGodown]

Modifies : DSPGodownName : Yes : ##DSPGodownName + “ – Godown”

Attribute – PreFetch Object

There are some scenarios in which it is required to set the values of variables according to the data fetched along with the object. At the report level, the ‘Set’ attribute for changing variable value takes precedence and ‘Fetch Object’ is evaluated later. In those cases, fetching the object first becomes mandatory. For this purpose, a new attribute PreFetch Object has been introduced, which will be evaluated before the ‘Set’ attribute.

Syntax

Pre Fetch Object : <Object Type> : <Object Name> : <Method Name1> [,<Method Name 2>…]

Where,

< Object Type > denotes the type of the Object.

< Object Name > denotes the name of the object, and

< Method Name 1 > denotes the method to be pre-fetched.

Example:

[Report : Simple Report]

Set : LedgerName : “Cash”

Pre Fetch Object : Ledger : LedgerName : LastVoucherDate

Set : SVFromDate : $LastVoucherDate : Ledger : ##LedgerName

In this code snippet, variables are set once, and then the PreFetch Object is done, and once again the variables are set to make sure that the values of the variables which were dependent on the object, will set now.

Prefetching the Collection

When the same collection is used in the Report either for repeating the line over its objects or multiple functions using the same, then a Collection of those objects can be prefetched at the Report level. A new Report attribute Fetch Collection is introduced to prefetch a Collection.

Syntax

Fetch Collection : <Collection 1> [,<Collection 2>..]

Where,

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

Example: Prefetching Ledger collection

[Report : Sample Report]

Fetch Collection : Ledger

Local : Collection : Fetch : Ledger

In this code snippet, Ledger Collection is pre-fetched. Sample Request Format XML file to fetch the object:

<TALLYREQUEST>EXPORT</TALLYREQUEST>

<TYPE>COLLECTION</TYPE>

<ID>All Party</ID>

</HEADER>

<BODY>

<DESC>

<SVEXPORTFORMAT>BinaryXML</SVEXPORTFORMAT>

<SVCURRENTCOMPANY TYPE=”String”>Remote Vivek</SVCURRENTCOMPANY>

</STATICVARIABLES>

<TDL>

<TYPE>Ledger</TYPE>

<CHILDOF>$$GroupSundryDebtors</CHILDOF>

<NATIVEMETHOD>OpeningBalance</NATIVEMETHOD>

<NATIVEMETHOD>ClosingBalance</NATIVEMETHOD>

</COLLECTION>

</TDLMESSAGE>

</TDL>

</DESC>

</BODY>

</ENVELOPE>

Function on Request

Functions in TDL are defined and provided by the platform. A TDL programmer can only call a function. Now in client/server environment, functions can be evaluated by either the sever or the client or both the client and the server.

Based on this information, functions can be classified as follows:

Evaluated at client side
Evaluated at server side
Hybrid

Evaluated at Client Side

These are the functions which will be evaluated at the client side. For this, no server request is required from the client. If these functions require any parameter as data, then required data needs to be fetched from the server before the function is called.

Example:

$$KeyExplode, $$ExplodeLevel, $$Line, etc., are the functions which do not require any parameter from the Tally server and are executed at the Tally client.

Evaluated at Server Side

These are the functions which will be evaluated at the server side. For each call of a function, a request will be sent to the server, along with the parameters.

Example:

$$NumStockItems, $$NumLedgers, etc., are the functions which will be executed at the server side. Sample Request Format XML file for Function Call:

<TALLYREQUEST>EXPORT</TALLYREQUEST>

<TYPE>FUNCTION</TYPE>

<ID>$$NumLedgers</ID>

</HEADER>

<BODY>

<DESC>

<SVCURRENTCOMPANY>Demo Company</SVCURRENTC OMPANY>

<SVEXPORTFORMAT>Binary XML</SVEXPORTFORMAT>

</STATICVARIABLES>

</DESC>

</BODY>

</ENVELOPE >

Hybrid

These are the functions which will be executed on either the client or the server side based on the availability of the data.

Example:

$$IsSales, $$CollAmtTotal, $$FilterAmtTotal, etc., are the functions which will be executed at the server or client side, based on the availability of data.

Server side execution

$$FilterAmtTotal:$OpeningBalance:Ledgers:MyFilter

Since Ledger Collection is available on the sever, the function $$FilterAmtTotal will be executed at the server end.

Client side execution

$$FilterAmtTotal:$Amount:LedgerEntries:MyFilter

Ledger Entries collection is available inside the ‘Voucher’ Object. So, the required Voucher Object needs to be fetched to the Client before the function is executed. Once the Voucher is brought to the client, the function will be executed on the client side, since it is assumed to be executed in the Voucher context.

Action Enhancements

The Action Modify Object is executed in the Display mode of any report. This action can be executed at the client’s end to modify any object present on the Server Company.

Syntax

Action : Modify Object : <PrimaryObjectSpec>.<Sub O bjectPathSpec>. M ethod-Name : value>[,Method Name: <val u e> , …] +

[,<SubObjec t PathSpec>.MethodNa m e:<value>, …..]

Where,

<PrimaryObjectSpec> can be (<Primary Object Type Keyword>, <Primary Object Identifier Formula>).

<SubObjectPathSpec> is given as CollectionName [<Index Formula>, [<Condition>]]

<MethodName> refers to the name of the method in the specified path.

<Index Formula> should return a number which acts as a position specifier in the Collection of Objects satisfying the given <condition> .

Sample Request Format XML file for Modifying ‘Ledger’ Object:

<TALLYREQUEST>IMPORT</TALLYREQUEST>

<SUBTYPE>Ledger</SUBTYPE>

<ID>All Masters</ID>

</HEADER>

<BODY>

<DESC>

<SVCURRENTCOMPANY>Demo Company</SVCURRENTCOMPANY>

</STATICVARIABLES>

</DESC>

<ADDRESS.LIST TYPE=”String”>

</ADDRESS.LIST>

<MAILINGNAME.LIST TYPE=”String”>

<MAILINGNAME>Customer 1</MAILINGNAME>

</MAILINGNAME.LIST>

<NAME TYPE=”String”>Customer 1</NAME>

<PARENT>Sundry Creditors</PARENT>

<LANGUAGENAME.LIST>

<NAME.LIST TYPE=”String”>

<NAME>Customer 1</NAME>

<NAME>Alias</NAME>

</NAME.LIST>

</LANGUAGENAME.LIST>

</LEDGER>

</TALLYMESSAGE>

</BODY>

</ENVELOPE>