With every Release, the TDL Procedural Capabilities are getting strengthened at a commendable pace. The latest along this path is the File Input/Output Capability.
Watch the below video to know about the Procedural Capabilities.
As we are aware, any High level programming language will support Reading and Writing From/ To multiple hardware devices. It will have predefined constructs in the form of functions to Read from and Write to a File as well. This file can reside on the hard disk or on a network, which can be accessed via various protocols HTTP or FTP.
This capability introduced in TDL will now pave the way for supporting import/export operations from the Tally DataBase in the most amazing way. It will now be possible to export almost every piece of information in any Data Format which we can think of. The Text and Excel Formats are supported, which allow data storage in SDF-Fixed Width, CSV-comma separated, etc., sufficing the generic data analysis requirements of any business.
The TDL artefacts used for supporting various Read/Write operations are Actions and Functions. These are made to work only inside the TDL Procedural Block. ‘Write’ operations are mostly handled using Actions, and all the file Access and Read operations are performed using Functions. These give tremendous control in the hands of the programmer for performing the data manipulations To/From the file. And that too, on a file present on a network accessible using the protocols FTP and HTTP. Since these artefacts operate on characters and not bytes, the file encoding ASCII/UNICODE does not have any effect on the operations.
The entire procedural Read/Write artefacts basically operate on two file contexts:
● Source file Context
When a file is opened for Reading purpose, the context available for all the ‘read’ operations is the Source File Context. All the subsequent ‘read’ operations are performed on the Source File Context.
● Target file Context
When a file is opened for Writing purpose, the context available for all the ‘write’ operations is the Target File Context. All the subsequent Write operations are performed on the Target File Context.
It is important to understand that these contexts are available o nly inside the procedural block (User Defined Function), where the files are opened for use. The file context concept is different from the concept of Object Context where the Object context is carried over to all its child Objects. File Contexts are only available to the functions, and the subsequent functions are called from within the parent Function. The called function can override the inherited context by opening a new file within its block.
The file context created by opening a file is available only till the execution of the last statement. Once the control is out of the function, the file is automatically closed. However, it is highly recommended as a good programming practice to close a file on exit.
Both the file contexts, i.e., Source and Target file contexts, are available simultaneously. This makes it possible to read from one file and write to another file simultaneously.
A programming language supporting File Read/Write typically supports the following operations:
● Open- This operation identifies the file which needs to be opened for Read/Write purpose.
● Close- This operation closes the opened file after Read/Write.
● Read - This is an operation to read the data from an opened File.
● Write - This is an operation to write the data to an opened File.
● Seek - This is an operation to access the character position in an already opened file.
● Truncate - This is an operation which will delete a particular number of characters/entire contents of the file.
As discussed, the entire procedural Read/Write concepts basically operate on two file contexts, i.e., a source file context and a target file context. Source context is used to read the contents from a file which is opened for reading purpose, whereas the target context is used to write the data to a file which is opened for writing purpose. Since both these file contexts are available simultaneously, it is possible to read from one file and write to another file.
It is used to open a text/excel file for read/write operatio n s. T h e file can r eside in H ard D i sk , in the main memory or o n FTP/HTTP site. Also, it is used to o pen a fi l e for read/write operati o ns.
If no parameters are used, then a mem o ry bu f fer will be c reated , wh i ch will act as a f i le. Th i s file will be in both r ead / write mode and will act as both the source and the tar g et c ontext. Based on the mode sp e cified (read/write), the file automatically becom e s the source file or the tar g et fil e , respec t ivel y .
Syntax
OPEN FILE [:<File Name> [:<File Format> [:<Open Mode> [:<Encoding>]]]]
Where,
< File Name > can be any expression which evaluates to a regular disk file name like C:\Output.txt, or to a HTTP/FTP site like “ftp://ftp.tallysolutions.com/Output.txt”
< File Format > can be Text or Excel. By default, ‘Text’ mode will be considered, if not specified. Also, during opening of an existing file, if the mode does not match, the Action will fail.
< Open Mode > can be Read / Write. By default, it is Read. If a file is opened for ‘Read’ purpose, then it must exist. If ‘Write’ mode is specified, and the file exists, it will be opened for updating. If the file does not exist, a new file is created. If the file is opened in ‘Write’ mode, it is possible to read from the file as well.
< Encoding > can be ASCII or Unicode. If not specified, ‘Unicode’ is considered as the default value for ‘Write’ Mode. In ‘Read’ mode, this parameter will be ignored and considered, based on the encoding of the file being read.
Example: 1
10 : OPEN FILE : “Output.txt” : Text : Write : ASCII
A Text File 'Output.text' is opened in ‘Write’ mode under the Tally application Folder, and if it already exists, the same will be opened for appending purpose.
Example: 2
10 : OPEN FILE : “http://www.tallysolutions.com/Output.txt” : Text
A Text File 'Output.text' is opened in ‘Write’ mode at the HTTP URL specified. If the file already exists, the same will be opened for appending purpose.
Example: 3
10 : OPEN F I LE : “C : \ Outpu t .xls” : Excel : Read
An Excel File 'Output.xls' is opened in ‘Read’ mode under C drive, and if the file does not exist, the Action will fail.
Note: Please refer to the functions like $$MakeFTPName and $$MakeHTTPName for constructing the FTP and HTTP URLs using the various parameters like server name, username, password, etc. Refer to Tally.Developer 9 Function Browser for help on usage.
A file which is opened for Read/Write operation needs to be closed, once all the read/write operations are completed. However, if the files are not closed explicitly by the programmer, these are closed by default when the function is returned. But, it is always recommended to close the file after the operations are completed.
Files which are opened in the current function can only be closed by it. If a function inherits the file contexts from the caller function, then it cannot close these files; however, it can open its own instances of the files. In such cases, the caller context files will not be accessible.
This action is used to close an opened source file.
Syntax
CLOSE FILE
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
.
.
30 : CLOSE FILE
In this example, the Excel file 'Output.xls', which is opened for reading purpose, is closed.
This action is used to close an opened target file.
Syntax
CLOSE TAR G ET FILE
Example
10 : OPEN FILE : “Output.txt” : Text : Write
.
.
.
30 : CLOSE TARGET FILE
In this example, the text file ‘Output.txt’, which is opened for writing purpose, is closed.
All the file accessing functions, for both text and excel files, operate on the source file context. The function $$TgtFile can be used to switch to the target file context temporarily. It evaluates the expression passed, in the context of the target file.
Syntax
$$TgtFile:Expression
Example
In this example, the objective is to Read the contents of a cell in Sheet 1 and copy it to a cell in the Sheet 2 of the same file. The function opens the File “ABC.xls” in ‘Write’ mode.
[Function : Sample Func]
Variable : Temp : String
10 : SET : Temp : “”
20 : OPEN FILE : “Output.xls” : Excel : Write
30 : ADD SHEET : “Sheet 1”
40 : WRITE CELL : 1 : 1 : “Item A”
50 : SET : Temp : $$TgtFile:$$FileReadCell:1:1
60 : ADD SHEET : “Sheet 2”
70 : WRITE CELL : 1 : 1 : ##Temp
80 : CLOSE TARGET FILE
In this example, there is no file present in the source file context, as the file is opened in the ‘Write’ mode. In such case, for reading a value from Sheet 1, the expression $$FileReadCell:1:1 will return no value. Prefixing the expression with $$Tgtfile will temporarily change the context to Target File for the evaluation of the expression, and will fetch the value from the cell 1 of Sheet 1, existing in the Target File context.
This function will return the size of the file, specified in bytes. It takes an optional parameter. If the parameter is not given, then it works on the current context file and returns the size.
Syntax
$$FileSize [:<FileName>]
Where,
< FileName > is an expression, which evaluates to the file name, along with the path.
Example
10 : Log : $$FileSize:“Output.xls”
It gives the size of the Excel file 'output.xls', in terms of bytes.
Writing to a F i le
V a rious Ac t ions have been introduced in order to wri t e to a te x t file. These Actions operate on the T a rget File context. The scope o f these Actions is within the TDL procedural block (User Defined Functi o ns), wh e re the file is o pened and the context is availa ble.
This action is used to append a file with the text specified. The ‘write’ operation always starts from the end of the file. This Action always works on the target file context.
Syntax
WRITE FILE : <TextToWrite>
Where,
< TextToWrite > can be any expression evaluating to the data that needs to be written to the file.
Example
10 : OPEN FILE : “Output.txt” : Text : Write
20 : WRITE FILE : “Krishna”
30 : CLOSE TARGET FILE
Here, a txt file ‘Output.txt’ is opened in ‘write’ mode and the content ‘Krishna’ is appended at the end of the file.
This action is similar to WRITE FILE, but it also places a new line character (New Line/Carriage Return) after the text. All the subsequent ‘writes’ begin from the next line. This action always works on the target context.
Syntax
WRITE FILE LINE : <TextToWrite>
Where,
< TextToWrite > can be any expression evaluating to the data that needs to be written to the file.
Example
10 : OPEN FILE : “Output.txt” : Text : Write
20 : WRITE FILE LINE : “Line 1”
30 : WRITE FILE LINE : “Line 2”
40 : CLOSE TARGET FILE
Here, a txt file 'Output.txt' is opened in ‘Write’ mode, and two more lines are appended at the end of the file.
This action removes the contents of the file by setting the file pointer to the beginning of the file and inserting an ‘end of file’ marker. It can be used to erase all characters from an existing file, before writing any new content to it.
Syntax
TRUNCATE FILE
Example
10 : OPEN FILE : “Output.txt” : Text : Write
20 : TRUNCATE FILE
30 : WRITE FILE : “New Value”
40 : CLOSE TARGET FILE
In this example, the entire contents of the existing txt file 'Output.txt' are removed and 'New Value' is inserted subsequently.
This action operates on the Target File Context. It is used to move the file pointer to a location as specified by the number of characters. As we already know that it is possible to Read and Write from the Target File context, all the subsequent Reads and Writes will be starting from this position. By Default, if the file position is not specified, the ‘Read’ pointer will be always be from the beginning of file and the ‘Write’ pointer will be from the end of the file.
Note: It has already been covered how to Read from the Target File context by using the function $$ TgtFile .
Syntax
SEEK FILE : <File Position>
Where,
< File Position > can be any expression, which evaluates to a number which is considered as the number of characters.
Reading a File
Some functions and Actions have been introduced, which can operate on the Source File context to read from the file or access some information from them. The scope of these functions is within the TDL procedural block (User Defined Functions) where the file is opened, and the context is available. It is also possible to read from the Target File Context by using the function $$TgtFile.
This function is used to read data from a text file. It takes an optional parameter. If the parameter is not specified or has value as 0, it reads one line and ignores the ‘end of line’ character. However, file pointer is positioned after the ‘end of line’ character, so that the next read operation starts on the next line. If the no. of characters is mentioned, it reads that many no. of characters.
Syntax
$$FileRead [:<CharsToRead>]
Where,
< CharsToRead > can be any expression which evaluates to the number of characters to be read.
Example
10 : OPEN FILE : “Output.txt” : Text : Read
20 : LOG : $$FileRead
30 : CLOSE FILE
In this example, the first line of the text file ‘Output.txt’ is being read.
This function is used to check if the current character being read is the End of file character.
Syntax
$$FileIsEOF
This action works on a source file context. It sets the current file pointer to the position specified. Zero indicates the beginning of the file and -1 indicates the end of the file. The file position is determined in terms of the characters. All the subsequent reads begin from this position onwards.
Syntax
SEEK SOURCE FILE : <File Position>
Where,
< File Position > can be any expression evaluating to a number, which is the no. of characters.
Example
10 : OPEN FILE : “Output.txt” : Text : Read
20 : SEEK SOURCE FILE : 2
30 : LOG : $$FileRead
40 : CLOSE FILE
In this example, the first line of the file ‘Output.txt’ is read, starting from the 3rd character.
Setting the Active Sheet
For a n Excel file, a ll t he Read and Write operations will b e perf o rmed o n the Active Shee t .
This action is used to change the Active Sheet during Read and Write operations.
Syntax
SET ACTIVE SHEET : <Sheet Name>
Where,
< Sheet Name > is an expression evaluating to a string, which is considered as name of the sheet.
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : SET ACTIVE SHEET : “Sheet 2”
30 : Log : $$FileReadCell:1:1
40 : CLOSE FILE
In this example, an Excel sheet Output.xls is opened in Read mode, 'Sheet 2' is made active and the content is read from the first cell.
Writing to a File
Various actions have been introduced in order to write to an excel file. These Actions operate on the Target File context. The scope of these Actions is within the TDL procedural block (User Defined Functions), where the file is opened and the context is available.
This action adds a sheet in the current workbook opened for writing. The sheet will always be inserted at the end. If a sheet with the same name already exists, it will be made as active.
Syntax
ADD SHEET : <Sheet Name>
Where,
< Sheet Name > is an expression evaluating to a string, which is considered as name of the sheet.
Example
10 : OPEN FILE : “Output.xls” : Excel : Write
20 : ADD SHEET : “New Sheet”
Here, an existing Excel sheet ‘Output.xls’ is opened in ‘Write’ mode and the new sheet ‘New Sheet’ is inserted at the end of the workbook.
This action removes the specified sheet from current workbook. The entire contents of the sheet will be removed. This action will fail if the workbook has only one sheet, or if the specified sheet name does not exist in the workbook.
Syntax
REMOVE SHEET : <Sheet Name>
Where,
< Sheet Name > is an expression evaluating to a string, which is considered as name of the sheet.
Example
10 : OPEN FILE : “Output.xls” : Excel : Write
20 : ADD SHEET : “New Sheet”
30 : REMOVE SHEET : “Sheet1”
In this example, a workbook is created with a sheet named ‘New Sheet’.
This action renames a work sheet.
Syntax
RENAME SHEET : <Old Sheet Name> : <New Sheet Name>
Where,
< Old Sheet Name > and <New Sheet Name> can be any expression, evaluating to a string, which will be considered as the name of the sheet.
Example
01 : OPEN FILE : “Output.xls” : Excel : Write
02 : RENAME SHEET : @@OlSheetName : @@NewSheetName
04 : CLOSE TARGET FILE
In this example, the existing sheet is renamed with a new sheet name.
This action writes the specified content at the cell address specified by the row and column number of the currently active sheet.
Syntax
WRITE CELL : <Row No> : <Column No> : <Content To be Written>
Where,
< Row No > and < Column No > can be any expression which evaluates to a number, which can be used to identify the cell
< Content To be Written > can be any expression which evaluates to data, which needs to be filled in the identified cell.
Example
10 : OPEN FILE : “Output.xls” : Excel : Write : ASCII
15 : ADD SHEET : “New Sheet”
20 : WRITE CELL : 1 : 1 : “Krishana”
30 : CLOSE TARGET FILE
It opens an Excel File ‘Output.xls’, adds a new sheet, and in that sheet, the first cell will have the content as ‘Krishna’.
This action writes multiple cell values at a specified row in the Active sheet. The no. of values separated by commas are written, starting from initial column no. specified, for the row specified.
Syntax
WRITE ROW : <Row No> : <Initial Column No> : <Comma Separated Values>
Where,
< Row No > and < Initial Column No > can be any expression which evaluates to a number, which can be used to identify the cell.
Comma Separated Values can be expressions separated with comma, which evaluate to data that needs to be filled, starting from the cell mentioned by 'Row Number' and 'Initial Column Number'.
Example
10 : OPEN FILE : “Output.xls” : Excel : Write
20 : ADD SHEET : “New Sheet”
30 : WRITE ROW : 1 : 1 : @@Val1, @@Val2
40 : CLOSE TARGET FILE
Here, cells (1,A) and (1,B) are filled with the values from expressions 'Val1' and 'Val2'.
This action writes multiple cell values at a specified column in the Active sheet. The no. of values separated by commas are written starting from the initial row no., specified for the column.
Syntax
WRITE COLUMN : <Initial Row No> : <Column No> : <Comma Separated Values>
Where,
< Initial Row No > and < Column No > can be any expression, evaluating to a number, which can be used to identify the cell.
Comma Separated Values can be expressions separated with comma, which evaluate to data that needs to be filled, starting from the cell mentioned by 'Initial Row Number' and 'Column Number'.
Example
10 : OPEN FILE : “Output.xls” : Excel : Write
20 : ADD SHEET : “New Sheet”
30 : WRITE Column : 5 : 5 : @@Val3, @@Val4
40 : CLOSE TARGET FILE
In this example, cells (5, E) and (6,E) are filled with the values from expressions ‘Val3’ and ‘Val4’.
Some functions and actions have been introduced which can operate on the Source File context to read from the file or access some information from them. The scope of these functions is within the TDL procedural block (User Defined Functions), where the file is opened and the context is available. It is also possible to read from the Target File Context by using the function $$TgtFile.
This function returns the content of the cell identified by the mentioned row number and column number of the active sheet.
Syntax
$$FileReadCell : <Row No> : <Column No>
Where,
< Row No > and < Column No > can be any expression which evaluates to a number used to identify the row number and the column number.
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : SET ACTIVE SHEET : “Sheet 1”
20 : Log : $$FileReadCell:1:1
The function $$ FileReadCell Logs the contents of the first cell of the excel sheet ‘Sheet 1'.
This function returns the number of sheets in the current workbook.
Syntax
$$FileGetSheetCount
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : Log : $$FileGetSheetCount
The function $$ FileGetSheetCount returns the total number of sheets in the Excel sheet 'Output.xls'.
This function returns the name of the active sheet.
Syntax
$$FileGetActiveSheetName
Example:
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : Log : $$FileGetActiveSheetName
The name of the a ctive sheet is re t urned a ft e r opening the Excel file ‘Output.xls’.
This function returns the name of the sheet at a specified index.
Syntax
$$FileGetSheetName : <Sheet Index>
Where,
< Sheet Index > can be any expression which evaluates to a number as the Sheet Index.
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
Log : $$FileGetSheetName:1
The function $$FileGetSheetName gives the name of the sheet at a particular index
This fu n ction retur n s the Index of the sh e et for a specified sheet name.
Syntax
$$FileGetSheetldx : <Sheet Name>
Where,
< Sheet Name > can be any expression which evaluates to the name of the Excel Sheet.
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : Log : $$FileGetSheetIdx:“Ledgers”
The function $$FileGetSheetIdx gives the index number of the sheet name.
This function gives the column name in terms of alphabets for the given index.
Syntax
$$FileGetColumnName:Index
Where,
< Index > can be any expression which evaluates to the Index number.
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : Log : $$FileGetColumnName:10
The function $$FileGetColumnName returns the value J .
This function returns the index of the column for a given alphabetical name.
Syntax
$$FileGetColumnldx : <Name>
Where,
< Name > can be any expression which evaluates to the name of the column in alphabets.
Example
10 : OPEN FILE : “Output.xls” : Excel : Read
20 : Log : $$FileGetColumnIdx:AA
The function $$FileGetColumnIdx returns the value as 27.
Scenario
ABC Company Limited, which is into trading business, is using Tally.ERP 9. It deals with purchase and sale of computers, printers, etc. The company management wants to import the stock items from the Excel sheet, or a text file into Tally.ERP 9.
Functional Demo
A configuration report is added in Tally.ERP 9 to accept the file location, work sheet name, column details, etc. An option to display the error report can also be specified.
.jpg)
By default, Excel format is selected. But, the user can also select the Import source format as Text and specify the file details. The text separator character should be specified as well, in addition to the column details.
.jpg)
Once the details are entered, a confirmation message is displayed to start the import process.
If the user has selected the option to display the error report after successful import, the report is shown with imported stock items and status as “Imported successfully”, as seen in the figure:
.jpg)
If the user has selected the option to display the Log file, then after the import, the log file is displayed as follows:
.jpg)
S
The imported items are now available in the Stock Item list as follows:
.jpg)
In case the import is unsuccessful, the error report, with the reason of failure, is displayed as follows:
.jpg)
Solution D e velopment
The import from the excel file is simplified, as the user can specify the import details. The file I/O capabilities are used to develop the solution. The steps followed to achieve the requirement are:
1. A report is designed to display the configuration report. The value entered by the user is stored in a system variable.
Local : Field : Name Field : Modifies : SIC Source : Yes
Local : Field : Name Field : Variable : SIC Source
|
|
Local : Fiel d : Name F ield : M odifies : SIC D i rPath : Y es
Local : Field : Name Field : Variable : SIC D i rPath
[System : Va r iable]
SIC Source : “Excel”
SIC DirPath : “C:\Tally.ERP9”
2. On form accept, the function to import the stock item is called.
On : Form Ac c ept : Ye s : Form Accept
On : Form Ac c ept : Ye s : Call : Smp Im p ort St o ck Items
3. A function “Smp Import Stock Items” is defined.
4. In this function, first of all, the format of the source file is checked, and then, the action ‘Open File’ is used to open the file in ‘Read’ mode accordingly.
20 : IF : ##SICSource = “Excel”
30 : OPEN FILE : @@TSPLSMPTotFilePath : Excel : READ
40 : ELSE :
50 : OPEN FILE : @@TSPLSMPTotFilePath : Text : READ
60 : ENDIF
5. The data from the Excel cells are read and added as items in the list variable.
120 : WHILE : NOT $$I s Empty: ( $$FileR e adCell: ##Row : ##Item C olumns. I temNam e )
130 : LIST ADD E X : I t em Deta i ls
140 : SET : Ite m Detail s [$$Loop I ndex]. I temName: $$FileR e adCell: # # Row:## I temColu m ns.Ite m Name
150 : S E T : ItemDet a ils[$$L o opInde x ].ItemG r p: $$Fil e ReadCel l: # # Row: # # ItemCol u mns.It e mGrp
160 : S E T : ItemDet a ils[$$L o opInde x ].ItemU O M: $$Fil e ReadCel l: # # Row: # # ItemCol u mns.It e mUOM
170 : INCREME N T: Row
180 : END WH I LE
6. If source format is ‘Text’, the text file is read line by line and added as items to the list variable.
210 : WHILE : NOT $$FileIsEOF
220 : SET : Temp Var : $$FileRead
230 : IF : NOT $$IsEmpty:##TempVar AND (NOT ##SICIncHeader OR (##SICIncHeader AND $$LoopIndex>1))
240 : LIST ADD EX : Item Details
250 : SET : ItemDetails[##Counter].ItemName : $$SICExtractDet:##TempVar:##ItemColumns.ItemName
260 : SET : ItemDetails[##Counter].ItemGrp : $$SICExtractDet:##Temp Var:##ItemColumns.ItemGrp
270 : SET : ItemDetails[##Counter].ItemUOM : $$SICExtractDet:##TempVar:##ItemColumns.ItemUOM
280 : INCREMENT : Counter
290 : ENDIF
300 : END WH I LE
7. A collection is populated using the List variable as data source.
[Collection : TSPL S MP Imp S tockIte m ]
Data Source : Variab l e : Item Details
[Collection : TSPL S MP Imp S tockItem Summ]
Source Collection : TSPL SMP Imp Stock I tem
By : SIC S tockItem : $It e mName
By : SIC S tockGroup : $ItemGrp
By : SICStockUOM : $It e mUOM
Filter : TSPL SMP No n Empty I tem
8. Now, the Stock Item objects are created. If the item can’t be imported, then the item details are written in the error file or compound variable, based on the format selected for displaying, i.e., ‘Report’ or ‘Log’.
380 : WALK COLLECTION : TSPL SMP Imp StockItem Summ
390 : SET : Last Status : “”
400 : IF : $$IsEmpty:$Name:StockItem:$SICStockItem
410 : NEW OBJECT: Stock Item
420 : SET VALUE : Name : $SICStockItem
430 : IF : NOT $$IsEmpty:$Name:StockGroup:$SICStockGroup
440 : SET VALUE : Parent : $SICStockGroup
450 : ELSE :
460 : SET : LastStatus : “Group” + $SICStockGroup + “does not exist”
470 : ENDIF
480 : IF : NOT $$IsEmpty:$Symbol:Unit:$SICStockUOM
490 : SET VALUE : Base Units : $SICStockUOM
500 : ELSE :
510 : SET : LastStatus : “Unit” + $SICStockUOM + “does not exist”
520 : ENDIF
530 : IF : $$IsEmpty:##LastStatus
540 : SAVE TARGET
550 : SET : Last Status : “Imported Successfully”
560 : ENDIF
570 : ENDIF
;; Writing Import Status to the LOG File, if LOG File is to be displayed at the end
580 : IF : ##SICOpenLogFile
590 : WRITE FILE LINE : $SICStockItem + ##SICTextSep + ##LastStatus
600 : ENDIF
;; Updating List of Compound Variables is the Status is to be displayed in a Report
610 : IF : ##SICDisplayReport
620 : LIST ADD EX : ItemImportStatus
630 : SET : ItemImportStatus[##Counter].ItemName : $SICStockItem
640 : SET : ItemImportStatus[##Counter].Status : ##LastStatus
650 : INCREMENT : Counter
660 : ENDIF
670 : END WALK
9. If the format selected is ‘Report’, then the stock item name and the status is updated in a compound variable; whereas, if the format selected is Log file, then the action ‘Write File’ is used to write in the file.
WRITE FILE LINE : $SICStockItem + ##SICTextSep + ##LastStatus
10. After import, if the user wants to display error report, a function is called to display the same.
690 : IF : ##SICDisplayReport
700 : DISPLAY : TSPL Smp SIC Error Report
710 : ENDIF
11. After the import, if the user has selected to display the log file, then the log file is displayed.
720 : IF : ##SICOpenLogFile
730 : EXEC COMMAND : @@TSPLSmpErrorFilePath
740 : ENDIF
12. The Error Report displays the reason of failure, if the Stock Item cannot be imported. In error report, the line is repeated over the collection populated, using list variable as the data source.
Prior to this Release, while invoking a user defined function, it was mandatory to pass values to all the parameters declared within the function. Now, the capability has been introduced to have optional parameters. The function will execute smoothly even if the caller of the function does not pass the values to these optional parameters. However, the caller of the function must pass all the mandatory parameters. Only the rightmost parameters can be optional, i.e., any parameter from the left or middle cannot be optional.
If the Parameter value is supplied by the calling Function, then the same is used, else the default Parameter value provided within the ‘Parameter’ Attribute is used as the Parameter value. For this enhancement, the Function attribute ‘Parameter’ has been modified to accept parameter value.
Syntax
[Function : <Function Name>]
Parameter : <Parameter Name1> : <Data Type>
Parameter : <Parameter Name2> : <Data Type>
Parameter : <Parameter Name3> : <Data Type> [: Parameter Value]
Parameter : <Parameter Name4> : <Data Type> [: Parameter Value]
Where,
< Parameter Name1 > and < Parameter Name2 > are mandatory parameters for which, values must be passed while calling the function.
< Parameter Name3 > and < Parameter Name4 > are optional parameters for which, values may or may not be passed while calling the function. If values for these parameters are passed, the parameter value specified within the ‘Parameter’ Attribute is ignored. In absence of these values, the specified parameter value is taken into consideration.
Note: Parameter Value indicates Optional Parameters, and all the Optional Parameters should be the rightmost elements of the function.
Example
[Function : Split VchNo]
;; this Function returns the number part of voucher number from a string. For example, Voucher Number is Pymt/110/2010-11. This Function will return only ‘110’.
Parameter : pVchNo : String
Parameter : pSplitChar : String : “/”
;; usual separator
00 : FOR TOKEN : TokenVar : ##pVchNo : ##pSplitChar
10 : IF : $$LoopIndex = 2
20 : RETURN : ##TokenVar
30 : ENDIF
40 : END FOR
While invoking the function $$SplitVchNo, only the Voucher No is passed. The 2nd Parameter is optional and the default value is “/”. It is passed only if the separator character is other than “/”.
Optional parameters can be very useful where the Parameter values remain constant in most of the cases; and rarely require some change.
Note: A small change has been done in the way function parameters are tokenized. The last parameter passed to the function is not broken up into sub-parts now. This is particularly useful in cases where we require the result of one function to be treated as a parameter to another function. In other words, if a function requires 4 parameters, it tokenizes only till 3 parameters and all the subsequent values are considered as the 4th parameter (last parameter).
In the prior releases, we have experienced major changes to the Variable Framework in the form of introduction of Compound Variables and List Variables. Continuous enhancements and changes are being made to ensure consistency and uniformity across the TDL framework.
Watch the below videos to understand the enhancements in Variable Framework.
Variables at ‘report’ scope can now be persisted into a user specified file. This is stored in a standard variable format and also allows reloading the report scope variables from the specified file. The Actions SAVE VARIABLE and LOAD VARIABLE have been introduced for this purpose.
The action SAVE VARIABLE is used to persist the Report Scope Variables in a user specified file.
Syntax
SAVE VARIA B LE : <FileName> [:<Variable List>]
Where,
< FileName > is the name of the file in which the report scope variables are persisted. The extension .PVF will be taken by default, if the file extension is not specified.
< Variable List > is the list of comma-separated variables that need to be persisted in the file. Specifying the variable list is optional.
Note: If the Variable List is not specified, all the variables at the ‘Report’ scope, which have ‘Persist’ attribute set to YES, will be persisted in the specified file. We need not declare the variable at System level unless it is required to persist the same in the default configuration file tallycfg.tsf.
Example
Let us assume that the variables EmpNameVar and EmpIDVar are declared at the Report Scope, and the same need to be persisted in a user specified file. We can achieve this using the newly introduced actions SAVE VARIABLE and LOAD VARIABLE . The buttons SAVEVAR and LOADVAR are added at the Form Level for the same.
[Button: SaveVar]
Key : Alt + S
Action : Save Variable : SmpVar.pvf : EmpNameVar, EmpIDVar
The action SAVE VARIABLE will persist the values of the variables EmpNameVar and EmpID V ar in the file Smp V a r . pvf
The action LOAD VARIABLE is used to reload the report scope variables from the specified file.
Syntax
LOAD VARIABLE : <FileName> [:<Variable List>]
Where,
< FileName > is the name of file in which the ‘report’ 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 loaded from the file. It is optional. In case it is not specified, all the variables saved in the file will be loaded.
Example
In the previous example, we have persisted values of the Report Scope Variables EmpNameVar and EmpIDVar in the file SmpVar.pvf . Now, let us see how to re-load these ‘report’ scope variables from the file.
[Button : LoadVar]
Key : Alt + L
Action : LOAD VARIABLE : SmpVar.pvf : EmpNameVar, EmpIDVar
The action LOAD VARIABLE will load the report scope variables EmpNameVar and EmpIDVar from the file SmpVar.pvf .
Note: Member Variable Specification or Dotted Notation Specification is not allowed for specifying Variable list for both the actions SAVE VARIABLE and LOAD VARIABLE . It has to be a variable name identifier at the current report scope.
The contents of a variable can now be entirely copied from one instance to another instance.
The action COPY VARIABLE is used to copy the content from one variable (Source) to another variable (Destination). This action is supported for all types of variables (Simple/Compound/List Variables).
Syntax
COPY VARIABLE : <Destination Variable> : <Source Variable>
Where,
< Destination Variable > is the name of the Simple/Compound/List Variable.
< Source Variable > is the name of the Simple/Compound/List Variable, from which the content has to be copied.
Example: Copying from Simple Variable to Simple Variable
[Function : SimpleVar Copy Function]
VARIABLE : SimpleVar1 : String : “Employee1”
VARIABLE : SimpleVar2 : String
10 : COPY VARIABLE : SimpleVar2 : SimpleVar1
20 : LOG : “Source” + ##SimpleVar1
30 : LOG : “Destination” + ##SimpleVar2
In this example, the variables SimpleVar1 and SimpleVar2 are declared at the Function level. After execution of the action COPY VARIABLE , the content of the variable is copied from SimpleVar1 to SimpleVar2 .
Example: Copying from Compound Variable to Compound Variable
Let us suppose that the following compound variables are defined:
[Variable : Employee1]
Variable : EmpName : String : “Praveen”
Variable : Designation : String : “Manager”
[Variable : Employee2]
Variable : EmpName : String
Variable : Designation : String
In the function below, contents are copied from Compound Variable Employee1 to Employee2:
[Function : Compound Var Copy Function]
VARIABLE : Employee1
VARIABLE : Employee2
10 : COPY VARIABLE : Employee2 : Employee1
20 : LOG : “Source” + ## Employee1.EmpName
30 : LOG : “Source” + ## Employee1.Designation
40 : LOG : “Destination” + ## Employee2.EmpName
50 : LOG : “Destination” + ## Employee2.Designation
Note: The content will be copied from a member variable of a Compound Variable (Source) to another member variable of a compound variable (Destination), based on the member variable names, since more than one member variable may have the same data type.
Example: Copying from List Variable to List Variable
Let us suppose that the following compound variables are defined:-
[Variable : Employee1]
Variable : EmpName : String
Variable : Designation : String
[Variable : Employee2]
Variable : EmpName : String
Variable : Designation : String
In the following function, the compound variables Employee1 and Employee2 are declared as List Variable. We are copying all the elements from the compound list variable Employee1 to the compound list variable Employee2 .
[Function : ListVar Copy Function]
LIST VARIABLE : Employee1, Employee2
10 : LIST FILL : Employee1 : Employees : $Name : $Name
20 : LIST FILL : Employee1 : Employees : $Name : $Designation + :Designation
30 : COPY VARIABLE : Employee2 : Employee1
40 : LOG : “Source Variable - Employee”
50 : FOR IN : KEY VAR : Employee1
60 : LOG : $$LISTVALUE:Employee1:##KEYVAR:EmpName
70 : LOG : $$LISTVALUE:Employee1:##KEYVAR:Designation
80 : END FOR
90 : LOG : “Destination Variable - Employee”
100 : FOR IN : KEY VAR : Employee2
110 : LOG : $$LISTVALUE:Employee2 : ##KEYVAR:EmpName
120 : LOG : $$LISTVALUE:Employee2 : ##KEYVAR:Designation
130 : END FOR
The Dotted Notation Syntax for Variables (##) has now been enhanced to allow specification of scope / relative scope, etc.
Syntax
.. (DOUBLE DOT) denotes owner scope
… (TRIPPLE DOT) denotes owner's owner scope and so on
(). denotes a system scope
Where,
< Definition Type > is the name of the definition such as Report, Function, etc., in the current execution chain.
< Definition Name Expression > can be any expression which evaluates to a Definition Name. The Definition Name Expression is optional.
(< Definition Type >, < Definition Name Expression >) can be used for absolute scope specification. The element (<Definition Type>, <Definition Name Expression>) has to be in the current execution chain, else one will not be able to refer to the same.
Example
Let us suppose that the Variable TSPLSMPScopeVar is declared at System Scope.
[Variable : TSPLSMPScopeVar]
Type : String
[System : Variable]
TSPLSMPScopeVar : “System Scope”
The function TSPLSMPScopeSpec is called from a Menu. We have declared the variable TSPLSMPScopeVar in the ‘Function’ scope also.
[Function : TSPLSMP ScopeSpec]
VARIABLE : TSPLSMPScopeVar
01 : SET : TSPLSMPScopeVar : “Function Level”
02 : Display : TSPLSMP ScopeSpec
The following report is displayed from the function TSPLSMP ScopeSpec. We have declared the variable TSPLSMPScopeVar in the ‘Report’ Level also.
[Report : TSPLSMP ScopeSpec]
Form : TSPLSMP ScopeSpec
Variable : TSPLSMPScopeVar
Set : TSPLSMPScopeVar : “Report Level”
Following are the field definitions of the report TSPLSMP ScopeSpec. Let us see the variable values at the field level by specifying the scope in Variable Dotted Syntax.
[Field : TSPLSMP ScopeSpecC u rrent]
Use : Name Field
Set As : ##T S PLSMPSc o peVar
;;Variable value in this field will be "Report Level" (Current Scope)
[Field : TSPLSMP ScopeSpecO w ner]
Use : Name Field
Set As : ##..TSPLSMPScopeVar
Border : Thin Left R i ght
;;Variable value in this field will be "Function Level" (Owner's Scope)
[Field : TSPLSMP ScopeSpecS y stem]
Use : Na m e Field
Set As : ## ( ).TSPLSMPScope V ar
Border : Th i n Left
;;Variable value in this field will be "System Level" (System Scope)
[Field : TSPLSMP ScopeSpecAbsolute]
Use : Name Field
Set as : ##(Function,“TSPLSMP ScopeSpec”).TSPLSMPScopeVar
Border : Thin Left
;;Variable Value in this field will be "Function Level" (Absolute Specification)
A variable can be declared in a scope in two ways, i.e., either by specifying the name of the variable (in this case, a separate variable definition is required) or by specifying the name of the variable and a data type (in this case, a separate variable definition is not required; and hence, is called as inline declaration).
Note: In this c h apter, we will go through the ‘Report’ Scope variable d e claration, s yntax a n d exam p les. It is a p plicable for other scopes also.
Let us look into the variable declaration syntax of Report Scope.
Syntax
[Report : <Report Name>]
;;This syntax expects a separate variable definition in the same name
Variable : <Variable Names>
OR
;;Inline declaration
Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
List Variable : <Variable Names> [:<Data Type>[:<Value>]]
Example
[Report : SMP Report]
Variable : Emp Name
Variable : Emp Relation : String
List Variable : Employee1
List Variable : Employee2 : String : “Prem”
[Variable : Emp Name]
Type : String
[Variable : Employee1]
Variable : EmpName : String
Variable : EmpID : String
Now, the ‘Data Type’ parameter can be pointing to a variable definition; in which case, it will allow one to have a variable which has the instance name and definition name different. This allows flexibility to create two instances of a compound structure in the same scope, with different instance names, without requiring to duplicate the definition. This capability is available at all the scopes where variable declaration is allowed.
Existing Syntax
[Report : <Report Name>]
Variable : <Variable Names>
OR
Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
List Variable : <Variable Names> [:<Data Type>[:<Value>]]
New E n hanced S y ntax
[Report : <Report Name>]
Variable : <Variable Names>
OR
Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
List Variable : <Variable Names> [:<Data Type>[:<Value>]]
OR
Variable : <Instance Names> : [<Variable Name>]
OR
List Variable : <Instance Names> : [<Variable Name>]
Where,
< Instance Names > is the list of Simple/Compound/List Variables separated by comma (instance variables).
< Variable Name > is the Simple or Compound variable name. A separate variable definition is required. It should not be an inline variable.
Example: 1
Given here is the definition of a Compound Variable “Employee”.
[Variable : Employee]
Variable : EmpName : String
Variable : Designation : String
Now, we can create a variable instance using the definition of another variable. Let us understand this with the help of the following ‘Report’ definition:
[Report : Employee Report]
;;An instance is declared with the name as 'Prem' and definition name as 'Employee'. The variable instance 'Prem' will inherit the entire structure of the variable definition 'Employee'.
Variable : Prem : Employee
;;An instance is declared with the name as 'Ramesh' and definition name as 'Employee'.
Variable : Ramesh : Employee
;;Locally, the instance "Ramesh" is modified to add a member variable.
Local : Variable : Ramesh : Add : Variable : EmpID : String
;; Two instances are declared with the names "Kamal" and "Vimal", and the definition name as "Employee"
Variable : Kamal, Vimal: Employee
;; A List Variable instance is declared with the name "EmployeeList" and the definition name as "Employee"
List Variable : EmployeeList : Employee
Example: 2
[Report : TSPL SMP Variable Instance]
Variable : Employee : String : “Suresh”
Variable : New Employee : Employee
In this example, we are trying to declare a variable instance ‘New Employee’, which is of the type of another variable ‘Employee’. This will NOT work because the variable ‘Employee’ is declared as inline and an explicit Definition does not exist for the same.
Hence, inline variables cannot be used to declare another variable instance.
Scenario
ABC Company Ltd., a manufacturing company, is having the Head Office in Bangalore and branch offices in Delhi, Mumbai, Kolkata and Chennai. The company uses Tally.ERP 9 at all the locations.
The Head Office and Branch Offices are using the e-mail capability of Tally extensively to send remainder letters, outstanding statements, etc., to the customers.
The System Administrator at the Head office will be facilitating the Branch office staff for email configurations in Tally. The company is using its own mail server and also another mail server “SIFY”. If there is a change in the mail server, the system admin needs to communicate the information to branch staff, and they will be updating the email configurations in Tally.ERP 9.
Now, the company wants to set the email configurations centrally for all the branches so that the branch staff need not struggle for email configurations, particularly when there is a change in the mail server. This solution provides the facility of saving multiple configurations in multiple file names, and later loading them from the file, based on user selection.
Requirement Statement
Presently in Tally.ERP 9, users need to set email configurations locally & update required details.
Now, the configurations can be created centrally and shared among the locations. Thus, the user need not set email configuration every time. They have to simply load the configuration from the file. This can be achieved using newly introduced actions SAVE VARIABLE & LOAD VARIABLE.
Functional Demo
Before looking into the design logic, we will have a functional demo.
Let us suppose that ABC Company Ltd. is using its own mail server and another mail server Sify in its Head Office and its branch offices.
Saving Email Configurations
Let us suppose that the System Administrator in Head Office wants to save the required email configurations in Tally.ERP 9 for HO and Branches
Gateway of Tally > F12: Configure > E-Mailing . The email configuration screen will appear as follows:
.jpg)
The System Admin needs to save the configurations for mail servers abc and Sify. Hence, he has to specify Email server as “User Defined” and enter the required configuration settings as follows:
.jpg)
Now, the System Admin has to press Alt+S, or click on the Button Save Config. The following screen will appear, where he has to enter the configuration file name:
.jpg)
Once the System Admin accepts this screen, the configuration details will be saved in the file “abc.pvf”. Similarly, he has to create the Configuration for the mail server “Sify”. The files will be created in Tally.ERP 9 application folder, as shown in the following screenshot:
.jpg)
The admin can share these two files to the staff in HO and Branch Offices, and they should place the file in the respective Tally.ERP 9 application folders.
Loading Configurations
Gateway of Tally > F12: Configure > E-Mailing . The e-mail configuration screen will be displayed with the previously set configurations.
Now, the user at HO/Branch wants to load the configurations for the email server “abc”. He has to press Alt+L or click on the Button “Load Config”, and enter the file name, as shown in the figure:
.jpg)
Accept the screen. The Email Configuration Report will display the configuration details loaded from the file “abc”. Accept the configuration screen, and the settings will be applicable to all reports. Suppose the User now wants to mail the report Balance Sheet. He has to select ‘Balance sheet’ and press Alt + M. The following configuration report will appear:
.jpg)
Note that the configuration details are changed as per the selected configuration. Now, the user wants to change the email server as Sify. Go to Gateway of Tally > F12:Configure > E-Mailing . Press Alt + L . Enter the file name as Sify and press Enter . The email configuration screen will have new configurations loaded from the file Sify .
Similarly, we can save/load multiple configurations.
Solution D e velopment
The steps followed to achieve Saving of Multiple Email Configurations are:
Variables SVMailServerName, SVMailServer, SVMailFormat, SVMailUseSsl, etc., are declared at ‘Report’ Level. All these variables have the attribute Persistent set as YES at the Definition level.
[#Report : E M ail Co n figurat i on]
Variable : SVMail S erverN a me, SV M ailServ e r, SV M ailForm a t, SVM a ilUseS s l Var i able : S VMailUs e SSLOnS t dPort,+
S VMailA u thUserN a me, SV E xportFo r mat
A button is added to the Form, and the action will call a User Defined Function. In a User Defined Function, we are executing a report to accept a File Name from the user. We are persisting all the report scope variables in the specified file through the Action SAVE VARIABLE.
A button is added to the Form and on clicking it, the action will call a User Defined Function. In the User Defined Function, we are executing a report to accept the File name from the user. We are reloading the report scope variables from the file through the Action LOAD VARIABLE. Please refer to the following code snippet for Save and Load configurations.
[Function : TSPL Smp SaveLoadVar]
Parameter : IsSaveVar : Logical : Yes
Variable : ConfigNamewithExt : String : Yes
00 : EXECUTE : TSPL Smp SaveLoadConfig
;; Correcting the file name entered with or without extension by the user
06 : IF : ##SaveLoadConfigName CONTAINS ".Pvf"
10 : SET : ConfigNamewithExt : ##SaveLoadConfigName
20 : ELSE :
30 : SET : ConfigNamewithExt : ##SaveLoadConfigName + ".pvf"
40 : ENDIF
;; Saving or Loading the variables based on parameter value
50 : IF : NOT $$IsEmpty : ##SaveLoadConfigName
60 : IF : ##IsSaveVar
70 : SAVE VARIABLE : ##ConfigNamewithExt
80 : ELSE :
90 : LOAD VARIABLE : ##ConfigNamewithExt
100 : ENDIF
110 : ENDIF
The corresponding field values need to reflect the values of the variables loaded from the file. This is handled by using the following code:
Local : Field : DSPMailServer : Set as : If #DSPMailServerName Contains $$SysName:UserDefined +
Then ##SVMailServer Else If #DSPMailServerName NOT Contains $$SysName:UserDefined Then +
$$GetMailServerAddr:#DSPMailServerName Else ##SVMailServer
Local : Field : DSPMailServerName : Set As : ##SVMailServerName
Local : Field : DSPMailFormat : Set As : ##SVMailFormat
Local : Field : DSPMailUseSsl : Set As : ##SVMailUseSsl
Local : Field : DSPMailUseSSLOnStdPort : Set As : ##SVMailUseSSLOnStdPort
Local : Field : DSPMailAuthUserName : Set As : ##SVMailAuthUserName
Local : Field : DSPFinalExportFormat : Set As : ##SVExportFormat
Also, if the field values are changed, the Report level variables need to be modified with those values. This is handled using the following code:
Local : Field : DSP MailS e rverName : Modi f ies : SVMailS e rverName : Yes
Loc a l : Field : DSP MailSer v er : Mod i fies : SVMailServ e r : Yes
Local : Field : DSP M ailFormat : Modifies : SVMailForm a t : Yes
Local : Field : DSP M ailUseSsl : Modifies : SVMailUseS s l : Yes
Local : Field : DSP M ailUse S SLOnStd P ort : Mod i fies : SVMa i lUseSS L OnStdPo r t : Yes
Local : Field : DSP M ailAut h UserName : Mod i fies : SVMa i lAuthU s erName : Yes
Local : Field : DSP F inalEx p ortForm a t : Mod i fies : SVEx p ortFor m at : Yes
On accepting the Form email configuration, we are calling a User Defined Function to set the System Variable values. Thus, the changed configuration details will be available for all the reports. Please refer to the following Code Snippet:
[Function: TSPL Smp Update System Variables]
10 : SET : ().SVMailServerName : ##SVMailServerName
20 : SET : ().SVMailServer : ##SVMailServer
30 : SET : ().SVMailFormat : ##SVMailFormat
40 : SET : ().SVMailUseSsl : ##SVMailUseSsl
50 : SET : ().SVMailUseSSLOnStdPort : ##SVMailUseSSLOnStdPort
60 : SET : ().SVMailAuthUserName : ##SVMailAuthUserName
70 : SET : ().SVExportFormat : ##SVExportFormat
This is a path-breaking enhancement in Tally which will enable scheduled execution of any Action. This has been supported with the introduction of a System Event called Timer. We can have a set of timer events of specified durations and trigger an Action on the same. For example, if we require Synchronization to be triggered at every one hour, we can define a Timer event which triggers the action ‘Sync’. Actions for Starting and Stopping the timer have been provided.
As we are already aware, Events like System Start , System End , Load Company , Close Company , On Form Accept , etc., introduced earlier as a part of the Event Framework, require user intervention. Automated events which can be used to take timely backups, display automated messages, etc., were not possible earlier. With the breakthrough introduction of Timer Event, performing Timer based automated events is possible now. System Event Timer has been introduced to perform the required set of operations automatically at periodic intervals.
Syntax
[System : Event]
<Timer Name> : TIMER : <Condition> : <Action> : <Action Parameters>
Where,
< Timer Name > is the user defined name for the timer event.
< TIMER > keyword indicates that it is a Time-based event.
< ConditionExpr > should return a logical value.
< ActionKeyword > is any one of the actions.
< Action Parameters > is nothing but the parameters of the action specified.
We can have multiple Event Handlers with unique names which can invoke specific Actions at different intervals. In order to specify the interval for the various Timers and to begin and end the Timers, the associated Actions introduced are ‘Start Timer’ and ‘Stop Timer’.
It starts the specified timer and accepts the Timer Name and Duration in seconds as the action parameters.
Syntax
START TIMER : <Timer Name> : Duration in seconds
Where,
< Timer Name > is the user defined name for the timer event.
This action stops the specified timer, and it accepts the Timer Name as its parameter.
Syntax
STOP TIMER : <Timer Name>
Where,
< Timer Name > is the user defined name for the timer event.
Following is an example of scheduling automatic backups every hour:
Example
[System : Event]
;; Setting up timer event to call a function
Auto Backup : TIMER : TRUE : CALL : Take Backup Function
;; Starting the Timer when Tally Application Starts
Schedule Backup : System Start : TRUE : START TIMER : Auto Backup : 3600
;; Adding Keys to ‘Company Info’ Menu
[#Menu : Company Info.]
Add : Keys : Stop Backup Timer
;; Declaring a Key to Stop the Timer
[Key : Stop Backup Timer]
Key : Alt + S
Action : Stop Timer : Auto Backup
Title : “Stop Backup”
In this example, following is done:
1. Auto Backup, a Timer event is declared under System Event to invoke the function
2. Take Backup function at periodic intervals, as specified within the action Start Timer .
3. Schedule Backup, a System Start event is declared under System Event to Start the above Timer ‘Auto Backup’ and execute the specified action every 3600 Seconds, i.e., every hour.
4. A corresponding Key to Stop the Timer is associated to Menu Company Info, which is defined to Stop the Timer. User can stop the timer if he chooses not to continue taking automatic backups any further.
Timer events can be very useful in many cases like displaying Exception Reports , Negative Balances intimation, Inventory Status below Minimum or Reorder Level, Outstanding Reminders , Auto Sync at regular intervals, and many more.
Action Enhancemen t s
New actions have been introduced in this release, viz. Refresh Data, Copy File and Sleep.
In Tally, whenever any report is being viewed, it contains the most recent updates till the last entry. If any report is left open and subsequently viewed later, possibly few more entries would have gone in the system entered by various other users on the Network. Hence, the report which is currently being viewed is older. To view the updated report, the user has to exit the report and once again, enter the Report. To solve this problem, a new action ‘Refresh Data’ has been introduced, which refreshes the data in memory automatically, as and when required.
Syntax
REFRESH DATA
Refresh Data can be used along with Timer Event and every few seconds, the Report can be refreshed automatically to display the updated information.
Example
[System : Event]
Refresh Timer : TIMER : TRUE : Refresh Data
[#Form : Balance Sheet]
Add : Keys : Enable Refresh
[Key : Enable Refresh]
Key : Alt + R
Action : Start Timer : Refresh Timer : 300
In this example, Refresh Timer , a Timer event is declared under System Event to invoke the Action Refresh Data at periodic intervals. A key Enable Refresh is added in the Balance Sheet Report, which will be used to Start the Timer Refresh Timer every 5 minutes.
Note: The action ‘Refresh Data’ is a Company Report - Specific Action. It will always require a Report in memory to Refresh the Data.
Action SLEEP has been introduced to specify time delays during the execution of the code. For few seconds, the system will be dormant or in suspended mode.
Syntax
SLEEP : <Duration in Seconds>
< SlEEP > is the action which halts the functioning of the Application for a few seconds as specified in <Duration in >.
Example:
[#Menu : Gateway of Tally]
Add : Item : Trial Balance after 10 secs : CALL : TBafterSleep
[Function : TBafterSleep]
00 : SLEEP : 10
10 : DISPLAY : Trial Balance
In this example, the system will halt for 10 seconds and display the Trial Balance subsequently.
A new action ‘Copy File’ has been introduced, which allows:
● Copying from one location to another within the same System
● Uploading of Files from a given Path to a FTP Site
● Downloading of File from FTP Site to the specified location/folder
Syntax
Copy File : <Destination File Path> : <Source File Path>
Where,
< Destination File Path > can be any expression evaluating to a valid local/FTP path.
< Source File Path > can be any expression evaluating to a valid local/FTP path.
Example
CopyFile : ##MyDstFilePath : ##MySourceFilePath
If any of the File path is an FTP path, the same can be constructed using functions like $$MakeFTPName. It accepts various parameters like servername, username, password, etc. The following code snippet sets the value of the variable MyDstFilePath using the function $$MakeFTPName.
SET : MyDstFilePath : $$MakeFTPName : ##SVFTPServer : ##SVFTPUser : ##SVFTPPassword : @SCFilePathName
The function $$MakeFTPName uses the various parameters which are System Variables captured from the default configuration reports.
There have been various enhancements at the TDL level to enable Remote Edit Capability in the product. The enhancements are as follows:
‘Fetch Object’ Attribute Changes
The attribute ‘Fetch Object’ has been supported at Report, Form, Field and the Function level as well. The Object Name specification in the syntax allows expressions now. It is also possible to specify multiple Object Names separated by the Fetch Separator Character. A new function $$FetchSeparator has been introduced to return this character.
‘Fetch Values’ Attribute Introduced
The evaluation of External Methods of an Object requires Object Context to be available at the Client End. A new Attribute ‘Fetch Values’ has been provided at the ‘Report’ level to specify the list of External Methods.
‘Multi Objects’ Attribute Introduced
Whenever multiple Objects of the same collection are getting modified at the Client’s End, a new attribute called ‘MultiObjects’ is introduced at the Report Level to enable the same.
‘Modifies’ Attribute Changes
The ‘Modifies’ attribute of the field has been changed to accept a third parameter (optional) which is an expression. This allows the variable to be modified with the value of the expression rather than the field value.
Collection attribute ‘Parm Var’ Introduced
As we already know, the ‘Collection’ Artefact evaluates the various attributes either during initialization or at the time of gathering the collection. It may require various inputs from the Requestor context for the same.
The direct reference of values/expressions from the report elements and objects in the collection at various points creates various issues like code complexity, performance lapses and non availability of these values on Server in Remote Environment.
In order to overcome these, a new Collection attribute ‘Parm Var’ has been introduced. ‘Parm Var’ in collection is a context-free structure available within the collection. The requestors Object context is available for the evaluation of its value. This is evaluated only once in the context of the caller/requestor. This happens at collection initialization, and the expression provided to it is evaluated and stored as a variable, which can be referred within any of the attributes of the collection anytime, and is made available at the Server end as well.
Lets understand each of these in detail.
When multiple methods of a Single Object/Multiple Objects of the same type are required, then that Object can be fetched at Report, Form, Field and Function levels.
Report Level
‘Fetch Object’ attribute has been enhanced at ‘Report’ level to take an expression instead of a variable name that evaluates to the name of an object.
The existing syntax of the ‘Fetch Object’ attribute at report level is as follows:
Syntax: Prior to 2.0
Fetch Object : <Object Type> : <Variable Identifier > : <List of methods>
Example
Fetch Object: Ledger: LedgerName: Name, Parent, ClosingBalance
Syntax: 2 . 0 Onwards
Fetch Object : <Object Type> : <Expression> : <List of methods>
Example
Fetch Object: Ledger: ##LedgerName: Name, Parent, ClosingBalance
Here, since the Object name is an expression, we need to prefix the variable name with ##.
Form Level
Attribute ‘Fetch Object’ has been introduced at ‘Form’ Level. In scenarios where multiple forms are available at a report; for each form, we require to fetch methods pertaining to different objects.
Syntax
Fetch Object : <Object Type> : <Expression> : <List of methods>
Example
[!Form : AccoutingViewVoucher]
Switch : AccVoucherView : NormalAccoutingViewVoucher : NOT$$IsAttendance : ##SVVoucherType
Switch : AccVoucherView : AttdAccoutingViewVoucher : $$IsAttendance:##SVVoucherType
[!Form : AttdAccoutingViewVoucher]
Fetch Object : AttendanceType : @@AttdEntryList : AttendanceProductionType, AttendancePeriod, BaseUnits
[!Form : NormalAccoutingViewVoucher]
FetchObject : Ledger : @@AllLedEntryList : Name, Parent, ReserveName
Field Level
There may be scenarios where we may need to Fetch Object values dynamically based on the current field values. For example, the field may be associated with a Table of ledgers. Based on the ledger selected, the corresponding methods of the Object require to be fetched. In such cases, this attribute will be useful.
Syntax
Fetch Object : <Object Type> : <Expression> : <List of methods>
Example
[Field : LED VAT Class]
Fetch Object : TaxClassification : $$Value:FirstAlias, RateofVAT, TaxType
Function Level
There may be scenarios where the method values need to be fetched based on the Object name passed as a parameter to the function. In such cases, ‘Fetch Object’ at the function level is required.
If we have already fetched the object methods at the ‘Report’ or ‘Field’ level, the same will be propagated to the called function. In case it is not fetched earlier, the same can be fetched at the ‘Function’ level as well. This enables dynamic fetching of Objects.
Syntax
Fetch Object : <Object Type> : <Expression> : <List of methods>
Example
[Function : FillUsingTrackingObj]
Parameter : pTrackKey : String
Fetch Object : Tracking Number : ##pTrackKey : *.*
In case the same set of methods for multiple objects needs to be fetched, the multiple Object Names need to be specified in the syntax of ‘Fetch Object’, separated by the Fetch separator character.
This function returns C_FETCH_SEPARATOR character that is used for separating multiple object names in FETCH OBJECT attribute.There may be scenarios where the same set of methods needs to be fetched from multiple objects. In that case, it is possible to specify multiple object names in the ‘Fetch Object’ syntax, separated by the character which is returned from the function $$FetchSeparator.
Example
Fetch Object : Ledger : “Debtor North” + $$FetchSeparator + “Debtor South” : Name, Parent, ClosingBalance
This is a report level attribute which allows computation of values for user defined (external) methods, based on the current Object context available.
Syntax
Fetch Values : <List of methods>
Example
[Report : VAT Classification]
Object : Tax Classification
Fetch Values : MasterID, CanDelete
This is a ‘Report’ level attribute which is required to be specified, in case Multiple Objects of the same collection are being added/modified in a Report. It is required specifically in case of multi master creation or alteration.
Syntax
MultiObjects : <Edit Collection>
Where,
< Edit Collection > is the name of the Collection for which modifications are to be done.
Example
[Report : Multi Ledger]
Multi Objects : Ledger Under MGroup
This is a field level attribute enhanced further to take a third optional parameter. Prior to Tally.ERP 9 Release 2.0, if a field had ‘Modifies’ parameter, the field value would be set to the variable. And based on this variable value, some calculations or concatenation was required to be performed. An invisible field was required for the same. With the enhancement in this Release, one can modify the variable value at the same field itself using an expression, i.e., the field, and the variable may have different values.
Syntax: P r ior 2.0
Modifies : <Variable Name> : <Logical Value>
Where,
< Variable Name > is the name of the variable.
< Logical Value > is any expression which evaluates to a logical value.
Example
[Field : BatchesInGodown]
Modifies : DSPGodownName : Yes
Syntax: 2 . 0 onwards
Modifies : <Variable Name> : <Logical Value> : <expression>
Where,
< Variable Name > is the name of the variable.
< Logical Value > is any expression which evaluates to a logical value.
< Expression > can be used to modify the variable value within the field.
Example
[Field : BatchesInGodown]
Modifies : DSPGodownName : Yes : ##DSPGodownName + “ - Godown”
As we already know, the ‘Collection’ Artefact evaluates the various attributes either during initialization or at the time of gathering the collection. It may require various inputs from the Requestor context for the same. For example, the evaluation of ‘Child of’ and ‘Filter’ attributes happens at the time of gathering the collection. It requires certain values from Requestors context like $name. In ‘Filter’ attribute, if $name of each object is to be compared with $name of the Requestors context, then we have to refer it as $ReqObject:$name. The direct reference of values/expressions from the report elements and objects in the collection at various points, creates a few issues as follows:
● Code complexity is increased, as observed in the Filter example above.
● The performance is impacted, as there is are repeated references in case of Filters.
● In a Remote Environment; where the Requestor Context is not available within the collection at the Server side
In order to overcome the above, a new Collection attribute ‘Parm Var’ has been introduced.
We already have the capability of declaring inline variables at collection level using the Attributes Source Var, Compute Var and Filter Var. These are context free structures available within the collection for various evaluations. For storing values in these, the various object contexts available are Source Objects, Target Objects, etc. One more attribute called ‘Parm Var’ has been introduced in collection, which is a context-free structure available within the collection. The request- ors Object context is available for evaluation of its value. This is evaluated only once in the context of caller/requestor. This happens at collection initialization and the expression provided to it is evaluated and stored as a variable which can be referred within any of the attributes of the collection anytime, and is made available at the Server end by passing it with the XML Request.
The attribute ParmVar evaluates the value of the variable based on the requestor object’s context.
Syntax
Parm Var : <Variable Name> : <Data Type> : <Formula>
Where,
< Variable Name > is the name of variable.
< Data Type > is the data type of the variable.
< Formula > can be any expression which evaluates to the value of ‘Variable’ data type.
Example
[Part : Groups and Ledgers]
Lines : Groups and Ledgers
Repeat : Groups and Ledgers : List of Groups
Scroll : Vertical
[Line : Groups and Ledgers]
Fields : GAL Particulars
Right Fields : GAL ClosBal
Explode : List of Ledgers : ##ExplodeFlag
[Part : List of Ledgers]
Lines : List of Ledgers
Repeat : List of Ledgers : Smp List of Ledgers
[Collection : Smp List of Ledgers]
Type : Led ger
Child Of : $Name
In the collection Smp List of Ledgers, the Child of attribute is evaluated based on the method $Name which is available from the Group Object in context. The line Groups and Ledgers (Requestor Object) is associated with a Group Object.
In a Remote environment, when such a Report is being displayed at the Clients end, the request for the collection gathering goes to the Server End. At the server end, the Requestor Context is not available. So, the evaluation of $Name will fail. To overcome such a situation, a new attribute called “Parm Var” has been introduced, which is a context-free structure available within the collection. It evaluates the expression based on the Requestors Context, thereby available at the Server Side also.
The Collection is Redefined as follows using the attribute ParmVar .
[Collection : Smp List of Ledgers]
Type : Ledger
Child Of : ##ParmLedName
Parm Var : ParmLedName : String : $Name
The value of variable ParmLedName is evaluated at the Client side based on method $name available from Group Object Context, and sent to the Server. While gathering the objects at the server side, the attribute ChildOf is evaluated, which uses the variable ParmLedName instead of $Name, available at the Server.
In the release 2.0, many new features like Remote Edit, SMS support, etc., have been introduced. The TDL language is also enriched with new capabilities to support these features. Using the new language capabilities, the source code of Tally.ERP 9 Release 2.0 has also been enhanced. The changes have been made in many definitions. For example, the values of some of the attributes have been changed, new attributes have been added and formulas have been rewritten.
Although, it has been tried to ensure maximum backward compatibility, there may be cases where the application developer may require to validate/rewrite the existing TDL codes to make them compatible with Tally.ERP 9 Release 2.0. In this section, the changes have been summarised in terms of listing the definitions. Although sincere efforts have been made in the direction of providing a comprehensive listing of definitions, one may come across a few cases where changes have been made. If any of these definitions are being used in customisations, one must refer to the source code changes available with the latest Release of TDE.
This release onwards, Fetch is mandatory in every collection. All the methods which are required to be used in a Report are to be fetched at the Collection level.
Whenever a new Voucher is being created, it is important to take care of the following:
● The variable name “SVViewName” has to be set to System Names
o AcctgVchView – For all Accounting vouchers
o InvVchView – For all Inventory vouchers, except Stock Journal voucher
o PaySlipVchView – For Payroll vouchers
o ConsVchView – For Stock Journal voucher
● The method ‘PersistedView’ has to be set to the value of the variable ‘SVViewName’.
Example
ds : Set : SVViewName : $$SysName:AcctgVchView
10 : NEW OBJECT : Voucher
|
|
Aa : Set Value : PersistedView : ##SVViewName
30 : CREATE TARGET
Many existing ‘collection’ definitions have been converted as Extract Collections. So, if these collections are used in any of the user TDLs, the code needs to be rewritten for Tally.ERP 9 Release 2.0. Many fields which were using the old collections as Tables have been modified to use the Extract Collections now. The ‘Table’ Attribute has been changed for those fields.
The following Table shows the fields in which extract collections are used in the ‘Table’ attribute:
|
Field N a me |
Ta b le Name OLD |
Extract Collection/ T able N a me |
|
EI AccAllocName |
Inv SalesLedgersAlloc Inv Purch Ledgers Inv Sales Income Ledgers Inv Purch Expense Ledgers NonInv Purch Support Ledgers NonInv Sales Support Ledgers |
Inv SalesLedgersAlloc Extract Inv Purch Ledgers VchExtract Inv Sales Income Ledgers Extract Inv Purch Expense Ledgers Extract NonInv Purch Support Ledgers - VchExtract NonInv Sales Support Ledgers - VchExtract |
|
EI Consignee |
Party Ledgers, Cash Ledgers Invoice Ledgers |
Party Cash Ledgers Extract Invoice Ledgers Extract |
|
EICommonLED |
Inv Sales Ledgers Inv Purch Ledgers Inv Sales Income Ledgers Inv Purch Expense Ledgers |
Inv Sales Ledgers Extract Inv Purch Ledgers Extract Inv Sales Income Ledgers Extract Inv Purch Expense Ledgers Extract |
|
VCH VATClass |
VCH VAT Sales ClassificationVCH VCH VAT Purc ClassificationVCH |
VCH VAT Sales ClassificationVCH Extract VCH VAT Purc ClassificationVCH Extract |
|
VCH AccAllocVAT Class |
VCH VAT Sales ClassificationVCH VCH VAT Purc ClassificationVCH |
VCH VAT Sales ClassificationVCH Extract VCH VAT Purc ClassificationVCH Extract |
|
VCH POS PartyContact |
Party Ledgers |
Party Ledgers Extract |
|
VCHACC StockItem |
Vch Stock Item |
Vch Stock Item Extract |
|
VCHJRNLStockItem |
Vch Stock Item |
Vch Stock Item Extract |
|
ACGLLed |
GainLoss Ledgers |
GainLoss Ledgers Extract |
|
ACLSFixedLed |
Cash Class Ledgers |
Cash Class Ledgers Extract |
|
ACLSLed |
Cash Ledgers Normal Ledgers Normal Ledgers, Cash Ledgers Non CENVAT Ledgers Non CENVAT Ledgers, Cash Ledgers, |
Cash Ledgers VchExtract Normal Ledgers Extract Normal Cash Ledgers Extract Non CENVAT Ledgers Extract Non CENVAT Cash Ledgers Extract |
|
EI AccDesc |
Sales Support Ledgers Purchase Support Ledgers |
Sales Support Ledgers VchExtract Purchase Support Ledgers VchExtract |
|
VCH AccVATClass |
SD Sales Classification Etc… |
SD Sales Classification Extract Etc … |
|
VCHIndentStockItem |
Vch Stock Item |
Vch Stock Item Extract |
|
VCHBATCH Godown |
Stockable Godown JOB Stockable Godown |
Stockable Godown VchExtract JOB Stockable Godown VchExtract |
|
VCHBATCH OrdrName |
Active Batches |
Active Batches VchExtract |
|
VCHBATCH NrmlName |
Active Batches |
Active Batches VchExtract |
|
VCHBATCH JrnlName |
Active Batches |
Active Batches VchExtract |
|
EI VATClass |
SD Sales Classification VCH VAT Sales ClassificationVCH VCH VAT Purc ClassificationVCH VAT Sales With Rate ClassificationVCH VAT Purc With Rate ClassificationVCH Addl VAT Sales With Rate ClassificationVCH Addl VAT Purc With Rate ClassificationVCH CessOn VAT Sales With Rate ClassificationVCH CessOn VAT Purc With Rate ClassificationVCH CST Sales With Rate Classification CST Purc With Rate Classification |
SD Sales Classification Extract VCH VAT Sales ClassificationVCH Extract VCH VAT Purc ClassificationVCH Extract VAT Sales With Rate ClassificationVCH Extract VAT Purc With Rate ClassificationVCH Extract Addl VAT Sales With Rate ClassificationVCH Extract Addl VAT Purc With Rate ClassificationVCH Extract CessOn VAT Sales With Rate ClassificationVCH Extract CessOn VAT Purc With Rate ClassificationVCH Extract CST Sales With Rate Classification Extract CST Purc With Rate Classification Extract |
|
VCHBATCH GRNName |
Active Batches |
Active Batches VchExtract |
|
POS BatchName |
Active Batches |
Active Batches VchExtract |
|
VCHBATCH DealerGodown |
Stockable DealerGodown |
Stockable DealerGodown VchExtract |
|
VCHBATCH ExciseMfgrGodown |
Stockable ExciseMfgrGodown |
Stockable ExciseMfgrGodown VchExtract |
|
VCHBILL TDSLedger |
TDS Ledger Table |
TDS Ledger Table VchExtract |
|
VCHBILL STaxLedger |
Service Tax Ledger Table |
Service Tax Ledger Table VchExtract |
|
VCHCSTCAT Name |
Voucher Cost Category |
Voucher Cost Category VchExtract |
|
VCHCST Name |
Cost Centre All Cost Centre |
Cost Centre VchExtract All Cost Centre VchExtract |
|
STKVCH Ledger |
Party Ledgers, Cash Ledgers |
Party Cash Ledgers Extract |
|
PF CashBank Ledger |
Cash Ledgers |
Cash Ledgers VchExtract |
|
VCH AttdEmpName |
Payroll DeactvationEmployees |
Payroll DeactvationEmployeesExtract |
|
VCH AttdType |
List of Attendance Types |
List of AttdTypesExtract |
|
VCH AutoAttdType |
List of Attendance Types |
List of AttdTypesExtract |
|
VCH EmpName |
Payroll Cost Centres Manual Vch Employees Under Category |
Payroll CostCentres AsVCHExtract Manual AsVchEmployees Under CategoryExtract |
|
PAYROLLFixedLed |
Payroll Liab Ledgers |
Payroll Liability LedgersExtract |
|
Payroll VCH Emp- CatParticulars |
List of CostCategories |
List of CostCategories Extract |
|
Payroll VCH Emp- Particulars |
Payroll Cost Centres Manual Vch Employees Under Category |
Payroll CostCentres VCHExtract Manual Vch Employees Under CategoryExtract |
|
PayrollVCHPayhead Name |
Vch Pay Heads |
Vch Pay Heads Extract |
|
Payroll FunctionAuto- CategoryName |
Payroll Vch Categories |
Payroll Vch Categories Extract |
|
Payroll FunctionAu-toCstTables |
Payroll Cost Centres AutoVch Employees Under Category |
AutoVch PyrlCostCentres VCHExtract AutoVch Employees Under CategoryExtract |
|
Payroll FunctionAuto- PayheadName |
Payroll Ledgers |
AutoVch PayrollLedgersExtract |
|
TDSAutoLedger |
Normal Ledgers |
Normal Ledgers Extract |
|
TDSFilter Bank |
Cash Class Ledgers |
Cash Class Ledgers Extract |
|
EI TrackOrder |
InvSalesOrders InvPurcOrders |
InvSalesOrders, Not Applicable, EndOfList, NewNumber InvPurcOrders, Not Applicable, EndOfList, NewNumber |
|
EI SalesOrder |
InvSalesOrders InvPurcOrders |
InvSalesOrders, Not Applicable, EndOfList, NewNumber InvPurcOrders, Not Applicable, End- OfList, NewNumber |
|
SRVTPartyName |
Service Party Ledgers |
Service Party Ledgers Extract |
|
SRVTPartyBillName |
Pending Party Bills |
Pending Party Bills Extract |
|
Definition Type |
Definition Name |
|
Part |
VCH Excise SubCat Tax Rate |
|
|
Trader PurcTypeofDuty |
|
|
VCH Excise SubCat Tax Rate |
|
Field |
VCH Excise SubCat Tax Rate |
|
|
Trader PurcTypeofDuty |
|
|
TDS TaxPartyLedger |
|
|
VCH TaxPymtDetails |
|
|
Trader PLARG23SlNo |
|
|
Trader SupplierRG23No |
|
|
Trader OriginalRefNo |
|
|
Trader MfgrImprName |
|
|
Trader DN SupplierInvNo |
|
|
Trader DN SupplierInvDate |
|
|
Trader DN NatureofPurc |
|
|
Trader DN QtyPurchased |
|
|
Trader DN QtyReturn |
|
|
Trader DN AssessableValue |
|
|
Trader CN SupplierInvNo |
|
|
Trader CN SalesInvDate |
|
|
Trader CN SalesInvNo |
|
|
Trader CN QtySold |
|
|
Trader CN QtyReturn |
|
|
Trader CN SplAEDOfCVDNotPassOn |
|
|
DealerInv AmtofDuty |
|
|
DealerInv DutyPerUnit |
In the definition [Form: Voucher], the option for ‘Alter’ mode is added and it is used to list all the fetches.
|
Definition Type |
Definition Name |
|
Form |
Vouc h er |
‘Fetch Object’ Added:
|
Definition Type |
Definition Name |
|
Field |
VCH S tockItem |
‘Compute V a r ’ and ‘Fetch’ Attributes Added
|
Definition Type |
Definition Name |
|
Collection |
Vouchers of FBT Category Calc |
|
Memo Vouchers of FBT Category Calc |
|
|
FBTCategoryCalc |
|
|
Vouchers of Regular FBT Category Calc |
|
|
Vouchers of Recovered FBT Category Calc |
|
|
VCHInTNo |
|
|
VCHInTNoG |
|
|
VCHInTNoB |
|
|
VCHInTNoBG |
|
|
VCHOutTNo |
|
|
VCH OutTNoG |
|
|
VCH OutTNoB |
|
|
VCH OutTNoBG |
|
|
TaxBill Details |
|
|
PayFunctionCaterotyCollection |
|
|
PayFunctionEmployeeCollection |
|
|
AllStatLedgersSlabSummary |
|
|
AllPFStatLedgers |
|
|
Admin AutoFil JrnlEmployees |
|
|
AutoFil PF Ledgers |
|
|
Admin AutoFil Employees |
|
|
AdminAutoPayableColl |
|
|
AdminAutoPayableColl PayrollSrc |
|
|
AdminAutoPayableCollJrnl |
|
|
AdminAutoPayableColl JrnlSrc |
|
|
PFESI EmployeeFilter Summary |
|
|
PFESI EmployeeFilter Vouchers |
|
|
Excise RG23DNoColl |
|
|
Trader ListOfPurcCleared |
|
|
Trader ListOfPurcNonCleared |
|
|
Trader ListOfMultiPurcCleared |
|
|
Trader ListOfMultiPurcNonCleared |
|
|
ExciseDealer Inventory Entries |
|
|
ExciseDealerInvoice InventoryEntries |
|
|
TDS DeductSameVoucher |
|
|
TDS TaxObjPartyBills |
|
|
TDS ITIgnoreNOP |
|
|
TDSDuty LedTable |
|
|
TaxObj AgstTableDebitNote |
|
|
TaxObj AgstTable |
|
|
SRCTaxObj AgstTable |
|
|
TDS CommonPartyLedger |
|
|
TaxObj AdvAgstTable |
|
|
TaxObj DedTable |
|
|
Pending TCS Bills |
|
|
PndgTaxBillsTillCurVchDate |
|
|
TaxBillColl |
|
|
TCS Vouchers of Party |
|
|
Pending Tax Bills |
|
|
BankColl |
|
|
InvSalesOrders |
|
|
ExciseInvSalesOrders |
|
|
InvPurcOrders |
|
|
InvOutTrackNumbers |
|
|
InvInTrackNumbers |
|
|
Pending Sales Orders |
|
|
VCHSo |
|
|
Pending Purc Orders |
|
|
VCHPo |
|
|
VCH OutTNo Src |
|
|
InPending Tracking Numbers |
|
|
OutPending Tracking Numbers |
|
|
Pending Bills |
|
|
STX SalePending TaxObj |
|
|
Pending STaxParty Bills |
|
|
STX CrDrNotePending TaxObj |
|
|
STX CategorywisePending TaxObj |
|
|
STX RcptPending TaxObj |
|
|
STXSource |
|
|
STX SalePending TaxObj |
|
|
STX JV SalePending TaxObj |
|
|
STXTaxObjOutput GAR7PymtAlloc |
|
|
STXTaxObjInput GAR7PymtAlloc |
|
Definition Type |
Definition Name |
|
Function |
ESIDeductionPayFunction |
|
ESIEligibilityPayFunction |
|
|
ESIContributionPayFunction |
|
|
PFNormalPayFunction |
|
|
PTNormalPayFunction |
|
|
PTMonthlyPayFunction |
|
|
FirstEPF12PayHeadAbsVal Function |
|
|
FirstEPF833PayHeadAbsVal Function |
|
|
PFNormalVchPayFunction |
|
|
PTMonthlyVCHPayFunction |
|
|
PTNormalVchPayFunction |
|
|
ESIDeductionVchPayFunction |
|
|
ESIEligibilityVCHPayFunction |
|
|
ESIEligibilityOnCurrentEarnVch |
|
|
ESIEligibilityOnSpecifiedFrmlVch |
|
|
ESIContributionVchPayFunction |
|
|
FirstEPF12PayHeadAbsVchVal Function |
|
|
FirstEPF833PayHeadAbsVchVal Function |
|
|
IsExciseRG23DNoExistsFunc |
|
|
IsSpecialAEDOfCVDExistsInStkItem |
|
|
SetTDSPymtDetails |
|
|
VoucherFill |
|
|
OrderObjExists |
|
|
TrackingObjExists |
|
|
FillUsingVoucher |
|
|
CopyBatchAllocationsValues |
|
|
STCatCheck |
|
|
STCatRate |
|
|
STCatCessRate |
|
|
STCatSecondaryCessRate |
|
|
STCatAbatmentNo |
|
|
STCatAbatPer |
|
|
STCatCheck |
Few Attributes added and ‘DebugExec’ Action Used
