Enabling access to your organisational data anytime, anywhere, and yet being truly usable, is what Tally.ERP 9 is capable of. With remote access, it will be possible for the owner or any authorized user to access Tally.ERP 9 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.
Tally.ERP 9 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.
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.
TSS (Tally Software Services) is a framework which provides a number of services to the Tally.ERP 9 users. The TSS architecture is derived from client/server architecture. In this architecture, Tally.ERP 9 Client is connected to Tally.ERP 9 server via middle-ware, i.e., Tally.NET Server. Following are the major components of the TSS architecture.
● Tally.NET Server
● Tally.ERP 9 Server
● Tally.ERP 9 Client
The communication between Tally.ERP 9 Server and Tally.ERP 9 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 scrutinise 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 Tally.ERP 9 Server.
TSS Features
● Register and Connect companies from Tally.ERP 9
● 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
Tally.ERP 9 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.
Tally.ERP 9 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.
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 > Click F3 :Company Info > Alter .
Step 2 : Configuring TSS features.
● Go to G ateway of Tally > Click F11:Features > TSS Features.
Step 3 : Authorizing the Remote Users.
● Go to Gateway of Tally > Click F3 :Company Info > Security Control > Users & Passwords.
Note:
♦ 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.
S tep 4: Connecting Companies to T ally.NET Server.
● Go to Gateway of T all y > F4:Connect Com p any
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 User name and Password
After entering of valid user name & password, Tally displays screen to select the remote company.
Step 3 : Load the Remote company
The above 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.
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 language has been enhanced with the client/server capability. Collection and Report definitions are enhanced to make server calls. Enhancements have taken place in the platform for the execution of Functions and Actions.
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.
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.
Syntax
Compute : Method-Name : Method-Formula
Where,
< Method-Formula > is any computational method, and
< Method-Name > denotes the name of the method.
Note: Please refer ‘TDL Enhancements for Tally.ERP 9.pdf‘ for further information on Collection attributes ‘Aggr Compute’ , ‘Compute’ and ‘Fetch’
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, C l osing Balance, Pare n t
Compute : PClosin g Balance : $ClosingBa l ance : Group : $Parent
Format : $Name, 1 5
Step 2 : Utilizing the fetched methods
● As a Table
[Field : S a mple Field]
Table : Ledgers
Show Table : Always
● In ‘Repeat’ at Part Level
[Part : Sa m ple Part]
Line : Sample Li n e
Repeat : Sample Li n e : Ledgers
[Line : Sam p le Line]
Fields : Sample Fl d 1, Sample Fld2, Sam p le Fld3
[Field : Sa m ple Fld1]
Use : Name Field
Set as : $Name
[Field : Sa m ple Fld2]
Use : Amount Fi e ld
Set as : $ClosingB a lance
[Field : Sa m ple Fld3]
Use : Amount Fi e ld
Set as : $Closing B alance
Sample Request Format XML file to fetch the internal methods and Compute method:
<ENVELOPE>
<HEADER>
<VERSION>1</VERSION>
<TALLYREQUEST>EXPORT</TALL Y REQUEST>
<TYPE> C OLLECTION</TYPE>
<ID>Le d ger</ID>
</HEADER>
<BODY>
<DESC>
<STATICVAR I ABLES>
<SVEXPORT F ORMAT>BinaryXML</SV E XPORTFORMAT>
<SVCURREN T COMPANYTYPE="String " >DemoCompany</SVCUR RENTCOMPANY>
<SVCURRENTDATE TYPE="Date"> 20-Dec-2008</SVCURR E NTDATE>
<SVFROMDA T E TYPE="Date">1-Apr - 2008</SVFROMDATE>
<SVTODATE TYPE="Date">31-Mar- 2 009</SVTODATE>
<SVCURREN T KBLANGUAGEID TYPE=" N umber">1033
</SVCURRENTKBLANGU A GEID>
</STATICVARIABLES>
<TDL>
<TDLMESSAG E >
<COLLECTION NAME="Ledger" ISMO D IFY="No" ISFIXED="N o " ISINITI A LIZE="Yes" ISOPTION = "No" ISINTERNAL="N o ">
<TYPE>Ledg e r</TYPE>
<METHOD>PC l osingBalance:$Closi n gBalance:Group:$Par e n </METHOD>
<NATIVEMET H OD>Name</NATIVEMETH O D>
<NATIVEMET H OD>Parent</NATIVEME T HOD>
<NATIVEMET H OD>ClosingBalance</ N ATIVEMETHOD>
</COLLEC T ION>
</TDLMESSA G E>
</TDL>
</DESC>
</BODY>
<ENVELOPE>
When multiple methods of a single Object are required for a Report, then that Object can be fetched at Report level. For this purpose, new Report attribute ‘Fetch Object’ has been introduced. Internally fetching an object will generate an XML fragment which will be sent to the Tally Server as a request.
Syntax
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.
<Method Name 1> denotes the method to be fetched.
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. Sample Request Format XML file to fetch the object:
<ENVELOPE>
<HEADER>
<VERSION>1</VERSION>
<TALLYREQUEST>EXPORT</TALLYREQUEST>
<TYPE>OBJECT</TYPE>
<SUBTYPE>Ledger</SUBTYPE>
<ID TYPE="Name">Cash </ID>
</HEADER>
<BODY>
<DESC>
<STATICVARIABLES>
<SVCURRENTCOMPANY>Demo Company</SVCURRENTCOMPANY>
<SVEXPORTFORMAT>BinaryXML</SVEXPORTFORMAT>
<SVFROMDATE TYPE="Date">1-Apr-2008</SVFROMDATE>
<SVTODATE TYPE="Date">31-Mar-2009</SVTODATE>
<SVCURRENTDATE TYPE="Date">1-May-2008</SVCURRENTDATE>
<SVVALUATIONMETHOD TYPE="String"></SVVALUATIONMETHOD>
<SVBUDGET TYPE="String"> </SVBUDGET>
<SVCURRENTKBLANGUAGEIDTYPE="Number">1033
</SVCURRENTKBLANGUAGEID>
<SVCURRENTUILANGUAGEIDTYPE="Number">1033
</SVCURRENTUILANGUAGEID>
</STATICVARIABLES>
<FETCHLIST>
<FETCH>Name</FETCH>
<FETCH>Parent</FETCH>
<FETCH>Closing Balance</FETCH>
</FETCHLIST>
</DESC>
</BODY>
</ENVELOPE>
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 PreFetchObject 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 pre fetch a Collection.
Syntax
Fetch Collection : <Collection 1> [,<Collection 2>..]
Where,
<Collection 1> is the collection whose objects need to be prefetched at Report.
Example: Prefetch i ng Ledg e r c ollection
[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:
<ENVELOPE>
<HEADER>
<VERSION>1</VERSION>
<TALLYREQUEST>EXPORT</TALLYREQUEST>
<TYPE>COLLECTION</TYPE>
<ID>All Party</ID>
</HEADER>
<BODY>
<DESC>
<STATICVARIABLES>
<SVEXPORTFORMAT>BinaryXML</SVEXPORTFORMAT>
<SVUSEPARMLIST>No</SVUSEPARMLIST>
<SVFORTABLE>No</SVFORTABLE>
<SVCURRENTCOMPANY TYPE="String">Remote Vivek</SVCURRENTCOMPANY>
<SVCURRENTDATE TYPE="Date">2-May-2008</SVCURRENTDATE>
<SVFROMDATE TYPE="Date">1-Apr-2008</SVFROMDATE>
<SVTODATE TYPE="Date">31-Mar-2009</SVTODATE>
<SVVALUATIONMETHOD TYPE="String"></SVVALUATIONMETHOD>
<SVBUDGET TYPE="String"></SVBUDGET>
</STATICVARIABLES>
<TDL>
<TDLMESSAGE>
<COLLECTION NAME="All Party" ISMODIFY="No" ISFIXED="No"
ISINITIALIZE="Yes" ISOPTION="No" ISINTERNAL="No">
<TYPE>Ledger</TYPE>
<BELONGSTO>Yes</BELONGSTO>
<CHILDOF>$$GroupSundryDebtors</CHILDOF>
<NATIVEMETHOD>OpeningBalance</NATIVEMETHOD>
<NATIVEMETHOD>ClosingBalance</NATIVEMETHOD>
</COLLECTION>
</TDLMESSAGE>
</TDL>
</DESC>
</BODY>
</ENVELOPE>
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
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 p arameter from the Tally server and are executed at the Tally client.
Evalu a ted 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:
<ENVELOPE>
<HEADER>
<VERSION>1</VERSION>
<TALLYREQUEST>EXPORT</TAL L YREQUEST>
<TYPE>FUNCTION</TYPE>
<ID>$ $ NumLedgers</ID>
</HEADER>
<BODY>
<DESC>
<ST A TICVARIABLES>
<SVCURRENTCOMPANY>Demo Company</SVCURRENTC OMPANY>
<SVEXPORTFORMAT>Binary X ML</SVEXPORTFORMAT>
<SVFROMDATE TYPE="Date " >1-Apr-2008</SVFROM DATE>
<SVTODATE TYPE="Date"> 31-Mar-2009</SVTODAT E >
<SVCURRENTDATE TYPE="D a te">1-May-2008</SVC U RRENTDATE>
<SVCURRENTKBLANGUAGEID TYPE="Number">1033< / SVCURRENTKBLANGUAG E ID>
<SVCURRENTUILANGUAGEID TYPE="Number">1033< / SVCURRENTUILANGUAG E ID>
</S T ATICVARIABLES>
</DESC>
</BODY>
</ENVELOP E >
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:$OpeningBalanc e: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:Ledger Entries: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.
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. For details on the usage of this action, please refer to ‘TDL Enhancements for Tally.ERP 9”.
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:
<ENVELOPE>
<HEADER>
<VERSION>1</VERSION>
<TALLYREQUEST>IMPORT</TALLYREQUEST>
<TYPE>DATA</TYPE>
<SUBTYPE>Ledger</SUBTYPE>
<ID>All Masters</ID>
</HEADER>
<BODY>
<DESC>
<STATICVARIABLES>
<SVCURRENTCOMPANY>Demo Company</SVCURRENTCOMPANY>
</STATICVARIABLES>
</DESC>
<TALLYMESSAGE>
<LEDGER NAME="Customer 1" RESERVEDNAME="">
<ADDRESS.LIST TYPE="String">
<ADDRESS>Abc</ADDRESS>
<ADDRESS>Def</ADDRESS>
</ADDRESS.LIST>
<MAILINGNAME.LIST TYPE="String">
<MAILINGNAME>Customer 1</MAILINGNAME>
</MAILINGNAME.LIST>
<ALTEREDON>20090112</ALTEREDON>
<NAME TYPE="String">Customer 1</NAME>
<CURRENCYNAME>Rs.</CURRENCYNAME>
<PINCODE>560001</PINCODE>
<PARENT>Sundry Creditors</PARENT>
<ISDEEMEDPOSITIVE TYPE="Logical">Yes</ISDEEMEDPOSITIVE>
<SORTPOSITION> 1000</SORTPOSITION>
<OPENINGBALANCE>1.00</OPENINGBALANCE>
<LANGUAGENAME.LIST>
<NAME.LIST TYPE="String">
<NAME>Customer 1</NAME>
<NAME>Alias</NAME>
</NAME.LIST>
<LANGUAGEID> 1033</LANGUAGEID>
</LANGUAGENAME.LIST>
</LEDGER>
</TALLYMESSAGE>
</BODY>
</ENVELOPE>
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.
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
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.
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 : Le d Report]
Line : LedRepor t Details
Repeat : LedRepor t Details : Ledger
Scroll : Vertical
[Line : Led R eportDetails]
Fields : Led Name
Right Field : LedClosin g Balance
[Field : Led Name]
Use : Name Field
Set as : $Name
[Field : Le d ClosingBalance]
Use : Amount Fo r ex Field
Set as : $ClosingB a lance
[#Collection: Ledger]
Fetch : Name, Closing Balance
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 : Le d Report]
Lines : LedRepor t Details
Repeat : LedRepor t Details : Ledger
Scroll : Vertical
[Line : Led R eportDetails]
Fields : Led Name
Right Fiel d s: LedClosin g Balance, LedSalesTo t al
[Field : Led Name]
Use : Name Field
Set as : $Name s
[Field : Le d ClosingBalance]
Use : Amount Forex Field
Set as : $ClosingBalance
[Field : Le d SalesTotal]
Use : Amount Forex Field
Set as : $LedgerSalesTotal
[#Collection : Ledger]
Fetch : Nam e , Closing Balance
Compute : Ledge r SalesTotal : $$AsReqObj:$ $FilterAmtTotal:Led Vouchers:MyParty:$Am ount
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 : TBalClosin g : $TB a lClosing : VoucherTyp e : #VoucherTypeName
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:
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 : S ample Report1]
Local : Collecti o n : Ledger : Fetch : Opening Balance
[Report : S ample Report2]
Local : Collecti o n : Ledger : Fetch : Closing Balance
Se p arate Collectio n s for fetching different m ethods
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 Ba l ance]
Type : Ledger
Fetch : Opening B alance
[Collection : Fetch Closing Balance]
Type : Ledger
Fetch : Closing B alance
