|
On this page Retrieve UDF value from Object
|
In Tally.ERP 9, the structure of an object, the data type and storages required in order to store the data are all predefined by the platform. All the data is stored in the Tally database. By default, data is always stored in predefined storages only.
There may be instances when additional information needs to be stored in the existing objects. This need gave rise to concept of User Defined Fields (UDF). A UDF can be used to store additional information to the Tally database. In other words, UDFs store additional information into the existing objects.
User Defined Fields have a storage component defined by the user. UDFs are stored in the current object context. They can be of any Tally data type such as String, Amount, Quantity, Rate, Number, Date, Rate of Exchange and Logical.
Defining UDFs does not serve the purpose, unless it is associated with one or more internal object. When a UDF is created and used in an already existing report, the data is stored in the context of the object, i.e., it is always associated to the object to which the report is associated, i.e., the object in context.
UDFs should be defined under the section [System: UDF].
Syntax
[System : UDF]
<Name of UDF>: <Data Type>: <Index Number>
Where,
< Name of UDF > Identifies the UDF. Ideally, it should describe the purpose for which it has been created.
< Data Type > is any of the Tally data types or ‘Aggregate’.
< Index Number > can be any number between 1 and 65536.
Numbers falling between 1 to 9999 and 20001 to 65536 are opened for customisation, and those between 10000 to 20000 are allotted for Common development in TSPL. The user can create 65536 UDFs of each data type.
Note: The index numbers 1 to 29 are already used for Default TDL.
Example
[System : UDF]
MyUDF 1 : String : 20003
MyUDF 2 : Date : 20003
The advantage of UDF in Tally is that it automatically attaches with the current object. No specific declaration is required for object association, when the UDF is defined within system definition.
The attribute Storage is used to store the value entered in the field, in the current object context.
Syntax
Storage : <Default Storage/Name of UDF>
Where,
< Name of UDF > identifies the UDF. Ideally, it should describe the purpose for which it is created.
Example
[Field : NewField]
Use : NameField
Storage : MyUDF
In the context of the current object, the value of a UDF can be accessed by prefixing $ to the UDF name.
Syntax
$<Name of UDF>
Example
[Field: NewField]
Use : NameField
Set As : $MyUDF
The UDFs are classified into two types, which are as follows:
● Simple UDF
● Complex/Compound/Aggregate UDF
It can store one or more values of a single data type. A UDF used for storage, stores the values in the context of the object associated at Line/Report level, by default. Only one value is stored in this case.
The following example code snippet demonstrates how a UDF can be made use of to store a single value:
Example
[Report : CompanyVehicles]
Object : Company
.
.
.
[Field : CVeh]
Use : Name Field
Storage : Vehicle
Unique : Yes
[System : UDF]
Vehicle : String : 700
The object is associated at the Report Level. The value stored in a UDF is in the context of ‘Company’ Object in this case. The UDF ‘Vehicle’ stores a single string value.
When multiple values of the same data type are to be stored, then the ‘Repeat’ attribute of Part is used. The field of the line uses the same UDF name in the ‘Storage’ attribute.
Syntax
Repeat : <Line name> : <Name of UDF>
Where,
< Line Name > is the name of the line to be repeated.
< Name of UDF > identifies the name of the UDF to store multiple values. The example in the section “UDF to store single value” can be modified to store multiple values.
Example
[Part : CompVeh]
Line : CompVeh
Repeat : CompVeh : Vehicle
Break On : $$IsEmpty:$Vehicle
Scroll : Vertical
In this scenario, multiple values of type String can be stored under the object Company.
Multiple values stored in a UDF can be displayed as Table in a field. The Collection is defined as:
Syntax
[Collection : <Collection Name>]
Type : <UDF Name> : <Object Name>
Format: $<UDF Name>, 20
Example
[Collection: CMP Vehicles]
Type : Vehicle : Company
Childof : ##SVCurrentCompany
Format : $Vehicle, 20
Title : "Company Vehicles"
It creates a collection of values stored in the UDF of the current object ‘Company’. This collection can be used in the ‘Table’ attribute of ‘Field’ definition. When the cursor is in the defined field, the values stored in the UDF will be displayed as a popup table. Consider the following example:
[Field : EI Vehicles Det]
Use : Short Name Field
Table : CMP Vehicles, Not Applicable
Show Table : Always
A popup t able is displayed when the cursor is placed in the field EI V ehicles Det . The t able con t ains values stored in the UDF which are Not Applicable as a list.
A Simple UDF can only store values of a single data type; so, when multiple values of different data types are required to be stored as one entity, an Aggregate UDF can be used.
Aggregate UDFs are very useful for storing multiple values and repeated values. An aggregate UDF is a combination of different types of UDFs. Aggregate UDFs can be used to store user data in a tabular format, attached to any internal object, and can be used as a collection of UDFs.
In other words, an Aggregate UDF comprises of a set of fields repeating more than once. The output can be stated in the form of a record consisting of fields of different types and sizes. When a line is repeated over an Aggregate UDF, it associates all its storage components (same or different data types) as a single unit.
To create an Aggregate UDF, the data type Aggregate is used while defining the UDF. The components are defined as simple UDFs.
Syntax
[System : UDF]
<Name of UDF> : Aggregate : <Index Number>
Example
A company wants to create and store multiple details of company vehicles. The details required are: Vehicle Number, Brand, Year of Mfg., Purchase Cost, Type of Vehicle, Currently in Service, Sold On date and Sold for Amount.
[System : UDF]
Company Vehicles : Aggregate : 1000
VVehicle Number : String : 1000
VBrand : String : 1001
VYear of Mfg : Number : 1000
VPurchase Cost : Amount : 1000
VType of Vehicle : String : 1002
VCurrently in Service : Logical : 1000
VSold On date : Date : 1000
VSold for : Amount : 1001
To store the required details, simple UDFs are defined and to store them as one entit y , a UDF of type Aggregate is defined, as shown in the example.
An Aggregate UDF defined does not associate each component field with it. The association will takes place only when a Line is repeated over an Aggregate UDF and within that Line, there are fields which store the value into the component UDFs.
Syntax
Repeat : <Line name> : <Name of Aggregate UDF>
Where,
< Name of Aggregate UDF > is the name of the UDF defined with Aggregate data type.
Example
[Part : Comp Vehicle]
Line : Comp VehLn
Repeat : Comp VehLn : Company Vehicles
BreakOn : $$IsEmpty:$VBrand
.
.
.
[Field : CMP VBrand]
Use : Short Name Field
Storage : VBrand
The Line is repeated over the Aggregate UDF and the Simple UDFs are entered in the fields.
Subform is an attribute that is used within a Field definition. It relates to a report (not Form) and can be invoked by a field. This attribute is useful to activate a report within a report, perform the necessary action and return to the report used to invoke the Subform. There is no limit on the number of Subforms that can be used at the field level.
Syntax
[Field : Field Name]
Sub Form : <Report Name> : <Condition>
Where,
< Report Name > is the name of the Report to be displayed.
< Condition > could be any expression, which evaluates to a logical value. The report will be displayed only when the condition is True.
A Subform is not associated to the Object at the Report level. An Object associated to the Field in which the Sub Form is defined, gets associated to the Sub Form. A Sub Form will inherit the info object from the Field which appears as a pop-up.
The Bill-wise Details is an example of a Subform attribute. This screen is displayed as soon as an amount is entered for a ledger whose Bill-wise Details feature has been activated.
Example
The following code snippet uses a Subform to enter the details of bills when the Bill Collection ledger is selected, while entering a Voucher. The values entered in the Subform are stored in an Aggregate UDF. This UDF is attached to the object to which the field displaying the Subform is associated. Here, it is the Object of a Ledger Entries Collection.
The following code is used to associate a Subform to the default Field in a voucher.
[#Field : ACLSLed]
Sub Form : BillDetail : ##SVVoucherType = "Receipt" and $LedgerName = "Bill Collection"
The Name Report for the Subform uses an Aggregate UDF to store the data. A Line is repeated over the Aggregate UDF at the Part level.
[Part : BillDetails]
Scroll : vertical
Line : BillDetailsH, BillDetailsD
Repeat : BillDetailsD : BAggre
Break After : $$Line=2
The attribute Storage is used for all the fields.
[Field: CustName1]
Use : Name Field
Storage : CustName
The UDF is defined as follows:
[System : UDF]
CustName : String : 1000
BillNo : String : 1001
BillAmt : Amount : 1001
EPrint1 : String : 1002
BAggre : Aggregate : 1000
Learning Outcome
● UDFs are stored in the context of the current Object. They can be of any Tally data type.
● UDFs should be defined under the section [ System: UDF ].
● The attribute ‘Storage’ in a Field definition is used to store the value entered in a Field.
● The value is stored in the context of the current Object.
● A Simple UDF can store one or more values of a single data type only.
● Aggregate UDFs are very useful for storing multiple values and repeated values
