In Tally.ERP 9, major changes have been provided by the platform to enhance the TDL capabilities to help the programmer to develop and deploy solutions with ease. Major improvements have taken place in terms of language usage standardisation and performance improvements.
There have been breakthrough enhancements at Collection level to provide Remoting and Advanced Reporting capabilities. Collection is now a complete Data Processing Artefact in TDL.
This chapter provides in depth knowledge of the various enhancements in attributes, modifiers, method formula syntax and symbol prefixes. The foremost focus is towards the enhancements at the collection level for providing the capabilities for aggregation, usage as tables, XML collection and dynamic object creation support for HTTP-XML based information interchange.
Watch the below video to know more about the Collection Capabilities.
Watch the below video to know more about Object Context Switching Function.
In Tally.ERP 9, new attributes and modifiers have been introduced to support the new capabilities. The behaviour of some of the existing attributes and modifiers has also changed.
New attributes that have been introduced are explained in this section.
The attribute Set By Condition is similar to a conditional Set at Field level. If multiple Set By Condition are mentioned under a Field, then the last satisfied Set By Condition will be executed.
Syntax
Set By Condition : <Condition> : <Value>
Where,
< Condition > is any logical formula.
< Value > is any string or a formula.
Example:
[Field : Sample SetbyCondition]
Set as : “Default Value”
SetbyCondition : ##Condition1 : "Set by Condition 1"
The Field Sample SetbyCondition will contain the value Set by Condition1 if the expression Condition1 returns TRUE, else the Field will contain the value Default Value.
As the name suggests, the value specified with this attribute is displayed when the mouse pointer is placed on a particular field. This means that, in addition to the static information displayed by Info or Set As attributes, we can provide additional meaningful information using this attribute.
In other words, when the user hovers the mouse pointer over the Field, a small hover box appears with supplementary information regarding the item being pointed over. As against attributes Info or Set As , this attribute value is independent of the Field Width.
Syntax
Tool Tip : <Value>
Where,
< Value > can be a String or a Formula.
Example:
[Field : Led Name]
Storage : Name
Tool Tip : “Please Enter the Name of the Ledger”
It helps to control the display of command window/calculator pane. It is a logical type of attribute.
Syntax
Full Screen : Yes/No
If it is set to YES, the command window will be hidden, providing extra space when the report is displayed. The default value of this attribute is YES. In case of Sub-Report/AutoReport, if the value of this attribute is not specified, the default value is NO.
Example:
[Report: My Report]
Full Screen : Yes
It indicates that the part should retain information about the line which is currently in focus, even if the focus is moved to other part. This allows the part to make the same line as the current line when it gets back the focus.
Syntax
Retain Focus : Yes/No
Example:
[Part : LedPart]
Retain Focus : Yes
It is used to highlight the appropriate line which satisfies the given condition. All the methods of the object associated with the line can be used while specifying the condition.
Syntax
Default Line : <Condition>
When the Report is invoked, the Line for which the condition is TRUE, is highlighted by default.
Example:
If the Line is repeated over the collection of Ledgers, then the following code will highlight the line of Cash Ledger.
[Part : The Main Part]
Default Line : $Name = “Cash”
Along with the Table title, sub titles for the columns can also be given. The attribute Sub Title has been introduced in the Collection definition for the same.
Syntax
Sub Title : <List of Comma Separated Strings>
Where,
< List of Comma Separated Strings > are Strings separated by comma, with respect to the number columns. Sub Title is a List type attribute.
Example:
[Collection : DebtorsLedTable]
Type : Ledger
Child Of : $$GroupSundryDebtors
Format : $Name, 15
Format : $OpeningBalance, 10
Title : $$LocaleString:"Table Sub-Titles"
Sub Title : $$LocaleString:"Name"
Sub Title : $$LocaleString:"Op.Balance"
It displays a table with two columns. Column titles are also displayed, using attribute Sub Title. Instead of using Sub Title attribute multiple times, a comma separated list can be given as follows:
Sub Title : $$LocaleString:"Name", $$LocaleString:"Op.Balance"
Enhancements have been done in the behaviour of the following attributes:
As of Release 2.x, the attributes ‘Set as’ and ‘Info’ were treated as the same attribute with aliases. When ‘Info’ was used, it had a special Skip and Prompt privilege. If both were specified, the last specification would override the previous specification and would be the effective specification.
Tally.ERP 9 onwards, this behaviour has been modified to treat both as individual attributes. When both these attributes are specified in a field, ‘Info’ takes precedence and ‘Set as’ is ignored.
When a collection is a union of collections, the ‘Format’ attribute in the collection behaves as a place holder for the columns. It is mandatory to specify ‘Format’ attribute in individual collections, when a collection is a union of collections.
Example:
[Collection : LedTable]
Collection : DebtorsLedTable, CreditorsLedTable
Format : A, 20
Format : B, 25
Here, A and B act as dummy identifiers, and the second parameter is width. The collections DebtorsLedTable and CreditorsLedTable are defined as follows:
[Collection : DebtorsLedTable]
Type : Ledger
Child Of : $$GroupSundryDebtors
Format : $Name, 15 Format : $StateName, 15
[Collection : CreditorsLedTable]
Type : Ledger
Child Of : $$GroupSundryCreditors
Format : $Name, 15
Format : $StateName, 15
It displays a table of two columns. The width of first column is 20 and of second column is 25.
The behaviour of the attribute Sync of Part definition is changed. The first line of next part is selected, as the default of Sync attribute is now set to NO. If the Part further contains parts, then the value of Sync attribute specified at Parent level overrides the value specified at child level.
Example:
[Part : Main Part]
Parts : SubPart1, SubPart 2
Sync : Yes
[Part : Sub Part 1]
Sync : No
[Part : Sub Part 2]
Sync : Yes
As a result of the default value of Sync attribute being set to NO, in the above code snippet, the Sync attribute finally has the value as YES.
Child Of attribute is enhanced further to support voucher type. Now, a collection of vouchers of a particular voucher type can be constructed. Prior to this release, the same could be achieved by applying Filters to the Collection. But, the enhanced approach will improve the performance. Further, the collection attribute Belongs To can be used in addition to Child of, to construct the Collection of Vouchers of a particular pre-defined voucher type, including related user-defined voucher types.
Syntax
[Collection : <Coll Name>]
Type : Vouchers : VoucherType
Childof : <String Form u la>
Belongs To : <Logical Val u e>
Where,
< Coll Name > is the name of the Collection.
< String Formula > can be a formula which results into the name of the Voucher Type
< Belongs To > is an optional attribute, which if used, takes <Logical Value>,i.e., YES or NO.
Example: 1
[Collection : Sales Vouchers]
Type : Voucher Type
Child of : $$VchTypeSales
Sales Vouchers is a collection of vouchers, whose voucher type is the predefined voucher type Sales .
Example: 2
[Collection : Sales Vouchers]
Type : Voucher Type
Child of : $$VchTypeSales
Belongs To : Yes
Sales Vouchers is a collection of vouchers, whose voucher type is pre-defined voucher type Sales, or any other user defined voucher type whose Type of Voucher is Sales .
In TDL, attribute modifiers are classified as Static/Load time or Dynamic/Runtime modifiers. Use , Add , Delete , Replace/Change are Static/Load Time modifiers . Option, Switch and Local are Runtime modifiers. The sequence of evaluation is generalized across all the definitions in TDL.
Sequence of attribute evaluation:
● Use
● Normal attributes
● Delayed Static/Load Time modifier
● Dynamic/Run-Time modifier
A new attribute modifier Switch has been incorporated from Tally.ERP 9 onwards. This attribute is similar to the Option attribute, but reduces code complexity and improves the performance.
The modifier Option compulsorily evaluates the conditions for all the options provided in the description code, and applies all the option statements which satisfy the evaluation conditions. This means that it is not easy to write the code where you just want one of the options to be applied. You have to make sure that other options are not applied using a negative condition. The new attribute modifier ‘Switch’ has been provided to support these types of scenarios, where evaluation is carried out only up to the point where the first evaluation process has been cleared.
Apart from this, Switch statements can be grouped using a label. Therefore, multiple switch groups can be created and zero or one of the switch cases would be applied from each group.
Syntax
Switch : <Label> : <Definition Name> : <Condition>
Switch : <Label> : <Definition Name> : <Condition>
If multiple Switch statements are mentioned within a single definition, then the evaluation will be carried out up to the point where the first condition is satisfied for the given label.
Example: 1
[Field : Sample Switch]
Set as : "Default Value"
Switch : Case1 : Sample Switch1 : ##SampleSwitch1
Switch : Case1 : Sample Switch2 : ##SampleSwitch2
Here, out of multiple switch statements having same label, zero or one statement is executed.
Example: 2
[Field : Sample Switch]
Set as : "Default Value"
;; If none of the condition is TRUE then Field will have Default Value
Switch : Case1 : Sample Switch1 : ##SampleSwitch1
Switch : Case1 : Sample Switch2 : ##SampleSwitch2
Switch : Case2 : Sample Switch3 : ##SampleSwitch3
Switch : Case2 : Sample Switch4 : ##SampleSwitch4
Here, multiple switch groups are created, and zero or one of the switch cases would be applied from each such group or label.
The behaviour of the following attribute modifiers has been enhanced.
Behaviour of the attribute USE, which is used to inherit the properties from other definitions, has now changed. Irrespective of the order of specification of attributes within a definition, USE will be evaluated first. In other words, the order in which USE is specified is immaterial, as in any case, it will be evaluated first. If multiple USE attributes are specified in a single definition, they are evaluated in the order of their occurrence.
Example:
[Field : Attr Use1]
Set as : "This shows the changed behavior of 'Use' attribute"
Style : Large Bold
Use : Name Field
The Field Attr Use1 uses existing field Name Field. Since USE is having higher precedence over other attributes, Field Attr Use1 will inherit all the attributes of Name Field. But, the style Large Bold at the Field Attr Use1 will override the inherited style within the field Name Field .
Static/Load Time modifiers like Add, Delete and Replace can be called as Delayed Attribute modifiers, as they are having least precedence among Delayed Static/Load Time modifiers.
Now these modifiers are generalized across all definitions. Earlier for definitions Report, Key, Color, Style, Border and Variable, the delayed attributes were applied in their sequence of appearance in the definition description. If more than one delayed attribute is used under any definition, then the attributes will be applied as they appear. This has been done to bring consistency across the definitions.
Example: 1
[Report : Test Report]
Form : Form1
Delete : Form
Form : Form2
The report Test Report won’t have any Form, as the attribute ‘Delete’, which is evaluated last, deletes all the existing forms.
Example: 2
[Report : Test Report1]
Form : Form1
Delete : Form
Add: Form : Form2
As a result of this code snippet, the report Test Report1 will have one form Form2 , since, on deletion of all the Forms, delayed attribute modifier Add is used to add a new form Form2 .
Delayed attribute modifier Local , which is used to locally modify the attributes of any child definition, is now enhanced to accept nested Locals.
Syntax
Local : <DefinitionType1> : <DefinitionName1> [: <DefinitionType2> : <Definition Name2> : ... ] : <Attribute> : <Value>
Where,
< Definition Type > can be a Form, a Part, a Line or a Field.
< Definition name > is the name of the definition type.
< Attribute > is the attribute of the Definition of which, the value needs to be altered, and
< Value > is the value assigned to this attribute within the current Report or Form or Part or Line.
Example:
[Report: Custom Report]
Local : Line : TitleLine : Local : Field : AmtField :Set as : “Sales Amount”
The field Amt Field is localized at the report Custom Report , by using nested locals.
System definitions overriding without # are treated as warnings now, instead of errors. #, ! or * modifications to [ System : MenuKeys ], [ System : Form Keys ], [ System :Formula ] and [ System: UDF ] were shown as errors. They have now been converted to warnings.
In Tally.ERP 9, overriding System Formula/Variable, without prefixing a # have been treated as an Error. The usage of #, * and ! prefix to system definitions like Menu Keys , Form Keys and UDF were not allowed and treated as errors.
Many existing codes have stopped working due to this behavioral change. Hence, in order to maintain backward compatibility, these have been enabled & treated as warnings and in some cases ignored, so that existing TDL codes continue to work, without any changes required for the same. These warnings are thrown only by the compiler, during the compilation using TD9.
However, it is advisable to use # for existing System Formula alteration, and refrain from using # for System Menu Keys, Form Keys and UDF definition, or using ! for any system descriptions.
Prior to Tally.ERP 9, all descriptions supported partial search on their attribute words. For example, Set as could have been written as Set a, Set or Se, which would allow minimum number of characters to be present to an extent where another attribute does not start with those characters. This behaviour is now removed as it is not practical to use partial words. But, multiple aliases are now supported to allow meaningful attribute names.
Example:
● Set as can be written as Set.
● Float Bottom Lines at Part definition can be written as Float.
● Top Part can be written as Part, Parts or Top Parts.
Since these aliases have been introduced, most of the existing TDL will work without any changes. In case of partial words/non-meaningful words used in any TDL, Tally would throw an error, which needs to be corrected in TDL.
To insert empty line between Menu items, BLANK keyword was used. Also Item attribute without any Value used to be considered as BLANK prior to Tally.ERP 9. For consistency in TDL coding, the later is now disallowed. Only BLANK keyword can now be used to indicate empty Menu Item.
In Tally.ERP 9, some new symbols have been introduced and the behaviour of the definition modifier # has been enhanced.
Multi-line commenting is a new feature in this release, which renders the TDL code more user-friendly and easy to maintain. A simple multi-line comment would look like:
/*
<Comment Line 1>
<Comment Line 2> */
Scope of modifying definitions using # is extended to system formula definition, to alter the value of the existing system formula. It helps to improve the performance with optimized formulae.
Example:
[#System : Formula]
NameWidth : 40
MaxNameWidth : 60
Here, the values specified to Formulae NameWidth and MaxNameWidth in DefTDL, are changed.
The definition modifier “*” overwrites the existing content of definition. The “*” modifier is very useful when there is a need to completely replace the existing definition content with a new code .
Syntax
[*<Definition Type> : <Definition Name>]
Example:
[Field : Sample ReInitialize]
Info : "Original Value"
Style : Large Bold
Color : Blue
[*Field : Sample ReInitialize]
Info : "ReInitialized-All the attribute values deleted & newly defined"
Lines : 1
‘ $ ’ operator has been enhanced with new capabilities. It allows direct access to any object method, including its sub-collections to any level, with a dotted notation framework. Using this new capability, there is no need to repeat a line over a sub-collection to access it. Values from any object, anywhere, can be accessed without making the object as the current object in context. Suffixing of PrimaryObjType : ObjNameFormula is still supported for backward compatibility. In cases where both are specified, the enhanced new primary object specification will be considered.
The earlier syntax to access a Method was:
$MethodName OR $MethodName : PrimaryObjType : ObjNameFormula
The enhanced method formula Syntax has been introduced to support access out of the scope of the Primary object and to access Sub object at any level using (.) dotted notation with index and condition support.
The new enhanced syntax is:
$<PrimaryObjectSpec>.<SubObjectPathSpec>.MethodName
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>.
Example:
Following are evaluated assuming Voucher as 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 current voucher,
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,
Set As : $LedgerEntries[1,@@LedgerCondition].BillAllocations[1].Name
LedgerCondition : $LedgerName = @@InvPartyName
4. To get the OpeningBalance of the first Bill for the Party, Acme Corp,
Set As : $(Ledger,@@PartyLedger).BillAllocations[1].OpeningBalance
PartyLedger : “Acme Corp”
Primary Object specification is optional. If not specified, the current object will be considered as primary object. Sub-Collection specification is optional. If not specified, methods from the current or specified primary object will be available. Index specifies the position of the Sub-Object to be picked up from the Sub-Collection. Condition is the filter which is checked on the objects of the specified Sub-Collection.
< Primary Object Identifier Formula >, < Index Formula > and Condition can be a value or formula.<Index Formula> can be any formula evaluating to a number. Positive Number indicates a forward search and negative number indicates backward search. This can also be keyword First or Last which is equivalent to specifying 1 or -1 respectively.
If both Index and Condition are specified, the index is applicable on the Object(s) which satisfy the condition, so 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.
Primary Object Path Specification can either be relative or absolute. Relative Path is referred using empty parenthesis () or Dotted path to refer to the Parent object relatively. SINGLE DOT denotes the current object, DOUBLE DOT the Parent Object, TRIPLE DOT the Grand Parent Object, and so on, within an Internal Object. Absolute Path refers to the path in which the Primary Object is explicitly specified.
To access the Methods of Primary Object using Relative Path following syntax is used:
$().MethodName or $..MethodName or $… MethodName
Example:
Being in the context of ‘LedgerEntries’ Object within the ‘Voucher’ Object, the following has 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 Absolute Path:
$(Ledger, “Cash”).OpeningBalance
In TDL, any Interface object exists in the context of any data object. Every Interface object needs to be associated with some data object. In the absence of any explicit object association, Interface object will get associated with ‘Anonymous’ object. TDL programmer can explicitly associate Interface objects like Report, Part, Line and Field with a data object. In Tally.ERP 9, Object association has become more natural and simpler.
A Report normally will be associated with a data object, which it gets from the previous Report, or will be associated with anonymous object.
From Tally.ERP 9 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 ‘ObjectIdentifierFormula’.
Syntax
Object : <O b jectType> [: <ObjectIdentifierFormula>]
Where,
<ObjectType> is the Type of any Primary Object, and
<ObjectIdentifierFormula> is any formula which evaluates to the name of a Primary Object. It is optional.
Example: Prior to Tally.ERP 9
[#Form : Sales Color]
Delete : Print
Add:Print : New Sales Format
[Report : New Sales Format]
Object : Voucher
Default Sales color form is modified to have new print format New Sales Format . This report gets the Voucher object from the previous Report.
Example: In Tally.ERP 9
[Report : Sample Report]
Object : Ledger : “Cash”
Ledger Cash is associated to the Report Sample Report . Now, the components of Sample Report , by default, inherit this ledger object association.
By default, Part inherits the Object from Report/Part/Line. This can be overridden in two ways:
Syntax: Prior to Tally.ERP 9
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, and
<SeekCondition> is a filter condition to the supplier collection. It is optional.
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 which has the stock Item “Tally Developer” is associated with the Part ‘Sample Part’.
From Tally.ERP 9 onwards, data object can be associated to Part by using the new attribute ‘Object Ex’. Now, even Primary Object can also be associated to a Part, which was not possible in the earlier Part level data object association. Also, 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 Interface Object”.
Syntax: In Tally.ERP 9
Object Ex : <Method Formula Syntax>
Where,
<Method formula syntax> is, <Absolute Spec>.[<SubObjectSpec>]
<Absolute Specification> is (<Object Type>, <Object Identifier Formula>). If only Absolute Spec is given, it should end with dot (‘.’).
<Sub Object Specification> is CollectionName[Index,<Condition>]
Example: 1
[Part : Sample Part]
Object Ex : (Ledger, "Customer 1").
Ledger object Customer 1 is associated to the Part Sample Part . Since only absolute specification is used, the Object specification ends with ‘.’.
Example: 2
[Part : Sample Part]
Object Ex : (Ledger,"Customer").BillAllocations [1,@@Condition1]
[System : Formula]
Condition1 : $Name = "Bills 2"
Secondary object Bill Allocation s is associated with the Part Sample Part.
An object can associated to a Line by Part attribute “Repeat’. Now, the Part attribute ‘Repeat’ has been enhanced to support the following:
● Extraction of collection from any Data object
● Extraction of collection from Interface Object associated Data object. This aspect will be elaborated in the section “Object Access via Interface Object”.
Repeat Syntax: Prior to Tally.ERP 9
Repeat : <Line Name>: <Coll Name>: [<Supplier Coll> :<S e ekTypeKeyword>:<See k Condition>]
Where,
< Coll Name > is the name of the Collection. If the Collection is present one level down in the object hierarchy, then the Supplier Collection needs to be mentioned.
< SupplierCollection > is the name of the Collection of secondary Objects,
< SeekTypeKeyword > can be First or Last, which denotes the position index, and
< 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
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 of ledger entries which satisfies the given condition.
In Tally.ERP 9 – Repeat Syntax
Repeat : Line Name : MethodFormulaSyntax [:SupplierCollection : SeekTypeKeyword : SeekCondition]
Where,
< MethodFormulaSyntax > is <Absolute Spec>.<SubObjectSpec>
< Absolute Spec > is (<Object Type>, <Object Identifier Formula>)
< Sub Object Spec > is CollectionName[Index,<Condition>]
and Supplier Collection syntax is provided just for the backward compatibility.
Example:
[Part : Sample Part]
Line : Sample Line
Repeat : Sample Line : (Ledger, “Customer”).BillAllocations
By default, a field inherits the object from the parent line or Field (if field 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 primary object, the secondary object is tried then.
From Tally.ERP 9 onwards, data objects in association with Interface objects can be accessed using the new Interface object access syntax. Data object, which is associated to Interface Object, can be accessed with the following 2-step procedure:
1. Identifying Part and Line Interface object with ‘Access Name’
2. Value/Collection Extraction
Part and Line can be identified by a unique access name. For this purpose, a new attribute ‘Access Name’ is introduced for ‘Part’ and ‘Line’ definitions.
Syntax
Access Name : Access Name Formula
Where,
< Access Name Formula > can be a formula which evaluates to a string.
Example: 1 – Access Name at Part Definition
[Part : Sample Part]
Line : Sample Line1
Access Name : “Sample Part”
Example: 2 – Access Name at Line Definition
[Line : Sample Line]
Field : Sample Fld1, Sample Fld2
Access Name : "Repeated Line" + $$String:$$Line
When Line ‘Sample Line’ is repeated over a collection, every Line is identified by a unique Access Name.
Once Part and Line Interface objects are able to uniquely identify by ‘Access Name’, then the data object can be accessed by either the new function $$ObjectOf or ‘New method formula syntax’.
Methods of data object, which is associated to Interface Object, can be extracted by using the function $$ObjectOf .
Syntax
$$ObjectOf : <DefinitionType> : <AccessNameFormula> : <EvaluationFormula>
Where,
< DefinitionType > may be Part or Line
< AccessNameFormula > is a string through which a Part or Line can be uniquely identified, and
< EvaluationFormula > is a method that needs to evaluated.
Example:
Line Sample Line has Access Name as Sample Acc Name and is in association with Ledger Object.
[Field : Sample Field]
Set as : $$Objectof:Line:”Sample Acc Name”:$Name
Field Sample Field displays the name of the object Ledger which is associated with a Line whose access name is “ Sample Line Acc Name ”.
Methods of data object, which is associated to Interface Object, can also be extracted by using new method formula. With this approach, sub object’s methods can be extracted.
Example:
Line ‘Sample Line’ has Access Name as ‘Sample Acc Name’ and in association with Ledger Object.
[Field : Sample Field]
Set as : $(Line,“MyLineAccessName”).BillAllocations[1].OpeningBalance
Field ‘Sample Field’ displays the name opening balance of a ledger which is associated with a Line whose access name is “Sample Line Acc Name”.
Collection inside the data object, which is associated to the Interface Object, can be extracted by using the new method formula.
Syntax - Enhanced Repeat
Repeat : Line Name : MethodFormulaSyntax [:SupplierCollection : SeekTypeKeyword : SeekCondition]
Where,
< MethodFormulaSyntax > is <Absolute Spec>.<SubObjectSpec>
< Absolute Spec > is (<Object Type>, <Object Identifier Formula>)
< Sub Object Spec > is CollectionName[Index,<Condition>]
and Supplier Collection syntax is provided just for the backward compatibility.
Example:
[Part : Sample Part]
Repeat : Sample Line:(Part, “MyPartAccessName”).InventoryEntries
Part having access name ‘MyPartAccessName’ is under the context of ‘Voucher’ Object. We can repeat a line “Sample Line” over Inventory Entries of the Voucher Object, which is associated with the Part having the access name “MyPartAccessName”
Prior to Tally.ERP 9, usage of TDL language token bracket (‘(’ and ‘)’) was restricted as mathematical operator only. From this release onwards, brackets can be used in following scenarios:
● During the function call to enclose the function parameter
● In the language syntax for nesting formulas
● As a Mathematical Operator
Prior to Tally.ERP 9, when a parameter for a function required expression and that expression contained any language token, then the TDL programmer was forced to replace the expression by a formula. This can now be achieved by enclosing the expression in a bracket. The expression inside the bracket is evaluated first and the result is used as the parameter for the function. Nesting can be performed up to any level. Brackets can also be used in places where the function parameter expects an identifier or a constant value.
Example: 1
Field ‘Sample Fld’ displays the first 5 characters of currently loaded Company’s email address.
Prior to Tall y .ERP 9
In this case, the First parameter to the function $$ StringPart is an expression that contains the language token ‘:’. So, a formula needs to be created.
[Field : Sample Fld]
Set as : $$StringPart:@CmpEmailAddress:0:5
CmpEmailAddress : $Email : Company : ##SVCurrentCompany
In T ally.ERP 9
[Field : Sample Fld]
Set as : $$StringPart:($Email:Company:##SVCurrentCompany):0:5
Example: 2
If the last object in the collection Ledger is a Sundry Creditor, then the Field ‘Sample Fld’ will have logical value YES else NO.
Prior to Tally.ERP 9
In this case, the condition contains language token ‘:’ and constant value ‘-1’. So, a formula needs to be created.
[Field : Sample Fld]
Set as : $$CollectionField:@@GroupCheck:@@IndexPosition:Ledger
[System : Formula]
GroupCheck : $Parent:Ledger:$Name = $$GroupSundryCreditors
IndexPosition : -1
In Tally.ERP 9
[Field: Sample Fld]
Set as: $$CollectionField:($Parent:Ledger:$Name = $$GroupSundryCreditors):(-1):(Ledger)
Prior to Tally.ERP 9, whenever an expression was a part of language syntax, language tokens were not permitted. This restriction led to the necessity of additional formulas, even when the formulas were not used more than once.
With this enhancement, expressions can be used in language syntax by enclosing them in brackets. Brackets can also be used when attribute value expects identifier or constant value.
Example: 1
If the given condition is satisfied, then the Field ‘Sample Fld’ will display “Cash Accounts”
Prior to Tall y .ERP 9
In this case, the condition contains language token ‘:’. So, a formula needs to be created.
[Field: Sample Fld]
Set By Condition : @IsLedgerIsCash : "Cash Accounts"
IsLedgerIsCash : ($Name:Ledger:##SVLedger) = "Cash"
In T ally.ERP 9
[Field : Sample Fld]
Set By Condition : ($Name : Ledger : ##SVLedger)= "Cash" : "Cash Accounts"
Example: 2
[Part : Sample Part]
Line : Sample Line
Repeat : (Sample Line) : My Collection
First parameter for ‘Repeat’ attribute is using bracket for identifier.
In TDL, brackets are used as mathematical operator to set the precedence of evaluation.
Example:
[Field : Sample Fld]
Set as : 4*(5+6)
If parentheses are not used, then the Field ‘Sample Fld’ will display 26, otherwise 44.
Some of the existing actions have been enhanced to support the multi-line selection capabilities. Several new actions have also been introduced in TDL.
Key action is enhanced to perform various operations on multiple lines. For example, multiple vouchers can be selected/unselected and various actions such as deletion, modification, etc., can be performed on the selected vouchers only. To achieve this, two attributes Scope and Selectable have been introduced. Scope attribute is introduced in Key definition and Selectable attribute is available at Part and Line definitions.
Through this attribute, scope for the Action(s) can be specified.
Syntax
Scope : <Scope Keyword>
Where,
< Scope Keyword > can have any of the following possible values: - Current Line/Line, All Lines, Selected Lines, Unselected Lines and Report.
At Part level, the attribute ‘Selectable’ indicates whether the lines owned by the particular Part are selectable or not, and the default value for the same is YES.
Syntax
Selectable : <Logical Formula>
At Line level, the attribute ‘Selectable’ indicates whether the line (or lines within the line) is selectable or not. The default value of attribute ‘Selectable’ for repeated lines is ‘YES’, and for non-repeated lines is ‘NO’. The value is also inherited from Parent Part/Line, and the same can be overridden at Line level.
Syntax
Selectable : <Logical Formula>
where,
<Logical Formula> must return the value as Yes or No
Following actions have been introduced/changed:
● Toggle Select– Selects/deselects a line
● Select All – Selects all the lines within a part
● Unselect All – Deselects all the lines within a part
● Invert Selection – Selects all the unselected lines within a part
● Modify Object – Modifies the values stored in the methods of an Object
The behaviour of existing actions ‘Cancel Object’, ‘Delete Object’, ‘Remove Line’ and ‘Multi Field Set’ have been modified to obey the scope specified in the Key description.
The actions Print Report, Upload Report, Email Report and Export Report can be executed now on the Selected Line scope. In the resultant report, the selected lines will be available as objects in the collection ‘Parameter Collection’. This collection can be used in the called report for displaying data. Actions like Cancel Object, Audit Object and Delete Object have been enhanced to work with ‘Report’ scope.
Following new actions have been introduced in the language:
The action ‘Modify Object’ has been enhanced to alter a method of an object at any level. ‘Modify Object’ also supports modifying multiple values of an object. Multiple values can be specified as a comma separated list of <Method Name> : <Value> pairs.
Syntax
Action : Modify Object : <PrimaryObjectSpec>.<SubObjectPathSpec> .MethodName : value>[,Method Name : <value> , …]+
[,<SubObjectPathSpec>.MethodName : <value>, …..]
The specifications given for <PrimaryObjectSpec>, <SubObjectPathSpec>, MethodName remain the same as described in the New Method syntax section.
A single ‘Modify Object’ action cannot modify Multiple Objects, but can modify multiple values of an Object.
‘Modify Object’ is allowed to have Primary Object Specification only once, that is, for the first value. Further values permissible are optional Sub Objects and Method Specification only.
Sub Object Specification is optional for second value and onwards. If Sub Object Specification is specified, the context is assumed to be the Primary Object specified for the first value. In absence of Sub Object Specification, the previous value specification's Leaf Object is considered as the context.
Example: 1
[Key : Alter My Object]
Key : Ctrl + Z
Action : Modify Object :(Ledger,"MyLedger").BillAllocations [First,$Name="MyBill"].OpeningBalance +
: 100,..Address[Last].Address : "Bangalore"
Existing ledger My Ledger is being altered with new value for opening balance of existing bill bearing Name as MyBill and last line of Address. Key Alter My Object can be attached to any Menu or Form, clicking which, the above will be altered.
Example: 2
[Key : Alter My Object]
Key : Ctrl + Z
Action : Modify Object :(Ledger,"MyLedger").BillAllocations[1].OpeningBalance : 1000, Name:”My New Bill”,+
..Address[First].Address : "Hongasandra Bangalore", + Opening Balance : 5000
Existing ledger My Ledger is altered with new values for opening balance for existing bill, opening balance of ledger and address. Key Alter My Object can be attached to any Menu or Form.
Example: 3
[Key : Alter My Object]
Key : Ctrl + Z
Action:ModifyObject:LedgerEntries[1].BillAllocations[1].Name : “Test1”, Amount :“1000.00”, ..BillAllocations[2]+
.Name:“Test2”, Amount : “2000.00”, ().Date : “1.4.08”
In a Voucher context, Key Alter My Object alters the Name, Amount and Date methods of the Sub object Bill Allocations in one line.
In Menu definition, a button which has the action ‘Modify Object’, can be added.
Example
[#Menu : Gateway of Tally]
Add : Button : Alter My Object
While associating a key with action ‘Modify Object’, the following points should be considered:
● Since menu does not have any Data Objects in context, specifying Primary Object becomes mandatory.
● Since Menu cannot work on scopes like Selected Lines, Unselected Lines, etc., scopes specified are ignored.
● Any formula specified in the value is evaluated assuming Menu Object as the requestor.
● Even Method values pertaining to Company Objects can be modified.
● A button can be added at the menu to specify the action Modify Object at the Menu level
This new action is similar to the action ‘Modify Object’. The action ‘Set Object Values’ works only in the ‘Edit’ mode of a Report, as it uses current context. This action changes the values of the object from current context, as specified.
Syntax
Action : Set Object Values : <SubObjectPathSpec>.<Method Name>: <Method Value>
Where,
< SubObjectPathSpec > is given as CollectionName [<Index Formula>, [<Condition>]]
< MethodName > refers to the name of the method in the specified path, and
< Method Value > is the value to be set for <Method Name>.
This action alters the current object in memory. When the Primary object is saved, the changes will be updated in Tally database.
Example
[Key : My Key]
Action : Set Object Values : Opening Balance : ($$AsAmount : 10)
The action ‘Backup Company’ allows to take the backup of multiple companies.
Syntax
Backup Company : <parameter sep char> : <String Formula>
Where,
< Parameter Sep Char > is a character used to separate parameter.
< String Formula > must evaluate to the value in the following order separated by the <Parameter Sep Char>:
< Destination > < Source > < Company Name > < Company Number >
< Destination > is the path where the backup file is to be stored.
< Source > is the path from where the company data is to be taken for backup.
< Company Name > is name of the Company.
< Company Number > is number of the company.
These four values must be specified for each company. They can be repeated for multiple companies.
Example: Single Company
[Button : My Cmp Bk Button]
Title : BackUp Cmp
Action : BackUp Company: “,” : “C:\,C:\Tally.ERP 9\Data,Global Enterprises,10037”
Key : Alt + G
Example: Multiple Company
[Button : My Cmp Bk Button]
Title : BackUp Cmp
Action : BackUp Company : “,” : “C:\,C:\Tally.ERP 9\Data,Global Enterprises,10037,C:\,C:\Tally.ERP 9\Data,+
TDL Demo,10027”
OR
[Button : My Cmp Bk Button]
Title : BackUp Cmp
Action : BackUp Company : “,” : @@MyCmpFor
[System : Formula]
MyCmpFor : “C:\,C:\Tally.ERP 9\Data,Global Enterprises,10037,C:\,C:\Tally.ERP 9\Data,TDL Demo,10027”
This action allows to restore multiple companies in one go.
Syntax
Restore Company : <parameter sep char> : <String Formula>
Where,
< Parameter Sep Char > is a character used to separate parameter.
< String Formula > must evaluate to the value in the following order separated by the < Parameter Sep Char >:
< Destination > < Source > < Company Name > < Company Number >
< Destination > is the path where the backup file is to be stored.
< Source > is the path where the backup file is available
< Company Name > is the name of the Company.
< Company Number > is the number of the company.
These four values must be specified for each company. These can be repeated for multiple companies.
Example: Single Company
[Button : My Cmp Res Button]
Title : Restore Cmp
Action : Restore Company : “,” : “C:\Tally.ERP 9\Data,C:\,Global Enterprises,10037”
Example: Multiple Company
[Button : My Cmp Res Button]
Title : Restore Cmp
Action : Restore Company : “,” : “C:\Tally.ERP 9\Data,C:\,Global Enterprises,10037,C:\Tally.ERP 9\Data,C:\,+
TDL Demo,10027”
OR
[Button : My Cmp Res Button]
Title : Restore Cmp
Action : Restore Company : “,” : @@MyCmpFor
[System : Formula]
MyCmpFor : “C:\,C:\Tally.ERP 9\Data,Global Enterprises,10037,C:\,C:\Tally.ERP 9\Data,TDL Demo,10027”
This action allows to change the TallyVault Password of multiple companies in one click.
Syntax
ChangeCrypt Company : <parameter sep char> : <String Formula>
Where,
< Parameter Sep Char > is a character used to separate parameter.
< String Formula > must evaluate to the value in the following order, separated by <Parameter Sep Char>:
< Company Data Folder > < New Tally Vault Key > < Old Tally Vault Key > < Company Name > < Company Number >
< Company Data Folder > is the path of the company data folder.
< New Tally Vault Key > is the new password of the company.
< Old Tally Vault Key > is the old password of the company.
< Company Name > is the name of the Company.
< Company Number > is the number of the company.
These 5 values must be specified for each company, and can be repeated for multiple companies.
Example
[Button : Chg Pwd]
Title : Change Pwd
Key : Alt + b
Action : ChangeCrypt Company : “,” : ”C:\Tally.ERP 9\Data\10037,NewPwd,OldPwd,Global Enterprises, 10037”
It is used to open web browser with any URL formula passed as a parameter. A list of parameters separated by space can be specified, if the application accepts command line parameters. Exec Command is an alias for action Browse URL.
Syntax
Action : Browse URL : <URL Formula> [:<command line parms>]
Where,
< URL formula > is an expression which evaluates to any link to a web site.
< command line parms > is the List of command line parameters, separated by space. ‘Browse URL’ Key Action can be used to open web browser with any URL Formula.
Example
[Button : Open Notepad]
Title : $$LocaleString:"Notepad"
Key : ALT + N
Action : Exec Command : Notepad : “Browse URL.Txt”
[Form : Hyperlink]
Parts : Hyperlink
Button : Open Notepad
Example: Field acting as a hyperlink
[Key : Execute Hyperlink]
Key : Left Click
Action : Browse URL : “www.tallysolutions.com”
[Field : Hyperlink Company]
Color : Blue
Border : Thin Bottom
Key : Execute Hyperlink
Set as : "Tally Solutions Pvt. Ltd"
Local : Key : Execute Hyperlink : Action : Browse URL : http://www.tally.co.in
Note: Existing Action Register Tally has been removed for generalization; which is now replaced with Action Browse URL.
A new Key/Button Action HTTP Post has been introduced which will help in exchanging data with external applications using web services. In other words, ‘HTTP Post’ Action can be used to submit data to a server over HTTP and gather the response. This will enable a TDL Report to perform a HTTP Post to a remote location.
This action will be discussed in detail under the topic HTTP XML Collection.
A new Key/Button Action Refresh TDL has been introduced, which allows the TDL programmer to reload the active TDL Files, without having to restart Tally.
Syntax
Action : Refresh TDL
Example: Field acting as a hyperlink
[Key : Refresh TDLs]
;; Any Key can be assigned if Report already have F5 assigned
Key : F5
Action : Refresh TDL
;; Refresh TDL will work from any Report
[#Form : Default]
Key : Refresh TDLs
Tally.ERP 9 Series A Release 1.0 onwards, actions can also be carried out based on certain events. On encountering these events, the given action or list of actions will be executed.
Currently, two events have been introduced in Tally.ERP 9
● On : Form Accept
● On : Focus
A new event On: Form Accept has been introduced that can be specified within the Form Definition. A list of actions can be executed when the form is accepted, which can also be based on some condition.
Syntax
On : Form Accept : <Condition>: Action : Action parameters
Where,
< Condition > should return a logical value.
< Action > can be any one of the actions.
< Action Parameters > are the parameters of the action specified.
Example
[Form : TestForm]
On : FormAccept:Yes:HttpPost : @@SCURL : ASCII : SCPostNewIssue : SC NewIssueResp
A new Event On: Focus has been introduced, which can be specified within definitions Part, Line and Field. When Part, Line or Field receives focus, a list of actions get executed which can also be conditionally controlled.
Syntax
On : Focus : Condition : Action : Action paramete r s
Where,
< Condition > should return a logical value.
< Action > can be any action.
< Action Parameters > are parameters of the action specified. Since On : Focus is a list type attribute, many actions can be specified, which will be executed sequentially.
Example
[Part : TestPart1]
On : FOCUS : Yes : HTTP Post : @@MyUrl : ASCII : ReqRep, RespRep
[Part : TestPart2]
On : FOCUS : Yes : CALL : SCSetVariables : $$Line
This is one of the breakthrough changes which has taken place at the platform level. We all know that TDL is a definition language which provides capability for rapid development. But now, TDL is procedural as well. With the introduction of Functions/Procedures as a part of Tally.ERP 9 family, the TDL capabilities have reached a new dimension.
This will help the application programmers to develop their own functions for achieving business functionality. There will be a decrease in platform dependency for particular business function.
The result would be faster development cycles for business modules.
The creation and usage of functions is discussed in detail in the section III “User Defined Functions for Tally.ERP 9”.
Following functions have been introduced in the Language:
The existing function $$IsBelongsTo will only check if the current object belongs to a specified object. The new function $$IsObjectBelongsTo has been introduced to provide more explicit control in the hands of the programmer, by allowing him to specify the object type and name, in addition to parentage against which it needs to be checked. This function is very useful in the context of summarized objects, as they are not of any native type and are just an aggregation of objects. This function allows an easy link back into the native object type, and walking up the chain. It is very useful when creating hierarchical reports on summarized collections.
Syntax
$$IsObjectBelongsTo : ObjType : ObjName : BelongsToName
Where,
< ObjType > denotes the Type of the Object.
< ObjName > denotes the Name of the Object.
< BelongsToName > denotes the name of the object Type.
Example
Whether Group North Debtors belongs to Group Sundry Debtors or not, can directly or indirectly be checked using the following statement:
$$IsObjectBelongsTo:Group:”North Debtors”:$$GroupSundryDebtors
Tally.ERP 9 onwards, various operations can be performed on multiple lines. To know how many lines were considered for any operation, the function $$NumLinesInScope has been introduced.
Syntax
$$NumLinesInScope : <ScopeKeyword>
Where,
< Scope Keyword > can be All Lines, Selected Lines, UnSelected Lines, Current Line/Lines.
Example
[Field : Sample Fld]
Set As : $$NumLinesInScope:SelectedLines
Field Sample Fld displays the total number of selected lines in the Part to which it belongs.
A new Built-in function $$ DateRange has been introduced to convert data types of the value from one form to due date format. Prior to this, only through Field’s format specification, conversion was possible. Now, the new function can be used inside User Defined Functions also.
Syntax
$$DateRange:<Due Date Expression>:<Base Date Expression>:<Flag>
Where,
< Base Date Expression > is a String Expression, and evaluates to Due Date.
< Due Date Expression > is a String Expression, and evaluates to Date.
< Flag > is a logical expression, and decides whether to include date given in second parameter.
Example
SET VALUE: OrderDueDate : $$DateRange:"10 Days":$Date:True
Method ‘Order Due date’ will have value as "10 Days" from $Date, with $Date also inclusive.
When you export a voucher to XML with due date, the tag <orderduedate> contains two attributes called JD and P. JD is the Julian Day of the given date. P is the due date mentioned in the field.
Julian Day (JD) value is calculated internally based on the calculation method of Tally.
Note: All value extraction can now be achieved using GroupBy; hence $$Extract functions have been removed from Tally.ERP 9, e.g., $$ ExtractGrpVal , $$ExtractLedVal , etc.
You can use the function $$IsCollSrcObjChanged to know when the source object is changed to the next source object, while the Walk or WalkEx attribute is being executed.
Syntax
$$IsCollSrcObjChanged
The return value of this function is Logical. It returns True for the source object and the first walked object. It will return False for the subsequent objects that are walked in the same source objects, till the source object is changed.
This function is especially useful when you want to aggregate the values for a source object while walking through multiple source object. This function will indicate that a source object is changed to the Aggregation computation expression.
Example
[Collection: TN Summary Counts]
Source Collection : My Vouchers
By : Summary : "Summary"
Aggr Compute : TotalIncluded : Sum : IF $$IsCollSrcObjChanged AND $IsVCHIncluded Then 1 Else 0
Aggr Compute : TotalUncertain : Sum : IF $$IsCollSrcObjChanged AND $IsVchUncertain Then 1 Else 0
You might need to evaluate some expression from the source collection context while walking in the sub-collection context to compute some value. For this purpose you can use the function CollSrcObj evaluate expression in the context of source object while walking the current object.
Syntax
$$CollSrcObj:<Expression>
Where,
Expression is any expression that needs to be evaluated in the context of the source object (methods, local formulae, and so on).
Example
[Collection: TNAnnexureSummaryTemplate]
Source Collection : My Vouchers
Walk : AllInventoryEntries
Compute : TNeVATVchNo : $$CollSrcObj:$VoucherNumber
Compute : TNeVATVchDt : $$CollSrcObj:$Date
By : ...
AggrCompute : ...
This function will work only when it is used in a collection context.
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, HTTP, and so on. A set of new capabilities have been added to Collection, which provides far more flexibility and power in the hands of the TDL programmer. This will allow writing significantly complex reports with ease, and still delivering enhanced performance with high volume of data.
Tally.ERP 9 onwards, Collection has been enriched with the following capabilities:
● Data Roll up/Summarization
● Collection re-use, extraction and chaining
● Indexed or Searchable Collection on TDL defined keys
Following attributes under ‘Collection’ have been introduced to achieve the above:
In context of summary collection, i.e., to achieve Data roll up, this attribute is mandatory. Source Collection specifies the collections to be used for source data. Multiple Source Collections can be used, which can either be specified as a comma separated list OR listed in several lines.
Syntax
Source Col l ection : <Collection name>, <Collection Name> …
Where,
< Collection Name > is any predefined collection, the methods and sub-objects of which are available to the current collection for further processing.
Example
[Collection : Vouchers Collection]
Type : Voucher
[Collection : Summary Collection]
Source Collection : Vouchers Collection
The ‘Summary Collection’ uses ‘Vouchers Collection’ as source data.
Attribute Walk allows specifying further elements to walk on the source. ‘Walk’ is optional and if not specified, the methods pertaining to the source object only, are available to be used. Walk can be specified to any depth for within the source object. This gives enormous flexibility and power. The Walk list has to be specified in the order in which they occur in the source object.
Syntax
Walk : <Sub-Object Type/Sub-Collection>[, <Sub-Object Type/ Sub-Collection> …]
Where,
< Sub–Object Type/Sub-Collection > is the name of the Sub-Object/ Sub Collection.
Example
[Collection: Vouchers Collection]
Type : Voucher
[Collection : Summary Collection]
Source Collection : Vouchers Collection
Walk : Inventory Entries
In the Summary Collection, by saying Walk : Inventory Entries, only methods within the ‘Inventory Entries’ Object are available to the current collection.
In case objects pertaining to Batch Allocations are required, the Walk can be written as:
Walk : Inventory Entries, Batch Allocations
wherein, all the methods within Batch Allocations will be available to the current collection.
Attribute By is mandatory and it allows to specify the criteria, based on which the aggregation is done. In other words, it works like GROUP – BY. Aggregation criteria can be one or more.
Syntax
By : <Method-Name> : <Method-Formula>
Example
[Collection : Vouchers Collection]
Type : Voucher
[Collection : Summary Collection]
Source Collection : Vouchers Collection
Walk : Inventory Entries
By : PartyLedgerName : $LedgerName
By : StockItemName : $StockItemName
In ‘Summary Collection’, Partywise Stock Items are clubbed, on which Aggregation, i.e., Sum/Min/ Max operations, would be performed.
‘Aggr Compute’ attribute is used for aggregation purpose based on the criteria(s) specified with attribute By. Aggregation can be done to find Sum, Minimum or Maximum, or the Last value of the Method within the Grouped Method. The Method on which Aggregation has to be performed can be of Data Type ‘Number’, ‘Quantity’, ‘Rate’ or ‘Amount’.
Syntax
Aggr Compute : <Method-Name> : <Aggr-Type> : <Method-Formula>
Where,
< Method–Name > refers to the method where the result can be stored and referred to later.
< Aggr–Type > takes operation to be performed on the given method within the given criteria, i.e., Sum, Max, Min, or Last.
< Method–Formula > should be evaluated to method names on which Aggregation operation needs to be performed.
Example
[Collection: Vouchers Collection]
Type : Voucher
[Collection : Summary Collection]
Source Collection : Vouchers Collection
Walk : Inventory Entries
By : PartyLedgerName : $LedgerName
By : StockItemName : $StockItemName
Aggr Compute : BilledQty : Sum : $BilledQty
BilledQty method retains the result of Aggregation, i.e., Summation of method BilledQty for a StockItem within a particular Party.
Apart from the ones used in By and Aggr Compute attributes, none of the other methods can be accessed unless they are declared explicitly. One of the ways of declaring the required methods is by listing them using the attribute Compute .
Syntax
Compute : <Method-Name> : <Method-Formula>
Example
Compute : Date : $Date
Method Date is being declared and made available for subsequent use.
Many a time, there are requirements where objects being walked in a collection need to be walked once for certain computation followed by, ensuring that these computations are reflected back as methods in all the objects. The attributes ReWalk and ReCompute are introduced for this purpose. The objects are being walked in the first iteration with the values accumulated in some variable and if Rewalk is Yes , these objects are walked again so that the accumulated values are re-computed as methods along with objects
Syntax
ReWalk : <Logical Constant>
ReCompute : <MethodName> : <Expression>
Where,
< Logical Constant > is either Yes or No.
<MethodName> refers to the method where the result can be stored and referred to later.
Example
/* Regular voucher collection for source */
[Collection: My Vouchers]
Type : Vouchers
/* Main Aggregate collection uses By with Walk and ReWalk for totling item amount Query to execute: Select $Item, $TotalAmount, $ItemTotalAmount from MainAggrCollection
*/
[Collection: Main Aggr Collection]
Source Collection : My Vouchers
Walk : Inventory Entries
;; Compute var for keeping total from first walk (NOTE: Need to reset this for every voucher)
Compute Var : WalkTotal : Amount: $$NettAmount:##WalkTotal:$Amount
;item name
By : Item : $StockItemName
;; itemwise total
Aggr Compute : TotalAmount : Sum: $Amount
; rewalk
Rewalk : Yes
;; must be same as total amount (but reflects for all entries)
ReCompute : ItemTotalAmount : ##WalkTotal
Another way of declaring required methods is by listing them in Fetch attribute. The only difference here is that the method names of the Objects within this collection have to be referred by the same name as in the Object.
Syntax
Fetch : <Existing-Method-Name-in-Source> …
Where,
< Existing – Method Name in source > refers to the methods of the source collection.
Example
Fetch : Date, Narration
;;is equivalent to writing
Compute : Date : $Date
Compute : Narration : $Narration
Fetch using wildc a rd charact e rs
The two wild characters can be used in Fetch attribute * and ?.
● * is used To fetch all the methods and collections of the current object in context.
● ? is used To fetch all the methods of current object in context.
Example
● To fetch all methods of current Object within Walk.
Fetch : ?
● To fetch all methods and collection of current Object within Walk.
Fetch : *
● To fetch the methods StockItemName, BilledQty, Amount and all the methods of collection Batch Allocation
Fetch : StockItemName, BilledQty, Amount, BatchAllocations.*
You can use the attribute Source Fetch to fetch methods from the source object context while in the current object context within Walk.
Syntax
Source Fetch: MethodSyntax, ...
Where,
MethodSyntax is the method or collections to be fetched from the source object context.
Example
[Collection: TNAnnexureSummaryTemplate]
Source Collection : My Vouchers
Walk : AllInventoryEntries
Source Fetch : Date
By : ...
AggrCompute : ...
Attribute Source Fetch is not relevant in a Simple Collection or an Extract Collection without Walk and will be ignored.
If the source collection does not have Walk or WalkEx attributes, then Source Fetch will be ignored. Source Fetch will also be ignored if the source collection of is of type native collection.
When a collection is being gathered, Fetch is used to fetch the methods at source and also bring them to the target object. In TDL, we also define multiple external methods at object level which can also be fetched using the Fetch attribute. This ensures that the resultant method is created at source and is also pulled into the target object. Any further access to these external methods using $ will provide the value directly, avoiding evaluation of method again.
However, there are scenarios, where Compute Var variables are used to evaluate expressions containing these external methods. Since Fetch is always evaluated after Compute Var, any access to external methods during Compute Var evaluation will end up evaluating again and again.
To solve this problem, an attribute Prefetch is introduced to declare the methods that are required to be fetched prior to Compute Var such that these Methods are available for usage within the current context thereby not requiring to re-evaluate the same expression each time they are used.
The sequence of methods declared in the Prefetch should be in the order of dependency, for instance, if Method 3 uses Method 2, and Method 2 uses Method 1, then, the declaration order in Prefetch should be Method 1, Method 2. A similar Source Prefetch is provided for the case of Source object context.
Syntax
PreFetch : <Method1,...>
Source Prefetch: <Method 1,...>
Where,
<Expression> is the value that needs to evaluated.
Note:
♦ Source Prefetch is applicable only when the walk is provided and Source Prefetch is evaluated before Source Var.
♦ Prefetch is evaluated before Compute Var but after Source Var.
Example
[Collection: LT_SummaryVchColl_With_PF]
Source Collection : LT_SimpleVchColl
Walk : LedgerEntries
By : LedgerName : $LedgerName
Aggr Compute : Amount : Sum : $Amount
/* Two External Object Methods are pre-fetched so that these expressions get evaluated only once and used multiple times */
Prefetch : LedgerParent, IsLedDebtorCreditor
Compute Var : vIsCreditAllowed : Logical : If $$IsEmpty:$LedCreditPer then No else Yes
Compute : IsCreditAllowed : ##vIsCreditAllowed
[#Object: Ledger Entry]
LedgerParent : $Parent:Ledger:$LedgerName
IsLedDebtorCreditor : $LedgerParent = $$GroupSundryDebtors OR $LedgerParent = $$GroupSundryCreditors
IsPartyLedBillWiseOn: If $IsLedDebtorCreditor then $IsBillWiseOn:Ledger:$LedgerName else No
LedCreditPer : If $IsLedDebtorCreditor and $IsPartyLedBillWiseOn then $BillCreditPeriod:Ledger:+
$LedgerName else ""
[Collection: LT_SimpleVchColl]
Type : Voucher
As we can observe, that the Method LedgerParent is being prefetched, as a result of which, while evaluating the subsequent Method IsLedDebtorCreditor , the value of LedgerParent will be available and is not required to be re-evaluated. Similarly, since IsLedDebtorCreditor is prefetched, the subsequent methods IsPartyLedBillwiseOn and LedCreditPer using this method are also using the prefetched value, without re-evaluating.
The attribute Keep Source is used to store the source data in main memory. The default value of this attribute is NO. When the Source Collection from which the Summary Collection is being prepared has a large number of objects and ‘Keep Source’ is set to YES, then the system goes out of memory since holding those objects in memory in one shot is not possible.
When Keep Source is set to No, the source objects are not retained in memory and they are processed as they are collected.
Syntax
Keep Source : Yes/No/...
Where,
Each dot specifies the parent one level up
. - Single dot retains the data of the source collection in current object.
.. - Double Dot retains the data of the Source Collection in current object’s parent.
... - Triple Dot retains the data of Source Collection in current object’s parent’s parent, and so on.
Example
● Keep the source collection in the current owner
Keep Source : Yes
OR
Keep Source : .
● Don’t keep the source collection data
Keep Source : No
● Keep the current source collections data in the current object’s parent
Keep Source : ..
● Keep the current source collections data in current object’s grand parent
Keep Source :...
Note: Please note that using the current object as a source-collection means that ‘ Keep Source ’ is not applicable, as there is no actual source collection created.
This attribute is used to create index dynamically where the TDL programmer can define the key and the Collection is indexed in the memory using the Key. Once the index is created, any object in the collection can be instantly searched without needing a scan, as in the case of a filter. Search Key is Case Sensitive .
This attribute has to be used in conjunction with function $$CollectionFieldByKey . This function basically maps the Objects at the run time, with the Search Keys defined at the Collection.
Syntax
Attribute – Search Key
Search Key : <Combination of Method name/s>
Function – $$CollectionFieldByKey
$$CollectionFieldByKey : Method-Name : Key-Formula : CollectionName
Where,
< Method-Name > is the name of the method,
< Key-Formula > is a formula that maps to the methods defined in the search key, exactly in the same order.
Attribute ‘Data Source’ allows to specify XML file as data source. The collection can be created directly from the specified XML file and the data in the XML file can be displayed in a report.
Syntax
DataSource : <Type> : <file path> : <Encoding>
Where,
< Type > specifies the type of data source - File Xml or HTTP XML
< File Path > is the data source file path.
< Encoding > is ASCII or UNICODE. It is Optional.The default value is UNICODE.
Example: 1
[Collection : My XML Coll]
DataSource : File Xml : “C:\MyFile.xml”
In this code snippet, the type of file is ‘File XML’ as the data source is XML file. The encoding is UNICODE by default, as it is not specified.
Example: 2
[Collection : My XML Coll]
DataSource : HTTP Xml : “http:\\localhost\MyFile.xml” : ASCII
In this code snippet, the type of file is ‘HTTP XML‘, as the data source is obtained through HTTP. The encoding of the file ‘MyFile.XML’ is ASCII.
Note: Support for other data sources like ODBC, DLL, etc., will also be available in the future releases.
Data roll up/ summarization capability facilitates creation of large summary collections of aggregations in a single scan, using the new attributes of the ‘Collection’ definition, as discussed above.
Prior to Tally.ERP 9, all the totals were generated using functions like $$CollAmtTotal or $$FilterAmtTotal via 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 can make the code very complex and may not scale up if a large number of totals need to be generated, as in the case of most business summary reports or a large underlying data set being used. Considering the object oriented nature of Tally data and existence of sub-objects up to any level, the task becomes even more complex. These functions require multiple data scans to produce a summary report with multiple rows and columns.
This methodology has now been complemented with a single scan to get all totals including those based on User Defined Fields (UDFs). Native aggregation capability has now been added to a collection itself. The overall effect is a reduction in TDL code complexity, resource requirement and enhanced performance by orders of magnitude especially concerning reports generation.
Example: 1
[Collection : My Source Collection]
Type : Voucher
[Collection : My Summary Collection]
Source Collection : My Source Collection
Walk : Ledger Entries
By : MyLedgeName : $LedgerName
Aggr Compute : My Total : Sum : $Amount
In this code snippet, My Summary Collection is created out of source collection My Source Collection where traversing is done to Ledger Entries using Walk, and Ledger Name is the method on which aggregation is performed to find the sum of the ledger amount.
Example: 2
In some scenarios, current object itself is required as a Source and aggregation is performed on collection obtained from it or its sub-collections. In such circumstances, if we use Source Collection as Voucher, then the entire vouchers within the company will be scanned unnecessarily to find the current one, which is a time consuming process. To avoid this, we can use Source Collection: Default, which will assume the current voucher as a Source.
[Collection : LedgerInAccAllocations]
Source Collection : Default
Walk : InventoryEntries, AccountingAllocations
By : LedgerName : $LedgerName
Compute : RateOfVA : $RateOfVAT:TaxClassification:$TaxClassificationName
Aggr Compute : Amount : Sum : $Amount
Filter : IsVATLedgerinAcc
[System: Formula]
IsVATLedgerinAcc : $$IsSysNameEqual:VAT:$TaxType:Ledger:$LedgerName
While printing a voucher as an invoice, if an aggregation has to be done on its tax ledgers to show as summary within the invoice, this has to be collected from the accounting allocations of the same voucher.
A collection can extract information from other collections, including its sub-objects with the choice of method(s), filter(s) and sort-order. Source Collection within a collection/collection(s) can be chained. In other words, Summary Collection can be used as Source Collection for some other Collections, and so on.
Example
[Collection : My Source Collection]
Type : Voucher
[Collection : My Summary Collection]
Source Collection : My Source Collection
Walk : Ledger Entries
By : MyLedgerName : $LedgerName
Aggr Compute : MyTotal : Sum : $Amount
[Collection: My Parent Summary Collection]
Source Collection : My Summary Collection
By : MyParent : $Parent:Ledger:$LedgerName
Aggr Compute : MyParentTotal: Sum : $MyTotal
In this code snippet, My Parent Summary Collection extracts a sub-set of information from a collection to an already summarized collection My Summary Collection.
The capabilities discussed above extend the data gathering capabilities of TDL. However, business reporting in general and in Tally uses hierarchical presentation or columnar presentation, rather than simple table representation. This creates a unique and natural experience of working with the product and business data.
In case one simply repeats the summarized collection and gets the desired report, everything works fine with the existing capabilities. However, if the Report is having two or more dimensions like Ledger, Cost Center and so on, a simple repeat on the summarized collection will not suffice. Let us understand the same with the help of an example.
Example
When a Report is to be designed with ledgers as rows and cost centers as columns, the following options are available:
● Use function(s) like $$CollectionField or $$FilterValue in each column.
● Create Summary Collection for each column.
The first one will scan through the whole collection for every value required. The second one will scan the whole source data as many times as the number of columns. Both of them will take a significant hit on the scale and volume that it can handle, and affect the resultant performance.
To provide presentation capabilities beyond simple tables, a new capability has been added to the ‘Collection’ definition. A search key can be defined in the collection using the ‘ Search Key ’ attribute. This implies that a unique key is created for every object, which can be used to instantly access the corresponding objects and their values without needing to scan or re-collect. The corresponding function created to access the same is $$CollectionFieldByKey .
Example
[Collection : LedCC]
Use : Voucher Collection
Walk : LedgerEntries, Category Allocations, Cost Centre +
Allocations
By : PartyLedgerName : $PartyLedgerName
By : Cost Centre Name : $Name
Aggr Compute : Amount : $Amount
Search Key : $PartyLedgerName + $CostCentreName
[Field : My Rep Field]
Set as : $$CollectionFieldByKey:$Amount:@MySearchKey:LedCC
MySearchKey : #LedName + #CCName
In Collection LedCC , a search key is created for every object with the help of Ledger Name and Cost Center.
Now, on any row/column in the report, combination total is accessed using
$$CollectionFieldByKey:$Amount:@MySearchKey:LedCC
Where,
MySearchKey is the formula to get the Ledger Name + Cost Center name at a particular point, LedName is the Field having LedgerName in current context, and CCName is the variable storing the Cost Centre Name in current context.
Now, Objects of the Summary Collection can be exposed to Tally ODBC Interface through Collection attribute ‘Is ODBC Table’. The values of the Collection attributes “Fetch’, ‘Compute, ‘By’ and Aggr Compute’ are available through Tally ODBC Interface.
Syntax
[Collection : <Name of Summ Col l >]
Is O D BC Table : <Logical value>
Where,
< Name of Summ Coll > is the name of the Summary Collection
< Logical value > can be either YES or NO.
Example
[Collection : Source Collection]
Type : Voucher
[Collection : Summary Collection]
Source Collection : My Source Collection
Walk : Ledger Entries
By : LedgerName: $LedgerName
Aggr Compute : Total : Sum : $Amount
Compute : Parent: $Parent:Ledger:$LedgerName
Is ODBC Table : Yes
The values of methods of the ‘Summary Collection’, ‘LedgerName’, ‘Total’ and ‘Parent’ are exposed to the Tally ODBC interface.
Collection capability has been enhanced to gather live data from HTTP/web-service delivering XML. The entire XML is now automatically converted to TDL objects and is available natively in TDL reports as $ based methods. There is no need to access the data via specialized functions, like $$XMLValue. Reports can be shown live from an HTTP server. Coupled with the new [OBJECT:] extensions and POST action, you can also submit data back to the server almost operating Tally as a client to HTTP-XML web-services.
Consider the following XML data stored in file TestXML.xml available at server Remote Server.
<CUSTOMER>
<NAME>Sapna Awasthi</NAME>
<EMPID>1000</EMPID>
<PHONE>
<OFFICENO>080-66282559</OFFICENO>
<HOMENO>011-22222222</HOMENO>
<MOBILE>990201234</MOBILE>
</PHONE>
<ADDRESS>
<ADDRLINE>C/o. Info Solutions</ADDRLINE>
<ADDRLINE>Technology Street</ADDRLINE>
<ADDRLINE>Tech Info Park</ADDRLINE>
</ADDRESS>
</CUSTOMER>
This capability allows us to retrieve and store this data as objects in Collection. The attributes in collection for gathering XML-based data from a remote server over HTTP are RemoteURL, RemoteRequest, XMLObjectPath, and XMLObject. Whenever the collection is referred to, the data is fetched from the remote server and is populated in the collection.
Syntax
[Collection : <Collection Name>]
RemoteURL : http-url
RemoteRequest : <request-report-name>,<pre-request-display-report> : <encoding type>
XMLObjectPath : <Start-node> : <Path-to-start-node>
XMLObject : <TDL-Object-Name>
Where,
Remote–URL attribute is used to specify the URL of the HTTP server delivering the XML data
RemoteRequest attribute is used to specify the Report name which is to be sent to the HTTP server as an XML Request. If the report requires user inputs, then it has to be accepted before the request is sent. Pre-request display report specifies the name of the report which accepts the user-input.
XMLObjectPath attribute is used when only a specific fragment of the response XML is required, and converts the same to TDL Objects in the Collection. By default, it takes the root node.
< Start-Node > allows you to specify the name and position of the XML node from which the data should be extracted. It takes two parameters as follows:
<Node N a me> : <Position>
< Path-to-Start-Node > is used to specify the path to reach the <start node> from the root node.
The path specification is:
<Root-node> : <Child Node> : < S tart Pos> : <Child Node> : <Start Pos> …
XMLObject attribute is used to specify the TDL Object specification. The following syntax is used for object specification:
[Object : < O bject Name>]
Storage : <Name> : T ype
Collection : <Name> : T ype
/* The second Parameter in the Collection Type can be a Object type in case of a complex collection or a simple data type in case of simple collection */
All these attributes cater to specific requirements based on the GET request or POST request, and whether the obtained data is stored in Tally.
In order to retrieve the data available in TestXML.xml file from a remote server (Pre-defined IP Address), ensure that web service is running on the machine. Check for IIS Server Installation. The file TestXML.xml can be copied to the directory C:\Inetpub\wwwroot to be accessible at the root and then the URL can be specified as follows: http://localhost/TestXML.xml.
If the XML request needs to be processed at the remote server by a file (.asp, .php, etc.), at least one web server (e.g., IIS, Apache etc) and PHP/ASP must be installed on the system.
If it is required to access the data (XML format) from remote server in a collection, it is sufficient to specify the URL of the server only. The attribute RemoteURL is used. The data thus obtained is available in the collection as objects and can be accessed as native methods.
The collection to populate XML Data available at the URL http://Remoteserver/TestXML.xml is created as follows:
Example
[Collection : XML Get Collection]
Remote URL : "http://RemoteServer/TestXML.xml"
This collection can be used in a TDL Report to display the data retrieved. The method names will be same as the XML Tag names.
By default, all the data from XML file is made available in the collection. If only a specific data fragment is required, it can be obtained using the collection attribute XML Object Path.
Example
From the XML file, if only the address is required, then the collection is defined as follows:
[Collection : XML Get CollObjPath]
Remote URL : "http://Remoteserver/TestXML.xml"
XML Object Path : ADDRESS:1:CUSTOMER
Consider that the XML file on the remote server contains multiple customer objects, with the hierarchy mentioned earlier. The file “TestXML.xml” has the following structure:
<CUSTOMERS>
<CUSTOMER>
.
.
</CUSTOMER>
<CUSTOMER>
.
.
</CUSTOMER>
<CUSTOMER>
.
.
</CUSTOMER>
</CUSTOMERS>
If the address of the second Customer is required, then the collection is defined as shown:
[Collection : XML Get CollObjPath]
Remote URL : "http://Remoteserver/TestXML.xml"
XML Object Path : ADDRESS : 1 : CUSTOMERS : CUSTOMER : 2
Consider that the Address further contains data as shown:
<CUSTOMER>
.
.
<ADDRESS>
<PHONE> 9902012345 </PHONE>
<PHONE> 9902099020 </PHONE>
</ADDRESS>
.
</CUSTOMER>
In this case, to retrieve the second phone number of the third customer, the collection is defined as follows:
[Collection : XML Get CollObjPath]
Remote URL : "http://Remoteserver/TestXML.xml"
XML Object Path : PHONE : 2 : CUSTOMERS : CUSTOMER : 3 : ADDRESS : 1
The data available in XML format is at the URL “http://Remoteserver/TestXML.xml”. The data is required to be mapped as TDL Objects. The collection attribute XML Object is used to specify the object name to which the obtained data is mapped.
Example
[Collection : XML Get Collection]
Remote URL : "http://Remoteserver/TestXML.xml"
XML Object : Customer Data
The Object specification for “Customer Data” is as follows:
[Object : Customer Data]
Storage : Name : String
Storage : EmpId : String
;; Complex Collection
Collection : Phone : XML Phone Coll
;; Complex Collection
Collection : ADDRESS : XML AddressColl
[Object : XML Phone Coll]
Storage : OfficeNo : String
Storage : HomeNo : String
Storage : Mobile : String
[Object : XML AddressColl]
;; Simple collection
Collection : AddrLine : String
If a TDL report is to be sent to the HTTP server as an XML request, and the XML response is to be obtained in the collection, then the collection attribute “Remote Request” is used. The attribute “Remote Request” takes a Report name as a parameter, which sends the request in XML format to the web page on the remote server. The response data received from the server is then available in the collection.
Example
The Test.php page on the remote server accepts the data in the following XML format.
<ENVELOPE>
<REQUEST>
<NAME>Tally</NAME>
<EMPID>00000</EMPID>
</REQUEST>
</ENVELOPE>
The following collection sends the request in the above XML format with the help of a TDL report XMLPostReqRep. The encoding scheme selected is ASCII.
[Collection : XML Post Collection]
Remote URL : "http://Remoteserver/test.php"
RemoteRequest : XMLPostReqRep : ASCII
XMLObjectPath : CUSTOMER
The report XMLPostReqRep is automatically executed when the collection is referred. In the Report, the XML Tag attribute is used at ‘Part’ and ‘Field’ Definitions.
[Part : XMLPostReqRep]
XML Tag : "REQUEST"
Scroll : Vertical
[Field : XMLPostReqRepName]
XML Tag : "NAME"
Set As : " Tally "
[Field : XMLPostReqRepPwd]
XML Tag : " EMPID "
Set As : " 00000 "
The XML Tag <Envelope> is added by Tally while sending the XML request.
The response received from http://Remoteserver/test.php page is the same XML given previously. The data now available in the collection can be displayed in a report.
A Pre-Request report is required when some inputs are to be accepted from the user, and the XML Request is to be generated out of those inputs. In that case, a TDL report is used which has to be accepted first. If the data captured through pre request report has to be sent to remote server for processing, then it has to be made available in the Request report. The input report name is specified as Pre-Request report.
[Collection : XML Post Collection]
Remote URL : "http://localhost/test.php"
RemoteRequest : XMLPostReqRep, XML PreReqRep : ASCII
XMLObjectPath : CUSTOMER
Report XMLPostReqRep sends the XML request to the page Test.php in the format described earlier. Before sending the XML request to the page, data entered in the report XML PreReqRep must be accepted. The data entered in the Pre-Request report can also be sent to the remote server in the XML request. Both the reports are triggered when the collection is referred.
A new Key/Button Action HTTP Post has been introduced which will help in exchanging data with external applications using web services. In other words, ‘HTTP Post’ Action can be used to submit data to a server over HTTP and gather the response. This will enable a TDL Report to perform an HTTP Post to a remote location.
Syntax
[Key : <Key Name>]
Key : <Key Combination>
Action : HTTP Post : <URL Formula> : <Encoding> : <Request Report>: <Error Report> : <Success Report >
Where,
< URL Formula > can be any string formula which resolves as an URL, and is defined under System Definition.
< Encoding > is the encoding scheme, which can be ASCII or UNICODE.
< Request Report > is the name of TDL Report used for generating the XML Request to be sent.
< Error Report > is displayed in case of failure.
< Success Report > is displayed when the post is successful.
Details pertaining to URL (at the receiving end), Encoding Format, Request Report, Error Report and Success Report should be specified along with HTTP Post Action. Universal Resource Locator (URL), for which information is intended, has to be specified through a System Formula.
Encoding Format specifies the encoding to be used while transmitting information to the receiving end. The valid encoding formats are ASCII and UNICODE. UNICODE is set by default.
Request Report is the name of the TDL Report which will be used for generating XML Request to be sent. Error Report and Success Reports are optional, and will enable the programmer to display a Report with the details of the XML response received.
Success or failure is determined by <STATUS> tag in the standard message format. If it is 1, it is a success, otherwise it is a failure. Based on the value of the <STATUS> tag (0/1), the error report and success report are executed, respectively. It will not close or accept the form, if status is not equal to 1. Both Request as well as Response are exchanged in XML format.
Example
[Key : XMLReqResp]
Key : Ctrl + R
Action : HTTP Post : @@MyUrl : ASCII : ReqRep: ERRRespRep : SuccRep
Scope : Selected Lines
;;URL Specification must be done as a system formula
[System : Formula]
MyUrl : http://127.0.0.1:9000
The defined Key XMLReqResp in the code snippet must be attached to an initial Report. When the report is activated and this Key is pressed, the Action HTTP Post activates a defined report ReqRep, which generates the request XML. The response data is made available in the collection called Parameter Collection . The reports ERRRespRep and SuccRep can use the Parameter Collection to display the error message/data in the Report.
Note: The XML response received for the action HTTP POST must be in the Tally compatible XML format. The file “XML for HTTP POST” shows the format received as a reponse from the PHP application file “CXMLResponse as per Tally”.
A Collection in TDL, as we all understand, can populate the data from a wide range of sources, which are available as Objects in the Collection. The various sources of Objects in Collection are:
● External Objects, i.e., Objects created by the TDL programmer.
● Internal Objects, i.e., All Internal Objects provided by the platform, and stored in the Tally DB. For example, Ledger, Group, Voucher, Cost Centre, Stock Item, etc.
● Objects populated in the collection from an external database using ODBC, referred to as ODBC Collection.
● Objects populated in collection from an XML file present on the remote server over HTTP. This collection is referred to as an XML Collection.
● Objects obtained after aggregation of data from lower level in the hierarchy of internal objects.
Tables are based on Collections. Prior to this release, not all collection types, as given above, could be used as tables. Not all internal objects were available in the Table. Only the masters, i.e., Groups, Ledgers, Stock Items, etc., could be displayed in the Table. Using Vouchers in the table was not possible. Data from ODBC Collection was also not possible to be displayed.
From this Release onwards, all limitations pertaining to the 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.
Prior to this release, the following types of Collections could not be used as Tables:
● Voucher Collection As Table
● Collections with Aggregation As Table
● Displaying information at lower levels in Object hierarchy in a Table
● Displaying aggregate methods in Table
● Displaying ODBC Collection As Table
● Displaying XML Collection As Table
Let us consider the following examples to understand the capability in a better way:
Now , the Vouc h ers can be displayed as table in a field.
Example: Voucher Collection as Table
[Collection : Vch Collection]
Type : Voucher
Filter : PurcFilter
Format : $VoucherNumber, 10
Format : $VoucherTypeName, 25
Format : $PartyLedgerName, 25
Format : $Amount, 15
[System : Formula]
PurcFilter : $$IsPurchase:$VoucherTypeName
;;Field displaying Table
[#Field : EI OrderRef]
Table : Vch Collection
Show Table : Always
Example: Displaying Inventory Entries (lower level information in Voucher) As Table
[Collection : Vch Collection]
Type : Voucher
Filter : PurcFilter
[Collection : Summ Collection]
Source Collection : Vch Collection
Walk : Inventory Entries
By : Name : $StockItemName
[System : Formula]
PurcFilter : $$IsPurchase:$VoucherTypeName
;; Field displaying Table
[#Field : EI OrderRef]
Table : Summ Collection
Show Table : Always
Example: Displaying Collections with aggregate methods As Table
[Collection : Vch Collection]
Type : Voucher
Filter : PurcFilter
[Collection : Summ Collection]
Source Collection : Vch Collection
Walk : Inventory Entries
By : Name : $StockItemName
Aggr Compute : BilledQty : Sum : $BilledQty
Aggr Compute : Amount : Sum : $Amount
Format : $Name, 25
Format : $BilledQty, 25
Format : $Amount, 25
[System : Formula]
PurcFilter : $$IsPurchase:$VoucherTypeName
;;Field displaying table
[#Field : EI OrderRef]
Table : Summ Collection
Show Table : Always
Example: Data fetched from Excel file in Collection displayed as Table
In this example, the excel file “Sample Data.xls” containing data is present in the path “C:\Sample Data.xls”. If the complete path is not specified, it locates the Excel file in Tally application folder.
[Collection : ODBC Excel Collection]
ODBC : "Driver= {Microsoft Excel Driver (*.xls)};DBQ= C:\Sample Data.xls"
SQL : "Select * From [Ledgers$]"
Format : $_1, 25
Format : $_2, 20
Format : $_3, 15
Format : $_4, 25
;; Field displaying table
[#Field : EI OrderRef]
Table : ODBC Excel Collection
Show Table : Always
This refers to XML Data fetched from Remote URL in Collection as Table. Following is the XML Data Sample to be retrieved from the Remote URL:
<CUSTOMER>
<NAME>Keshav</NAME>
<ADDRESS>
<ADDRLINE>Line1</ADDRLINE>
<ADDRLINE>Line2</ADDRLINE>
<ADDRLINE>Line3</ADDRLINE>
</ADDRESS>
<ADDRESS>
<ADDRLINE>Line1</ADDRLINE>
<ADDRLINE>Line2</ADDRLINE>
<ADDRLINE>Line3</ADDRLINE>
</ADDRESS>
</CUSTOMER>
In this example, the complete URL of the file is http://localhost/XMLData.xml. Here, the file XMLData.xml is located in the local machine. Instead of local host, the IP Address of the machine or 127.0.0.1 can be specified. The web service should be installed in the machine.
Example
[Collection : XML Table]
RemoteURL : "http://localhost/XMLData.xml"
XMLObjectPath : CUSTOMER
Format : $NAME, 25
;; Field displaying Table
[#Field : EI OrderRef]
Table : XML Table
Show Table : Always
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 the object added depends on the specification in the TYPE attribute. In case the TYPE attribute has not been specified, it defaults to adding a standard empty object. So if the TYPE is ledger, a ledger object would be added, and so on. However, the following hold 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 for deciding 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 collection:
NEWOBJECT : type-of-object : condition
Whenever a new object is to be added at the collection level, it will walk through the NEWOBJECT attribute specification and validate the condition specified. The first one which is satisfied, decides the type of object to be added. The object can be a schema defined internal object or a TDL defined object [OBJECT: MYOBJECT].
The capability to use objects defined in TDL is being separately enhanced and shown here for completeness of the NEW OBJECT attribute. As of now, these TDL defined objects can be used only for HTTP-XML based exchange with other systems to take input and send requests or receive XML and operate them like TDL objects. They cannot be persisted or saved into the Tally company database.
Please refer the following code snippet for Object specification:
Example: This collection can be used in a Report opened in ‘Alter’ Mode.
[Collection : Coll Customer]
;; New TDL Object Defined
New Object : Customer Data
[Object : Customer Data]
Storage : Name : String
Storage : CustId : String
;; Complex Collection
Collection : PhoneColl : Phone
Collection : AddressColl : Address ;; Complex Collection
[Object : Phone]
Storage : OfficeNo : String
Storage : HomeNo : String
Storage : Mobile : String
[Object : Address]
Storage : AddrLine1 : String
Storage : AddrLine2 : String
In case there is no NEW OBJECT specified, the existing behavior will continue for backward compatibility. In case of Sub-Objects like LedgerEntries, the same behaviour continues, since they are added by their parent objects and not by the Collection.
Enabling access to your organizational data ‘any-time, any-where’, and yet being truly usable, is what Tally.ERP 9 is capable of. 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 the attributes ‘FetchObject’ and ‘FetchCollection’ at the Report level, significantly help in the above functionality.
The remoting capabilities are discussed in detail in the next section Writing Remote Compliant TDL for Tally.ERP 9 .