Search Results start_date_le_end_date




Overview
Explore in AI Chat

Overview

PO_VAL_NOTIFICATION_CONTROLS is a validation package in the Oracle E-Business Suite Purchasing module (APPS schema). It encapsulates a set of server-side business rules used to validate supplier notification and notification control records before they are committed to the database. The package belongs to the broader PO_VAL family of validation utilities, which are invoked by the Purchasing forms and related PL/SQL APIs during record-level and field-level validation.

The package exposes a small, focused set of procedures, each targeting a specific integrity constraint. Collectively these procedures enforce that notification dates are logically ordered, that percentage and amount columns fall within permitted ranges, and that mandatory attributes are populated when the controlling condition code requires them. The header comment identifies the source file as PO_VAL_NOTIFICATION_CONTROLS.pls 120.1, dated 2005, and marked noship, indicating a long-standing internal validation unit rather than a shippable public API.

Because the procedures accept PL/SQL table (array) parameters — such as PO_TBL_NUMBER and PO_TBL_DATE — the design supports bulk validation of multiple notification rows in a single call, which is characteristic of the Purchasing validation architecture.

Key Procedures and Functions

  • START_DATE_LE_END_DATE — Validates that the start date active is less than or equal to the end date active for each notification row. This is the procedure directly associated with the search term "start_date_le_end_date"; it is the canonical date-ordering check for notification controls. It operates over parallel arrays of notification identifiers and date values.
  • PERCENT_LE_ONE_HUNDRED — Confirms that the notification quantity percentage does not exceed one hundred percent. It receives arrays of notification identifiers and percentage values.
  • AMOUNT_GT_ZERO — Ensures that the notification amount is strictly greater than zero, rejecting zero or negative amounts.
  • AMOUNT_NOT_NULL — Enforces that the notification amount is populated when the associated notification condition code demands a value. It accepts arrays of identifiers, amounts, and condition codes so that the requirement can be applied conditionally.
  • START_DATE_ACTIVE_NOT_NULL — Enforces that the start date active is populated when the controlling condition code requires it, again using arrays of identifiers, dates, and condition codes.

Each procedure returns results through x_results (an in-out PO_VALIDATION_RESULTS_TYPE collection accumulated across calls) and x_result_type (an out parameter conveying the overall validation status). This shared signature pattern allows the caller to accumulate and inspect multiple validation outcomes in one processing cycle.

Tables Accessed

The ETRM metadata documents a single table reference: PLITBLM, accessed through an APPS synonym. This is consistent with the package acting as a pure validation layer — its inputs arrive as array parameters supplied by the caller, and it does not perform direct DML against notification control base tables. The PLITBLM reference is likely used for supporting lookups or temporary staging during validation. Broader notification data (PO_NOTIFICATION_CONTROLS and related entities) is sourced by the calling form or API, not by this package itself.

Usage Notes

PO_VAL_NOTIFICATION_CONTROLS is typically invoked from the Purchasing notification maintenance forms during field validation and record save, and may also be called by other validation packages during bulk processing. The metadata records that it is referenced by one other package, reflecting this nested-call pattern. Custom code invoking these procedures should supply properly populated PL/SQL tables, pass a correctly initialized PO_VALIDATION_RESULTS_TYPE, and inspect x_result_type after each call to determine whether validation succeeded. Direct invocation outside the standard Purchasing validation flow should be undertaken with care, since the procedures enforce mandatory business rules rather than performing data correction.