Search Results validate_email_id

Overview

APPS.PER_ZA_USER_HOOK_PKG is a South Africa-specific user hook package that extends Oracle EBS Human Resources (HR) person and assignment processing with country-legislative validation logic. In the Oracle E-Business Suite, "user hooks" are predefined extension points embedded in the delivered HR APIs. Oracle seeds each hook as a stub package, and implementers replace the stub body with customer-specific or legislation-specific code. This package is the South African localization of that pattern.

The package is classified in ETRM as an "OTHER" API under the APPS schema. Its header comment dates from release 12.0.0 and is invoked from both hr_applicant_api and hr_employee_api "before process" hook points, meaning validation executes prior to the actual insert or update of person records. The core business purpose is to enforce South African statutory and DDF (Descriptive Flexfield) requirements — most visibly the Race attribute stored in PER_INFORMATION4 — during the creation of applicants, employees, contingent workers, and other person records. It also validates and maintains assignment extra information, addresses, phone and e-mail data, and personal payment methods, all of which carry South African reporting obligations.

Key Procedures and Functions

ETRM documents fifteen procedures. The person-creation validations include VALIDATE_APPLICANT and VALIDATE_EMPLOYEE, which are the before-process hooks called from the applicant and employee APIs respectively; both reference the Race flexfield segment (PER_INFORMATION4). VALIDATE_CWK performs the equivalent validation for contingent workers, while VALIDATE_PERSON provides a general person-level check.

Communications and address checks are handled by VALIDATE_EMAIL_ID, VALIDATE_PHONE_NO, and VALIDATE_PERSON_ADDRESS, which validate the corresponding person contact and address records. VALIDATE_CHARCTER_SET (as spelled in the package) performs character-set validation on supplied values.

Assignment extra information is managed by a set of procedures that validate, create, and update the South Africa assignment extra info entity: VALIDATE_ASG_EXTRA_INFO, CREATE_ZA_ASSIGN_EXTRA_INFO, and UPDATE_ZA_ASSIGN_EXTRA_INFO. Organizational and location data are validated by VALIDATE_ORG_INFO and VALIDATE_LOCATION_EXTRA_INFO. Finally, payroll-related personal payment data is handled by VALIDATE_UPDATE_PER_PAYMENT and VALIDATE_CREATE_PER_PAYMENT, covering the update and creation paths respectively.

Tables Accessed

ETRM records the following base tables, accessed through APPS synonyms. PER_ALL_PEOPLE_F is the primary person table and is read for validation and, in some paths, written. PER_PERSON_TYPES is consulted to confirm the person type governing the record being processed. PER_ALL_ASSIGNMENTS_F and PER_ASSIGNMENT_EXTRA_INFO support the assignment extra information procedures that persist South Africa-specific assignment attributes. HR_ORGANIZATION_INFORMATION provides organizational flexfield data used by the organization information validation. PAY_PERSONAL_PAYMENT_METHODS_F underpins the personal payment method validation and maintenance routines. The package is also referenced by five other packages, indicating that it participates in a wider South African HR integration chain rather than operating in isolation.

Usage Notes

Because the procedures are user hooks, they are not normally invoked directly by end users. They fire automatically when the delivered hr_applicant_api and hr_employee_api execute their before-process hook points during hire, applicant entry, and related person maintenance flows in the Oracle HRMS forms. Assignment extra information routines may also be triggered from assignment maintenance or from concurrent processes that maintain South African assignment data. The payment method procedures align with payroll personal payment method setup.

Custom code should not call these procedures directly in place of the standard APIs. Implementers extending South African HR functionality should treat this package as the supported hook surface and place additional logic within the same hook framework. As with all seeded hook packages, customers should avoid modifying the stub in a way that breaks the delivered signature, since the documented procedures are invoked positionally by the calling APIs.