Following are the highlights of language enhancements in this Release, which have been discussed ahead in detail:
● In Developer Mode, enhancements like creation of log files in Excel format, enriched Key Recording/Playback, and introduction of new Calculator Pane Commands, have been made.
● Event NatLangQuery has been introduced to pass control to the TDL program, when a request is received by way of SMS or Calculator Pane commands.
● Zip/Unzip Capability has been introduced, which allows compression/ decompression of files. Password protection is also supported.
● Editing capability has been extended to Columnar Reports.
● New data types Date, DateTime and Duration have been introduced, which along with the existing data types ‘Date’ and ‘Due Date’, are now collectively called as Calendar data types.
In market, there are customers using Tally.ERP 9 for their day-to-day operations and also developers or partners who build solutions for the customers. To empower the developers of Tally with various tools to builds solutions efficiently, a new capability to operate Tally in the Developer Mode was introduced in Release 4.6. In other words, capability was introduced to operate Tally in two modes, viz., Normal Mode , to be used by the End Users and Developer Mode , to be used by the TDL Developers. Through the Developer mode, a host of Developer Tools have been offered for debugging the code, optimizing the performance of customized reports, recording the user operations and playing them back, etc.
To further enrich the Developer Mode experience, following enhancements have been incorporated in this release.
Microsoft Excel is widely used in organizations for representing their Tabular data, as it comes with a galaxy of features for data representation. It is, therefore, ideal to output any tabular data in Microsoft Excel format, for easier and better data analysis.
From Release 4.7, the tabular Profiler or Debugger Expression data will dump the information in
Excel Format, to enable the developer to analyze the data with ease. The behaviour will be:
● If the System has MS Office 2007 or below, then the output format will be ‘.xls’.
● If the System has MS Office 2010 or above, then the output format will be ‘.xlsx’.
● If the System does not have MS Office installed, then the behaviour will be the same as in Release 4.6, i.e., the format will be text files.
Thus, the developer can make use of Excel features like sorting, filtering, graphical representation, etc., thereby attaining performance optimization quickly. For example, by sorting the Profiled Information in descending order of Time or Count, the developer can quickly determine the artefact that has taken the longest time or the Collection that has been needlessly gathered multiple times, thus optimizing the performance quickly.
With respect to Key Recording and Playback, following enhancements have been done:
In Release 4.6, when a Macro gets recorded beyond 2000 characters, it is not possible to read back the characters beyond 2000 using the Function $$FileRead, and play them.
From Release 4.7 onwards, the reading capacity of the Function $$FileRead has been increased to 4000 characters per line.
Again, if the Macro gets recorded beyond 4000 characters, the Function $$FileRead cannot read further, which means that Keys beyond 4000 characters cannot be played back.
Hence, the Macro Recording capability has been enhanced in such a way that after recording 4000 characters, a new macro gets created automatically, and the subsequent keys are recorded in the new macro. The new macro will bear the same macro name, with a number concatenated to it. All the Macros created will be dumped in a single file, and replayed when required. Thus, n number of macros can be recorded in a file, read and played back.
For example, if the Name of the Macro is Testing, then after every 4000 characters, a new Macro is created with the Name Testing-1, Testing-2,...Testing-n. Thus, there is no limit to the number of characters which can be recorded, read and played back.
In Release 4.6, using the Action Dump Recording, all the Keys, along with the Macro Name, were written to a file Macros.Log, by default.
From Release 4.7 onwards, the Action ‘Dump Recording’ has been enhanced to write the macros to a File specified by the user. The Action ‘Dump Recording’ will accept 2 optional parameters, viz. File Name and Separator.
● If the File Name is left unspecified, then by default, the Action would dump the recording to the file Macros.log.
● If the Separator is left unspecified, then by default, the system would consider Tilde (~) as the default separator.
Syntax
Dump Recording [: <File Name> [: <Separator between keys>]]
Where,
< File Name > is the name of the file where macro and keys will be recorded.
< Separator between keys > is the separator used to differentiate the macro name from the keys.
Example
[Button : Dump Recording]
Title : "Dump"
Key : Alt + U
Action : Dump Recording : “BSView.txt” : “-”
On clicking the Button ‘Dump Recording’, a file BSView.txt is created in Tally Application Folder.
Note: The behaviour of Calculator Pane Command Dump is retained as in Release 4.6, i.e., it will create a file with the name Macros.Log in the Tally Application Folder.
When the macro keys are recorded using Key Recording Actions or when they are dumped into the Macros File from the Calculator Pane; in order to play them back, one needs to make use of the Action Trigger Key, which sends a list of keys in sequence to the system as if an operator is pressing those Keys.
Very often, some keys like Enter, Up, Down, etc., are repeated in sequence more than once. For example, to scroll down to the 7th Voucher in Daybook, one needs to trigger the Down Key 6 times. Similarly, in an Invoice Entry, moving to the first Item field needs multiple hits of Enter key. Hence, the action ‘Trigger Key’ has now been enhanced to support the <Key>:<Number> combination in the syntax, which will trigger the particular Key for the specified Number of times.
Example: 1
Trigger Key : DD, Enter : 5, “Item 1”, Enter
This is the same as:
Trigger Key : DD, Enter, Enter, Enter, Enter, Enter, “Item 1”, Enter
Following happens when the above Action is invoked from Gateway of Tally:
● The First D navigates us to Display.
● The Subsequent D navigates us to Daybook.
● Enter:5 triggers the Enter Key 5 times, i.e., Drills down into the current voucher, accepts 4 subsequent non-skipped fields, and moves to the 5th non-skipped Field in the Voucher.
● In the Fifth field, the text Item 1 is entered.
● The Subsequent Enter then accepts the current field, and the focus is shifted to the next non-skipped field.
Example: 2
Trigger Key : DS, Enter:3
This action will take us through Display (D) -> Statement of Accounts (S) -> Outstandings (1st Enter) -> Receivables (2nd Enter) ; the 3rd Enter selecting the first item in the list and displaying all the outstanding bills within it.
For the convenience of the developer, certain calculator pane commands have been introduced in this Release.
Mode: ? will list all the modes available in the Calculator Panel.
.jpg)
● Command - Help
From any of the modes, Help command will list down all the supported commands for the particular mode, along with their purpose.
.jpg)
● Command - Open
From any of the modes, the Open command will open the most recently logged file. Consider the following examples:
● If the current mode is Debug, the file being opened will be either debug.xlsx, debug(1). xlsx, debug(2).xlsx, ……. or debug(<n>).xlsx, whichever is the most recent in debugger log. (Depending on the available Excel Version, the file extensions will vary.)
● If the current mode is Profile, the file being opened will be either tdlprof.xlsx, tdlprof(1). xlsx, tdlprof(2).xlsx, ……. or tdlprof(<n>).xlsx, whichever is the most recent in profiler log. (Depending on the available Excel Version, the file extensions will vary.)
● If the current mode is Record, the file being opened will be macros.log.
.jpg)
As we are already aware, Tally has a natural language processing capability which accepts queries either from the Calculator Pane or from SMS Request. Tally has the intelligence of parsing received/ given commands, in order to process the same. This parsed information is used by the system to process the query and deliver the result. However, in certain cases, queries received might not be understood by the system. There have also been requirements in the market to support data updation queries like Ledger, Voucher Creation, etc.
In order to cater to the above requirements, a new System Event NatLangQuery has been introduced. This event gives complete control in the hands of the TDL Developer, thereby enabling him to process the query received and do the needful. If the query is ignored by TDL, then the System continues to process it and provide the response as usual.
Syntax
[System : Event]
<Event Name> : NatLangQuery : <Condition> : <Action> : <Action Parameters>
Where,
<Event N a me> can be a ny u nique name, indicating the p u rpose of the eve n t.
<Conditi o n> if evaluated to TRUE on receiving a query , a n action will b e e xecu ted.
<Action> is the Action Call which can be u sed for processing the Query rec e ived/given.
<Action P a ra m eters> can be a Function Name and its required Parameters.
Example
[System: Event]
Ledger Creation: NatLangQuery: @@IsLedgerinQuery: Call: Create Ledger
Whenever a Query is received, Tally checks the logical condition @@IsLedgerinQuery. If it evaluates to TRUE, then the function ‘Create Ledger’ is invoked.
Note: In the given syntax, < Action > can be any global Action like Display, Alter, Print, etc. However, NatLangQuery being a query from a remote location, it is not advisable to populate any report in the User Interface of Tally at the Server end.
In order to support the event “ NatLangQuery ”, the following System Variables, along with a Built-in TDL Function $$ NatLangInfo , have been introduced.
This is a String Variable bearing the complete request / query string when a Query is received.
This is a String Variable bearing the part of the query that is not understood by the system.
This is a String Variable which carries the response back to the requestor. After processing the Query, this variable needs to be set with an appropriate response that is sent back to the requestor by Tally.
This is a Logical Variable which denotes the status of the Query Processed. After processing the Query, this variable needs to be set to YES to indicate if the Query was processed by TDL successfully.
● Update YES to indicate that the Query is processed by TDL and the response is prepared.
● Update NO to indicate that the Query is not processed/understood by TDL.
If updated as YES , then only the system will send the response specified in TDL. If updated as NO , the System processes the Query and sends the appropriate response.
A Built-In TDL F unction $$NatLan g Info h as been introduced to provide cer t ain information like Com p any Name, User Name, Fr o m Date, To Date , etc., from the Query receiv e d.
Syntax
$$NatLangInfo : <InfoType>
The valid values for < InfoType > are as follows:
● Company
● UserName
● FromDate
● ToDate
● ObjectName
Example
$$NatLangInfo :Company returns the current Company Name.
$$NatLangInfo :UserName returns the Name of the User from whom the Query is received.
● If the request is from Calculator Pane, Tally responds with the current logged in user name.
● If the request is initiated through an SMS Query, Tally responds with the name of the Tally.NET User from whose device, the request is received.
$$NatLangInfo:FromDate returns the From Date of the period, based on the received query or from the recent context.
$$NatLangInfo:ToDate returns the To Date of the period, based on the received query or from the recent context.
$$NatLangInfo:ObjectName returns the Name of the Object, based on the received query or in the recent context. For example, if Query received is – “Sales for April 2013”, then NatLangInfo will return the following:
Object Name- Sales
From Date - 1-April-2013
To Date - 30-April-2013
Create Ledger RadheShyam SundryDebtors
The requirement here is to create a Ledger with the name ‘RadheShyam’, under the Group ‘Sundry Debtors’.
1. Firstly, we need to write a system event to trap the query received and perform the necessary action.
[System : Event]
Create Ledger : NatLangQuery : @@IsCreateLedger : Call : Create Ledger
2. If the Request contains ‘Create Ledger’, then only the above action is to be performed, so the following system formula needs to be declared to check the value of the variable SVNatLangFullRequest.
[System : Formula]
IsCreateLedger : ##SVNatLangFullRequest CONTAINS “Create Ledger”
3. When the action is being executed, firstly we need to tokenize the words from the string:
[Function : TokenizeQuery]
000 : List Delete Ex : SMSStrings
010 : For Token : TokenVar : ##SVQueryRequest : " "
020 : List Add Ex : SMSStrings : ##TokenVar
030 : End For
[System : Variable]
List Var : SMSStrings : String
4. Finally, create the ledger with the Action ‘New Object’
[Function : CreateLedger]
000 : Call : TokenizeQuery
010 : New Object : Ledger : ##SMSStrings[3] : Yes
020 : Set Value : Name : ##SMSStrings[3]
030 : Set Value : Parent : ##SMSStrings[4]
040 : Save Target
5. Send the Response to the source of the query
050 : Set : SVNatLangResponse : “Ledger Created”
060 : Set : SVNatLangRequestProcessed : Yes
Similarly, the
NatLangQuery
Event can also be used to customize the interpretation of the queries being sent, and act accordingly.
Note
♦ We have used Space as a delimiter for Tokenizing Query Strings in the given example. One can specify any delimiter like Inverted quotes, comma, etc., to separate different strings.
♦ If customized with the help of Tokens, the Query Signature must be retained exactly in the same order and with the delimiters specified. In the given example, if the Query ‘Create Ledger Keshav under SundryDebtors’ is specified, the code will fail, as the function expects the 4th Word to be a Group Name. Hence, the Programmers must communicate the Query Signature clearly with the end users.
ZIP is an archive file format that supports compression of data without any loss. A Zipped file may contain one or more files or folders in compressed form. The ZIP file format permits a number of compression algorithms. Originally created in 1989 by Phil Katz, the ZIP format is now supported by a number of software utilities.
The need for supporting this format in Tally.ERP 9 has been felt in various offline Integration projects. Data Exchange takes place between branches and their Head Offices, Distributors and the Principal Companies, etc., where the Head Offices/ Principal Companies having Tally or any other ERP would require the data from Branches/ Distributors for performance visibility. Usually, Principal Companies require the Item-wise Sales Information of the distributors, which helps them in planning their Stocks.
For integration purpose, Head Offices/ Principal Companies generally get Tally.ERP 9 installed at Branches/ Distributors’ locations. The day-to-day Transactions like Sales, Purchase Orders, etc., are then exported from Tally.ERP 9 and integrated by copying the appropriate XML files to FTP, which is consumed by the Head Offices/ Principal Companies.
At locations where the volume of transactions is large, the XML File becomes too bulky to upload to FTP, and subsequently, downloading from FTP takes a long time, thereby causing performance issues. Hence, zipping the file before uploading to FTP was necessary. This would save time both while uploading the File and while downloading it at the other end. Hence, the concept of Compression, i.e., Zip-Unzip has been introduced in Tally.ERP 9.
Along with the actions for Zip/Unzip capability, wildcards * and ? are also supported, as a part of folder/file specification. Asterisk(*) represents zero or more characters in a string of characters. For example, t*.doc considers all files starting with ‘t’, bearing the extension .doc, e.g., Tally.doc, Tallyzip.doc, etc. Question Mark (?) represents any one character. For example, TDLDebug?.* considers all the files starting with ‘TDLDebug’, followed by any variable single character, and bearing any extension, e.g., TDLDebug1.xlsx, TDLDebug2.xlsx, TDLDebug1.log, etc.
Zip action can be used to archive a set of folders/ files.
● System Action - ZIP
System action Zip is useful when a single File or Folder Source needs to be zipped into a Target file.
Syntax
Zip : <Target File> : <Source Path> [:<Password> [:<Overwrite> [:<Include Sub-directory> [:<Show Progress Bar>]]]]
Where,
< Target File > is the name of the Zip File to be created, along with the Path.
< Source Path > is the path of the Folder/File(s), which is to be zipped. It can be a folder, or a file path (with or without wildcard characters).
< Password > is the password assigned to the Target zipped file.
< Overwrite > is the Logical Flag to specify the behaviour of the Action, if the Target File already exists. If YES is specified, the file will be overwritten. If ‘NO’ is specified, the file will not be overwritten, and will remain as it is. The default value is ‘NO’.
< Include Sub-directory > is the Logical Flag to specify whether to include sub directories available in the specified source path or not. If the Source Path ends with a Folder, the entire Folder along with its Sub-Folders will be zipped, irrespective of this parameter. If the Source Path ends with a File Name Pattern, i.e., with wild cards, this parameter will be considered. If a ‘YES’ is specified, all the files/sub-folders matching the wild card pattern will be included for Zipping. If ‘NO’ is specified, they will not be included. The default value is ‘NO’.
<Show Progress bar> is the Logical Flag to specify if the Progress Bar needs to be shown during the Zipping Process. If ‘YES’ is specified, the Progress Bar will be shown, and if ‘NO’ is specified, it will not be shown. If no value is specified, the default value will be assumed as ‘NO’.
Note: Wild Cards * and ? are supported only for the last information in the path. For example, C:\Wor?\Cust*.txt is invalid whereas C:\Work\Cust*.txt is valid.
Example: 1
ZIP : “.\Target.zip” : “tally.ini”: “Tally” : No
With the above Action, the following will be achieved:
1. The file tally.ini from the current Tally Application/Working Folder will be zipped to the File Target.zip in the Tally Application Folder itself.
2. The resultant Zip File will contain the password Tally.
3. If the file Target.zip exists in the current application folder, it will not be overridden.
Example: 2
To Zip a ll t ext files in w ork folder .
ZIP: “D:\Target.zip”: “D:\Work\*.txt”: “Tally”: No: Yes: Yes
With the above Action, the following will be achieved:
● All the text files from the folder D:\Work will be zipped to the File Target.zip in D:\.
● The resultant Zip File will contain the password Tally.
● If the file Target.zip exists in D:\, it will not be overridden as the 4th Parameter is set to No.
● All the text files within the Sub-directories will be included under the Folder D:\Work, as the 5th Parameter is set to Yes.
● The Progress Bar will be shown during Zipping of the Files, as the 6th Parameter is set to Yes.
Procedural Actions Start Zip, Zip Add Path, Zip Exclude Path and End Zip are very useful in cases where Multiple Folders/Files need to be zipped into / excluded from a Target File.
Syntax
Start Zip : <Target File> [: <Overwrite>]
Zip Add Path : <Source Path> [: < Include sub-directory>]
:
:
Zip Exclude Path : <Exclude Path>
:
:
End Zip [: <Password> [: <Show Progress Bar>]]
Where,
< Target File > indicates the name of the resultant Zip File , and also includes the Folder Path .
< Overwrite > is the Logical Flag to specify the behaviour of the Action, if the Target File already exists. If YES is specified, the file will be overwritten. If ‘NO’ is specified, the file will not be overwritten, and will remain as it is. The default value is ‘NO’ .
< Source Path > is the path of the Files or Folders, which are to be zipped. It can be a folder or a file path (with or without wildcard characters).
< Include Sub-directory > is the Logical Flag to specify whether to include sub directories available in the specified source path or not. If the Source Path ends with a Folder, the entire Folder along with its Sub-Folders will be zipped, irrespective of this parameter. If the Source Path ends with a File Name Pattern, i.e., with wild cards, this parameter will be considered. If a ‘YES’ is specified, all the files/sub-folders matching the wild card pattern will be included for Zipping. If ‘NO’ is specified, they will not be included. The default value is ‘NO’.
< Exclude Path > is the path of the Files/ Folders which need to be excluded from the Target Zip .
< Password > is the password assigned to the Target zipped file.
< Show Progress Bar > is the Logical Flag used to specify if the Progress Bar needs to be shown during the Zipping Process. If ‘YES’ is specified, then the Progress Bar will be shown, and if ‘NO’ is specified, it will not be shown. If no value is specified, the default value will be assumed as ‘NO’.
Example: 3
Start ZIP : “Target.zip” : Yes
/* Overwrite the File Target.zip, if it exists */
Zip Add Path : “tally.ini”
End Zip
The outcome of this example will be similar to the outcome of Example: 1. The only difference is that it is set to overwrite the target file Target.Zip , if it exists in the current application folder (as the <Overwrite> Parameter of the Action ‘Start Zip’ is set to Yes).
Example: 4
Start Zip : “Target.zip” : Yes
Zip Add Path : “.\Tally.ini”
Zip Add Path : “D:\Documents\*.doc” : Yes
/* Include Sub-Folders also */
Zip Add Path : “C:\Work”
/* The Folder Work and the Files within this folder will be included in the Zip File */
End Zip
In this example, there are 3 Source Paths, which are required to be zipped:
● First Path indicates that the file Tally.ini from the current application folder is to be zipped.
● The Second Path indicates that the PDF files from within the D:\Documents Folder, including the Sub-Folders, need to be zipped.
● The Third Path indicates that the entire folder C:\Work needs to be zipped.
The above source files would be zipped to the target file Target.zip, which is specified in the Action Start Zip.
Example: 5
Start Zip : “Target.zip” : Yes
/* Overwrite the existing file in the target location */
Zip Add Path : “.\Tally.ini”
Zip Add Path : “D:\Documents\*.doc” : Yes
/* Include Sub-Folders also */
Zip Add Path : “C:\Work”
Zip Exclude Path : “*.txt”
End Zip
In this example, apart from using Action Zip Add Path to specify the first 3 source paths, the subsequent Action Zip Exclude Path is used to specify the exclusion of Folders or Files with the extension .txt. Thus, all the text files from the above specified source paths will be excluded.
The Unzip action can be used to extract the original files from the zipped files.
System Action Unzip is useful when all the folders/ files in the Source Zip File need to be completely unzipped, as they are. (This Action cannot be used in case of partial Unzip.)
Syntax
Unzip : <Target Folder>: <Source File> [: <Password> [: <Overwrite> [:<Show Progress Bar>]]]
Where,
<Target Folder> is the path of the Target folder where the Unzipped Files need to reside.
<Source File> is the name of the Zip File to be unzipped.
<Password> is the Zip File Password. A Zip File bearing a Password cannot be extracted without the Password.
<Overwrite> is the Logical Flag to specify the behaviour if the Files being unzipped already exist in the Target Folder. The default value is ‘NO’.
<Show Progress Bar> is the Logical Flag to specify if Progress Bar needs to be shown during the Extracting (Unzipping) Process. If YES is specified, the Progress Bar will be shown and if NO is specified, the Progress Bar will not be shown. The default value is ‘NO’ .
Example: 1
Unzip : “.” : “D:\Target.zip” : “Tally”
In this example, the file D:\Target.zip will be unzipped entirely in the current Tally Application Folder. Since the Zip File bears a password Tally, same is being passed as the 3rd Parameter.
Example: 2
Unzip : “Documents” : “D:\Target.zip” : “Tally”
In this example, all the folders/ files within the Zip File D:\Target.zip will be extracted to the folder Documents in the current Tally Application folder.
The Procedural Actions Start Unzip , Extract Path , Unzip Exclude Path and End Unzip are very useful in case of partial Unzip . Using the Action ‘Extract Path’, one can specify the Folder/ File Path to be marked for extracting. The action ‘Unzip Exclude Path’ can help to exclude the specified Folders/ Files from the Zip File and extract the rest. These actions can be used in both the cases, i.e., for partial unzip as well as for total unzip.
Syntax
Start Unzip : <Source File> [: <Password >]
Extract Path : <Folder/ File Path>
:
:
Unzip Exclude Path : <Folder/ File Path>
:
:
End Unzip : <Target folder> [:< Overwrite> [:<Show Progress Bar>]]
Where,
<Source File> is the path of the Zip File which needs to be zipped.
<Password> is the password to access the Target zipped file.
<Extract Path> is the File/ Folder which need to be extracted from the Zip File.
<Unzip Exclude Path> is the path of Files/ Folders, which need to be excluded from the unzipping operation.
<Target Folder> is the path of the Target folder, where the Unzipped Files need to reside.
<Overwrite> is the Logical Flag to specify the behaviour if the Files being unzipped already exist in the Target Folder. The default value is ‘NO’.
<Show Progress Bar> is the Logical Flag to specify if Progress Bar needs to be shown during the Extracting (Unzipping) Process. If YES is specified, the Progress Bar will be shown and if NO is specified, the Progress Bar will not be shown. The default value is ‘NO’.
Example: 3
Start Unzip: “D:\Target.zip”
End Unzip : “D:\Unzipped” : Yes
/* Overwrite the existing files, if any, in the Target Folder */
These actions will unzip all the folders/ files within D:\Target.zip to the folder D:\Unzipped and if any file already exists, the same will be overwritten (as the second parameter of the Action End Unzip is set to Yes.)
Example: 4
To extract only .txt and .doc files from the zip file.
Start Unzip : “D:\Target.zip”
Extract Path : “*.txt”
Extract Path : “*.doc”
End Unzip : “.”
In this example, only the *.txt and *.doc files from D:\Target.zip will be unzipped to the current Tally Application Folder.
Example: 5
Start Unzip : “D:\Target.zip”
Extract Path : “Samples\Supporting Files\”
Unzip Exclude Path : “*.xls”
End Unzip : “.”
In this example, from D:\Target.zip , all the Files and SubFolders within the folder ‘Supporting Files’ under ‘Samples’ will be unzipped to the current Tally Application Folder, as the target folder is specified as a dot (.). Also, all the files with extension .xls will not be zipped.
Note: A file which has been zipped from Tally.ERP 9 can be extracted by using any standard third party archiving tools like Winzip, Winrar, etc., and vice-versa.
Limitations of Zip/Unzip in Tally.ERP 9:
In the following cases, Zip/Unzip action will fail:
● If the number of files being Zipped is greater than 65535
● If the Size of the Zip File is greater than or equal to 4 GB
● If the Size of any File within the Zip File is greater than or equal to 4 GB
Multiple-Column feature in Tally.ERP 9 has till date been used by the Tally users for various reporting needs like Comparative Analysis of Data across Multiple Periods (Months, Quarters, Years, etc.), Multiple Companies, Multiple Godowns, etc. It can also be used for comparative study of various parameters like Budget vs. Actual Performance, by getting the same displayed in the form of a column-based report.
It was felt highly desirable if, apart from these reporting functionalities, various data entry operations could also be performed in a Columnar or Tabular manner. This would not only facilitate data entry in a simple, user friendly manner, but also considerably reduce the time taken to enter the data. For instance, Attendance of Employees could be accepted against the Attendance Types or days, in a Tabular format. Similarly, other examples could be Employee-wise Pay Head-wise Salary Structure, Stock Item-wise Price Level-wise Price List, etc., where this capability could be used effectively. In order to make this possible in Tally, the Columnar capability was required to be extended to support Edit mode.
From Release 4.7 onwards, support for Multi Columns has been extended to Edit Mode too, to enable the developer to design and implement such functionalities in Tally, as per requirement.
To make this possible in TDL, the Horizontal Scrolling behaviour has been enhanced to work in Edit Mode, which will enable the developer to create a user friendly interface, thereby allowing the user to enter data conveniently in tabular format. To achieve the columnar scrolling behaviour; in TDL, fields within the required line can be repeated over either of the following:
● Collec t ion o f O b ject s , OR
● Sub-Collectio n s un d er a Primary Objec t , provided the Sub-Collectio n s con t ain Obj e ct(s)
In the absence of the above ‘Repeat’ specification, the only criterion to repeat the Fields/ Columns is that the number of Fields to be repeated must be known to the Line.
Note: With respect to Object context, Horizontal Scroll will only happen if Objects/Sub Objects, on which Columns are to be repeated, exist. In other words, in Create Mode with Object Context, Horizontal Scroll will not work as the number of fields to be repeated is not known.
A Data Type in a programming language is a classification, identifying one of the various types of data supported by that language, each having certain pre-defined characteristics. It determines the possible values for that type; the operations that can be done on values of that type; and the way values of that type can be stored. They are an integral part of every programming language and hence, almost all programming languages support a set of primitive data types.
TDL, being a domain-specific language, supports various domain-specific data types like Quantity, Rate, Amount, Rate of Exchange, etc., apart from the basic data types like String, Number, Date and Logical.
In Release 4.7, a few Date and Time related data types have been introduced to support various business requirements. All the data types pertaining to date and time are now collectively referred to as Calendar data types, which are as follows:
● DATE
● TIME
● DATETIME
● DURATION
● DUE DATE
However, two data types, viz., Date and Due Date were already supported in TDL. The data types Time , DateTime , and Duration are the ones which have been introduced in Release 4.7.
With the introduction of these data types, now various business functionalities like capturing Date and Time of entering a voucher, calculating the weekly average clock-in time of employees, etc., will be possible in Taly.ERP 9.
Calendar Data Types
As already discussed, Calendar Data Types comprise of the data types Date, Time, DateTime, Duration and Due Date, of which, ‘Time’, ‘DateTime’ and ‘Duration’ have been introduced in Release 4.7.
Apart from the new data types, a few supporting Functions, Formats, Input Keywords and Qualifiers have also been introduced for each. Formats can be specified to indicate the format in which the value has to be displayed. The concept of Input Keywords and Qualifiers has been introduced to assist the Tally user in data entry operations, as well as to minimize the effort of the programmer in setting the values of any particular calendar data type within a Field. For example, in a Field of data type ‘Date’, specifying the Input keyword ‘Week’ as the value, will lead to setting of the current week’s beginning date as the value. Also, Qualifiers like ‘This’, ‘Next’, etc., if specified along with the Input Keywords, will lead to storing and displaying of values determined by the ‘Input Keyword-Qualifier’ combination. For example, specifying ‘Next Week’ will return the beginning date of the following week as the value. All of these have been discussed in detail in the following sections.
Specifying the data type as Date indicates that the data container can only hold Date values. The data container can be a UDF , a Variable or a Field. The date values can range from January 1, 1901 to December 31, 2098. The default separator character within a Date is ‘Hyphen’, e.g., 22-12-2011.
Example
[System : UDF]
DateOfPurchase : Date : 1107
/* A new System UDF DateofPurchase of Type Date is declared. */
[Field : Date of Purchase]
Type : Date
Storage : DateOfPurchase
/* A Field DateofPurchase of Type Date is defined for updating values in the UDF DateOfPurchase */
Apart from specifying the Type as Date , one of the various available Formats can also be specified, using the attribute ‘Format’. The various Formatting Keywords for the data type ‘Date’ are listed in the following table. If no Format is specified, the default format ‘Universal Date’ is assumed.
|
Format |
Field Value Specified |
Value Returned |
|
Short Date |
22-Dec-2011 |
22-12-2011 |
|
Long Date |
22-Dec-2011 |
Thursday, 22 Dec, 2011 |
|
Universal Date (default format) |
22-Dec-2011 |
22-Dec-2011 |
|
Month Beginning |
1-Dec-2011 22-Dec-2011 |
Dec-2011 22-Dec-2011 |
|
Month Ending |
31-Dec-2011 22-Dec-2011 |
Dec-2011 22-Dec-2011 |
Example
[Field : Date of Purchase]
Type : Date
Storage : DateOfPurchase
Format : “Short Date”
/* The Format specified within the Field DateofPurchase is Short Date, and hence, the date is returned in dd-mm-yyyy format. */
There are certain Input keywords, which can be specified instead of the date itself. This increases the ease of data entry. The Input Keywords available for the data type Date are as follows:
|
Input Keyword |
Alias |
Value Returned |
|
Today |
Today, Day, Now |
Current system date |
|
Tomorrow |
Tomorow, Tommorrow |
Next day’s date |
|
Yesterday |
YDay |
Previous day’s date |
|
Week |
Current week’s beginning date |
|
|
Month |
Mth |
Current month’s beginning date |
|
Year |
Yr |
First date, i.e., 1-Jan, of the current year |
Example:
[Field : Date of Purchase]
Type : Date
Storage : DateOfPurchase
Format : “Short Date”
Set As : Today
/* The input keyword Today sets today’s date as the value within the Field Date of Purchase. */
There are also some date qualifiers, which can be used in combination with input keywords, to return the required date value. Qualifiers cannot be used independently, but they can be provided as additional specification for the input keyword. The various date qualifiers are as follows:
|
Date Qualifier |
Usage (along with Input Keywords) |
|
Financial |
Financial Year, This Financial Year, Prev Financial Year, Next Financial Year, Last Financial Year |
|
This |
This Week, This Month, This Year, This Financial Year |
|
Prev/Last |
Prev Week, Prev Month, Prev Year, Prev Financial Year, Last Week, Last Month, Last Year, Last Financial Year |
|
Next |
Next Week, Next Month, Next Year, Next Financial Year |
[Field : Date of Purchase]
Type : Date
Storage : DateOfPurchase
Format : “Short Date”
Set As : Last Financial Year
/* In Last Financial Year, ‘Last’ and ‘Financial’ are qualifiers, while ‘Year’ is an Input Keyword. It sets the field value as the 1st day of the last/previous financial year. */
Note: Week is assumed to begin on Sunday. For example, on 20th August, 2013, the value of the Field set as ‘Prev Week’ is returned as 11th August, 2013, which is the Sunday of the week prior to the current week.
Various Type casting and Manipulation Functions have also been provided, corresponding to the Data Type Date. They are as follows:
Function - $$Date
The function $$Date is used to convert a valid date value from any other data type to the data type Date. This is mainly required when manipulations on the date need to be performed.
Syntax
$$Date : <Expression>
Where,
< Expression > can be any expression, which evaluates to a valid date value.
Function - $$MonthOfDate
The function $$MonthofDate returns the month corresponding to the date specified as the parameter.
Syntax
$$MonthOfDate : <Date Expression>
Where,
<Date Expression> can be any expression, which evaluates to a valid date value.
The result returned will be of Type ‘Number’. For example, if the specified date is 05-04-2013, then the function returns the value 4, as the date belongs to the 4th month of the year.
Function - $$DayOfWeek
The function $$DayOfWeek returns the weekday corresponding to the date specified as the parameter.
Syntax
$$DayOfWeek : <Date Expression>
Where,
<Date Expression> can be any expression, which evaluates to a valid date value. For example, if the specified date is 05-04-2013, then the result would be Friday.
Function - $$DayOfDate
This function returns a number to represent the day, corresponding to the date specified as the parameter. For example, Sunday will be represented by the number 1, Monday by 2, and so on.
Syntax
$$DayOfDate : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value.
For example, if the specified date is 05-04-2013, then the result would be 5, as the corresponding day is Friday, which is the 5th day of the week.
Function - $$YearOfDate
The function $$ Yearof Date returns a number representing the year of the date specified as the parameter.
Syntax
$$YearOfDate : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value. The result returned by the function will be of Type ‘Number’. For example, if the specified date is 05-04-2013 , then the result would be 2013 .
Function - $$ShortMonthName
The function $$ShortMonthName returns the short form of the name of the month, corresponding to the date specified as the parameter, for example., Jan, Feb, etc.
Syntax
$$ShortMonthName : <Date Express i on>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value.
For example, if the date value is 05-04-2013, then the value returned by the function will be Apr.
Function - $$FullMonthName
The function $$ FullMonthName returns the full name of the month, corresponding to the date specified as the parameter, e.g., January, February, etc.
Syntax
$$FullMonthNam : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value. For example, if the specified date is 05-04-2013, then the result would be April.
Function - $$WeekEnd
This function returns the date of the first Sunday following the date specified as the parameter. However, if the argument date, i.e., the date specified, itself corresponds to the day Sunday, then the date corresponding to the following Sunday will be returned.
Syntax
$$WeekEnd : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value.
For example, if the specified date is 05-04-2013 , then the result would be 07-Apr-2013 , being the following Sunday. If the date specified is itself 07-04-2013 , then the date returned will be 14-Apr- 2013 , i.e., the date of the following Sunday.
Function - $$MonthEnd
It returns the date of the last day of the month, corresponding to the date specified as parameter.
Syntax
$$MonthEnd : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value. For example, if the specified date is 05-04-2013, then the result would be 30-Apr-2013.
Function - $$YearEnd
This function returns the last date of the year, considered to be starting from the date specified as the parameter.
Syntax
$$YearEnd : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value.
For example, if the specified date is 05-04-2013 , then the result would be 4-Apr-2014 , which is one year from the date specified, i.e., the last day of the year, if the specified date is considered as the current date.
Function - $$MonthStart
The function $$ MonthStart returns the date of the first day of the month, corresponding to the date specified as the parameter.
Syntax
$$MonthStart : <Date Expression>
Where,
<Date Ex p re s sion> can be any expression, which evaluates to a valid d a te v a lue. For e xample, if the sp e cified d a te is 05-0 4 -2013 , then the result wo u ld be 1-Apr-2013 .
Function - $$FinYearBeg
This function is used to fetch the starting date of the company’s financial year, corresponding to a particular specified date. Two parameters are required for this function. The 1st parameter is the Date value for which the corresponding Financial Year’s Beginning date is to be identified. The 2nd parameter is the "Financial Year From" date of the company, i.e., the time from which the financial year of the company normally starts. Specification of this parameter is essential as the Financial year is determined by the law of the country, and can be Apr-Mar, Jan-Dec, etc.
Syntax
$$FinYearBeg : <First Date Expression> : <Second Date Expression>
Where,
< First Date Expression > evaluates to the Date, for which the corresponding Financial Year’s Beginning date is to be identified.
< Second Date Expression > is used to specify the normal financial year beginning date (irrespective of the year).
For example, if the first parameter is 05-04-2013 and the second parameter date is 1-4-2010, then the result would be 1-Apr-2013.
Function - $$FinYearEnd
This function is used to fetch the end/last date of the company’s financial year, corresponding to a particular specified date. Two parameters are required for this function. The 1st parameter is the Date value for which the corresponding Financial Year’s Ending date is to be identified. The 2nd parameter is the “Financial Year From” date of the company, i.e., the time from which the financial year of the company normally starts. Specification of this parameter is essential as the Financial year is determined by the law of the country, and can be Apr-Mar, Jan-Dec, etc.
Syntax
$$FinYearEnd : <First Date Expression> : <Second Date Expression>
Where,
< First Date Expression > evaluates to the Date, for which the corresponding Financial Year’s Ending date is to be identified.
< Second Date Expression > is used to specify the normal financial year beginning date (irrespective of the year).
For example, if the first parameter is 05-04-2013 and the second parameter date is 1-4-2010, then the result would be 31-Mar-2014.
Function - $$PrevYear
The function $$PrevYear returns the previous year’s date, respective to the date specified as the parameter, i.e., the date exactly a year ago.
Syntax
$$PrevYear : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value.
For example, if the specified date is 05-04-2013, then the result would be 5-Apr-2012.
Function - $$NextYear
The function $$ NextYear returns the next year’s date, corresponding to the date specified as the parameter, i.e., the date exactly a year from now.
Syntax
$$NextYear : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value.
For example, if the specified date is 05-04-2013, then the result would be 5-Apr-2014.
Function - $$PrevMonth
The function $$ PrevMonth returns the previous month’s date, corresponding to the date specified as the parameter, i.e., the date exactly a month ago.
Syntax
$$PrevMonth : <Date Expression>
Where,
< Date Expression > can be any expression, which evaluates to a valid date value. For example, if the specified date is 05-04-2013, then the result would be 5-Mar-2013.
Function - $$NextMonth
The function $$ NextMonth returns the next month’s date, corresponding to the date specified as the parameter, i.e., the date exactly a month from now.
Syntax
$$NextMonth : <Date Expression>
Where,
<Date Expression> can be any expression, which evaluates to a valid date value. For example, if the specified date is 05-04-2013 , then the result would be 5-May-2013.
A new Data Type TIME has been introduced, which represents an absolute time of the day. Specifying the Data Type as ‘Time’ indicates that the data container can hold only the Time values. The data container can be a UDF, a Variable or a Field. A value of this data type describes the time, with milliseconds precision, i.e., using the sub-parts HOURS , MINUTES , SECONDS , and MILLI- SECONDS . Thus, the format is hh:mm:ss:MMM
By default, Colon is the separator between the sub-parts of the time value, which can also be altered by the user. For example, 16:35:12:348
Example
[System : UDF]
TimeOfPurchase : Time : 1108
/* A new System UDF TimeofPurchase of Type Time is declared. */
[Field : Time of Purchase]
Type : Time
Storage : TimeOfPurchase
/* A Field Time of Purchase of Type Time is defined for updating values in the UDF TimeOfPurchase */
Just as in the case of ‘Date’ data type, various Formatting Keywords have also been introduced for the ‘Time’ data type, to render the Time in various formats. The formats are listed in the following table.
|
Format |
Alias |
Value of Field |
Value Returned |
|
12 hour (Default Format) |
12 hr |
16:35:12:348 |
4:35 PM |
|
24 hour |
24 hr |
16:35:12:348 |
16:35 |
|
With Seconds |
With Sec, With Secs |
16:35:12:348 |
4:35:12 PM (12 hr format) 16:35:12 (24 hr format) |
|
With MilliSeconds |
With MilliSecs, With MilliSec |
16:35:12:348 |
4:35:12:348 PM (12 hr format) 16:35:12:348 (24 hr format) |
|
Prefix AMPM |
AMPM Prefix |
16:35:12:348 |
PM 4:35:12:348 (12 hr format, with millisec) By default, the AM/PM designator is suffixed to the time value. Specifying the format ‘Prefix AMPM’ makes the AM/PM designator get appended as prefix, instead of suffix. |
|
No Zero |
0:00 |
If this format is specified, the time won’t be displayed, if the time value in the field is 0:00 |
|
|
Separator: ‘<Symbol>’ |
16:35:12:348 |
This format specifier is used to change the time separator. For example, Format : “Separator: ‘/’” will return the value as 4/35 PM, instead of 4:35 PM |
The input Keywords available for the data type Time are as shown in the following table:
|
Input Keyword |
Value Returned |
|
Now |
Current system time value |
|
Midnight |
Midnight time value, i.e., 0:00 |
|
Noon |
Noon time value, i.e., 12:00 |
Function - $$Time
The Function $$ Time is used to convert a valid time value from any other data type to the Data Type Time. It is mainly required when manipulations on the time need to be performed.
Syntax
$$Time:<Expression>
Where,
<Expression> can be any expression, which evaluates to a valid Time value.
A new Data Type DateTime has also been introduced. Specifying the Data Type as DateTime indicates that the data container can hold only the values of type ‘DateTime’. The data container can be a UDF, a Variable or a Field. A value of data type ‘DateTime’ represents a date, along with the absolute time of the day. The date and the time are described using the sub-parts DAY, MONTH, YEAR, HOUR, MINUTE, SECOND, and MILLISECONDS. Thus, the format is dd-mm-yy hh:mm:ss:MMM
By default, the separator for the ‘Date’ part is Hyphen (-) and for the ‘Time’ part is Colon (:). However, the same can be altered by the user. The date-time combination values can range from January 1,1901 00:00:00:000 to December 31, 2098 23:59:59:999
Example
[System : UDF]
DateTimeOfPurchase : DateTime : 1109
/* A new System UDF DateTimeofPurchase of Type DateTime is declared. */
[Field : Date and Time of Purchase]
Type : DateTime
Storage : DateTimeOfPurchase
/* A Field DateandTimeofPurchase of Type DateTime is defined for updating values in the UDF DateTimeOfPurchase */
Date Only
This Format is specified to accept both Date and Time values in the Field, but display only Date. In other words, if this Format is specified within a field of type DateTime, then the field can accept both Date and Time values, but will display only Date.
For example, consider a Field of Type DateTime, where the Format is specified as ‘Date Only’. If the Input keyword ‘Today’ is entered in this Field, then instead of displaying the current date and time, the field will display only the current date.
Example:
[Field : Date of Purchase]
Type : DateTime
Storage: DateTimeOfPurchase
Format : “Long Date, Date Only”
/* Both Date and Time values will be accepted as input in the Field DateofPurchase, but only the Date value will be displayed. */
Time Only
This Format is specified to accept both Date and Time values in the Field, but display only Time. In other words, if this Format is specified within a field of type DateTime, then the field can accept both Date and Time values, but will display only Time.
For example, consider a Field of type DateTime, where the Format is specified as ‘Time Only’. If the Input keyword ‘Now’ is entered in this Field, then instead of displaying the current date and time, the field will display only the current time.
Example
[Field : Time of Purchase]
Type : DateTime
Storage : DateTimeOfPurchase
Format : “12 hour, Time Only”
/* Both Date and Time values will be accepted as input in the Field TimeofPurchase, but only the Time value will be displayed. */
Input Keywords
Input Keywords available for the date type DateTime are as shown in the following table:
|
Input Keyword |
A lias |
V alue Returned |
|
T oday |
Da y , Now |
Current system date & time. |
|
T omorrow |
T o morow, T omorrow |
Next d ay’s date & time, i.e., the date and time exactly a day later. |
|
Y esterday |
YDay |
Previous day’s date & time, i.e., the date & time exactly a day before. |
|
Week |
The ‘Date’ part is set as the Current week’s beginning date. |
|
|
Month |
Mth |
The ‘Date’ part is set as the Current month’s beginning date. |
|
Year |
Yr |
The ‘Date’ part is set as the Current year’s beginning date. |
Date Qualifiers
All the qualifiers for the data type Date are applicable for the data type DateTime as well.
Function - $$DateTime
The Function $$DateTime is used to convert a valid Date and/or Time (DateTime) value from any other data type to the data type ‘DateTime’. This is mainly required when manipulations on DateTime values need to be performed.
Syntax
$$DateTime : <DateTime Expression>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
Function - $$AddHours
The function $$ AddHours is used to add a certain specified number of hours to a value of data type DateTime.
Syntax
$$AddHours : <DateTime Expression> : <Value>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
< Value > is the number of hours to be added to the DateTime value.
For example, if the specified DateTime is 05-04-2013 5:20 PM and the <Value> to be added is 4, then the value returned by the function would be 5-Apr-2013 9:20 PM.
Function - $$SubHours
It is used to subtract a certain specified number of hours from a value of data type DateTime.
Syntax
$$SubHours : <DateTime Expression> : <Value>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
< Value > is the number of hours to be subtracted from the DateTime value.
For example, if the specified DateTime is 05-04-2013 5:20 PM and the <Value> to be subtracted is 4, then the result would be 5-Apr-2013 1:20 PM.
Function - $$AddMinutes
The function $$AddMinutes is used to add a certain specified number of minutes to a value of data type DateTime.
Syntax
$$AddMinutes : <DateTime Expression> : <Value>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
< Value > is the number of minutes to be added to the DateTime value.
For example, if the specified DateTime is 05-04-2013 5:20 PM and the value to be added is 20, then the result would be 5-Apr-2013 5:40 PM.
Function - $$SubMinutes
The function $$ SubMinutes is used to subtract a certain specified number of minutes from a value of data type DateTime.
Syntax
$$SubMinutes : <DateTime Express i on> : <Value>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
< Value > is the number of minutes to be subtracted from the DateTime value.
For example, if the specified DateTime is 05-04-2013 5:20 PM and the <Value> to be subtracted is 20, then the result would be 5-Apr-2013 5:00 PM.
Function - $$AddSeconds
The function $$AddSeconds is used to add a certain specified number of seconds to a value of data type DateTime.
Syntax
$$AddSeconds : <DateTime Express i on> : <Value>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
< Value > is the number of seconds to be added.
For example, if the specified DateTime value is 05-04-2013 5:20:15 PM and the < Value > to be added is 15, then the result would be 5-Apr-2013 5:20:30 PM.
Function - $$SubSeconds
The function $$ SubSeconds is used to subtract a certain specified number of seconds from a value of data type DateTime.
Syntax
$$SubSeconds : <DateTime Express i on> : <Value>
Where,
< DateTime Expression > can be any expression, which evaluates to a valid Date and/or Time (DateTime) value.
< Value > is the number of seconds to be subtracted from the DateTime value.
For example, if the specified DateTime value is 05-04-2013 5:20:15 PM and the <Value> to be subtracted is 15, then the result would be 5-Apr-2013 5:20:00 PM.
Two subtypes have also been introduced for the data type ‘DateTime’:
Date
This SubType is specified to accept both Date and Time values in the Field, but display only Date. In other words, if this SubType is specified within a field of type DateTime, then the field can accept both Date and Time values, but will display only Date.
For example, consider a Field of type DateTime, where the sub-type is specified as ‘Date’. If the Input keyword ‘Today’ is entered in this Field, then instead of displaying the current date and time, the field will display only the current date.
Example
[Field : Date and Time of Purchase Date]
Type : DateTime : Date
Storage : DateTimeOfPurchase
Time
This SubType is specified to accept both Date and Time values in the Field, but display only Time. In other words, if this SubType is specified within a field of type DateTime, then the field can accept both Date and Time values, but will display only Time.
For example, consider a Field of type DateTime, where the sub-type is specified as ‘Time’. If the Input keyword ‘Now’ is entered in this Field, then instead of displaying the current date and time, the field will display only the current time.
Example
[Field : Date and Time of Purchase Time]
Type : DateTime : Time
Storage : DateTimeOfPurchase
Here, both Date and Time will be accepted but only the ‘Time’ part of the DateTime value is displayed in the field. Manipulation can be done on date as well as time.
Note: Two fields with subtypes as Date and Time can have the same storage and the changes from one field will be reflected in the other field.
DURATION
Values of this data type will represent the interval between two Date and/or Time values (two DateTime values), measured in years, months, weeks, days, hours, minutes, and seconds.
Example
[System : UDF]
TenureOfService : Duration : 1110
[Field : Tenure Of Service]
Type : Duration
Storage : TenureOfService
/* A Field TenureOfService of Type Duration is defined for updating values in the UDF TenureOfService */
The format options available for the Duration data type are:
|
Format |
Alias |
Va l ue of Field |
V a lue Returned |
|
Days (Default) |
Day , Dys |
25 |
25 Days |
|
Y ears |
Y e ar , Y r , Yrs |
25 |
25 Y ears |
|
Mont h s |
Month |
25 |
25 Months |
|
W eeks |
Week, Weak, Wks |
25 |
25 W e eks |
|
Ho u rs |
Hou r , Hr , Hrs |
25 |
25 Hours |
|
Minutes |
Mins, Minut e , Min |
25 |
25 Minu t es |
|
S e conds |
Secs, Second, Sec |
25 |
25 Sec o nds |
|
YMD (Years, months a n d days) |
416 |
1 Y ea r, 1 Month and 2 0 Days |
|
|
HMS (Hours, minutes and seconds) |
5000 |
1 Hou r, 23 Mi n utes and 2 0 Seconds |
Example
[Field : Tenure Of Service]
Type : Duration
Storage : TenureOfService
Format : “Months, Days”
Points to Remember
1. Any combination of the formats can be provided. However, Week is an independent format and cannot be clubbed with any other format. Let’s see the following illustrations:
● In the above example, if the value entered by the user in the Field is 100, then the lowest (in terms of duration) of the formats specified will be considered as the input format, i.e., 100 will be considered as 100 days and then, the same will be displayed as output in terms of months and days, i.e., 3 months and 10 days.
● If the Format is specified as ‘Weeks, Days’, then the value returned will be in Days, as ‘Weeks’ is an independent entity and cannot be clubbed with any other format.
2. If the value entered is less than the lowest value (in terms of duration) among the formats specified, then the value returned will be zero. For example,
● If 6 days is entered and the format is weeks, then the value returned will be 0 weeks.
● If 8 days is entered and the format is weeks, then 1 week will be displayed.
Function - $$Duration
The Function $$ Duration is used to convert a valid duration value from any other data type to the data type Duration. This is mainly required when manipulations on values of type Date, Time or DateTime need to be performed.
Syntax
$$Duration : <Expression>
Where,
< Expression > can be any expression evaluating to a valid duration value like 10 days, 5 hrs, etc.
Note: A value of Type ‘Date’, when subtracted from another value of Type ‘Date’, will result in a value of Type ‘Number’, and not ‘Duration’. If the resultant value is needed to be of Type ‘Duration’, the function $$Duration has to be used.
Function - $$GetEndDateTime
If the initial/starting DateTime value and the Duration value are provided, then the Function $$ GetEndDateTime will return the final/ending DateTime value.
Syntax
$$GetEndDateTime : <DateTime Expression> : <Value>
Where,
< DateTime Expression > can be any expression, evaluating to a valid Date/DateTime value.
< Value > is used to specify the Duration value.
For example, if the specified Datetime value is 05-04-2013 12:12 AM and the Duration value is set as 10 days, then the result would be 15-Apr-2013 0:12 AM (12:12 AM same as 0:12 AM)
Function - $$GetStartDateTime
If the final/ending DateTime value and the Duration value are provided, the Function $$ GetStartDateTime will return the initial/starting DateTime value.
Syntax
$$GetStartDateTime : <DateTime Expression> : <Value>
Where,
< DateTime Expression > can be any expression, evaluating to a valid Date/DateTime value.
< Value > is used to specify the Duration value.
For example, if the specified DateTime value is 05-04-2013 12:12 AM and the Duration value is 11 hours 30 minutes, then the result would be 4-Apr-2013 12:42 PM .
Function - $$GetDuration
If two DateTime values, representing the Initial/Starting and Final/Ending DateTime values, are provided, then the function $$GetDuration will return the duration between them.
Syntax
$$GetDuration : <First DateTime Expression> : <Second DateTime Expression>
Where,
< First DateTime Expression > can be any expression, which evaluates to a valid Date/DateTime value.
< Second DateTime Expression > can be any expression, which evaluates to a valid Date/ DateTime value.
For example, if the first parameter is 05-04-2013 12:12 AM and the second parameter is 15-Apr-2013 0:12 AM, then the value returned would be 10 Days. (12:12 AM is the same as 0:12 AM).
Function - $$AddDuration
The function $$AddDuration adds a duration value to another duration value. Two duration values are provided as parameters. If a particular parameter contains only a number and no unit is specified, it is assumed to be that many number of days.
Syntax
$$AddDuration : <First Duration Expression> : <Second Duration Expression>
Where,
< First Duration Expression > can be any expression, which evaluates to a valid Duration value or a Number.
< Second Duration Expression > can be any expression, which evaluates to a valid Duration value or a Number.
If the first Duration parameter is set to 10 Days and the second Duration parameter is set to 4 Months, then the result would be 130 Days.
Function - $$SubDuration
This function subtracts the specified duration or from another duration value. Two duration values are provided as parameters. If a particular parameter contains only a number and no unit is specified, it is assumed to be that many number of days.
Syntax
$$SubDuration : <First Duration Expression> : <Second Duration Expression>
Where,
< First Duration Expression > can be any expression, which evaluates to a valid Duration value or a Number. It is the value to be subtracted, and should be less than or equal to the other value.
< Second Duration Expression > can be any expression, which evaluates to a valid Duration value or a Number.
If the first parameter Duration is set to 10 Days and the second Parameter Duration is set to 4 Months, then the result would be 110 Days.
The values of Data Type Due Date are used to represent the Due Date in cases like Purchase Order, Bill Credit Period, etc., in Tally.ERP 9. These values actually comprise of two date values, i.e., the ‘From’ Date and the last date by which honouring of the commitment is due (i.e., the ‘due date’). A flexible range of values can be specified. The value can be a Date (the ‘due date’) or the Duration, in terms of Days, Weeks, Months and Years, from the starting date (‘From’ date). The acceptable duration values used to specify the due date range from 0 to 89 years.
Four input formats can be specified for values of data type Due Date. If no input format is specified, then the default format Days is considered.
|
Format |
Value Returned |
|
Days (Default) |
Due Date in Days |
|
Weeks |
Due Date in Weeks |
|
Months |
Due Date in Months |
|
Years |
Due Date in Years |
Function - $$DateRange
This function is used to convert a valid Due Date value from any other data type to the data type Due Date. It is used to set the values to a method of Type ‘Due Date’ programmatically. For example, while creating a Purchase Order Voucher programmatically using User Defined Functions, to set the value to method OrderDueDate (of type Due Date), we need to use this Function.
Syntax
$$DateRange : <Value> : <Date Expression> : <Logical Expression>
Where,
< Value > must evaluate to a Date OR the duration in terms of Days, Weeks, Months and Years.
< DateExpression > must evaluate to a Date, which is considered as the ‘From’ Date.
< Logical Expression > must evaluate to a logical value. This logical value denotes whether the specified ‘From’ date is also to be included, while calculating the due date.
For example, if the first parameter is set to 2 M, the second Parameter to 05-04-2013, and the third Parameter to YES, then the method, say ‘OrderDueDate’, will be set as 04-06-2013, i.e., 2 Months from the specified ‘From’ date, including the ‘From’ date. However, if the logical expression is NO, then the value stored in the method would be 05-06-2013.
Function - $$DueDateByDate
This function returns the due date value in ‘Date’ format. The parameter passed to this function is a value of type Due Date.
Syntax
$$DueDateByDate : <Due Date Expression>
Where,
< Due Date Method > can be any expression, which evaluates to a value of Type Due Date.
In continuation to the previous example, if the method ‘ OrderDuedate ’, evaluated with the Logical value set as YES, is provided as the parameter, the result would be 04-06-2013, i.e., the Due Date in ‘Date’ format.
Function - $$DueDateInDays
This function provides the due date value in ‘number of days’ format. The parameter passed to this function is a value of type Due Date. The function returns the due date in terms of the total number of days, considered from the ‘From’ date.
Syntax
$$DueDateInDays : <Due Date Expression>
Where,
< Due Date Method > can be any expression, which evaluates to a value of Type Due Date.
Function - $$IsSetByDate
This function checks and indicates if the due date is mentioned in terms of ‘Date’, instead of ‘Number of Days’. It returns a logical value, i.e., ‘Yes’ OR ‘No’. If the due date’s format is ‘Date’, then the function returns ‘Yes’, else it returns ‘No’.
Syntax
$$IsSetByDate : <Date Expression>
Where,
< Date Expression > can be any value of Type Due Date.
Setting a data container (Field, UDF or Method) of type Date OR Time with a value of data type DateTime is possible. For example, if the value of a field of type Date or Time is set by referring to another field of type DateTime, the particular date value OR time value is taken, respectively, and the same is displayed in the Field.
Example
[Field : Date of Pu r chase]
Type : D a te
Storage : D a teOfPurchase
Format : “ L ong Dat e ”
Set as : # D ateandT i meOfPu r chase
Date and TimeOfPurchase is a Field containing a value of type DateTime . When this field is being referred to in the Field Date of Purchase of type Date, the ‘Date’ part of the value is extracted and set as the value of the field.
Date and Time functions can be used on a value of type DateTime . The vice versa is also true, i.e., DateTime functions can also be used on a value of type Date or Time.
Example
$$DayOfWeek:$DateTimeOfPurchase
/* Date function is used on method value of type DateTime */
$$DayOfDate:#DateandTimeOfPurchase
/* Date function is used on field value of type DateTime */
$$Time:#DateandTimeOfPurchase
/* Time function is used on field value of type DateTime */
$$DateTime:#DateOfPurchase
/* DateTime function is used on field value of type Date */
1. Data Type Time currently does not support time zones.
2. Data Type Date is independent of the Data Type Time. This means that if the time is changed from PM to AM, or vice versa, the Date does not change.
3. Time is cyclic in nature, i.e., if 12 hours are subtracted from 1 am, it results in 1 pm.
1. In a field of type DateTime, for entering the time value, date must be entered first.
2. When a value of type Date is converted to type DateTime, then default value of time is taken as 0:00.
3. When a value of type Time is converted to type DateTime, then the default value of Date is assumed as the current date.
In Duration data type, if no unit is specified, then it is by default taken as days. For example, in a Field of type ‘Duration’, if the value entered is 10, then it is considered as 10 days.
Negative Duration is not supported.
We are already aware that the COM DLL Support feature had been introduced for TDL in Release 4.6, to support COM DLL Processing. But, the support was restricted to only a few data types. In the Release 4.61, the support had been extended to many more data types. For Further details on COM Capability, refer to ‘ What’s New in Release 4.6 ’ and ‘ What’s New in Release 4.61 ’ in this document.
From Release 4.7 onwards, the COM support has been extended for two other data types, viz., Time and DateTime.
