Results for “per_job_flex”

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

Overview

PER_JOB_FLEX is an Oracle EBS PL/SQL package owned by the APPS schema. In the E-Business Suite data model, objects whose names terminate in _FLEX are conventionally associated with the Key Flexfield infrastructure — specifically with the validation, derivation, and cross-validation logic that governs how flexfield segment combinations are accepted or rejected during data entry. PER_JOB_FLEX therefore operates in the Oracle Human Resources (PER) product family, where the Job flexfield defines the set of descriptive and validated segments (for example, job group, job code, and category attributes) that together uniquely identify a job definition in the enterprise.

The package is classified in the ETRM repository as an OTHER API, meaning it is not registered as a public, supported integration interface such as an Open Interface or a business API with a published parameter contract. It exists primarily to service the internal flexfield machinery that surrounds job definition and job validation, and it is documented as VALID in both Oracle EBS 12.1.1 and 12.2.2. Its role is best understood as a supporting component of the PER Jobs key flexfield rather than as a standalone callable interface for external consumers.

Key Procedures and Functions

The ETRM metadata records a single documented procedure or function for this package, identified as DF. Consistent with the naming conventions used throughout Oracle HRMS flexfield packages, DF denotes the internal "default" routine. Routines of this name are invoked by the flexfield framework when a new job flexfield combination is being built and the system must supply default segment values — typically derived from existing job attributes or from the flexfield structure definition — before user entry or validation proceeds.

Because the ETRM entry documents only the identifier and does not expose a parameter signature, no argument list is asserted here. The procedure should be treated as an internal implementation detail of the job flexfield. Its behavior is driven by the flexfield definition and by the context in which the combination is being created, rather than by an externally documented calling contract.

Tables Accessed

The documented dependency information identifies PER_JOB_SHD as the table referenced by PER_JOB_FLEX through an APPS synonym. PER_JOB_SHD is the shadow (suffix _SHD) table associated with the PER_JOBS entity. Shadow tables in Oracle HRMS hold the dated, effective-history rows for their parent entity and are used by the DateTrack mechanism to support retrospective and future-dated changes.

Access to PER_JOB_SHD indicates that the package reads job definition data — including the flexfield segment values that make up each job's identifying combination — in order to support defaulting and validation of job flexfield combinations against existing, date-effective job records. The metadata does not document write operations, and none are claimed here. Note that PER_JOB_SHD is a legacy object retained for backward compatibility; in later releases the principal job data is held in PER_JOBS, and the shadow table continues to be referenced by flexfield-related code for historical continuity.

Usage Notes

PER_JOB_FLEX is not intended for direct invocation by customer code, concurrent programs, or forms. It is invoked indirectly by the Oracle Application Object Library flexfield engine whenever the Job key flexfield is exercised — for example, when a user defines or updates a job in the Job form, when a job flexfield combination is validated during assignment entry, or when HRMS processes resolve a job's segment combination.

Because the ETRM metadata confirms that the package is not referenced by any other documented package, its consumers are the compiled flexfield components and forms that bind to the Job flexfield definition, rather than a PL/SQL dependency chain. Customizations should not call PER_JOB_FLEX directly, since its interface is undocumented and may change between patch levels. Integrations that need to create or validate jobs should use the supported HRMS business APIs (for example, the job and position APIs in PER_JOBS_API or the corresponding dataloader interfaces), letting the flexfield framework invoke PER_JOB_FLEX on their behalf.