4.8 Edits
Edits ensure your organization’s guidelines are properly followed and that all exceptions are sent to the appropriate personnel to review.
You can configure your system so that during the origination process, at each change to an application’s status, the system will perform a set of edits on the Verification link’s Edits screen (found on the Application Entry, Underwriting, and Funding windows).
Edits ensure your organization’s guidelines are properly followed and that all exceptions are sent to the appropriate personnel to review. If the edits check fails, then the system will not allow the change of status, and the application will remain in its current status. This screen allows you to define the validations the system must perform on the Verification master tab, as the status of application changes.
Origination edits are used to validate applications entered through the standard Application Entry and Applications windows. The Edits screen contains two sections, the Edit Type Definition section and the Edit Sub Type Definition section.
To set up the Edits
- On the Oracle Financial Services Lending and Leasing home screen, click Setup > Setup > Administration > User > Products > Edits > Line.
- On the Edits screen, choose Origination or Open Interface.
- In the Edit Type Definition section, perform any of the Basic Operations mentioned in Navigation chapter.
A brief description of the fields is given below:
Table 4-22 Edit Type Definition
Field Do this Edit Specify the edit name. Description Specify the description for the edit. Edit Type Select the edit type code from the drop-down list. System Defined Select Yes, if the entry is system defined. System defined entries cannot be modified. Select No, if the entry is not system defined and it can be modified. Enabled Check this box to enable the edit. Company Select the portfolio company associated with this edit, from the drop-down list. This may be ALL or a specific company. Branch Select the portfolio branch within the company associated with this edit, from the drop-down list. This may be ALL or a specific branch. This must be ALL if you selected ALL in the Company field. Channel Select the channel from the drop-down list, This can be ALL or a specific channel. Product Select the product associated with this edit, from the drop-down list. This may be ALL or a specific product. State Select the state with this edit from the drop-down list. This may be ALL or a specific product. Currency Select the currency associated with this edit, from the drop-down list. This may be ALL or a specific branch. - Perform any of the Basic Actions mentioned in Navigation chapter.
- In the Edit Sub Type Definition section, perform any of the Basic Operations mentioned in Navigation chapter.
A brief description of the fields is given below:
Table 4-23 Edit Sub Type Definition
Field Do this Edit Sub Type Select the edit sub type for the edit, from the drop-down list. Edit Select the description for the edit, from the drop-down list. Result Select the result type for the edit, from the drop-down list. Enabled Check this box to enable the edit. Value Specify the expected value for the first edit. The Value field records the threshold value for the edit. The actual function of the entered value is dependent on the edit category. Override Responsibility Select the responsibility that can override the edit, from the drop-down list, if the edit result is an override. Designates the user responsibility level required to continue processing applications that fail the edit based on the Value field. You may define the same edit multiple times with a Result = OVERRIDE and different Value and Override Responsibility combinations to encompass various results. System Defined Select Yes, if the entry is system defined. System defined entries cannot be modified. Select No, if the entry is not system defined and it can be modified. - Perform any of the Basic Actions mentioned in Navigation chapter.
Using the Edit Type field of the Edit Type Definition section, you can define when you want the edits check to occur by selecting from the following list of edit types:
Table 4-24 Edit Type Definition
Edit type Description APP ENTRY EDITS Edits that normally run on Application Entry form. APP PRESCREENING EDITS Edits that run between application entry and the pulling of a credit bureau. These edits determine whether the application should be reviewed further, and whether a credit bureau should be pulled. PRE Qualify Edits Edits that run to check whether the minimum details which are required to prequalify the application are satisfied or not. APP AUTOMATIC APPROVAL EDITS Edits that run after a credit bureau has been pulled and scored. These edits determine whether an application should be automatically approved or declined. APP APPROVAL EDITS Edits that run whenever an application is manually changed to a status/sub status that indicates the application (in its current state) should be approved. APP DECLINE EDITS Edits that run whenever an application is manually changed to a status/sub status that indicates the application (in its current state) should be declined. APP CONTRACT EDITS Edits that run whenever an APPROVED or CONDITIONEDAPPROVED application is about to be funded. These edits ensure the validity of the contract data. Each entry in the Edit Sub Type field is grouped into the following categories:Table 4-25 Edit Sub Type field
Origination edit sub types Description ORIGINATION APPLICANT EDITS Edits that pertain to data entered for an applicant on an application. ORIGINATION APPLICATION EDITS Edits that pertain to data entered for the requested line of credit. ORIGINATION ASSET EDITS Edits that pertain to data entered for asset entered on the application. ORIGINATION CONTRACT EDITS Edits that pertain to data entered for the contract on the application. ORIGINATION CREDIT BUREAU EDITS Edits that pertain to data gathered from the credit bureau reports for the applicants on the application. ORIGINATION DECISION EDITS Edits that pertain to data required to make a decision on the application. Each entry in the Edit Sub Type field can be set up with more than one entry in the Description field. The purpose of specific edits fall into the following types:Table 4-26 Description
Description starts with (Edit Category) Description of Edit Category CHD: (RECORD POPULATION EDITS) Check for the existence of an entire data record. DUPLICATE: (DUPLICATION EDITS) Check for duplication of existing data. RANGE: (VALUE RANGE/TOLERANCE EDITS) Check to determine whether data entered for a specific data field is within the specific tolerance. REQUIRED: (REQUIRED FIELD EDITS) Check to determine whether a specific data field has been populated within a data record. FLK: (LOOKUP VALUE EDIT) Check API entered data against the existence of that value in the related lookup types lookup codes. XVL: (CROSS VALIDATION EDIT) Check to determine whether specific field, or set of fields, value corresponds to a value obtained by calculating them from another field or set of fields (for example, Total Payments = Terms * Standard payment amount). An Edits check can produce one of three results: an ERROR, a WARNING, or an OVERRIDE.Table 4-27 Edits check
Edit type Results ERROR The system will prevent you from proceeding when an edits check fails. The only option is to change the source data. The application will revert to its previous status/sub status. The user will be directed to correct the specific error. Until the edits that return an ERROR value are addressed, the user cannot continue processing the application. Warning When an edits check fails in these cases, the system allows the process to continue. Warnings serve as informational messages and can be ignored. The user will be notified that an edit failed, but the failure need not stop the current processing of the application. The user can either ignore the error, or have the application revert to its previous status/sub status and address the error before processing the application further. Override The edit check has failed; however, the system allows users with the responsibility specified in the Override Responsibility field to continue. Multiple override levels can be setup depending upon the resulting value of the edit. If the user has override responsibility, the application will process as if the edit had not failed. If the user does not have override responsibility, the application will revert to its previous status/sub status and the sub status changes to OVERRIDE REQUIRED. The system will then direct the application to a user with the authority to process the application. (See the Queues chapter for more information). Note:
Do not set the Result field to Override for credit application edits.
This section consists of the following topic:
Parent topic: Product