HomeDeveloper ReferenceTDL ReferenceWriting Remote Compliant TDL Reports

 

Explore Categories

 

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

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.

Step 4: Connecting Companies to T ally.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 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 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 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, 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:

<ENVELOPE>

<HEADER>

<VERSION>1</VERSION>

<TALLYREQUEST>EXPORT</TALLY REQUEST>

<TYPE>COLLECTION</TYPE>

<ID>Ledger</ID>

</HEADER>

<BODY>

<DESC>

<STATICVARIABLES>

<SVEXPORTFORMAT>BinaryXML</SVEXPORTFORMAT>

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

<SVCURRENTDATE TYPE=”Date”> 20-Dec-2008</SVCURRENTDATE>

<SVFROMDATE TYPE=”Date”>1-Apr-2008</SVFROMDATE>

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

<SVCURRENTKBLANGUAGEID TYPE=”Number”>1033

</SVCURRENTKBLANGUAGEID>

</STATICVARIABLES>

<TDL>

<TDLMESSAG E >

<COLLECTION NAME=”Ledger” ISMO D IFY=”No” ISFIXED=”No” ISINITIALIZE=”Yes” ISOPTION = “No” ISINTERNAL=”No”>

<TYPE>Ledger</TYPE>

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

<NATIVEMETHOD>Name</NATIVEMETHOD>

<NATIVEMETHOD>Parent</NATIVEMETHOD>

<NATIVEMETHOD>ClosingBalance</NATIVEMETHOD>

</COLLECTION>

</TDLMESSAGE>

</TDL>

</DESC>

</BODY>

<ENVELOPE>

Report Level Enhancements

Fetching 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 Type> denotes the type of the Object.

<Object Name> denotes the name of the Object.

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

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

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

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:

<ENVELOPE>

<HEADER>

<VERSION>1</VERSION>

<TALLYREQUEST>EXPORT</TALLYREQUEST>

<TYPE>FUNCTION</TYPE>

<ID>$$NumLedgers</ID>

</HEADER>

<BODY>

<DESC>

<STATICVARIABLES>

<SVCURRENTCOMPANY>Demo Company</SVCURRENTC OMPANY>

<SVEXPORTFORMAT>Binary XML</SVEXPORTFORMAT>

<SVFROMDATE TYPE=”Date ” >1-Apr-2008</SVFROMDATE>

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

<SVCURRENTDATE TYPE=”Date”>1-May-2008</SVCURRENTDATE>

<SVCURRENTKBLANGUAGEID TYPE=”Number”>1033</SVCURRENTKBLANGUAGEID>

<SVCURRENTUILANGUAGEID TYPE=”Number”>1033< /SVCURRENTUILANGUAGEID>

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

Writing Remote Compliant TDL Reports

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 : S ample Report1]

Local : Collection : Ledger : Fetch : Opening Balance

[Report : S ample 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

Enhancements in Tally.ERP 9 Releases

Release 2.0

There have been various enhancements at the TDL level to enable Remote Edit Capability in the product. The enhancements are as follows:

Fetch Object’ Attribute Changes

The attribute ‘Fetch Object’ has been supported at Report, Form, Field and the Function level as well. The Object Name specification in the syntax allows expressions now. It is also possible to specify multiple Object Names separated by the Fetch Separator Character. A new function $$FetchSeparator has been introduced to return this character.

Fetch Values’ Attribute Introduced

The evaluation of External Methods of an Object requires Object Context to be available at the Client End. A new Attribute ‘Fetch Values’ has been provided at the ‘Report’ level to specify the list of External Methods.

Multi Objects’ Attribute Introduced

Whenever multiple Objects of the same collection are getting modified at the Client’s End, a new attribute called ‘MultiObjects’ is introduced at the Report Level to enable the same.

Modifies’ Attribute Changes

The ‘Modifies’ attribute of the field has been changed to accept a third parameter (optional) which is an expression. This allows the variable to be modified with the value of the expression rather than the field value.

Collection attribute ‘Parm Var’ Introduced

As we already know, the ‘Collection’ Artefact evaluates the various attributes either during initialization or at the time of gathering the collection. It may require various inputs from the Requestor context for the same.

The direct reference of values/expressions from the report elements and objects in the collection at various points creates various issues like code complexity, performance lapses and non availability of these values on Server in Remote Environment.

In order to overcome these, a new Collection attribute ‘Parm Var’ has been introduced. ‘Parm Var’ in collection is a context-free structure available within the collection. The requestors Object context is available for the evaluation of its value. This is evaluated only once in the context of the caller/requestor. This happens at collection initialization, and the expression provided to it is evaluated and stored as a variable, which can be referred within any of the attributes of the collection anytime, and is made available at the Server end as well.

Lets understand each of these in detail.

‘Fetch Object’ Attribute Changes

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.

Report Level

‘Fetch Object’ attribute has been enhanced at ‘Report’ level to take an expression instead of a variable name that evaluates to the name of an object.

The existing syntax of the ‘Fetch Object’ attribute at report level is as follows:

Syntax: Prior to 2.0

Fetch Object : <Object Type> : <Variable Identifier> : <List of methods>

Example

Fetch Object: Ledger: LedgerName: Name, Parent, ClosingBalance

Syntax: 2 . 0 Onwards

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

Example

Fetch Object: Ledger: ##LedgerName: Name, Parent, ClosingBalance

Here, since the Object name is an expression, we need to prefix the variable name with ##.

Form Level

Attribute ‘Fetch Object’ has been introduced at ‘Form’ Level. In scenarios where multiple forms are available at a report; for each form, we require to fetch methods pertaining to different objects.

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

Field Level

There may be scenarios where we may need to Fetch Object values dynamically based on the 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 : *.*

In case the same set of methods for multiple objects needs to be fetched, the multiple Object Names need to be specified in the syntax of ‘Fetch Object’, separated by the Fetch separator character.

Function – $$FetchSeparator

This function returns C_FETCH_SEPARATOR character that is used for separating multiple object names in FETCH OBJECT attribute.There may be scenarios where the same set of methods needs to be fetched from multiple objects. In that case, it is possible to specify multiple object names in the ‘Fetch Object’ syntax, separated by the character which is returned from the function $$FetchSeparator.

Example

Fetch Object : Ledger : “Debtor North” + $$FetchSeparator + “Debtor South” : Name, Parent, ClosingBalance

‘Fetch Values’ Attribute Introduced

This is a report level attribute which allows the computation of values for user-defined (external) methods, based on the current Object context available.

Syntax

Fetch Values : <List of methods>

Example

[Report : VAT Classification]

Object : Tax Classification

Fetch Values : MasterID, CanDelete

‘Multi Objects’ Attribute Introduced

This is a ‘Report’ level attribute which 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

‘Modifies’ Attribute Changes

This is a field level attribute enhanced further to take a third optional parameter. Prior to Tally.ERP 9 Release 2.0, if a field had ‘Modifies’ parameter, the field value would be set to the variable. And based on this variable value, some calculations or concatenation was required to be performed. An invisible field was required for the same. With the enhancement in this Release, one can modify the variable value at the same field itself using an expression, i.e., the field, and the variable may have different values.

Syntax: Prior 2.0

Modifies : <Variable Name> : <Logical Value>

Where,

<Variable Name> is the name of the variable.

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

Example

[Field : BatchesInGodown]

Modifies : DSPGodownName : Yes

Syntax: 2 .0 onwards

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”

 

Post a Comment