Search Results confirm_delete_lines




Overview

PER_LETTER_REQUESTS_PKG is an Oracle EBS PL/SQL package owned by the APPS schema that supports the Oracle HRMS letter request feature. This feature governs the generation of standard letters and correspondence for employees, applicants, and other persons tracked within Oracle Human Resources. A "letter request" represents a controlled request to produce a letter of a given letter type for a defined business group, optionally linked to a vacancy or an event. The package encapsulates the validation, insertion, locking, updating, and deletion logic for these letter request records, providing a reusable server-side layer so that the corresponding Oracle Forms user interface and any concurrent processing do not manipulate the underlying tables directly.

The package header bears the source control marker peltr01t.pkh 115.1 2003/01/15 and is declared AUTHID CURRENT_USER, meaning that the executing user's privileges are used at runtime rather than the definer's. Within the ETRM classification the object is catalogued as an OTHER API, and it is referenced by no other documented packages, so it functions as a leaf-level utility package rather than a shared library.

Key Procedures and Functions

The package exposes eight documented procedures, all declared in the package specification excerpt.

  • CHECK_REQUEST_UNIQUE — Validates that a letter request defined by its letter request identifier, business group, vacancy, event, letter type, date-from, and request status does not duplicate an existing request, enforcing uniqueness before a row is created or a status is changed.
  • CHECK_REQUEST_LINES — Verifies the letter request lines associated with a given letter request identifier, typically to confirm that line-level data exists or is consistent before further processing.
  • CONFIRM_DELETE_LINES — Determines whether request lines exist for a letter request and returns this fact through an output BOOLEAN, allowing the calling code to confirm or block deletion of the parent request.
  • INSERT_ROW — Inserts a new letter request record, returning the generated rowid and letter request identifier along with the business group, letter type, date-from, status, automatic or manual indicator, vacancy, and event values.
  • LOCK_ROW — Acquires a row-level lock on an existing letter request so that concurrent form sessions cannot modify the same record simultaneously.
  • UPDATE_ROW — Applies modified attribute values to an existing letter request identified by a rowid.
  • DELETE_ROW — Removes a letter request record identified by its rowid and letter request identifier.
  • CONCURRENT_PROGRAM_CALL — Submits a concurrent program from within the package, accepting application, program, and two argument values and returning the generated concurrent request identifier.

Tables Accessed

The package operates against the HRMS letter request tables through APPS synonyms. PER_LETTER_REQUESTS holds the header-level letter request records validated and maintained by the check, insert, lock, update, and delete procedures. PER_LETTER_REQUESTS_S is the corresponding translated or secondary table consulted in the same operations, particularly where descriptions require language-specific values. PER_LETTER_REQUEST_LINES stores the individual lines belonging to a request and is consulted by CHECK_REQUEST_LINES and CONFIRM_DELETE_LINES, and its existence directly affects whether a request may be deleted.

Usage Notes

PER_LETTER_REQUESTS_PKG is invoked primarily from the Oracle Forms user interface for letter requests, where triggers call the check routines before commit, use LOCK_ROW to coordinate multi-user editing, and rely on INSERT_ROW, UPDATE_ROW, and DELETE_ROW for DML. CONFIRM_DELETE_LINES is called when a user attempts to remove a request that may still have lines. CONCURRENT_PROGRAM_CALL allows the form to launch the letter generation or related concurrent process and capture its request identifier without leaving the application. Because the package is defined with AUTHID CURRENT_USER, any custom code invoking it must run under a user with appropriate privileges on the underlying PER tables. The absence of documented dependencies on this package indicates that it is not intended as a public integration point; customizations should prefer documented HRMS business APIs and treat direct calls to this package as a last resort.