https://help.tallysolutions.com/docs/td9rel54/tdl_reference/writing_remote_compliant_tdl_reports.htm

Writing Remote Compliant TDL Reports

On this page

Client/Server Architecture – An Overview

Tally Client/Server Architecture using Tally Software Services

Setting up Tally.NET Server for Remote Access

Setting up the Client Tally

TDL – In a Client/Server Environment

TDL Enhancements for Remote

Writing Remote Compliant TDL Reports

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.

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

Figure_12.1_Overview_of_Tally.NET.jpg

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.

Figure_12.2_Block_diagram_of_clientserver_architecture.jpg

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 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

Tally.NET Server

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

Figure_12.3_Tally.NET_Architecture.jpg

Tall y .ERP 9 Server

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

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.

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 > 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

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

Figure_12.8_Connecting_Tally.NET.jpg

Step 2 : Provide the User name and Password

Figure_12.9_Providing_User_Name_and_Password.jpg

After entering of valid user name & password, Tally displays screen to select the remote company.

Step 3 : Load the Remote company

Figure_12.10_Loading_Remote_Company.jpg

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.

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 Enhancements for Remote

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.

Collection Enhancements

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.

Note: Please refer ‘TDL Enhancements for Tally.ERP 9.pdf‘ for further information on Col­lection 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>

Report Leve l Enhancements

Fet c hing the Object

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 T ype> denot e s the type of the Object.

<Object Nam e > den o tes t he name of t he Object.

<Method Name 1> de n otes the method to be f etched.

Example: Pre-fetc h ing Ledg e r Obje c t with methods ‘Name’ & ‘Cl os ing Balan c e’

[Report: S imple Report]

Fetch Obje c t : Ledger : Ledger Name : Name, Paren t ,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>

<TALLYREQU E ST>EXPORT</TALLYREQ U EST>

<TYPE>OBJE C T</TYPE>

<SUBTYPE>L e dger</SUBTYPE>

<ID TYPE=" N ame">Cash </ID>

</HEADER>

<BODY>

<DESC>

<STATICVAR I ABLES>

<SVCURRENT C OMPANY>Demo Company < /SVCURRENTCOMPANY>

<SVEXPORTF O RMAT>BinaryXML</SVE X PORTFORMAT>

<SVFROMDATE TYPE="Date">1-Apr- 2 008</SVFROMDATE>

<SVTODATE T YPE="Date">31-Mar-2 0 09</SVTODATE>

<SVCURRENT D ATE TYPE="Date">1-M ay-2008</SVCURRENTDA T E>

<SVVALUATI O NMETHOD TYPE="Strin g "></SVVALUATIONMETH O D>

<SVBUDGET T YPE="String"> </SVB U DGET>

<SVCURRENT K BLANGUAGEIDTYPE="Nu m ber">1033

</SVCURREN T KBLANGUAGEID>

<SVCURRENT U ILANGUAGEIDTYPE="Nu m ber">1033

</SVCURREN T UILANGUAGEID>

</STATICVA R IABLES>

<FETCHLIST>

<FETCH>Nam e </FETCH>

<FETCH>Par e nt</FETCH>

<FETCH>Clo s ing Balance</FETCH>

</FETCHLIS T >

</DESC>

</BODY>

</ENVELOP E >

PreFetching the 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 : S imple Report]

Set              : LedgerNam e : “Cash”

Pre Fetch O bject : Ledger : L edgerName : LastVou c herDate

Set : SVFromDat e : $LastVoucherDate : L edger : ##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,

<Colle c tion 1> is the collection w h ose objec t s ne e d to be pref e tched at Rep o rt.

Example: Prefetch i ng Ledg e r c ollection

[Report : S ample Report]

Fetch Coll e ction : Ledger

Local : Collection : Fetch : Le d ger

In t h is code snippet, L edger C ollection is pre-fetched. Sample Re q uest Form a t XML file to fetch the object:

<ENVELOPE>

<HEADER>

<VERSION>1</VERSION>

<TALLYREQUEST>EXPORT</TAL L YREQUEST>

<TYPE>COLLECTION</TYPE>

<ID>A l l Party</ID>

</HEADER>

<BODY>

<DESC>

<ST A TICVARIABLES>

<SVEXPORTFORMAT>Binar y XML</SVEXPORTFORMAT>

<SVUSEPARMLIST>No</SV U SEPARMLIST>

<SVFORTABLE>No</SVFOR T ABLE>

<SVCURRENTCOMPANY TYP E ="String">Remote Vi v ek</SVCURRENTCOMPA NY>

<SVCURRENTDATE TYPE=" D ate">2-May-2008</SV C URRENTDATE>

<SVFROMDATE TYPE="Dat e ">1-Apr-2008</SVFRO M DATE>

<SVTODATE TYPE="Date" >31-Mar-2009</SVTODA T E>

<SVVALUATIONMETHOD TY P E="String"></SVVALU A TIONMETHOD>

<SVBUDGET TYPE="Strin g "></SVBUDGET>

</S T ATICVARIABLES>

<TD L >

<TDLMESSAGE>

<COLLECTION NAME="A l l Party" ISMODIFY=" N o" ISFIXED="No"

ISINITIALIZE="Yes" ISOPTION="No" ISIN T ERNAL="No">

<TYPE>Ledger</TYP E >

<BELONGSTO>Yes</B E LONGSTO>

<CHILDOF>$$GroupS u ndryDebtors</CHILDO F >

<NATIVEMETHOD>Ope n ingBalance</NATIVEM E THOD>

<NATIVEMETHOD>Clo s ingBalance</NATIVEM E THOD>

</COLLECTION>

</TDLMESSAGE>

</T D L>

</DESC>

</BODY>

</ENVELOP E >

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 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 ‘Vouche r ’ Object. So, the required V ouch e r Object n e eds to be fetched to t h e C lient b efore the function is execute d . Once the V ouch e r is bro u ght t o the client, the fu n ction will be executed on the client side, since it is assumed to be executed in the Vo u cher cont e xt.

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. 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,

<PrimaryObject S pec> c a n be (<Primary O b ject T ype Keyword>, <Primary Obj e ct I d entif ier Formul a >).

<SubObjectPat h S p ec> is given a s CollectionName [<Index Formula>, [<Condition>]]

<MethodName> refers to the name of the met h od in the specifi e d path.

<Ind e x Formula> sho u ld re t urn a numb e r which acts as a position sp e cifier in the Collection o f Objec t s s a tisfying the g iven <cond i tion > .

Sample Re q uest Form a t XML file f o r Mo d ifying ‘Ledg e r’ Object:

<ENVELOPE>

<HEADER>

<VERSION>1 < /VERSION>

<TALLYREQU E ST>IMPORT</TALLYREQ U EST>

<TYPE>DATA < /TYPE>

<SUBTYPE>L e dger</SUBTYPE>

<ID>All Ma s ters</ID>

</HEADER>

<BODY>

<DESC>

<STATICVAR I ABLES>

<SVCURRENT C OMPANY>Demo Company < /SVCURRENTCOMPANY>

</STATICVA R IABLES>

</DESC>

<TALLYMESS A GE>

<LEDGER NA M E="Customer 1" RESE R VEDNAME="">

<ADDRESS.L I ST TYPE="String">

<ADDRESS>A b c</ADDRESS>

<ADDRESS>D e f</ADDRESS>

</ADDRESS. L IST>

<MAILINGNA M E.LIST TYPE="String " >

<MAILINGNA M E>Customer 1</MAILI N GNAME>

</MAILINGN A ME.LIST>

<ALTEREDON > 20090112</ALTEREDON>

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

<CURRENCYN A ME>Rs.</CURRENCYNAM E >

<PINCODE>5 6 0001</PINCODE>

<PARENT>Su n dry Creditors</PARE N T>

<ISDEEMEDP O SITIVE TYPE="Logica l ">Yes</ISDEEMEDPOSI T IVE>

<SORTPOSIT I ON> 1000</SORTPOSIT I ON>

<OPENINGBA L ANCE>1.00</OPENINGB A LANCE>

<LANGUAGEN A ME.LIST>

<NAME.LIST TYPE="String">

<NAME>Cust o mer 1</NAME>

<NAME>Alia s </NAME>

</NAME.LIS T >

<LANGUAGEI D > 1033</LANGUAGEID>

</LANGUAGE N AME.LIST>

</LEDGER>

</TALLYMES S AGE>

</BODY>

</ENVELOP E >

Writing Remote Compliant TDL Repor t s

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.

Fetc h ing th e 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: F inal Led Report]

Form        : Final Led Report

Fetch Obje c t : Ledger : L edgerName : Name,Led g er Contact, Ledger Phone,TBalO p ening, TBalClosing

Repeating Lines over a Collection

The followi n g t echniques are used to o p timize the perform a nce, when a line is re p eated over a coll e ction in a report to be d isplayed on the client.

Fet c hing 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 : 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

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 : 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

Repeat i ng over Period Co l lection

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

Using th e same Collecti o n 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:

Fet c hing the required methods locally at Rep o rt

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