Maintain Validation Parameter Values {SNAPPA-8}

This option is used to define validation rules with which academic applicants must comply.


It is of crucial importance that users should remember that the parameters for each rule are 'hard coded' in the DATABASE PROCEDURE that is linked to each rule. If a new rule is defined in block one, the DATABASE PROCEDURE linked to the rule must be specifically designed to cater for the parameters linked to the rule.


If a completely new DATABASE PROCEDURE is linked to a new rule that does not exist in the database, the academic applicant will not be evaluated against that rule.

Similarly, if new parameter records and values are linked to an existing rule that is linked to an existing DATABASE PROCEDURE, those new parameters and values will be ignored if the DATABASE PROCEDURE is not upgraded to include the new parameters.

Users can define new rules using the same DATABASE PROCEDURE. Care must be taken that the parameter records for the new rule matches the parameter records needed by the procedure. Different parameter values can be entered for the new rule.


The program comprises three blocks - all on one screen: Block 1, where the rule is defined: block 2, where the parameters are defined; and block 3, where values that are matched against the applicant are captured for the rule parameters

Users can navigate from one block to the other using mouse navigation. This is in addition to the normal <NEXT BLOCK> or <PREVIOUS BLOCK> modes of block navigation.

The records in the different blocks are interrelated. If all the records in block 1 are queried and the user scrolls through the records, the corresponding parameter records for the current rule will be displayed in block 2. The same relationship exists between the records in blocks 2 and 3.

Fields in this option:

Block 1: Validation Rules  

Field Type
&
Length		 Description
Rule Code A4  Enter a code that will uniquely identify an application validation rule.
Rule Description A250 Enter the rule description.
Sequence N3 Enter the sequence in which this validation must be performed.
Stop Quote A1 Enter 'Y' if the application program must prevent the generation of a quote should all the applicable rules for the application not have been successfully validated. See the manual on the student validation results in {SNAPPA-9}.
Stop Admits A1 Enter 'Y' if the application program must prevent the admission of an application should all the applicable rules for the application have not have been successfully validated yet.
Admit Status A1 Enter the admission status that should be allocated to the applicant. This admit status must be defined as active in {SCODE-26}.  If the admission status is inactive in {SCODE-26} it will not be available for selection in the LOV'S.
Database Procedure A12 Enter the name of the database procedure that will be used to execute the logic of this validation rule. Please review the remarks about the database procedure in the comments at the start of this manual. If the user defines a function that does not exist as yet, a warning message will be displayed indicating that it must be created in i23pkg.sql

The LOV on this field gives a list of database procedures already in use in this table.
Active A1 Enter a 'N' if the validation rule is no longer needed or the user wants to disable the validation rule temporarily. The application program calls a function that will always validate only active validation rules. If some applicants were validated against a rule that is later set to not active, those applicant's validation outcome records must be manually corrected, if desired, in {SNAPPA-9}.
Error Message A250 Enter the error message that will be generated for internal use when a validation of an academic application is not successful.
Student Message A250 Enter a message that will be included in an application correspondence document sent to the applicant. This document will include the description of the failed validations and this student message should explain to the applicant why he / she failed the validation.
  • Note: This field is NOT mandatory. This is to cater for those types of rules where the applicant should not see a message regarding a failed application validation.
  • Users must ensure that messages are entered where it is applicable.

Block 2: Rule Parameters  

The rule code is not displayed in this block, instead it is populated automatically in a hidden field in the background.

Note: Please remember that each parameter record inserted for a rule code must be defined in the corresponding database procedure.


Field Type
&
Length		 Description
Parameter number N4 Enter the number of the parameter. This value does not necessarily denote the sequence in which the parameter is evaluated in the database procedure.
Description A512 Enter a description for this prompt.
Table Reference A40 Enter the ORACLE database table against which the prompt values must be validated (A40). This table is used in block 3 to determine if valid parameter values are used in the academic application validation process. This value must exist in {DMAIN-1} and is installed with the ITS system. We suggest that this data is inserted with the help of the systems administrator.
  • The format of the data in this field must be of the format SCHEMA.TABLE e.g. STUD.IAIQAL
Column Reference A20 Enter the ORACLE column in the ORACLE table against which the prompt values must be validated. This value must exist in {DMAIN-1} and is installed with the ITS system.
Description column A40 Enter the column in the table that contains the description for the column value referred to in the previous field

Example: Suppose that the applicant must have a specific Certificate logged against his application number the following data will be entered in the previous field and in this field:

   1. Table name: STUD.IBUCER
   2. Column name: IBUCODE
   3. Description column in the table: IBUNAME

Thus, if a student must have a certificate called 'ID', the program will validate that the value 'ID' is entered in block 3 for the specific validation rule, that the value exist in column IBUCODE in table STUD.IBUCER. When the user uses the mouse right click while on the record in block 3, the program will display the value in the column IBUNAME where the column IBUCODE has the value 'ID' (i.e. the description of the code 'ID').
LOVSQL A8 Enter the code of an additional SQL clause that will be included in the LOV.
Note: This has not yet been implemented in Integrator 1.
Data Type A1 Enter the data type of the parameter value that will be entered in the parameter value table. (N)umeric , (C)haracter, (D)ate. This is used as a second validation mechanism to ensure that the user enters the correct type of data for the parameter values in block 3.

Block 3:  Parameter Values  

Field Type
&
Length		 Description
Hidden
Two fields are hidden in the background, i.e. the Rule code and the Parameter number.
Parameter Values A30 The parameter value for the rule and parameter is entered in this field. Please keep the following in mind:
  • When the cursor moves from block 2 to block 3, a record is inserted in block 3, together with the rule code and parameter value. If records already exist, the program will automatically query those records. To remove a value, the record must be deleted. If the <CLEAR FIELD> option is used, the program will raise an error as the value field is a mandatory field.
  • The value field cannot be updated. Should a new value be required, the unwanted record must be deleted using the <DELETE RECORD> action and a new record must be inserted.
  • The program will check that the correct type of data is entered based on the setting of the Data Type field in block 2.
  • A LOV will be dynamically build based on the Table Reference, Column Reference and Description Column defined in block 2. If values do not exist in the Table Reference and Column Reference fields in block 2, no LOV will be available.


Example:

validation Parameters snappa-8 image


Processing
Rules		  
  Any changes made to any blocks in this option can be written to a log file. The user can decide if this data is critical enough to be written to a log file. Please study the manual {DMAIN-31} to learn how to create the log facility and a print program. The table IDs needed for the creation of the log facility are:
  • Block 1 - JHD
  • Block 2 - JHH
  • Block 3 - JHI
It is recommended that users use the JBDLOG log table as this is the general student data log table.

For rules used in the AutoEnrol process: this option can only be used to disable Application Rules validated by rule Z033: "SNAPPA 3 Validations". It cannot be used to disable any other Stage/Rules used in the AutoEnrol process, defined in GWEBM-18/19.

See Also:
History of Changes

Date System Version By Whom Job Description
30-Apr-2006 v01.0.0.0 Phlip Pretorius T116049 Original development and new manual format.
04-Jul-2006 v01.0.0.0 Phlip Pretorius T129781 Add the logic of the LOV on the database procedure field.
22-Feb-2007 v01.0.0.0 Hermien Hartman T131172 Copy newer version to Int1.
23-Mar-2007 v01.0.0.1 Phlip Pretorius T137678 Correct tab sequence of fields.
21-May-2007 v01.0.0.2 Phlip Pretorius F141527 Add correction of values on block three.
16-Aug-2007 v01.0.0.2 Melanie F141527 Add information regarding popup on procedure entry not in i23pkg.
03-Oct-2008 v01.0.0.2 Magda van der Westhuizen t152511 Update manual:  Language Editing:  Juliet Gillies.
05-Jun-2013 v02.0.0.0 Melanie Zeelie t191287 Add detail to manual for active indicator.
07-Jan-2014 v02.0.0.1 Magda van der Schyff T193793 Add detail regarding AutoEnrol process.
02-Feb-2016v04.0.0.0Magda van der Westhuizent211861ATOV:  211861 :  Inactive Status Code