|
On this page
|
Release 6.4.1 enhancement - Export Header
In the previous lesson, the usage of Variables, Buttons and Keys were explained. In this lesson, the concept of ‘Objects’ and ‘Collections’ will be discussed in detail. Let us try to understand what an object is in general, its importance and usage in TDL.
Any information that is stored in a computer is referred to as Data. Database is a collection of information organized in such a way that a computer program can quickly select desired data. A database can be considered as an electronic filing system. To access information from a database, a Database Management System (DBMS) is used. DBMS allows to enter, organize, and select data in a database.
The organization of data in a database is referred to as the ‘Database Structure’. The widely used database structures are hierarchical, relational, network and object-oriented.
In the hierarchical structure the data is arranged in a tree-like structure. This structure uses the parent–child relationships to store repeating information. A parent can have multiple children, but a child can have only one parent. The child in turn can have multiple children. Information related to one entity is referred to as an object. A database is a group of interrelated objects.
An object is a self-contained entity that consists of both data, and procedures to manipulate the data. It is defined as an independent entity, based on its properties and behaviour/functionality. Objects are stored in a data base.
A relationship can be created between the objects. As discussed, the hierarchical structure has a parent-child relationship. For example, child objects can inherit characteristics from parent objects. Likewise, a child object can not exist without a parent object.
After discussing the object concept in general, let us examine the Tally object structure in the following section.
The Tally data base is hierarchical in nature, in which the objects are stored in a tree-like structure. Each node in the tree can be a tree in itself. An object in Tally is composed of methods and collections. Method is used to retrieve data from the database. A collection is a group of objects. Each object in the collection can further have methods and collections. The structure is as shown below:
Everything in TDL is an Object. As mentioned in the earlier chapters, Report, Menu, Company, Ledger, etc., all are objects in TDL. The properties of objects in TDL are called Attributes. For example, the attributes Object, Title, Form are all properties that define the Report object.
An object can have Methods and Collections, as mentioned earlier. For example, the Object ‘Ledger’ contains the Methods Name, Parent, etc., and the collections Address and BillwiseDetails.
As shown in the image the Objects available at Level 1 are referred to as Primary objects and objects which are at Level 2-n are referred to as Secondary objects.
Two different types of objects are available in TDL. The following section describes the classification of objects in TDL.
Objects in TDL are classified into two types, based on the their usage and behaviour, as follows:
● Interface Objects
● Data Objects
Interface objects define the user interface while Data objects store the value in the Tally Primary or Secondary database. Any data manipulation operation on the data object is performed through Interface objects only. Figure 6.2 shows the classification of objects in TDL.
Objects used for designing the User Interface are referred to as Interface objects. Report, Form, Menu, etc., are interface objects. Interface objects like Report and Menu are independent items and can exist on their own. The objects Form, Part, Line, Field can’t exist independently. They must follow the containment hierarchy as mentioned in the section Basic TDL Structure.
Example
[Field : Sa m ple Fld]
Width : 22
[Line : Sam p le Ln]
Field : Name Field
TDL allows a re-usage of all the objects. There are two ways to obtain some more properties that are required in an object:
● The existing object can either be used in new objects or in lieu of defining a new object.
● The existing object can be modified to add new properties.
The interface objects can be shared by other interface objects. For example, a single field can be used in multiple lines. The following examples describe the discussed scenarios:
Example : 1
[Field : Sample Fld]
Width : 22
Set As : “TDL Demo”
[#Field : Sample Fld]
Style : Normal Bold
The field Sample Fld will have both the properties. The width of the field is 22 and text is displayed using the style Normal Bold.
Example : 2
[Field : Sa m ple Fld]
Width : 22
Set As : “TDL Demo”
[Field : Sa m ple Fld1]
Use : Sample Fld
Style: Normal Bo l d
The field Sample Fld1 will have both the properties. The width of the field is 22 and the text is displayed using the style Normal Bold.
Example : 3
[Line: TitleA]
Field : Name Field
[Line: TitleB]
Field : Name Field
The field Name Field is used in both the lines TitleA and TitleB .
A set of available attributes of interface objects are predefined by the platform. A new attribute can not be created for an interface object. Interface objects are always associated with a Data Object and essentially add, retrieve or manipulate the information in Data Objects.
Data is actually stored in the Data Objects. These objects are classified into two types viz., Internal objects and User defined objects/TDL objects.
Internal objects are provided by the platform. They are stored in the Tally Database. Multiple instances of internal objects can exist. In Tally.ERP 9, internal objects are of several types. Examples of internal objects are Company, Group, Ledger, Stock, Stock Item, Voucher Type, Cost Centre, Cost Category Budget, Bill and Unit of Measure.
All the Objects which are defined by the user in TDL are referred to as User Defined Objects or TDL objects. User defined objects are further classified as Static Objects or Dynamic Objects.
Static TDL Objects cannot be stored in Tally Database. The data for the Static object is hard coded in the program and can be used for display purpose only.
Dynamic TDL Objects can be created from the data available in any of the following external data sources:
● XML Files from remote HTTP server
● DLL files
● From any type of database through ODBC
In TDL, the data from all these external data sources is available in a collection.
As discussed earlier, a user can create Static TDL Objects for which the data is hard coded. Consider the following examples of Employee Details.
Employee Details
In TDL, two objects have to be created such that EmpNo, Name, Date and Designation become the attributes of the object. The code snippet to create these objects is as shown:
[Object : E mp 1]
EmpNo : E001
Name : “Krishna”
Date : Aug 01 Designation : Manager
[Object : E mp 2]
EmpNo : E002
Name : “Radha”
Date : Aug 01
Designation : “Asst. Manager”
Consider the data for a ledger object which has multiple bill details associated with it.
This hierarchical structure shows that the ledger Krishna is created under the group Sundry Creditors. It further contains multiple bill details. The Ledger Name is Krishna, the parent group is Sundry Creditors and the closing amount is 3000. The two bills Bill 1 for the amount 1000 and Bill 2, for the amount 2000, are associated with the ledger Krishna.
Note: Please refer to Appendix for the detailed structure of Internal Objects and Methods.
Each Interface object exists in the context of a Data Object. An Interface object either retrieves information from the Data Object or stores information into the Data Object. The association of the Interface object with a Data Object can be done at the Report, Part, Line and Field level. All the methods of the associated Data Object are available in the Interface object, which is said to be in the ‘Context’ of the associated Data Object.
The data is always retrieved from the database in context of the current object. All the data manipulation operations are performed on the object in context only.
Any expression such as Formulae, Methods and so on which are evaluated in the Interface object, will be in the ‘Context’ of the Data Object.
To understand the concept of object context, consider the following example:
When the Interface object ‘Report’ is associated to the Data Object ‘Ledger’, then all the methods and collection of the Ledger object can be referenced in the associated report. The Method
$Name, when used in the field, will display the name of the Ledger object associated at the Report level. If no object is associated at the Report level, then no data will be displayed in the field, since there is no object in the context.
A Collection is termed as a group of objects. It refers to a collection of zero or more objects. The objects in the collection can be obtained either from the Tally database, or from external data sources, e.g., XML file.
In default TDL, many collections are defined which are referred to as Internal Collections. The collections created by a user are called user defined collections. Object in a collection follow the Tally object structure, i.e., each object of the collection can contain Methods, Collections, and so on.
A collection can be a collection of objects or a collection of collections. Figure 6.3 shows the collection of objects.
The collection of collections is referred to as a Union of collection. This capability will be discussed in detail in the section Collection capabilities. In TDL, the collections are of two types: Simple collection and Compound collections.
Collections can have multiple Methods and Collection. They are classified as Simple Collection and Compound Collection based on the constituents of the collection.
Simple collections contain only a single method which is repeatable. Simple Collections cannot have sub-collections. The Name and Address are examples of Simple Collections.
The collections which have sub-collections and multiple methods are called Compound Collection. Any Internal or External Collections of Primary or Secondary or user defined objects is an example of a Compound Collection. In both Simple and Compound Collections, the index can be used to fetch user-defined or internal methods of the Object. The Index can be either First or Last.
After describing the classification of a Collection, the following topic describes the various data sources of a Collection.
Collection , the data processing artefact of TDL, provides extensive capabilities to gather data not only from Tally database, but also from external sources using ODBC, DLLs and HTT P .
Based on the source of data, the collections are referred to as Exter n al c o llecti o n, ODBC co l lecti o n, HTTP XML collection and Aggregate/summary collection.
In cases where a collection contains objects from Tally database, it is referred to as an Internal Collection. In the collection of internal objects, the attributes used are Type, Child Of, Belongs To.
The collection of static TDL objects are referred to as an External Collection. The attribute used to create an external collection is Object .
The Data Objects populated in the collection are from an external database using ODBC. The attributes used are ODBC, SQL, SQL Objects, SQL Parms and SQL Values.
The Objects of this collection are obtained from the XML file using HTTP. The file can be made available either on the local machine or on the remote server. The attributes used in creating an XML collections are ‘Remote URL’, ‘Remote Request’, ‘XML Object Path’ and ‘XML Object’.
A collection can be populated with objects obtained by executing a DLL file. The DLL’s can be written using an external application to extend the existing functionality of Tally. This allows the users to extend the kernel capability by adding their own functions.
External Plug-Ins are written as DLL’s and can be of two types:
● C++ DLL’s
● ActiveX DLL’s
In order to create the Collection that calls an external PlugIn the following attributes are used. Values can be passed to the DLL’s as parameters.
Syntax
[Collection : My DLL Collection]
Plug-In : <path to dll>.<pInput param>
ActiveX Plug-In : <Project Name>.<Class Name>.<pInput param>
The value returned by executing the DLL will be available as objects in the collection.
TDL provides a set of attributes to create a collection and populate it with objects obtained from various data sources. The set of attributes used in the collection is based on the data source as mentioned in the section Sources of Collections. This section describes the attributes used in the creation of an internal and external collection. Creating collections from various data sources will be explained later.
To create a collection of internal objects, the attribute ‘Type’ is used. It accepts object type name as the value. The collection definition for creating an internal collection has the following syntax.
Syntax
[Collection : <Collection Name>]
Type : <Object Type>
Where,
< Collection Name > is a user defined name for the collection.
< Object Type > is the name of any of the internal objects, For example, Group, StockItem, Voucher, etc.
This attribute is used to define a collection of a particular Type or Subtype. This attribute can take values of the default TDL objects as well as the user defined fields (UDF).
Syntax
Type : <ObjectType> [: <ParentType>]
Where,
< Object Type > is the name of the object type or its sub-type.
< Parent Type > is optional and is required if the subtype is to be specified.
Example
[Collection : My Collection]
Type : Ledger
The collection My Collection consists of a collection of Ledgers which is an Internal object.
To create a collection of Static TDL objects the attribute used is Object. The collection definition for creating external collection has the following syntax:
Syntax
[Collection : <Collection Name>]
Object : <Object Name>, <Object Name>, ……., <Object Name>
Where,
< Collection Name > is the user defined name for the collection.
< Object Name > are the names of user-defined objects.
Attribute – Object
The attribute Object is used to create a collection of user-defined objects. A collection can have multiple collections/objects in it.
Syntax
Object : <List of Objects>
Where,
< List of Objects > is a comma-separated list of objects.
Here, the objects are defined using the Object definition, as shown in the following example.
Example
[Collection : Emp]
Object : E mp1, Emp2
[Object : E mp1]
EmpName : " Ram Kumar"
Age : "25"
[Object : E mp2]
EmpName : " Krishna Yadav"
Age : "30"
The Objects of Collection ‘Emp’ has the Methods ‘EmpName’ and ‘Age’.
In TDL, methods are used to retrieve data from Objects and Collections. The following section explains the Usage and Types of methods.
Object Association is the process of linking an Interface Object with one or more Data Objects. Each Interface Object must be in the context of a Data Object. A TDL programmer can associate an Interface Object with any Data Object. If a Interface object is not explicitly associated with any Data Object, then Anonymous Object is associated to it. Anonymous Object is a Primary data Object provided by platform. It has no methods, sub-collections, or parameters.
Object Association can be done at the following levels:
● Report Level Association
● Part Level Association
● Line Level Association
● Field Level Association
Once an Object is associated at the Top level, the child level Interface Objects inherit it, unless it is explicitly overridden. If there is no explicit association of the Data Object at the Report level, it is associated with the Anonymous Object.
A Report is normally associated with a data object, which it gets from the previous Report and if not, will be associated with the anonymous object. From Release 3.0 onwards, the syntax for association has been enhanced to override the default association as well. The Report attribute ‘Object’ has been enhanced to take an additional optional value as ‘Object Identifier Formula’.
Syntax
Object : <ObjectType> [: <ObjectIdentifierFormula>]
Where,
< ObjectType > is a Type of Primary Object.
< ObjectIdentifierFormula > is an optional value and refers to any formula which evaluates the name of Primary Object.
Example 1: Without the Object Identifier
[#Form : Sales Color]
Delete : Print
Add : Print : New Sales Format
[Report : New Sales Format]
Object : Voucher
Default Sales Color Form is modified to have a new print format ‘New Sales Format’. This Report gets the voucher object from the previous Report.
Example 2: With the Object Identifier
[Report: Sample Report]
Object : Ledger : “Cash”
The Ledger ‘Cash’ is associated to the Report ‘Sample Report’. Now components of a ‘Sample Report’ by default, inherit this ledger object association.
Part inherits the Object from the Report/Part/Line, by default. This can be overridden in two ways.
The syntax of an Object attribute at the part level is as follows:
Syntax
Object : <SupplierCollection> : <SeekTypeKeyword> [: <SeekCondition>]
Where,
< SupplierCollection > is the name of the Collection of Secondary Objects.
< SeekTypeKeyword > can be First or Last, which denotes the position index.
< SeekCondition > is an optional value, and is a filter condition to the Supplier collection.
Example: Part in the Context of Voucher Object
[Part : Sample Part]
Line : Sample Line
Object : InventoryEntries:First:@@StkNameFilter
Scroll : Vertical
[System : Formula]
StkNameFilter : $StockItemName = "Tally Developer”
The first inventory entry having stock item “Tally Developer” is associated with Part ‘Sample Part’.Only sub-objects can be associated at part level for which the primary object is associated at the Report level. To overcome this limitation a new attribute ‘Object Ex’ is introduced at part level in release 3.0.
The attribute ‘Object Ex’ provides the ease of using enhanced method formula syntax, while specifying the object association. Now even the Primary Object can be associated to a Part, which was not possible with the Object attribute of ‘Part’ Definition.
Syntax
Object Ex : <Method Formula Syntax>
Where,
< Method formula syntax > is, <Absolute Specification>.[<Sub Object Specification>]
<Absolute Specification> is (<Object Type>, <Object Identifier Formula>). If only Absolute Spec. is given, then it should end with dot (‘.’).
<Sub Object Specification> is CollectionName[Index,<Condition>]
Example : 1
[Part: Sample Part]
Object Ex : (Ledger,"Customer")
The Ledger object “Customer 1” is associated to the Part ‘Sample Part’. Since only the absolute specification used, the Object specification is ends with ‘.’
Example : 2
[Part : Sam p le Part]
Object Ex : (Ledger,"Customer") . BillAllocations[1, @ @Condition1]
[System : F o rmula]
Condition1 : $Name = "Bills 2"
The Secondary Object ‘Bill Allocation’ is associated with the Part ‘Sample Part’.
The Data Object associated to some other Interface Object can also be associated to a Part. This aspect will be elaborated in the section ‘Object Access via UI Object’ of the Enhancement training. The enhanced method formula syntax is discussed in detail under the section ‘Accessing Methods’.
An object can be associated to a Line by Part attribute ‘Repeat’. Now, the Part attribute ‘Repeat’ is enhanced to support the following.
● Extraction of collection from any Data object.
● Extraction of collection from UI Object associated Data object. This aspect will be elaborated in the section “Object Access via UI Object”.
Syntax
Repeat : <Line Name> : <Coll Name> : [<Supplier Coll> : <SeekTypeKeyword> : <SeekCondition>]
Where,
< Coll Name > is the name of the Collection. If the Collection is present in one level down of the object hierarchy, then Supplier Collection needs to be mentioned.
< SupplierCollection > is the name of the Collection of secondary Objects.
< SeekTypeKeyword > can either be First or Last which denotes the position index.
< SeekCondition > is an optional value and is a filter condition to the supplier collection.
Example: Part in the context of V oucher Object
[Part : Sample Part]
Line : Sample Line
Repeat : Sample Line: Bill Allocations: Ledger Entries: First: @@LedFormula
[System : Formula]
LedFormula : $LedgerName = “Customer”
The Line ‘Sample Line’ is repeated over Bill Allocations of first Object ‘Ledger entries’, which satisfies the given condition.
Instead of specifying the <Coll Name>:[<Supplier Coll>:<SeekTypeKeyword>: <SeekCondition>], the new method formula syntax can be used as follows:
Syntax
Repeat : <Line Name> : <MethodFormulaSyntax>
Where,
< MethodFormulaSyntax > is <Absolute Spec>.<SubObjectSpec>
<Absolute Spec> is (<Object Type>, <Object Identifier Formula>)
<Sub Object Spec> is CollectionName[Index,<Condition>]
Example
[Part : Sample Part]
Line : Sample Line
Repeat : Sample Line : (Ledger, “Customer”).BillAllocations
The Line ‘Sample Line’ is repeated over Bill Allocations of Object Ledger for Customer ledger.
By default, it is inherited from the Parent line or Field (if field is inside a field). This cannot be overridden. However Field also allows Object Specification syntax. This association, if specified, acts as the ‘Secondary Context Object’ for the Field. During any formula evaluation, if the formula/method fails in the context of the Primary Object, the Secondary Object is tried then.
Each piece of information stored in the data object can be retrieved using a method. A method either performs some operation on the object, or retrieves a value from it. To retrieve the value from database, the storage name is prefixed with $ symbol. TDL provides pre-defined methods and allows the user to create methods as well. Methods are classified as Internal or External.
The methods which are defined by the platform are called as Internal Methods. For example, the methods Name, Address and Parent are the internal Methods of Object ‘Ledger’.
A user can change the behaviour or perform an action on the internal object by defining new Methods. Methods defined by the user are referred to as External/User-defined methods. For example., a method ‘DiffBal’ can be created for an Object ‘Ledger’, which gives the difference of the total debit amount and total credit amount.
Methods of an object can be accessed in TDL in three different ways, based on the object context.
Incase you are already in the object context, use the Method name prefixed with $ directly.
Syntax
$<MethodName>
Where,
< Method Name > is the name of the Method of the object in context.
Example
$CompanyName
In cases where the user is not in the object context, or is in a different object context then following syntax may be used:
Syntax
$<Method Name> : <Object Name>:<formula>
Where,
< Method Name > is the name of the Method, which belongs to the Object.
< Object Name > is the name of the Object.
< Formula > is the value, based on which, the Method value is retrieved.
Example
$Name : Ledg e r : ##SVLedgerName
In cases where the user is not in the object context, or in a different object context, the following syntax may be used:
Syntax
$<Method Name> : < Collection Name> : <Seek Type>
Where,
< Method Name > is the name of the Method which belongs to the Collection.
< Collection Name > is the name of the Collection.
< Seek Type > is the searching direction. It can either be First or Last.
Example
$LedgerName : LedgerEntries:First
The Method formula syntax allows direct access to any object Method, including its sub-collections to any level, with a dotted notation framework.The values from any object anywhere can be accessed, without making the object as the current object. This syntax is introduced to support access out of the scope of the Primary Object and to access the Sub object at any level using (.) dotted notation, with index and condition support.
Syntax
$<PrimaryObjectSpec>.<SubObjectPathSpec>.MethodName
Where,
< Primary Object Spec > can be (<Primary Object Type Keyword>, <Primary Object Identifier Formula>)
< SubObjectPathSpec > is given as the Collection Name [<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 matching the given <condition>
Example: Assuming that the Voucher is the current object
1. To get the Ledger Name of the first Ledger Entry from the current Voucher:
Set As : $LedgerEntries[1].LedgerName
2. To get the amount of the first Ledger Entry on the Ledger Sales from the current voucher (Sales Invoice):
Set As : $LedgerEntries[1,@@LedgerCondition].Amount
LedgerCondition : $LedgerName = “Sales”
3. To get the first Bill Name of the first Ledger entry on the Party Ledger from the current voucher (Sales Invoice):
Set As : $LedgerEntries[1,@@LedgerCondition].BillAllocaions[1].Name
LedgerCondition : $LedgerName = @@InvPartyName
4. To get the Opening Balance of the first Bill for the Party Ledger Acme Corp:
Set As : $(Ledger,@@PartyLedger).BillAllocations[1].OpeningBalance
PartyLedger : “Acme Corp”
The Primary Object specification is optional. If it is not specified, the current object will be considered as the Primary Object. A Sub-Collection specification is optional. If not specified, Methods from the current or specified primary object will be made available. The Index specifies the position of the Sub-Object to be picked up from the Sub-Collection. This Condition is ‘Filter’ which is checked on the objec t s of the specified Sub-Collection .
< Primary Object Identifier Formula >, < Index Formula > and Condition can be a value or formula.
The Index Formula can be any formula evaluating to a number. The Positive Number indicates a forward search while a negative number indicates a backward search. This can also be a keyword First or Last , which is equivalent to specifying 1 or - 1 respectively.
In cases where both the Index and Condition are specified, the index is applicable on the Object(s) which satisfies the condition so that one gets the nth Object which clears the condition. Let’s say for example, if the Index specified is 2 and Condition is Name = ‘Sales’, then the second object which matches the name ‘Sales’, will be picked up.
The Primary Object Path Specification can either be Relative or Absolute. A Relative Path is referred to by using empty parenthesis () or a dotted path to refer to the Parent object relatively. A SINGLE DOT denotes the current object, DOUBLE DOT the Parent Object, TRIPLE DOT the Grand Parent Object, and so on, within an Internal Object. The Absolute Path refers to the path in which the Primary Object is explicitly specified.
To access the Methods of Primary Object using a Relative Path, the following syntax is used.
Syntax
$().<MethodName> or $..<MethodName> or $…<MethodName>
Example
With regard to the context of LedgerEntries Object within Voucher Object, the following have to be written to access the Date from its Parent Object which is the Voucher Object.
$..Date
To access the Methods of Primary Object using the Absolute Path:
Example
$(Ledger, “Cash”).OpeningBalance
Having understood the concept of Objects, Collection, Methods and Object association, let us now concentrate on understanding the concept of Collection as a Data Processing Artefact in TDL.
In previous sections, we saw that a Collection can contain objects from Tally Database or populate objects from external data sources as well. In further sections, we will discuss the capabilities of collection from the data processing perspective. Let’s segregate the capabilities into:
● Bas i c Ca p abilities
o Union
o Filtering
o Sorting
o Searching
● Adv a nced Ca p abilities
o Extraction
o Aggregation
o Usage As Tables
o Integration Capabilities using HTTP XML Collection
o Dynamic Object Support
o Collection Capabilities for Remoting
We will be covering the Basic capabilities in detail with all the relevant attributes and functions for achieving the same. Some portions of Advanced capabilities which were available prior to Tally.ERP 9 will be covered here. The latest developments pertaining to this, will be covered in our training program ‘TDL Enhancements for Tally.ERP 9’.
‘Union’ refers to creation of a Collection by combining multiple Collections. The total number of objects in the resultant Collection will be the sum of objects in all the Collections. The following figure shows a Collection of sub-collections, which can further be unions of collections, and so on.
.jpg)
This example shows that Collection C1 contains Collection C2 and Collection C3. Likewise, Collection C2 further contains Collection C4 and Collection C5. The attribute Collection is used to create a Union as follows:
The attribute ‘Collection’ is used to specify a Collection under the main Collection. All the objects belonging to the Sub collections are available in the resultant Collection.
Syntax
Collection : <List of Collections>
Where,
<List of Collections> is a comma-separated list of collections. The Collections that are used can be of different types.
Example
[Collection : Groupandledger]
Collections : Group, Ledger
Here, the collections ‘Group’ and ‘Ledger’ are used, under the main collection GroupandLedger.
If it is required to retrieve only a specific set of objects from a Collection, then the collection needs to be filtered. Filtering is applied on the Collection, based on a condition. All the objects which satisfy the given condition are retrieved and are available in the Collection.
The attributes used for applying a filter are ChildOf , BelongsTo and Filter .
Attribute - Child Of
The ChildOf attribute helps to control the display of the contents of a collection. It retrieves only those objects whose direct parent is the string specified as the parameter of this attribute.
Syntax
ChildOf : <String Formula>
Example
[Collection : My Collection]
Type : Ledger
ChildOf : "Sundry Debtors"
It will return all the ledgers grouped directly under the group ‘Sundry Debtors’. The following definition code will return all the ledgers under the group blank. By default, Tally returns the ledger ‘Profit and Loss’.
ChildOf : ""
Attribute - BelongsTo
The attribute ‘Belongs To’ is used along with the ‘Child Of’ attribute. This attribute determines whether to retrieve the first level of objects under the value specified in ‘ChildOf’, or include all the objects upto the lowermost level. ‘Belongs To’ takes a logical value.
Syntax
BelongsTo : <Logical Value>
Where,
< Logical Value > can be either YES or NO .
Example
Consider the previous example of accounts. The following code is an extension of that code.’
[Collection : My Collection]
Type : Ledger
ChildOf : "Sundry Debtors"
BelongsTo : Yes
This code will retrieve all the objects directly under the group ‘Sundry Debtors’, as well as all the objects which are under the sub groups of ‘Sundry Debtors’.
Attribute - Filter
The attribute ‘Filter’ is used to specify the condition for filtering the objects. The ‘Filter’ attribute takes a system formula. The condition is specified in the formula. If more than one filter has to be specified, they can be separated by comma.
Syntax
Filter : <FilterName>
Where,
< Filter Name > is the name of the Global formula.
Example
[Collection : LtdDebtors]
Type : Ledgers
ChildOf : “Sundry Debtors”
Filter : NameFilter
[System : Formula]
NameFilter : $Name contains "Ltd" OR $Name contains "Limited"
The filter Namefilter is used to fetch only those objects, whose name contains the string “Ltd” or “Limited”.
Function - $$FilterAmtTotal
It is used to get the sum of values returned by the specified filter expression, when applied to all the Objects in the Collection that satisfy the expression. The value returned is of type Amount.
Syntax
$$FilterAmtTotal:<CollectionName>:<FilterExpression>:<ValueExpression>
Where,
< CollectionName > is the name of a Collection,
< FilterExpression > is a System Formula.
< FilterExpression > is evaluated for each Object. The resultant Objects that clear the filter are selected for further processing.
< ValueExpression > is any valid expression, which is to be evaluated on each Object of the Collection.
Example
$$FilterAmtTotal:AllLedgerEntries:CashBankEntries:$Amount
[System : Formula]
CashBankEntries : $$IsCashLedger:$LedgerName AND $$IsDr:$Amount
The filter in the example checks whether the ledger is a Cash Ledger and the amount is of the type ‘Debit’. $$IsCashLedger is a logical Function, which checks whether the argument passed is a Cash Ledger or not. This statement can be evaluated only in the context of a Voucher Object.
Function - $$FilterQtyTotal
It is similar to $$ FilterAmtTotal , except that the Value Expression should evaluate to type Quantity.
Syntax
$$FilterQtyTotal:<CollectionName>:<FilterExpression>:<ValueExpression>
Where,
< CollectionName > is the name of Collection
< FilterExpression > is a System Formula.The Filter Expression is evaluated for each Object, and the resultant Objects that clear the filter are selected for further processing.
< ValueExpression > is any valid expression, which is to be evaluated on each Object of the Collection.
Function - $$FilterCount
The function $$FilterCount is used to get the total number of Objects in a Collection, after the filters are applied.
Syntax
$$FilterCount : <CollectionName> : <FilterExpression>
Where,
< CollectionName > is the name of a Collection.
< FilterExpression > is a System Formula.
Example
$$FilterCount:AllLedgerEntries:HasBankEntry > 0
[System : Formula]
HasBankEntry :($$IsDr:$Amount!=$IsDeemedPositive:VoucherType:$VoucherTypeName)+
AND($$IsLedOfGrp:$LedgerName:$$GroupBank OR $$IsLedOfGrp:$LedgerName:$$GroupBankOD)
It confirms whether the voucher has any Ledger under the Group Bank or BankOD .
Note : The function $$FilterCount will not work at menu level.
$$ IsLedOfGrp accepts two parameters and returns TRUE if parameter 1 is a ledger of a Group mentioned in parameter 2. GroupBankOD and GroupBank are functions which return the name of the reserved groups Bank OD and Bank.
Function - $$FilterValue
This function is used to get the value of a specific expression, based on the position specified in the set of objects filtered by the expression.
Syntax
$$FilterValue : <ValueExpression> : <CollectionName> : <PositionSpecifier> : <FilterExpression>
Where,
< CollectionName > is the name of the Collection.
< FilterExpression > is the filter applied to get a set of filtered Objects.
< PositionSpecifier > denotes the position.
< ValueExpression > is any valid expression to be evaluated on each Object of the Collection.
Example
$$FilterValue:$LedgerName:LedgerEntries:First:IsPartyLedger
This example filters all the objects within LedgerEntries to satisfy the filter condition IsPartyLedger and returns the first value of the requested method LedgerName that satisfies the condition.
Function - $$GroupSundryDebtors
It returns the name of the group ‘Sundry Debtor’, even if the user renames it.
Syntax
$$GroupSundryDebtors
Example
[Collection : Sample Coll]
Type : Ledgers
Child Of : $$GroupSundryDebtors
This will populate the collection Sample Coll with all objects under the Group ‘Sundry Debtors’. In case the user has renamed the group “Sundry Debtors” as “My Sundry Debtors”, the following code snippet won’t have any objects in the collection.
[Collection : Sample Coll1]
Type : Ledgers
Child Of : “Sundry Debtors”
But in this case, $$ GroupSundryDebtors will populate the collection with all the objects that are under the Group ‘Sundry Debtor’ even if the user renames the group.
Function - $$GroupSundryCreditors
It returns the name of the group ‘Sundry Creditors’, even if the user renames it.
Syntax
$$GroupSundryCreditors
Example
[Collection : Sample Coll]
Type : Ledgers
Child Of : $$GroupSundryCreditors
This will populate the collection Sample Coll with all objects under the Group ‘Sundry Creditors’. In case the user has renamed the group “Sundry Debtor” as “My Sundry Debtors”, the following code snippet won’t have any objects in the collection.
[Collection : Sample Coll1]
Type : Ledgers
Child Of : “Sundry Creditors”
But in this case, $$GroupSundryCreditor will populate the collection with all the objects that are under the Group “Sundry Creditors”, even if the user renames the group.
Sorting refers to the arrangement of objects in a specific order within the collection. The ordering is done on the basis of a specific method and the sort order can either be ascending or descending. The attribute Sort is used for this purpose.
Attribute - Sort
A collection can be sorted by specifying the sort sequence using the ‘Sort’ attribute. The collection can be sorted by a combination of fields in ascending as well as in descending order.
Syntax
Sort : < Sort Name> : <List of Methods>
Where,
< List Of Methods > is a comma separated list of methods. Sorting is done based on values of methods. The default sort order is ascending. Prefix Methods name with ‘-’, for descending order.
Example
[Collection : My Collection]
Collections : MyLedger
Sort : Default : $ClosingBalance, $Name
Collection capabilities have been enhanced to enable the indexing of objects based on a particular method. Whenever a collection is indexed on a particular method, it allows instant access to the corresponding values without the need for a complete scan.
Syntax
Search Key : < Combination of Method name/s>
This implies that a unique key is created for every object which can be used to instantly access the corresponding objects and its values. The function which is used to retrieve the values from a collection based on the key specified is $$ CollectionFieldByKey .
Function - $$CollectionFieldByKey
Syntax
$$CollectionFieldByKey : <Method Name> : <Key Formula> : <Collection Name>
Where,
< Method Name > is the name of the method.
< Key Formula > is a formula that can be mapped to the methods defined in the search key exactly in the same order.
Example
[Collection: My Ledgers]
Type : Ledger
Search Key : $Name
[Field : My Closing Bal Field]
Set as : $$CollectionFieldByKey:$ClosingBalance:@MySearchKey:My Ledgers
MySearchKey : #LedName
Here, a search key is defined on $ name for collection MyLedgers . In the Field, value $Closing Balance is retrieved based on ledger name. In this case, retrieval is faster than ordinary retrieval.
This capability is quite useful in case of matrix reports, i.e., when two or more dimensions need to be represented as rows and columns. In such a case, defining the search key on a method combination, and using $$ CollectionFieldByKey for value retrieval improves performance. The usage and examples based on the explanation above will be covered in detail in our training program “TDL Enhancements for Tally.ERP 9”.
Note : The function $$CollectionFieldByKey will not work at menu level
The Collection capabilities have been enhanced to extract information from the collection using other collections, including its sub-objects, with the choice of method (s), filter(s) and sort-order. Specific attributes have been added at the collection level to achieve the same.
Prior to Tally.ERP 9, extraction was possible using specific function $$CollectionField.
This is used to get the value of a specified expression as applied on the nth Object of a Collection.
Syntax
$$CollectionField:<ValueExpression>:<PositionNumber>:<CollectionName>
Where,
< CollectionName > is the name of a collection.
< ValueExpression > is any valid expression to be evaluated on the element at position < PositionNumber > in the collection.
Example
$$CollectionField:$Amount:1:AllLedgerEntries
It returns the first value of the Method Amount from AllLedgerEntries Object.
This function affects the performance of the report in terms of time taken to display the report. A detailed discussion on the enhancements for extraction, chaining and reuse will be covered in the training program “TDL Enhancements for Tally.ERP 9.”
Note : The function $$CollectionField will not work at menu level
A major technological advancement in this release of Tally.ERP 9 is “Data Roll up in TDL Collection – GROUP BY”, which is a part of the TDL language capabilities. This is a milestone achievement over the past 10 years. This will now facilitate the creation of large summary tables of aggregations in a single shot, using the new attributes of the Collection description. This allows us to Walk down the object hierarchies and gather values to summarizes them in one scan. Overall, it reduces the TDL code complexity, resource requirement and increases performance drastically in case of reports generated using this new capability.
The attributes used for extraction, chaining, and aggregation and grouping are Walk, By, Fetch, Compute, AggrCompute. A detailed discussion on enhancements for aggregation and Grouping using the new attributes will be covered in training program “TDL Enhancements for Tally.ERP 9.”
Prior to Tally.ERP 9, the totals were generated using the Total and aggregation functions like CollAmtTotal or FilterAmtTotal on collections. These have certain advantages and disadvantages. While they provide excellent granularity and control, each call is largely an independent activity to gather the data set and then aggregate it. This significantly affects the performance of the reports.
Let us now discuss the various functions which are available for summarization and aggregation.
This function is used to get the sum of values of Type Amount returned by a specified expression when applied to all Objects in a given Collection. The return value is of type Amount.
Syntax
$$CollAmtTotal : <CollectionName> : <ValueExpression>
Where,
< CollectionName > is the name of a Collection.
< ValueExpression > is any valid TDL expression to be evaluated on each Object of Collection.
Example
$$CollAmtTotal:LedgerEntries:$Amount
It gets the sum of values in the Method Amount after it is applied on each Object in the Collection LedgerEntries . This statement will hold good only when one is in the context of Voucher Object.
This function is used to get the sum of values of Type Quantity returned by the specified expression when applied to all Objects in a given Collection. The value returned is of Type Quantity.
Syntax
$$CollQtyTotal : <CollectionName> : <ValueExpression>
Where,
< CollectionName > is the name of a Collection
< ValueExpression > is any valid TDL expression to be evaluated on each Object of Collection.
Example
$$CollQtyTotal:InventoryEntries:$BilledQty
Each Inventory entry in the current Voucher Object is picked up and the Method BilledQty is evaluated on it. The resultant quantity is summed up to get the result.
This function is used to get the sum of values of Type Number returned by the specified expression, when applied to all Objects in a given Collection. The value returned is of the Type Number .
Syntax
$$CollNumTotal : <CollectionName> : <ValueExpression>
Where,
< CollectionName > is the name of a Collection.
< ValueExpression > is any valid expression to be evaluated on each Object of the Collection.
Example
$$CollNumTotal:InventoryEntries:$Height
Each Inventory entry in the current Voucher Object is picked up and the Method Height evaluated on it. The resultant height is summed up to get the result. Here, Height is an external Method of Object Inventory Entry in a Voucher.
TDL allows to display the values obtained from the collection as a pop-up table. Earlier, the values of voucher and the ODBC data couldn’t be displayed as a collection. Now, all limitations pertaining to usage of Collections as Tables have been completely eliminated. Any collection which can be created in TDL, can be displayed as a table now. Collection with aggregation and XML Collections can also be used as Tables.
The Collection capability has been enhanced to gather live data from HTTP/web-service delivering XML. The entire XML is automatically now converted to TDL objects and is available natively in TDL reports as $ based methods. Reports can be shown live from an HTTP server. The attributes in collection for gathering XML based data from a remote server over HTTP are RemoteURL, RemoteRequest, XMLObjectPath, and XMLObject.
When a collection is used for editing (alter/create), objects are dynamically added to the collection when a new line is repeated over the same. The type of object which is added depends on the specification in the TYPE attribute. In case the TYPE attribute is not specified, it defaults to adding a standard empty object.
However, the following holds true for a COLLECTION keeping in mind the latest enhancements:
● It can be made up of multiple types of objects (say Ledgers and Groups).
● It can have TDL defined objects which are retrieved from XML file.They are specified using XML Object.
● It can have aggregated objects.
Depending solely on the TYPE attribute to make a decision, the object type is a constraint with respect to the above facts. This is now being removed with the introduction of a new attribute which will independently govern the type of object to be added to the collection on-the-fly. The following is now supported in a collection.
NEWOBJECT : type-of-object : condition
A detailed discussion on the subject can be accessed from our training program “TDL Enhancements for Tally.ERP 9”.
Enabling access to your organizational data ‘any-time, any-where’, and yet being truly usable, is what Tally.ERP 9 delivers. With remote access through Tally.NET Server, it will be possible for any authorized user to access Tally.ERP 9 from anywhere.
Major Enhancements have taken place at the collection level to achieve remoting capabilities.The attributes Fetch, Compute and AggrCompute provided at the Collection level, and FetchObject and FetchCollection at the Report level significantly help in above functionality.
When you integrate Tally.ERP 9 with a third-party application, the communication can happen in a connected or non-connected environment where Tally.ERP 9 can act as a client or server or both.
In a connected environment, when communication happens over a network, Tally.ERP 9 can send GET or POST request to third-party applications and gather responses using collection capabilities. A GET request is always without a request body while a POST request has a request body. In both the cases, the request can have HTTP headers as required by the third-party and the HTTP standards.
To support this requirement collection is enhanced with a new attribute, Export Header , to specify the HTTP headers when you send requests to HTTP servers.
Syntax
[Collection: <Collection Name>]
Export Header : <String Expression>
Where,
<Collection Name> - the name of the collection where the data is populated.
<String Expression> - a valid expression that evaluates to a string.
A GET request sent to a server can have HTTP headers. It will not have any request body.
To send a GET request to a server with HTTP headers, specify the server URL in the collection attribute, Remote URL or the data source HTTP JSON or HTTP XML and the headers with the attribute Export Header . The choice of the attribute for URL specification depends on the format of data exchange.
Syntax
[Collection: <Collection Name>]
Export Header: <String Expression>
Remote URL : <Target URL>
OR
Data Source : HTTP JSON : <Target URL> [: <Encoding>]
OR
Data Source HTTP XML : <Target URL>
[: <Encoding>]
Where,
<Collection Name> - the name of the collection where the data is populated.
<Target URL> - the URL to which the request is to be sent.
<Encoding> - can be ASCII, UNICODE, UNICODE8, UTF8, or UTF16. It is applicable for the data source types File XML, HTTP XML, File JSON, HTTP JSON. The default value is UTF16.
A POST request is sent to a server with request body and HTTP headers, where the headers are optional.
To send a POST request to a server with HTTP headers, specify the server URL in the collection attribute, Remote URL or the data source HTTP JSON or HTTP XML and the headers with the collection and report attribute Export Header . To construct the request body use the attribute Request Report . When you specify the headers in both collection and the request report (using Export Header ), both the headers will be considered. The choice of the attribute for URL specification depends on the format of data exchange.
[Collection: <Collection Name>]
Export Header : <String Expression>
Remote Request : <Request Report> [: <Encoding>]
Remote URL : <Target URL>
OR
Data Source : HTTP JSON : <Target URL> [: <Encoding>]
OR
Data Source : HTTP XML : <Target URL> [: <Encoding>]
When you use the attribute Export Header you can observe the following:
● When multiple collections are used, like summary collection or union collection , specify the attribute Export Header in the collection where the attribute Data source is mentioned.
● In the case of POST request, the headers specified at collection and report levels will be part of the request sent. The order of adding headers in the request is first from the collection and then from the report.
● The attribute Export Header is applicable only when an HTTP source is specified using the attribute Remote URL or data sources like HTTP JSON or HTTP XML.
Example
Case 1 : Send a GET request with HTTP headers and receive the response
The HTTP header " Accept:application/json " is sent to the server, in order to receive the response in JSON format. Data source type HTTP JSON is used to exchange the data in JSON format.
[Collection: TSPL Get Employees JSON]
Export Header : "Accept:application/json"
Data Source : HTTP JSON: " http://localhost/ExportHeader/getempdetails.php " :UTF8
|
Request Sent |
Response Received |
|
Accept: application/json |
{ "employees": {"employee": [ { "Name": "John Smith" }, { "Name": "Jessica Jones" } ] } } |
Case 2: Send a POST request with HTTP headers and receive the response
In the request, Accept:application/xml , Emp Id as HTTP header and Leave Type as body are sent to the server to receive the response in XML format for the selected employee and the leave type. Data source type HTTP XML is used to exchange data in the XML format.
[Collection: TSPLLeaveSummaryXML]
Data Source : HTTP XML: " http://localhost/ExportHeader/getleavedetails.php "
Export Header : "Accept:application/xml"
Export Header : "EmpId:5989"
RemoteRequest : TSPL Leave Request: UTF8
XML Object Path: "LeaveInfo:1:Envelope:LeaveDetails:1"
The request report, TSPL Leave Request is used to construct the request body.
|
Request Sent |
Response Received |
|
Accept: application/xml EmpId : 5989 <Request> <LeaveType> Earned Leave </LeaveType> </Request> |
<Envelope> <LeaveDetails> <Employee> Vamsi </Employee> <EmpId>5989</EmpId> <Gender>Female</Gender> <LeaveInfo> <Type>Earned Leave</Type> <Entitled>24</Entitled> <Availed>10</Availed> </LeaveInfo> </LeaveDetails> </Envelope> |
Learning Outcome
● An object is a self-contained entity that consists of both data and procedures to manipulate the data.
● Objects are stored in a database.
● Tally data base is hierarchical in nature in which the objects are stored in a tree-like structure.
● Everything in TDL is an Object.
● Objects used for designing the User Interface are referred to as interface objects.
● Data is actually stored in the Data Objects. Data objects are classified into two types namely Internal objects and User defined/TDL Objects.
● A collection can be a collection of objects or a collection of collections.
● Collection, the data processing artefact of TDL provides extensive capabilities to gather data, not only from the Tally database, but also from external sources using ODBC, DLLs and HTTP.
● In TDL, Object association can be done at the following levels:
o Report Level Association
o Part Level Association
o Line Level Association
o Field Level Association
● Each piece of information stored in a data object can be retrieved using a method. Methods are classified as internal or external methods.
● Union, Filtering, Sorting and Searching are the basic capabilities of collection.
● Extraction, Aggregation, Usage As Tables, Integration Capabilities using HTTP XML Collection, Dynamic Object Support and Collection Capabilities for Remoting are the advanced capabilities of collection.