In this release, the programmable configuration support has been extended to the actions ‘Print Report’, ‘Export Report’, ‘Upload Report’ and ‘Email Report’.
A new attribute Plain XML has been introduced at Report level to export the report in plain XML format. New functions $$StrByCharCode and $$InPreviewMode have been introduced, whereas the functions $$Inwords and $$ContextKeywords have been enhanced. New events ‘Start Import’, ‘Import Object’ and ‘End Import’ have been introduced for ‘Import File’ definition.
Collection Enhancemen t s
With every release, performance improvements are being brought, especially with respect to the data gathering and processing artefact ‘Collection’, used to gather and deliver data to presentation layers. Performance is enhanced drastically if collection is gathered judiciously as per usage.
Sometime back, the Collection attribute ‘Keep Source’ had been introduced for performance enhancement. This was used to retain the source collection gathered once with the specified Interface Object, i.e., either with the current Object or its parents/owners. It drastically improved the performance in scenarios where the same source collection was referred multiple times within the same Object hierarchy chain.
Similarly, there are scenarios where there is Union of multiple collections using the same source collection, and each collection walks over its sub objects across different paths, and computes/ aggregates the values from sub level. In such cases, significant CPU cycles will be utilized in gathering and walking over the same Source Object along different paths more than once.
A new attribute WalkEx has been introduced, which when specified in the resultant collection, allows us to specify a collection list. The source collection specification is available in the resultant collection. The collections referred in WalkEx do not have any source collection specified and contain attributes only to walk the source collection and aggregate over Sub Objects of an already gathered collection. The advantage of using WalkEx is that all walk paths specified in the collection list are traversed in a single pass for each object in the source collection. This results in improvements in performance drastically.
Syntax
[Collection : <Collection Name>]
WalkEx : <Collection Name1>, <Collection Name2>,..
Where,
< Collection Name1 >, < Collection Name2 >, and so on, are the collection names specifying Walk and aggregation/computation attributes.
Example
The requirement here is to generate a Report displaying Item Wise and Ledger Wise amount totals for all Vouchers.
;;The source collection “Voucher Source” is a Collection of Vouchers
[Collection : VoucherSource]
Type : Voucher
;;The collection using “Vo u cher Source” as a source c ollection, and walking over Ledger E ntries Sub-Object, aggregating Amount by gr o upin g ove r Ledge r Name
[Collection : Ledger Details]
Source Collection : VoucherSource
Walk : AllLedgerEntries
By : Particulars : $LedgerName
Aggr Compute : Tot Amount : Sum: $Amount
Keep Source : ().
;;The collection using V oucher Source as a source collection, a nd w alking over Inventory Entries Sub-Object, aggregating Amount by grouping over S tock Item Name
[Collection : StockItem Details]
Source Collection : Vouche r Source
Walk : AllIn ventoryEn t ries
By : Particulars: $StockIt e mName
Aggr Compute : Tot Am o unt : Sum: $Amount
Keep Source : ().
;;The Resul t ant Collection, which is a union of objec t s from the above two collections “ L edger D etails” and “ S to c kItem De t ails”
[Collection : Union LedStk Vouchers]
Collection : Ledger D etails, StockI t em Det a ils
In this example, both the collections ‘Ledger Details’ and ‘StockItem Details’ are using the same Collection ‘Voucher Source’. We can observe that while gathering and summarizing values from the source collection, each object of the collection ‘Voucher Source’ is traversed twice for aggregating objects over two different paths, i.e., once for ‘Ledger Entries’ and then for ‘Inventory Entries’. The report finally uses the Union collection ‘Union LedStk Vouchers’ to render the same.
Let us now move on to the new approach using “WalkEx” to achieve the same
;;The so u rce collection “ V oucher Source” is a Collection of V ou che rs
[Collection : VoucherSource]
Type : Voucher
/* The collection “ U nionLed S tkVouch e rs” is the resul t ant collection which will contain all the Objects obtained out of walks and multiple walks over the same S ou r ce C o l lection. The Report finally uses this Collection. T he attribute WalkEx is specified which has v alue s as collection names “Ledger Detail s ” and “StockItem De t ails”*/
[Collection : Union LedStk Vouchers]
Source Collection : Voucher S ource
WalkEx : Ledger Details, StockItem Details
Keep Source : ().
/*The C o llection “L e dger D etails” walks over “ A llLedgerEntries” Sub-Objects and aggregates the amount by grouping over L edger Name. Note the a b sence of source collection. */
[Collection : Ledger Detail s ]
Walk : AllLedg e rEntries
By : VchStoc k Item : $LedgerName
Aggr Compute : VchLedA m ount : Sum : $Amount
/*The Collection “StockIt e m De t ails” walks over “ AllInventoryEntries” Sub-Objects and aggregates the amount by groupi n g over Stock Item Name. Note the absence of S ource Collection in this. */
[Collection : StockItem Details]
Walk : AllInve n toryEntries
By : VchStoc k Item : $StockItem N ame
Aggr Compute : VchLedA m ount : Sum : $Amount
The Collections used within ‘WalkEx’ use the same Source Collection. Each Object of “Voucher Source” is walked across “Ledger Entries” and “Inventory Entries” in a single pass. Thus, there is an exponential improvement in performance as it traverses each object only once, to gather the values for the resultant collection. In the case of Union Collection, for every Collection using different walk path, the Source Collection Object is being traversed again and again.
Let us consider the following code design, to understand the implication on various other collection attributes, in cases where ‘Walk Ex’ is used.
;; Source Collection
[Collection : Src C o ll]
...
;;Resultant Collection “Res Coll” is using the S o urce C ollection “Src C oll”, and Walk Ex Colle c tio n s “ W al k E x C o l l 1 ” a nd “Wa l k Ex Coll 2” are specified
[Collection : Res C o ll]
Source Collection : Src Coll
WalkEx : Walk Ex Coll 1, Walk Ex Co l l 2
;;Walk Ex Coll 1
[Collection : Walk Ex Coll 1]
Walk : Path1, SubPath1, SubSubPat h 1
By : GroupName1 : $Meth o d1
;;Walk Ex Coll 2
[Collection : Walk Ex Coll 2]
Walk : Path2, SubPath2, SubSubPat h 2
By : GroupName2 : $Meth o d2
The following table shows the attributes of ‘Collection’ definition and their applicability in the Resultant collection as well as WalkEx collections.
|
Attributes |
Resultant Collection |
Walk Ex-Collections |
|
Source Collection |
Specified and applicable |
Ignored |
|
Keep Source |
Specified and applicable |
No significance |
|
Is Client Only |
Specified and Considered |
Ignored |
|
Sorting |
Specified and applicable |
Ignored |
|
Filtering |
Specified and applicable |
Ignored |
|
Max |
Specified and applicable |
No significance |
|
Parm Var |
Specified and Considered |
Ignored but to be inherited from the resultant collection |
|
Source Var |
Specified and Considered |
Specified and applicable |
|
Compute\Filter Var |
Specified and applicable |
Specified and applicable |
|
Fetch |
Specified and applicable |
Specified and applicable |
|
Compute |
Specified and applicable |
Specified and applicable |
|
Aggr Compute |
No significance |
Specified and applicable |
|
Walk\By |
If Specified these two attributes WalkEx will be ignored |
Specified and applicable |
As we are already aware, a collection can be populated dynamically using the data available from a variety of external data sources. A common attribute ‘Data Source’ is used to specify the Type and identity of the source from where the data is to be retrieved. Thereafter, the data is available as objects and the associated information can be extracted from them using the corresponding methods. For example, if the data is populated from an XML file, the tag names are referred to as the method names. In case the data is populated from a compound variable, the corresponding member variable names are referred to as method names.
Prior to this release, the Data Sources supported were:
● XML available over HTTP/HTTPS using Post/Get methods
● XML File available within the local disk or over a network
● Output XML from an External DLL
● Specific Objects from Current/Parent Report
● Variable
Syntax
Data Source : <Type> : <Identity> [:<Encoding>]
Where,
< Type > specifies the type of data source: File Xml/HTTP Xml/Report/Parent Report/DLL/Variable
< Identity > can be file path, scope, etc., depending on the type specification.
< Encoding > can be ASCII or UNICODE. This is Optional. The default value is UNICODE.
From release 3.0 onwards, the collection attribute Data Source has been enhanced to support “Directory” as data source type. This will enable to gather all information pertaining to the contents of the disk directory/folder. Each folder constituent, i.e., either File or Directory, along with its corresponding details, are available as an object in the collection.
Let us consider the directory/folder “ABC”, as shown in the following figure:
.jpg)
The folder contains two files “a.txt” and “b.txt” and the folder “abcsub”. In order to retrieve the item details along with the corresponding information like type, size and date modified within a collection, the attribute ‘Data Source’ can be specified with the new enhanced syntax as:
Syntax
[Collection : <Collection Name>]
Data S o urce : <Type> : <Identity> [:<Encoding>]
Where,
< Collection Name > is the name of the collection where the data is populated as objects.
< Type > specifies the type of data source. As per the new enhancement, it is “Directory”.
< Identity > is the Directory/folder Path, when the type specified is ‘Directory’
< Encoding > can be ignored for Type “Directory”.
The following code will populate the collection “ABC Contents” with the folder contents from the path “C:\ABC”. In this case, each of the items, i.e., a.txt, b.txt and “abcsub”, will be available as separate objects of the collection. The related information pertaining to each object will be available as methods $name, $filesize, $IsDirectory, $IsReadOnly, $IsHidden, etc.
[Collection : ABC C o ntents]
Data Source : Directory : "C: \ ABC"
Note: $filesize is applicable only if the object is of type FILE.
Over the years, there has been a major requirement from the user community to enable Image Printing in Tally. Earlier, we used to achieve this capability by creating a new Font Type by associating an Image with a particular character and further using the ‘Style’ for the field. This had a few limitations in terms of image size, resolution and color. Also, it was not a clean way of incorporating the feature.
From this release onwards, Image Printing is being supported with the help of the following latest enhancements:
● ‘Graph Type’ attribute of Part allowing the specification of BMP, enabled for ‘Print’ Mode
● A new Definition Type ‘Resource’ introduced in TDL
The configuration settings allow the user to specify the location of the Image file and the same is printed as a logo on the top left of the following default Reports.
● Sales Invoice - both Normal and Simple formats
● Delivery Note/Challan
● Debit Note
● Credit Note
● Outstanding Receivables
● Remainder Letters
● Pay Slips
● Purchase Order
● Receipt voucher
● Confirmation of Accounts
Prior to Tally.ERP 9 release 3.0, specification of Image (as BMP only) within a part was supported. The attribute Graph Type of the part is used for the same.
Syntax
[Part : Par t Name]
…
Graph T ype : Yes/Bitmap Image Path
Where,
<Graph Type> accepts ‘Yes’, or a path of the bmp file. If the value of <Graph Type> is “Yes”, then it will be treated as a graph. If the value is not “Yes”, then system will look for a Bitmap file with the given expression. However, the bitmap image was only supported in the ‘Display’ Mode.
From this Release onwards, this capability has been extended to ‘Print’ mode also. A few points are to be considered:
1. The attribute ‘Graph Type’ supports Bitmap and JPG/JPEG. If the image type is specified as a JPEG/JPG, it will consume the same. If it is of any other type, this will be considered as BMP and the same will be located from the path specified. If the file is unavailable or is not a valid image file, then the area allocated for image will be blank.
2. The Part containing ‘Graph Type’ cannot display or print any contents and any contents specified within the fields will be ignored. That's why it requires the specification of dummy lines and fields within the part.
3. Part Height and Width must be apportioned appropriately as per the Image size to be printed [If the height and/or width is not given, then the system will take the actual image size and use the same for display]. If the user has specified Height and/or width which is different from actual image size, then the system will do proportionate resizing of the image to fit into the given area [For example, let's say that area allocated for the image is 300 X 300 and actual image size is 150 X 75. Then, the system will display image in 300 X 150].
A new definition type “Resource” has been introduced in TDL. This will allow accessing and using the resources (images, icons, cursors, etc.) from a local disk, HTTP/FTP or from a DLL/EXE. The image formats supported at present are BMP/JPEG/ICON/CUR. The resource thus created can be used in a ‘Part’ definition using the attribute “Image”. This is applicable both in ‘Print’ and ‘Display’ mode.
Note : However, when the same report is exported in PDF, only BMP and JPEG are sup- ported. Other file formats will be ignored.
Syntax
[Resource : Name]
Source : <Path to Image file>
Resource : <NameOfResource> [:<DLL/EXE Name with path > ]
Resource Type : Bitmap/Icon/Jpeg/Cursor
This is a ‘Single’ type attribute, and hence accepts only one parameter. It allows us to specify the image file path. This file can be a local disk file, or a file available over an HTTP/FTP path.
Syntax
Source : <P a th to Image file>
Where,
<Path to Image file> can be any string expression which evaluates to the file path, along with Filename and extension.
Example: 1
[Resource : CmpImag e]
;; where the image “Tally.bmp” is available in local disk
Source : “C : \Tally. b mp”
Example: 2
[Resource : CmpImag e ]
Source : “ H t tp://ww w.tally s olution s.com/i m ages/ta llyHTTP . JPE G”
;; wh e re the image t ally H TTP.JPEG is available over an HTTP Path
This is a ‘Dual’ type attribute and accepts two parameters. The first parameter refers to the resource name present in an Exe/DLL. The second parameter is used to specify the path and the name of Exe/DLL. However, this is optional. In case not specified, the system will look for the resource within tally.exe itself.
Syntax
Resource : <NameOfResource> [:<DLL/EXE Name with path>]
Where,
< Name of Resource > is a string expression which evaluates to the name of the resource present in the specified DLL/EXE (When resources are added to DLL/EXE, the user can give a separate name for the resource).
< DLL/EXE Name with path > can be a string which evaluates to the complete DLL/EXE path.
Example: 1
[Resource : CmpImag e ]
Resource : “TITLEICO N ”
;; This uses the resource “TITLEICON” present in Tally exe, as we have not specified the EXE path.
Example: 2
[Resource : CmpImag e ]
Resource : "60040" : C :\ProgramFiles \ Windows N T + \Ac c essories\wordp a d.exe
Resource Type : BMP
;; This uses the resource "60040" present in the wordpad.exe, as we have specified the EXE path as the second parameter.
Note : The attribute “Source” and “Resource” are mutually exclusive, i.e., either of them can be used. We cannot use both together. If both are specified in TDL, then the system will use SOURCE and ignore the RESOURCE attribute.
This is a ‘Single’ type attribute, and hence accepts only one value as a parameter. It allows the specification of Type of the resource. ‘Type’ can be any one of the standard windows image resources like Bitmap, Icon, Cursor or JPEG. The type specified in ‘Resource Type’ will be used for loading the image appropriately.
‘Resource Type’ is a mandatory attribute and must be specified for all sources. If not specified, the type would taken as ‘Bitmap’ by default.
Note: For the Icon resources - the nearest sized Icon will be taken. For example, if we have two Icons 16X16 and 32X32 and the part size is 20X20, then the 16X16 icon will be used for displaying.
Syntax
Resource T y pe : BMP/Icon/Jpeg/Cursor
Example
[Resource : CmpImag e ]
Source : “C:\Tally. b mp” Resource Type : BMP
With the introduction of the new attribute “Image”, it is possible for the resource created by using the Definition “Resource” to be used in the Part.
Syntax
[Part : Par t Name]
…
Image : <Resource Name>
Where,
<Resource Name> is the name of the Resource definition.
Example
[Part : Part ABC]
Image : Cmp I mage
A matrix report looks like a grid. It contains a row of labels, a column of labels, and information in grid format that is related to both the row and column labels. In Tally, two dimensional matrix reports can be designed using the Auto column report approach (using Repeat Variables). Traditionally, these types of Reports are referred to as columnar Reports. In particular, Matrix report is a variant of automatic auto column reports, where the columns are repeated over a variable associated at the Report. The collection repeated with this variable is used to populate the repeated values into the variable. The method value in the detail line is extracted from a different collection, based on the corresponding row and column indexes.
Following is a typical two-dimensional matrix report showing the total number of stock items sold for each party.
.jpg)
The latest enhancements in the area of Columnar Reporting enables us to design the reports using a new approach altogether. A field within a line can display method values from multiple objects of the collection. Context Free repeat within the part and line enable repetition on simple as well as list variable values. These features give a better control in the hands of the programmer
These features give a better control in the hands of the programmer in designing such reports.
If we consider the above report layout, the labels in columns can now repeat over a collection of Parties. The data in the cells can be populated based on the combination of row and column label values across the dimensions. In the previous table, for example, the highlighted cell contains the value of total sales quantity corresponding to the party “Party 2” for the Stock Item “Stock Item 2”.
The following enhancements have been enabled to achieve this functionality:
● ‘Repeat’ Attribute for Part and Line over a Collection
● Context Free Repeat for Part and Line, together with SET/Break On
● Usage of the function $$LineObject
The ‘Repeat’ Attribute has been enhanced consistently across ‘Part’ and ‘Line’ Definitions to support “Context Based” as well as “Context Free” Repeat.
The common syntax allows the repetition of a contained line, with or without a collection.
Syntax
[Part : <Pa r t Name>]
Repeat : <Line Name> [: <Collection>]
Set : <Count>
Where,
< Part Name > is the name of the part.
< Line Name > is the name of the line to be repeated.
< Collection > is the name of collection on which the line is repeated. It is an optional parameter.
< Count > denotes the number of times the line is to be repeated, if Collection Name is not specified.
Context based Repeat – The ‘Repeat’ attribute of the Part can repeat the contained line over a collection. Each line in this case is associated with each object of the collection. This was the earlier capability even before Tally.ERP 9.
Context Free Repeat – From Release 1.8, the Collection parameter in the above syntax has been made optional. This allows the repetition of a contained line without a collection. Since the no. of times the line has to be repeated is not known, the usage of the attribute SET to specify the count becomes mandatory. In case of ‘Edit’ mode, the attribute ‘Break On’ can be used to specify the terminating condition for repetition.
So far, the ‘Repeat’ attribute at ‘Line’ definition has been accepting only a field name which internally uses the repeat behaviour of the Report and Variable for determining the no. of times it can be repeated. This attribute has now been enhanced to support the consistent syntax to enable “Context Based” and “Context Free” repetition of the same field horizontally.
Syntax
[Line : <Li n e Name>]
Repeat : <Field Name> [: <Collection Name>]
Set : <Count>
Where,
< Line Name > is the name of the Line.
< Field Name > is the name of the Field to be repeated.
< Collection Name > is the name of the collection on which the Field is repeated. It is optional.
< Count > denotes the no. of times the Field has to be repeated, if collection name is not specified.
Context based Repeat – The ‘Repeat’ attribute of the line can repeat the contained field over a collection. Each field in this case is associated with each object of the collection.
Context Free Repeat – The collection parameter in the above syntax is optional. This allows the repetition of a contained field without a collection. Since the no. of times the field is to be repeated is not known, the usage of the attribute SET to specify the count becomes mandatory. In case SET is not specified, the Field will be repeated as per the existing Columnar behaviour.
Example 1: Item-Wise Party-Wise sales quantity report using Context-Based Repeat of Field
Following screen shows the Item-wise-Party-wise Report using enhanced columnar capability:
.jpg)
Following is the code snippet to design the above report using enhanced columnar capability:
1. Collection definitions for Stock Item, for Party, for getting the values, etc., are as follows:
[Collection : Smp CFBK Voucher]
Type : Voucher
Filter : Smp IsSales V T
[Collection : Smp S t ock Ite m ]
Source Collection : Smp CFBK Voucher
Walk : Invento r y Entri e s
By : IName : $StockIt e mName
Aggr Compute : BilledQ t y : SUM : $BilledQty
Keep Source : ().
Filter : SmpNonE m ptyQty
[Collection : Smp CFBK Party]
Source Collection : Smp CFBK Voucher
Walk : Invento r y Entri e s
By : PName : $PartyL e dgerName
Aggr Compute : BilledQ t y : SUM : $BilledQty
Keep Source : ().
Filter : Smp NonEmptyQty
[Collection n : Smp C F BK Summ Voucher]
Source Collection : Smp CFBK Voucher
Walk : Invento r y Entri e s
By : PName : $ PartyLedgerName
By : IName : $ StockItemName
Aggr Compute : BilledQ t y : SUM : $BilledQty
Keep Source : ().
Search Key : $PName + $IName
;; System Formu l a
[System : Formula]
Smp IsSales V T : $$ I sSales:$VoucherT y peName
Smp NonEmpt y Qty : NOT $$IsEmpty:$BilledQty
From these Collections, following can be observed:
● The Rows, i.e., Stock Items, are repeated over the Collection ‘Smp Stock Item’.
● The Columns, i.e., Party Names, are repeated over the Collection ‘Smp CFBK Party’.
● The Intersection values between these Rows and Columns, i.e., Item wise Party wise Sales Quantity, are set using the Collection ‘Smp CFBK Summ Voucher’. This Collection is indexed on Methods $PName + $IName using the Collection Attribute ‘Search Key’. Thus, the Collection is indexed on Party Name and Stock Item Name, which makes it unique across all the Objects within the Collection ‘Smp CFBK Summ Voucher’.
The Lines for Title and Details are repeated for the Party Names as shown below:
[Line : Smp C FBK Rep Title]
Use : Smp CFBK Rep Detai l s
Local : Fie l d : Default : Type : String
Local : Fie l d : Default : Align : Center
Local : Fie l d : Smp CFBK Rep Name : Set as : “Particular s ”
Local : Fie l d : Smp CFBK Rep Name : Widespaced : Yes
Local : Fie l d : Smp CFBK Rep Party : Set as : $PName
Local : Fie l d : Smp CFBK Rep Party : Lines : 0
Local : Fie l d : Smp CFBK Rep ColTotal : Set as : “Total”
[Line : Smp C FBK Rep Details]
Fields : Smp CFBK Rep Nam e , Smp CFBK Rep Party , S mp CFBK Rep Col Total
Repeat : Smp CFBK Rep Party : Smp CF B K Party
Title Line uses the detail line where the Field “Smp CFBK Rep Party” is repeated over the Collection “Smp CFBK Party”. In the Title Line, the Field “Smp CFBK Rep Party” is set with the value “$PName”, which sets the Party Names from the Collection “Smp CFBK Party”.
2. Retrieving the values in cells based on Party name available from context and stock item name available in the field as shown below:
[Field : Smp CFBK Rep Name]
Use : Name Fi e ld
Set as : $IName
Display : Stock V o uchers
Variable : Stock I t em Name
[Field : Smp CFBK Rep Party]
Use : Qty Primary Field
Set as : $$ReportObject : $$CollectionFi e ldByKey:$Bille d Qty:@SKForm u la:SmpCFBKSumm V oucher
SKFormula : $PName + #SmpC F BKRepName
Format : “NoZero”
Border : Thin Le f t
In this code snippet, we can observe that the Field “Smp CFBK Rep Party” is the intersection between rows & columns. The value is gathered from the Collection “Smp CFBK Summ Voucher” using the function $$CollectionFieldByKey, where the Index Key in the current context is passed as a parameter. “$PName” in the current object context returns the Party Name. Similarly, the Field Value “#SmpCFBKRepName” in the current context returns the Stock Item Name. Hence, the Search Key Index “Party Name + Stock Item Name” for every Intersection point is passed to this function, which extracts and returns the corresponding Quantity from the Collection.
3. Calculating Field Level To t als, i.e., Stock Item T o t als, across a ll Parties is d o ne using the Line Attrib u te ‘ T o t al ’ and the Fu n ction $$ T o t a l , as shown below:
[Line : Smp C FBK Rep Details]
Total : Smp CFBK Rep Party
[Field : Smp CFBK Rep Col T o tal]
Use : Qty Primary Field
Set as : $$ T otal:SmpCFBKRe p Party
Line “Smp CFBK Rep Details” contains an Attribute ‘Total’, which accepts Field Names as its value. In other words, we declare at the Line that the Fields are to be summed for later use. This sum gets accumulated and rendered in the Field “Smp CFBK Rep Col Total”, where the function
$$Total returns the accumulated Total for the given Field Name as the Parameter to this Function.
Since the Line Attribute ‘Field’ can now be repeated over a Collection, wherein the Object context inherited from the Line is overridden in the Field; to switch back to the parent context, i.e., Line’s object context and extract the required method value, a New Function $$LineObject has been introduced.
Syntax
$$LineObject : <String Formula>
Where,
<String Formula> can be any expression that gets evaluated in the Object context associated at the current field's parent ‘Line’ in the Interface Object hierarchy.
The Actions “Remove Line”, “Show Last Removed Line” and “Show Removed Lines” work on the concept of Object Identifier. Whenever the collection of internal objects is rendered as a report, the default buttons "Remove Line" and “Restore Line” using the above actions work on them as they are uniquely identifiable.
In cases where the Collection used contains aggregated Objects, or objects from an external data source like XML, etc., the objects available do not contain a unique identifier. When such collections are rendered, the Actions mentioned above do not work.
In order to overcome the problem, the behaviour of the attribute ‘Search Key’ has been enhanced to assign a unique key for such Object Types. It takes a single method or a combination of methods, which will serve as a unique identifier to each object of the aggregated or external collection. It has to be ensured that each object in the collection must contain unique values for the method which is assigned as the key.
Syntax
[Collection : <Collection Name>]
Search Key : <Expression>
Where,
< Expression > evaluates to a unique identifier for each object of the collection. It is usually a combination of method names separated by ‘+’, which must make a unique combination for each object of the Collection.
Example:1
Please observe the previous sample Item-Wise Party-Wise report, wherein Alt + R Key combination does not work for Removal of Line, as there is no unique identifier for the Line Object. Each line in the example is repeating over the objects of the collection “Smp Stock Item”. To specify the unique Object identifier, this Collection is altered by specifying the ‘Search Key’ attribute, with a unique combination of Methods as value. In this case, it is the method name $Iname, i.e., the Stock Item Name, based on which the objects are grouped.
[#Collectio n : Smp Stock Item]
Search Key : $IName
Example: 2
Following is another example using external data objects as available in the following XML file, containing the data for Students and corresponding marks in various subjects.
<StudData>
<Student>
<Name> R akesh< / Name>
<Subject>
<Name>Hi s tory</N a me>
<Mark>90</M a rk>
</Subject>
<Subject>
<Name>Ci v ics</Na m e>
<Mark>90</M a rk>
</Subject>
<Subject>
<Name>Ka n nada</N a me>
<Mark>90</M a rk>
</Subject>
</Student>
<Student>
<Name>Uma</ N ame>
<Subject>
<Name>Hist o ry</Nam e >
< Mark>8 0 </Mark>
</Subject>
<Subject>
<Name>Civ i cs</Nam e >
< Mark>5 0 </Mark>
</Subject>
<Subject>
<Name>Kan n ada</Na m e>
< Mark>6 5 </Mark>
</Subject>
</Student>
<Student>
<Name>Pras h anth</N a me>
<Subject>
< Name>H i story</ N ame>
<Mark>50< / Mark>
< /Subje c t>
<Subject>
< Name>C i vics</N a me>
<Mark>90< / Mark>
</Subject>
<Subject>
< Name>K a nnada</ N ame>
<Mark>90< / Mark>
</Subject>
</Student>
</StudData>
The data populated from the above XML is displayed as a columnar report as follows:
.jpg)
Student-wise Subject-wise Marks information is listed in tabular form, as shown in the figure. Now, on removing the selected line(s), the required lines must be removed. Since this report is constructed out of an external source, i.e., XML Data, the same requires a unique identifier for each object in the repeated line. In this case, it is the Student Name; hence, the Search Key should contain this as an identifier.
Following is the sample code required to display the above report in a columnar fashion, with the Remove/Restore Line behaviour incorporated:
[Report : Ext XML Data Stud]
Form : Ext XML Data Stud
[Form : Ext X ML Data Stud]
Parts : Ext XML Data Stud
Bottom ToolBar Buttons : BottomTool b arBtn8, Bottom T oolbarBtn9,+
Bo t tomToolbarBtn10
[Part : Ext X ML Data Stud]
Lines : Ext X ML Data Stud H e ading, Ext XML Data Stud Info
Repeat : Ext X ML Data Stud I n fo : Ext XML Da t a Stud e nts
Scroll : Vertical
CommonBorder : Yes
[Line : Ext X ML Data Stud H e ading]
Fields : Ext XML Data Stud Name, Ext XML Data Stud Mark
Repeat : Ext XML Data Stud Mark : E x t XML Data Stud Subj Summary
Local : Field : Default : Type : String
Local : Field : Default : Style : Normal Bold
Local : Field : Default : Align : Centre
Local : Field : Ext X ML Data Stud N a me : Set As : “S t udent N ame”
Local : Field: Ext X ML Data Stud M a rk: Set As: $S u bjectName
Local : Collection: Ext X M L Data Stud SubjSum m ary: Del e te: Filt e r
Local : Collection: Ext XML Data S t ud Sub j Summary: +
Delete : By: Student N ame
Border : Thin Top Bottom
[Line: Ext X ML Data Stud I n fo]
Fields : Ext XML Data Stud Name, Ext XML Data Stud Mark
Repeat : Ext XML Data Stud Mark: Ext XML Data Stud Subj Summary
[Field : Ext XML Data Stud Name]
Use : Name Field
Set A s : $Na m e
[Field : Ext XML Data Stud Mark]
Use : Number Field
Set A s : $$N u mber:$SubjectT o tal
Align : Right
Border : Thin Left
[Collection : Ext X M L Data Students]
Data Source : File XML : "D:\StudData. x ml" : Un i code
XML Object Path : Student : 1 : StudData
Search Key : $Name
[Collection : Ext X M L Data Stud Subj Summa r y]
Source Collection : Ext XML Data Students
Walk : Subject
By : Student N ame : $..Name
By : Subject N ame : $Name
Aggr Compute : Subject T otal : SUM : ($$Numbe r :$Mark)
Keep Source : ().
Filter : ForThis S tudent
[System : Formula]
ForThisStud e nt : $Studen t Name = $$ReqOb j ect:$Name
In this code, Line ‘Ext XML Data Stud Info’ is repeated over the Collection ‘Ext XML Data Students’, where Search Key is specified to be $Name. Hence, the Remove/Restore Line behaviour will work.
As announced in Release 2.0, we are aware that the variables at the Report scope can be persisted in a user specified file using the action SAVE VARIABLE. This can be re-loaded as required using the action LOAD VARIABLE.
The latest enhancements in variable persistence allow the user to persist and re-load the variables at System Scope (in a User Specified File) as well.
The action SAVE VARIABLE, which is used to persist the Report Scope Variables in a user specified file, now allows us to persist the System Scope Variables also. Syntax of this action remains the same. The desired behaviour is achieved with changes in variable list specification.
Syntax
SAVE VARIA B LE : <FileName> [:<Variable List>]
Where,
< File Name > is the name of the file in which the report scope/ system scope variables are persisted. The extension .PVF will be taken by default, if the file extension is not specified.
< Variable List > is the comma-separated list of variables that need to be saved in the file.
● Now ‘*’ can also be used to specify the variable list, which means all at ‘current scope’.
● The current scope can either be ‘System’ or ‘Report’.
● Specifying ‘*’ will ignore the ‘Persist’ flag and save all the variables in the scope, irrespective of “Persist: Yes” at the ‘Variable’ definition level.
● If Variable list is not provided, it will persist all the variables which are set as “Persist: Yes” at the Variable definition level.
● Dotted notation syntax is also supported in the variable list specification for scope specification.
However, this cannot be used for SUB levels. It can be used only for accessing parent scope variables.
● Single Dot “.” refers to current scope, Double Dot “ . .” to parent scope, Triple Dot “ . . . ” to grandparent scope, and so on.
● “ (). ” refers to the System Scope.
The action LOAD VARIABLE , which is used to load the Report Scope Variables in a user specified file, now allows us to load the System Scope Variables also. Syntax of this action remains the same. The desired behaviour is achieved with changes in variable list specification.
Syntax
LOAD VARIA B LE : <File Name> [:<Variable List>]
Where,
< File Name > is the name of the file in which the report scope/ system scope variables are persisted. Specifying file extension is mandatory while loading variable values.
< Variable List > is the comma-separated list of variables that need to be loaded from the file.
Variable List specification changes:
● While loading, ‘ * ’ is not relevant and will be ignored.
● While loading, ‘Persist’ flag of the variable is ignored. It is assumed that the variable must have a persist flag OR it is saved forcefully and hence to be loaded.
Example:1
There is a requirement to persist values of all system scope variables in a user specified file and load the values from the file whenever required. Refer to the following code snippet:
[#Menu : Gateway of Tally]
Add : Button : SLSystemSco p eSave, S LSystemScopeLo a d
;;Buttons SLSystemScope S a ve & S L Syste m Sco p eL oad are added at the G a teway of Tally Menu to execute the actions S A V E V AR I ABLE & L O A D V ARI A BL E .
[Button : SLSystemS c opeSave]
Key : Alt + F
Action : SAVE VARIABLE : SL S ystemScope.pvf : *
Title : “Save Sys Var”
Values of all system sc o pe v a riables will be persisted in the fi l e SLSystemScope.pvf on execution of t he action S A VE V ARIABLE .
[Button : SLSystemS c opeLoad]
Key : Alt + L
Action : LOAD VARIABLE : SL S ystemScope.pvf
Title : “Load Sys Var”
Values of all system sc o pe v a riables will be loaded from the fi l e SLSystemScope.pvf on execution of the action LOAD V A R IABLE .
Example:2
There is a requirement to persist values of all system scope variables which are set as “Persist : Yes” at variable definition level in a user specified file, and load the values from the file whenever required. Refer to the following code snippet:
[#Menu : Gateway of Tally]
Add : Button : SLSystemSco p eSave, S LSystemScopeLo a d
Buttons SLSystemScopeSave & SLSystemScopeLoad are added at the Gateway of Tally Menu to execute the actions SAVE VARIABLE & LOAD VARIABLE .
[Button : SLSystem S copeSave]
Key : Alt + F
Action : SAVE VARIABLE : SL S ystemScope.pvf
Title : “Sa v e Sys Var”
;; Values of all variables at system scope which are set “Persist : Yes” at variable definition level, will be persisted in the file SLSystem- Scope.pvf on execution of the action SAVE VARIABLE.
[Button : SLSystemS c opeLoad]
Key : Alt + L
Action : LOAD VARIABLE : SL S ystemScope.pvf
Title : “Lo a d Sys Var”
;;Values of all variables will be loaded from the file SLSystemScope.pvf on execution of the action LOAD VARIABLE.
Example: 3
There is a requirement to persist the system scope variables SVSymbolInSign & SVInMillions in a user specified file, and load the values of these variables from the file whenever required. Refer to the following code snippet:
[#Menu : Gateway of Tally]
Add : Button : SLSystemSco p eSave, S LSystemScopeLo a d
Buttons SLSystemScopeSave & SLSystemScopeLoad are added at the Gateway of Tally Menu to execute the actions SAVE VARIABLE & LOAD VARIABLE.
[Button : SLSystemS c opeSave]
Key : Alt+F
Action : SAVE VARIABLE : SLSys t emScope.pvf : SVSymb o lInSign,SVInMi l lions
Title : “Save Sys Var”
Values of the system sco p e variab l es SVSymbo l InS i gn & SVInMil l ions will be persisted in the file SLSystemScope.pvf on executi o n of the action S A VE V ARIABLE.
[Button : SLSystemS c opeLoad]
Key : Alt + L
Action : LOAD VARIABLE : SLSys t emScope.pvf : SVSymbolInSig n ,SVInMillions
Title : “Load Sys Var”
Values of the system scope variables SVSymbolInSign & SVInMillions will be loaded from the file SLSystemScope .pvf on execution of the action LOAD VARIABLE.
Example: 4
The following report is displayed in ‘Create’ mode from a menu item.
[Report : Smp SLRep o rt]
Form : Smp SLForm
Variable : S aveLoadVar1, S aveLoadVar2
The variables SaveLoadVar1 & SaveLoadVar2 are declared at Report Scope.
[Form : Smp S LForm]
Parts : Form SubTitle, Smp SL P a rt
Button : Smp SaveVar, Smp LoadVar
Buttons SmpSaveVar & SmpLoadVar are added at ‘Form’ Level to execute the actions SAVE VARIABLE & LOAD VARIABLE.
Let us look into the following scenarios to persist and load System Scope as well as Report Scope Variable values:
1. Persist & Load all Report Scope Variables & a specific System Scope Variable
[Button : Smp SaveV a r]
Key : Alt + S
Action : SA V E VARIA B LE : SL R eportCfg.pvf: *,().SVI n Millions
Title : “Save Variable”
;; Values of all variables declared at report scope and the value of system scope variable SVInMillions will be persisted in the file SLReportCfg.pvf on execution of the action SAVE VARIABLE. (The variable SVInMillions is prefixed with (). to denote the same as System Scope Variable).
[Button : Smp LoadVar]
Key : Alt + L
Action : LOAD VARIABLE : S LReportCfg.pvf : *,(). S VInMillions
Title : “Load Variable”
Variable list specification * will be ignored. Values of all report scope variables and the value of system scope variable SVInMillions will be loaded from the file SLReportCfg.pvf on execution of the action LOAD VARIABLE.
2. Persist and Load a specific Report Sco p e variable & a specific Syst e m Scope variable
[Button : Smp SaveV a r]
Key : Alt + S
Action : SAVE VARIABLE: SLReport C fg.pvf : SaveLoadVar1 , + ( ).SVInMillions
Title : “Save Variable”
;;Value of Report scope variable SaveLoadVar1 and value of system scope variable SVInMillions will be persisted in the file SLRe- portCfg.pvf on execution of the action SAVE VARIABLE.
[Button : Smp LoadV a r]
Key : Alt + L
Action : LOAD VARIABLE : SLRepor t Cfg.pvf : SaveLoadVar1, + ().SVInM i llions
Title : “Load Variable”
;;Value of Report scope variable SaveLoadVar1 and value of system scope variable SVInMillions will be loaded from the file SLRe- portCfg.pvf on execution of the action LOAD VARIABLE.
As a part of the Language enhancements, in recent past, there have been significant enhancements as a part of the Event Framework. Before this release, events introduced were mostly related to handling the application start up and close, and company loading and unloading. The Object specific events were mainly focused around trapping events while rendering the data on the screen, and printing.
In this Release, events have been introduced to handle user specific requirements on data manipulation during Export and Import of data. With the introduction of the Events Start Import, Import Object and End Import, the programmers have got complete control to manipulate the data prior to importing the same into the company. This can be useful in scenarios like Inter-Branch data transfers; where Delivery Note in a branch gets transformed into Receipt Note in the other, Sales transaction in a Branch gets transformed into Purchase transaction in the other, and so on. Also, an action Import Object has been introduced to begin the Import process.
While exporting Full objects to XML and SDF formats; with the introduction of Export Events Before Export, Export Object and After Export, the user will be able to trap these events and get an access to the object being exported, which can be altered as required before export. This can be useful in scenarios like changing required information during export, not displaying price/ amount of the stock item while synchronizing Delivery Note to the branch offices, creating a consolidated sales entry from all the sales transactions of the day, etc.
The following events can be used within Import File Definition:
Syntax
On : Start Import : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event Start Import executes the actions before beginning the import process. At this stage, the data objects will not be available, since it is prior to gathering the data from the file. This event can be used to communicate any messages to the user like starting the import process, etc.
Syntax
On : Import Object : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition returns TRUE, event Import Object executes the actions after gathering the Objects from File, before importing the same in the current company. At this stage, data objects are available, since it is post gathering the data from file. This event is useful to manipulate & transform data from one form to another, i.e., from Receipt Note to Delivery Note, etc.
Syntax
On: Import Object: <Logical Co n dition> : Import Ob j ect
If the Event ‘On Import Object’ is used, it overrides the default Import Object behaviour, as a result of which, we need to explicitly specify to begin importing the objects. After performing the necessary actions prior to importing the objects, the Action Import Object must be specified to instruct the system to continue the import process.
Syntax
On : End Import : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE , the Event End Import executes the actions after importing the objects. At this stage, the data objects will not be available, since it is post importing the objects within the current company. This event can be used to communicate any messages to the user like ‘ending the import process’, ‘Import Successful’, etc.
Example
[#Import File : Vouchers]
On : Start I mport : Yes : Call : Start I mport
On : Import Object : Yes : Call : Change Values
On : Import Object : Yes : Import Object
On : End Im p ort : Yes : Call : End Im p ort
[Function : Start Import]
00 : MSGBOX : “Status” : “Sta r ting Im p ort Pr o cess”
[Function : Change Values]
00 : SET VALUE : Narration : $N a rration + “ - U pdated b y +
Import Object Event”
10 : SET TARGET : LedgerEntries[ 1 ]
20 : SET VALUE : LedgerName : “Branch Ledger”
[Function : End Import]
00 : MSGBOX : “St a tus” : “Imported data success f ully”
In this example, before importing the data, Narration Method is being altered and the first Ledger Name is being altered to Branch Ledger. Before starting and after ending the import process, appropriate messages are being displayed to the user.
The following events can be used within Form definition:
Syntax
On : Before Export : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event Before Export executes the action before beginning the export. This event can be used to communicate any message to the user.
Syntax
On : Export Object : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event Export Object executes the action before the object is exported. The user will get the object being exported, which can be altered as required before export. The form level Export Object is used to get an access to the object associated at the Report Level and manipulate the same before exporting.
Syntax
On : After Export : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition specified returns TRUE, the Event After Export executes the action at the end of Form Export. This event can be used to communicate any message to the user.
The following events can be used within Line Definition:
Syntax
On : Export Object : <Logical Condition> : <Action> : <Action Parameters>
If the logical condition returns TRUE, the Event Export Object executes the action before every object is exported. The line level ‘Export Object’ is used to get an access to each object associated at the line level and manipulate the same before exporting.
Example
[Form : ExpEvtForm]
On : Before Export : Yes : Call : Export Start
On : After Export : Yes : Call : Export End
Part : ExpEvtPart
Button : Export Button
Full Object : Yes
[Part : ExpEvtPart]
Line : ExpEvtLine
Repeat : ExpEvtLin e : ExpL e dger
Scroll : Vertical
[Line : ExpEvtLine]
On : Export Object : Yes : Call : ExportObj e ct:$$Line
Fields : ExpEvtFld1, ExpEvtFl d 2
Full Object : Yes
[Collection : ExpLedger]
Type : Ledger
Fetch : Name, Parent
[Function : ExportS t art]
00 : MSGBOX : “Status” : “Starting Export”
[Function : ExportO b ject]
Parameter : LineNo : Number
01 : INSERT COLLECTION OBJECT : Na m e
02 : SET VALUE : Na m e : “Led” + “-” + $name+“-” + “00” + $$Strin g :##LineNo
[Function : ExportE n d]
00 : MSGBOX : “Statu s ” : “En d ing Exp o rt”
In this example, the line is repeated over the Collection ExpLedger which is of type Ledger. The event Export Object at the line level will be triggered before exporting of every ledger object. The function “Export Object”, which is called on occurrence of the event, inserts a new object for the collection "Name" and the method Name (alias name) will be set with the new value by concatenating the strings “Led”, Name of the ledger and the line no. prefixed with “00”.
Before starting and after ending the export, appropriate messages are being displayed to the user through the events ‘Before Export’ and ‘After Export’ at ‘Form’ Level. The exported fragments of XML and SDF outputs can be seen in the following figures, in which we can observe that an alias name is created with the value as set inside the function:
.jpg)
_(3.0).jpg)
.jpg)
.jpg)
Prior to Tally.ERP 9 release 1.52, when multiple reports were printed or mass mailing was being done in a sequence; before each Action, a configuration report was displayed for user input. This would interrupt the flow, thereby requiring a dedicated person to monitor the process, which is time consuming. This had been addressed in Tally.ERP 9 release 1.6, by providing an optional logical parameter to suppress the repeated display for the configuration screen, before the invocation of global actions ‘Print’, ‘Export’, ‘Upload’ and ‘Email’.
In order to print, export, upload and email the current report in context, the actions ‘Print Report’, ‘Export Report’, ‘Upload Report’ and ‘Email Report’ are used. Prior to this release, the programmable configuration was not supported for these actions. With the latest enhancement, the display of configuration screen can be suppressed for these actions also. The syntax of these actions supporting programmable configurations is:
Syntax
<Action Name> [ : <Report Name> [:<Logical Value>]]
Where,
< Action Name > can be any of ‘Print’, ‘Export’, ‘Mail’ and ‘Upload’. The actions ‘Print Report’, ‘Export Report’, ‘Upload Report’ and ‘Email Report’ have also been enabled in the latest release.
< Report Name > is name of the report or a dot (.). Since ‘Print Report’, ‘Export Report’, ‘Upload Report’ and ‘Email Report’ take the current report in context, and the subsequent parameter is the logical parameter for suppressing the configuration, dot (.) signifies the specification of the current Report Name. This is an optional parameter. However, it is mandatory in case suppress configuration is to be enabled.
< Logical Value > can be TRUE/FALSE or YES/NO. It is an optional parameter. By default, the value is NO. If set to YES, the configuration screen would not be displayed.
Note: The variables to be set as per the requirement of each Action is done in the same way as discussed in prior releases. Refer to the topic “Programmable Configuration for Actions” in Release 1.6 document for more details.
Example:
To export current report without displaying the configuration screen:
|
|
40: EXPORT REPORT: . : TRUE
|
|
Many Third Party Applications use Tally's rapid application development environment to render various complex reports using Tally Definition Language (TDL). Tally.ERP 9 acts as a front end application for various external databases to retrieve and manipulate information, as and when required. Tally, being a comprehensive business application, loads all the TDLs required as per the functional aspects of the Application. In cases where the third party applications require using Tally purely as a development platform, loading of complete application TDLs may prove to be expensive in terms of startup time.
This release onwards, the application TDLs are segregated as:
● Base TDL Files – This contains the commonly required templates like styles, variables, buttons, etc., which can be used by any report which is rendered.
● Default TDL Files – This contains the TDLs which are specifically meant for functional requirements of the Tally.ERP 9 application.
This has enabled us to launch Tally using the minimal Base TDL files avoiding the overhead of loading the Default TDL files. This can be achieved by using the command line parameter /NODEF.
Syntax
<Tally Application> /NODEF
Example:
D:\Tally.ERP9\Tally.Exe/NODEF/NOINITDL/TDL:"D: \Party\CustomReports.TDL"
In this case, the Tally.ERP 9 application would start only with Base TDLs, without loading the default TDL Files, which means that Tally Application would start rapidly. None of the INI TDLs will be loaded due to the parameter/NOINITDL. Only the TDL file passed with the parameter/TDL, D:\Party\CustomReports.TDL will be loaded.
Note: In line with the above enhancement, the product Tally.Developer 9 Release 3.0 will also support the command line parameter /NODEF. In case the application needs to be started with only the Base TDLs, the option /NODEF will be used.
As we are already aware, the TDL Procedural artefact “Function” is used in two scenarios:
1. Evaluation – where the function is expected to perform some computation and return the result to the expression within which it is called. The usage is similar to a Predefined function. In evaluation mode, the function is called using a “$$”.
Example:
[Field : My F ield]
Set as : $$MyUserF u nction : Parameter1 : Parameter2
2. Execution – where the function is expected to perform certain set of tasks, which changes the state of the application or the data. The usage is similar to a Predefined Action. In execution mode, the function is called using the keyword “Call” and can be invoked from a Key/Button, a Menu item, an Event, or from within another function.
Example:
[Key : My Ke y ]
Action : CA L L : MyUserActi o nFpunction : P a rameter1 : Parameter2
In case of predefined Functions, whenever a function accesses and manipulates certain UI elements like variable, field, etc., or data elements like method values of objects, a link is established between the element and the calling UI. Each time these get manipulated, the function gets re-evaluated, new values are calculated and the corresponding UI is refreshed with new values.
Let us look at the following example to articulate this better:
[Variable : My Variable]
Type : String
[Field : My F ield]
Type : String
Set a s : ##MyVaria b le
When the report is started, the ‘Set as’ attribute of the field ‘My Field’ is evaluated. During this evaluation, a link between the Field ‘My Field’ and the Variable ‘My Variable’ (which is accessed for its value) is established.
Consider a scenario where, say, a F12:configuration of the report changes the ‘MyVariable’ value. Now, the system would automatically determine that the Field ‘My Field’ was depending on the value of the variable, which has changed now; and hence, RE-EVALUATE the field's ‘Set As’ attribute to get its new value.
In case of a TDL procedural “Function”, we faced certain issues, where the fields calling the function for some evaluation were not refreshed with new values when the accessed elements got modified elsewhere, and the function did not get re-evaluated. To articulate this better, let’s extend the previous example by using a user defined function.
[Variable : My Variable]
Type : String
[Field : My F ield]
Type : String
Set a s : $$MyUserFu n ction
[Function : My User F unction]
Returns : String
01 : RETURN : ##MyVariable
In this case, the system would not establish any relation between the Field and the variable, as it is processed via a function; and hence, when the Value of the variable is changed elsewhere, the Field's ‘Set As’ will not get re-evaluated automatically to get its new value.
This issue has been resolved in this Release. The related refresh problems which might have been have faced by the users in context of using "Function" in the evaluation scenario, have been resolved. However, in some negligible cases, we may hit with performance issues due to repeated refresh. This mainly happens when the modification of values of UI / data elements like objects, variables, etc., causes the regeneration of linked UI elements. To overcome the same, certain rules have been established and implemented at the platform level itself. In very few cases where one may require a slight change in design of the function, using the new actions and functions may be useful.
This function, when prefixed to an expression, helps in evaluating it without establishing the link with the UI elements. There may be a few cases where the programmer would not want the system to establish relationship between the caller and the object being accessed, to refresh the value in subsequent modification. In such cases, prefixing $$ExclEvaluate would indicate the same to the system.
Example
[Variable : My Variable]
Type : String
[Field : My F ield]
Type : String
Set a s : $$ExclEval u ate:##MyVariab l e
OR
Set a s : $$ExclEval u ate:$$MyUserFu n ction
[Function : My User F unction]
Returns : String
01 : LOG : ##MyVariable
02 : RETURN : “Cons t ant St r ing”
In evaluation mode, the dependent regenerations of UI elements are deferred till the function exit. In cases where it is desired to trigger regenerations based on the set of statements as and when they occur, one can enclose the statements within the START SUB - END SUB action block.
To articulate this better, let's take the previous example, where the Variable is being accessed by a field. The following function, on a button press, changes the value of the Variable two times.
[Function : My User functio n ]
01 : SET : M y Varia b le : “First Value”
02 : SET : M y Varia b le : ##MyVaria b le + “, Second Value”
In normal scenario, as both SET actions are modifying the value of the variable, the field (dependent on this variable) would get re-valuated twice. However, the platform has the ability to do it only once during the end of the function by default, when the function is called in EVALUATION mode.
To change this behaviour to refresh the field twice, these two SET actions can be covered inside START SUB - END SUB as follows:
[Function : My User functio n ]
01 : START SUB
02 : SET : M y Varia b le : “First Value”
03 : SET : M y Varia b le : ##MyVaria b le + “, Second Value”
04 : END SUB
The purpose of this action is the same as START SUB - END SUB. The only difference is that this action takes an Action to be executed as parameter. The former one encloses a set of Actions inside the block.
Following is the alternative of the previous code by using SUB ACTION, rather than using the START SUB - END SUB action block.
[Function : My User functio n ]
01 : SUB ACTION : S E T : My Variable : “Fi r st Valu e ”
02 : SUB ACTION : SET : My Variable : ##MyV a riable + “, Second Value”
In execution mode, the dependent regenerations are handled as and when they occur. In cases where we would like to defer regenerations based on the set of statements, we can enclose the statements within the START XSUB ... END XSUB block.
Let's take the following example to demonstrate this:
[Field : My F ield]
Set as : $Value1 + $Value2
;; field value dep e nds o n the Value1 and V alue2 of the c u rrent object
[Function: ModifyC u rrentObj]
01 : SET VALUE : Va l ue1 : “Somethi n g else”
02 : SET VALUE : Va l ue2 : “Another value”
This code would normally cause the field to be re-evaluated twice during the function execution. However, enclosing it in an XSUB block would convert it into a single re-evaluation as below:
[Function : ModifyC u rrentObj]
01 : S T ART XSUB
02 : SET VALUE : Va l ue1 : “Somethi n g else”
03 : SET VALUE : Va l ue2 : “Another value”
04 : E N D XSUB
The purpose of this action is the same as START XSUB and END XSUB. The only difference is that this action takes an Action to be executed as parameter. The former one encloses a set of Actions inside the block.
Following is the alternative of the previous code by using XSUB ACTION, rather than using the START XSUB ... END XSUB block.
[Function : ModifyC u rrentObj]
02 : XSUB ACTION : SET VALUE : Value1 : "S o mething else"
03 : XSUB ACTION : SET VALUE : Value2 : "A n other v a lue"
Tally provides the capability to export any report in XML format. The XML generated is in standard format for better readability, i.e., line ending characters after each closing tag, indentation for each sub tag, etc. Most of the applications can directly consume the data available in standard format. However, there are some legacy and non-standard applications which require an XML without formatting and applied styles. They consume the entire unformatted XML available as a single string, without even a new line character.
A new attribute ‘Plain XML’ has been introduced in ‘Report’ definition. This attributes generates the XML without applying any formats and styles.
Syntax
Plain XML : <Logical Expression>
Where,
< Logical Expression > can be any expression which evaluates to logical value YES/NO.
Example
[Report : Si m ple Tr i al bala n ce]
Form : Simple Trial balance
Title : “Trial Balan c e”
Plain XML : YES
In Tally quantity of a Stock item can be expressed using a Simple or Compound Unit of Measure. Simple Unit – Unit of measure used to express the quantity of an Item. E.g., kgs, nos, pcs, etc. Compound Unit – The unit of measure which is a combination of Simple units related to each other by a conversion factor, is termed as a Compound Unit. Examples of compound units are kg of 1000 gms, dozen of 12 nos, etc. In case of compound unit, the highest unit is referred to as the Base/Primary unit and the sub units thereafter, are referred to as the Tail units. The quantity is always expressed in terms of the Primary unit. A compound unit can be nested further to contain another compound unit as a Tail unit, up to any no. of levels. E.g., Bag of 10kgs of 1000 gms.
Example, if the unit of measure used for a Stock item “Grains” is Bag of 10kgs of 1000 gms and the closing balance is 12-5-250 bags, it means that the quantity of items is 12 bags 5 kgs 250 gms. Whenever the tail unit quantity crosses the conversion factor, it adds up to the bigger unit. If the gms part exceeds 1000 in this example and the value is 12-5-1250 bags, then it will be converted to 12-6-250 bags.
In TDL, the data type to support representation & storage of data of the above type is Quantity. It comprises of subtypes Number, Base/Primary units, Alternate/Secondary units and unit symbol.
We know that when a method of type ‘Quantity’ is retrieved in a report, it is always expressed in terms of primary units. In case the Unit of Measure is a nested compound unit, the user may require the quantity in terms of any of the units in the entire Compound unit chain. The ‘Format’ attribute of Field has been enhanced to specify the Tail unit, in which the quantity value needs to be extracted.
Syntax
[Field : <F i eld Name>]
Type : Quantity
Set As : $<Method Name>
Format : "Tail Units:" + <String Expression>
Where,
< String Expression > must evaluate to any Tail Unit Name used in the Item.
Example
As per the previous example, the unit of measure used for the Stock item “Grains” is Bag of 10kgs of 1000 gms and the closing balance is 12-5-250 bags. In a field, we may require to retrieve the value in kgs or gms instead on bags. For this, the following specification can be used:
[Field : Qty Format Enhancement]
Use : Qty Primary Field
Set As : $Closing B alance
Format : “Tail Units:” + “kgs”
● If Format is “Tail Units:kgs”, value returned is 125kgs250 gms=12X10 kgs+5kgs & 250 gms
● If the Format is “Tail Units:gms”, the value returned would be 125250 gms = 12X10X1000 gms+ 5X1000 gms +250 gms.
Note: Appropriate conversions take place as per the conversion factors set in the nested Compound unit chain.
When the data is exported from an external application to Excel Format, especially in the following scenarios, Excel faces refresh issues. Here, we are considering the scenarios when Tally exports the data into Excel.
● When a cell in an Excel Template is having a formula which depends on multiple cells which are being written from Tally. If one out of these cells is having a drop-down list, then the excel formula is not refreshed after the Export.
● If the design of Excel template is depending on one of the Excel cells, and this cell is written by Excel Export from Tally, then the template using the contents of this cell will not take these changes into effect.
This problem can be addressed at the TDL level by writing those data corresponding to cells prior to on the one on which the rest of the cells containing the formula/template are dependent. The rest of the data can be written as a chunk only.
For this purpose, a new attribute ‘Cell Write’ has been introduced at Field. This attribute enables writing of the specific field value in the Excel file, before the entire information gets written.
Note: This attribute has to be used judiciously and strictly as per the above scenarios, since this will increase the export time multifold.
Syntax
Cell Write : <Logical Value>
Where,
< Logical Value > can be YES or NO.
Example
[Field : VAT acc R a te Fld]
Cell Write : YES
Everyone is aware that the Indian government has recently launched a symbol to represent the Indian currency. To display the same in Tally.ERP 9, a function $$StrByCharCode has been introduced in TDL. The function $$StrByCharCode accepts the ‘ASCII’ code or ‘Unicode’, and displays the corresponding special symbol. This function can be used in scenarios where the special symbols are to be displayed in Tally.ERP 9, e.g., foreign currency symbol.
Syntax
$$StrByCharCode : <ASCII code/U n icode>
Where,
< ASCII code/Unicode > can be any expression which returns a valid ASCII or Unicode number. (This number must be in decimal system).
For example the ASCII code for the new rupee symbol is 8377, for Carriage Return is 13, etc.
Example
[Field : StrByCharC o de Repo r t]
Set AS : $$StrByC h arCode:@@CodeC h ar
[System : Formula]
Code Char : 8377
The new Rupee symbol is displayed in the field ‘StrByCharCode Report’.
In scenarios where the printing events ‘Before Print’ and ‘After Print’ were used to trigger an Action, the action used to get called even if the report was in ‘Preview’ mode. To overcome this problem, the function $$InPreviewMode has been introduced, using which, the events can be triggered conditionally as required.
The function $$InPreviewMode checks if the report is in ‘Preview’ mode or not. It is useful in scenarios where some specific controls are to be applied, related to actual Printing. For example, a document can be printed only once, the voucher cannot be altered or deleted after printing an invoice, etc.
Syntax
$$InPreviewMode
Example:
[#Report : Printed Invoice]
On : Print : NOT $$ I nPreviewMode:CALL:UpdateD o cSetPrintedFlag
In this case, the Action created using function ‘$$UpdateDocSetPrintedFlag’ is triggered only in ‘Print’ mode and not in ‘Preview’ mode.
In a remote environment, multiple users connect to the same company and access the data therein. All the TDLs available at the server are enabled for the Remote user. There may be scenarios where some restrictions need to be applied to the data access based on the user identity. This can be achieved at the TDL level by using a new function $$RemoteUserId, which will return the user name of the remote user accessing the TDL.
Syntax
$$RemoteUserId
This function, when called in TDL, will return the user name of the remote user at the Server end.
Till now, the function $$InWords accepted only ‘Amount’ data type and displayed the amount in words. Now, it has been extended to accept ‘Number’ data type as well, and display it in words.
Syntax
$$InWords : <Expression> : <Form a t String>
Where,
< Expression > can be any expression which evaluates to an Amount or a Number.
< Format String > is any string expression used to specify the format, e.g., Forex, No Symbol, etc.
Example
[Field : InWords]
Set as : $$ I nWords:1 00000
The function displays '”ONE LAKH” in the field ‘InWords’.
Till now, the function $$ContextKeyword has been used to return the Title of the Report or Menu. For scenarios like adding a report to the list of favourites, where the Definition name of the current report is required instead of the report Title, the function $$ContextKeyword has been enhanced to return the Report name or Definition name.
Now, the function $$ContextKeyword accepts two logical parameters as follows:
$$ContextKeyword : [:<1st Logic a l Expression>] [:<2nd Logical Expression>]
Where,
< 1st Logical Expression > can be any expression which evaluates to YES/NO. The default value of this parameter is NO and it returns the Title of the current report. If the value is specified as YES, then the title of the parent report is returned. If no report is active, then the parameter is ignored. If the attribute ‘Title’ is not specified in ‘Report’ definition, then by default, the name of the Report definition is returned.
< 2nd Logical Expression > can be any expression which evaluates to YES/NO. It specifies that the name of the Report definition should be returned, instead of the Title of the Report.
Example
[Field : Context Keyword Rep]
Set As : $$ContextKe y word:No:Yes
Here, the function $$ContextKeyword returns the name of the cur r ent report definition.
Example
[Field : Context Keyword Parent]
Set As : $$ContextKe y word:Yes:Yes
Here, the function $$ContextKeyword returns the name of the p arent Interface definition, i.e ., either a Menu Definition Name or the Parent Report Definition Name.
