Results for “hr_contact_bk1”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.HR_CONTACT_BK1 is the "before" (validation and derivation) stub of the HR Contact public API in Oracle EBS Release 12.1.1 and 12.2.2. It belongs to the Oracle Human Resources (PER) module and forms part of the family of generated API packages that Oracle supplies so that external programs — forms, concurrent programs, workflows, and custom PL/SQL — can create and maintain person (contact) records without performing direct DML against the base tables. The package is classified as OTHER in the ETRM repository and is owned by APPS.

The package name contains the "BK1" suffix, which identifies it as the pre-processing half of a two-part API structure. For every business operation exposed by the HR Contact API, Oracle generates a _B (before) routine, which contains the logic that must run before the row is inserted or updated, and an _A (after) routine, which contains the logic that must run after the DML has completed. The _BK1 package holds only the _B specifications; the corresponding _A specifications live in a companion package. The header comment visible in the source (peconapi.pkh, dated 2005/10/02) confirms that HR_CONTACT_BK1 is generated from the HR Contact API definition file and should never be modified manually.

Key Procedures and Functions

The documented API exposes two procedures, both declaring the documented date-tracked parameters including P_START_DATE and a full set of descriptive attributes (last name, sex, date of birth, email address, national identifier, work telephone, and thirty attribute columns for DFF support).

• CREATE_PERSON_B — The before-processing routine for creating a person or contact record. It validates the incoming arguments, derives default values, and prepares the data that the corresponding CREATE_PERSON_A routine will insert. Typical before-logic includes checking mandatory fields such as last name and start date, deriving the effective end date, resolving the person type, and populating WHO columns and the primary key from sequence generators.
• CREATE_PERSON_A — The after-processing routine that performs the actual insert into the person table and any dependent tables (for example person type, contact, and telephone records), inserts the date-tracked row into the corresponding _F shadow table, and raises business events or calls post-insert business rules.

Because HR_CONTACT_BK1 exposes the _B specifications, callers normally invoke the combined wrapper in the HR_CONTACT_API package, which internally calls CREATE_PERSON_B first and then CREATE_PERSON_A, ensuring the before and after steps execute in the correct order within a single logical transaction.

Tables Accessed

The ETRM metadata for this object does not list the base tables reached through APPS synonyms. In line with the documented purpose of the HR Contact API, and the naming conventions of the PER schema, the create-person flow operates on the PER_ALL_PEOPLE_F date-tracked table (through the person entity), together with supporting person-type and contact tables. The _B routine performs validation and derivation reads; the _A routine performs the inserts and also writes the corresponding date-tracked shadow rows so that the Datetrack framework remains consistent.

Usage Notes

HR_CONTACT_BK1 is a generated, Oracle-owned package and is referenced by one other packaged object in the ETRM repository. It is not intended for direct invocation by end users or custom code. The supported entry points are the HR_CONTACT_API wrapper package and the HR Contact forms and concurrent programs that call the API on a user's behalf.

The API must always be called together with its datetrack parameters — the start date is mandatory and the effective end date is derived by the API itself. Direct DML against the underlying person tables should be avoided because it bypasses the derivation, validation, datetrack, and business-event logic contained in CREATE_PERSON_B and CREATE_PERSON_A. Any customer extension should use the DFF attribute columns declared by the API rather than altering the generated package. The package is present in both 12.1.1 and 12.2.2 and remains unchanged apart from generated version stamps, so customisations written against it are generally portable across those releases.