Академический Документы
Профессиональный Документы
Культура Документы
ID.NEW
ID.OLD
ID.NEW.LAST
R.NEW()
R.OLD()
R.NEW.LAST()
R.NEW, R.NEW.LAST AND R.OLD are three important common variables . When the
validate, commit or authorise button is clicked, these three variables are populated.
R.NEW is populated with the record on the screen. R.NEW.LAST is populated with
the corresponding record from $NAU table if available and R.OLD is populated with
the corresponding record from LIVE table if available. ID.NEW, ID.NEW.LAST,
ID.OLD contains the corresponding ID’s of the record (As is obvious the same ID is
stored in these three variables. The purpose of these three ID variables are discussed
On clicking the Authorise button, the following common variables are re-initialised
R.NEW contains the record from the web-page. After the execution of the processing
logic if any, R.NEW is written into the Live table.
If required, R.NEW can be manipulated programmatically before its written onto the
LIVE table. R.NEW.LAST is also a dimensioned array defined in I_COMMON as
R.NEW.LAST(C$SYSDIM). The ID corresponding to the record in this variable is
stored in ID.NEW.LAST, also a common variable defined in I_COMMON.
R.OLD retains the record copy before the amendment. Contents of R.NEW(which
contain the amendments) are then written into the $NAU table. At this stage, the
previously authorized record is in LIVE and the amended record is in $NAU with an
INAU status.
(Amendment of an authorised record is possible only if the application allows it; some
contract based applications do not allow to edit an authorised record).
The USER.ID of the current USER logged in to T24 and his user profile is loaded in
the common variable R.USER. R.USER is declared as a dynamic array in
I_COMMON. Every time T24 needs to perform an SMS check, instead of reading the
USER record, it refers to this variable. If the user has USER.SMS.GROUP attached,
the values of USER.SMS.GROUP is embedded in the appropriate fields in R.USER
Due to incorrect relationship between field name and the data that is input.
In case of Error Messages, you need to correct the data input in the particular fields
and commit the transaction again.
1.2 Override Messages: These are warning messages, at least most of the time. A
user may accept or reject override. If accepted, T24 saves the record and the override
message is stored as part of it in the field OVERRIDE. If you do not want to accept the
Override, you may either put the record on hold to correct it later or amend the record
and commit it again.
AF=AC.CLASS (AC.CLASS has been defined in the I_ file and refers to the field position of class.
Here it is 1
In the for loop AV is used as the loop counter so that we can check if all classes are in the correct
position. Value in pos 1 must be 1, value in pos 2 must be 2 and so on.
Explanation for R.NEW(AF)<1,AV> - R.NEW is a dimensioned array. Each dimension refers to field
in the table. AF has been set to 1, hence we are looking at the contents of R.NEW(1). We know
each dimension is actually a dynamic array. To refer to a value within a dynamic array we must give
the field position and also multi value position. When working with R.NEW field position is always 1
as each dimensioned array contains data about only one field only. The second subscript within <>
tells us which multi value we are referring to.
R.NEW(1)<1,1> is 1 and R.NEW(1)<1,2> is 3.
In the second iteration of the for loop AV is 2, AF is 1
R.NEW(1)<1,2> is 3 and AV is 2. As the values are not equal error gets displayed against the