https://help.tallysolutions.com/docs/td9rel54/tdl_reference/release_2_0.htm

What’s New in Release 2.0

TDL Procedural Enhancements

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.

TDL Procedural File Input/Output 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.

File Contexts

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.

File Operations

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.

General File Operations

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.

Action – OPEN 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.

Actions – CLOSE FILE and CLOSE TARGET FILE

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.

Action – CLOSE FILE

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.

Action – CLOSE TARGET FILE

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.

General Functions - $$TgtFile, $FileSize

Function - $$TgtFile

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.

Function - $$FileSize

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.

Read/Write Operation on Text Files

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.

Action – WRITE FILE

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.

Action – WRITE FILE LINE

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.

Action – TRUNCATE 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.

Action – SEEK FILE

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.

Function - $$FileRead

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.

Function - $$FileIsEOF

This function is used to check if the current character being read is the End of file character.

Syntax

$$FileIsEOF

Action – SEEK SOURCE FILE

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.

Read/Write Operation on Excel Files

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 .

Action – SET ACTIVE SHEET

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.

Action – ADD SHEET

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.

Action – REMOVE SHEET

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

Action – RENAME 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.

Action – WRITE CELL

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

Action – WRITE ROW

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

Action – WRITE COLUMN

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

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.

Function - $$FileReadCell

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

Function - $$FileGetSheetCount

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

Function - $$FileGetActiveSheetName

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

Function - $$FileGetSheetName

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

Function - $$FileGetSheetIdx

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.

Function - $$FileGetColumnName

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 .

Function - $$FileGetColumnldx

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.

Use Case – Import from Excel

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.

Figure_1._The_Configuration_Report_(2.0).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.

Figure_2._The_Configuration_Report_(2.0).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:

Figure_3._Success_Report_(2.0).jpg

If the user has selected the option to display the Log file, then after the import, the log file is displayed as follows:

Figure_4._Log_File_(2.0).jpg S

The imported items are now available in the Stock Item list as follows:

Figure_5._List_of_Stock_Items_(2.0).jpg

In case the import is unsuccessful, the error report, with the reason of failure, is displayed as follows:

Figure_6._Error_Report_(2.0).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.

Function Parameter Changes – Optional Parameters

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

Variable Framework Enhancements

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. The following enhancements have taken place in variable framework recently.

Variable Persistence at ‘Report’ Scope

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.

Action - SAVE VARIABLE

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

Action - LOAD VARIABLE

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.

Variable Copy

The contents of a variable can now be entirely copied from one instance to another instance.

Action - COPY VARIABLE

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

Scope Specification in Variable Dotted Syntax

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)

Definition Name and Instance Name of Variable can be different now

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.

Use Case – Multiple Email Configurations

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:

Figure_7._Email_Configuration_Screen_(2.0).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:

Figure_8._User_Defined_Configuration_(2.0).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:

Figure_9._Save_Configuration_Screen_(2.0).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:

Figure_10._Files_in_Application_folder_(2.0).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:

Figure_11._Load_Configuration_Screen_(2.0).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:

Figure_12._Email_Configuration_Screen_(2.0).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:

Declaring variables at ‘Report’ Level

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

Saving Configuration

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.

Loading Configurations

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

Event Framework Enhancements

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.

Timer Event

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

Actions - Start Timer and Stop Timer

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

Action - STOP TIMER

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.

Action - Refresh Data

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

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.

Action - Copy File

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.

TDL Enhancements for Remoting

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

‘Fetch Object’ Attribute Changes

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

‘Fetch Values’ Attribute Introduced

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

‘Multi Objects’ Attribute Introduced

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

‘Modifies’ Attribute Changes

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

Collection attribute ‘Parm Var’ Introduced

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

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

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

Lets understand each of these in detail.

‘Fetch Object’ Attribute Changes

When multiple methods of a Single Object/Multiple Objects of the same type are required, then that Object can be fetched at Report, Form, Field and Function levels.

Report Level

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

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

Syntax: Prior to 2.0

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

Example

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

Syntax: 2 . 0 Onwards

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

Example

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

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

Form Level

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

Syntax

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

Example

[!Form : AccoutingViewVoucher]

Switch : AccVoucherView : NormalAccoutingViewVoucher : NOT$$IsAttendance : ##SVVoucherType

Switch : AccVoucherView : AttdAccoutingViewVoucher : $$IsAttendance:##SVVoucherType

[!Form : AttdAccoutingViewVoucher]

Fetch Object : AttendanceType : @@AttdEntryList : AttendanceProductionType, AttendancePeriod, BaseUnits

[!Form : NormalAccoutingViewVoucher]

FetchObject : Ledger : @@AllLedEntryList : Name, Parent, ReserveName

Field Level

There may be scenarios where we may need to Fetch Object values dynamically based on the current field values. For example, the field may be associated with a Table of ledgers. Based on the ledger selected, the corresponding methods of the Object require to be fetched. In such cases, this attribute will be useful.

Syntax

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

Example

[Field : LED VAT Class]

Fetch Object : TaxClassification : $$Value:FirstAlias, RateofVAT, TaxType

Function Level

There may be scenarios where the method values need to be fetched based on the Object name passed as a parameter to the function. In such cases, ‘Fetch Object’ at the function level is required.

If we have already fetched the object methods at the ‘Report’ or ‘Field’ level, the same will be propagated to the called function. In case it is not fetched earlier, the same can be fetched at the ‘Function’ level as well. This enables dynamic fetching of Objects.

Syntax

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

Example

[Function : FillUsingTrackingObj]

Parameter : pTrackKey : String

Fetch Object : Tracking Number : ##pTrackKey : *.*

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

Function – $$FetchSeparator

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

Example

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

‘Fetch Values’ Attribute Introduced

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

Syntax

Fetch Values : <List of methods>

Example

[Report : VAT Classification]

Object       : Tax Classification

Fetch Values : MasterID, CanDelete

‘Multi Objects’ Attribute Introduced

This is a ‘Report’ level attribute which is required to be specified, in case Multiple Objects of the same collection are being added/modified in a Report. It is required specifically in case of multi master creation or alteration.

Syntax

MultiObjects : <Edit Collection>

Where,

< Edit Collection > is the name of the Collection for which modifications are to be done.

Example

[Report : Multi Ledger]

Multi Objects : Ledger Under MGroup

‘Modifies’ Attribute Changes

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

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

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. 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 collec­tion 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.

Collection Attribute - Parm Var

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.

Default TDL Changes

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.

Mandatory ‘Fetch’ at the Collection Level

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.

Voucher Creation

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

Extract Collections List and Usage as Tables

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 Cen­tre

Cost Centre VchExtract All Cost Centre VchExtract

STKVCH Ledger

Party Ledgers, Cash Led­gers

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- Cat­Particulars

List of CostCategories

List of CostCategories Extract

Payroll VCH Emp- Par­ticulars

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-toC­stTables

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

Modified Definition List and corresponding Changes

Changes in ‘Set As’

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

Options added in Alter Mode

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