Search Results check_delete

Overview

APPS.OTA_AR_DELETE is a lightweight PL/SQL package belonging to the Oracle Training Administration (OTA) module of Oracle E-Business Suite. Its declared purpose is to provide a referential-integrity guard used when Oracle Receivables objects — specifically customers, contacts, and addresses — are considered for deletion. Because OTA stores training and event bookings against AR customer and contact records, deleting an AR entity that is still referenced by OTA business objects would leave orphaned rows in the booking, event-association, delegate, and finance tables. The package therefore exposes a single validation entry point that callers invoke before permitting a delete, allowing the OTA module to raise an application error rather than allowing silent data corruption.

The package is declared as AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, and its callable interface is intentionally narrow — a single procedure. This design reflects its role as a pre-delete validation hook rather than a transactional API. The source header indicates the package dates from the 11i porting era (script otdar01t.pkh), confirming that the interface has been stable across the 12.1.1 and 12.2.2 releases and remains in use on the ETRM 12.2.2 file system.

Key Procedures and Functions

The ETRM metadata documents exactly one callable program unit within this package:

• CHECK_DELETE — Validates whether an AR customer, contact, or address is safe to delete from an OTA perspective. Its parameter list accepts a customer identifier, a contact identifier, and an address identifier, each with a default of NULL, allowing the caller to check one or more of those dimensions in a single call. When the referenced OTA records exist, the procedure is expected to signal a validation failure; when they do not, it returns normally, permitting the AR deletion to proceed.

No other procedures or functions are documented for this package in the ETRM repository, and the package specification excerpt terminates immediately after CHECK_DELETE. There are no public helper functions, no package-level constants exposed, and no overloaded variants.

Tables Accessed

ETRM records four OTA tables referenced through APPS synonyms. These define the scope of the referential check:

• OTA_BOOKING_DEALS — Booking-level deal records that carry the customer and contact context of a training enrollment.
• OTA_DELEGATE_BOOKINGS — Delegate-level booking rows, which link individual attendees to bookings and therefore to customer and address data.
• OTA_EVENT_ASSOCIATIONS — Associations between events and external entities used to determine whether an AR record participates in an event.
• OTA_FINANCE_HEADERS — Finance header rows generated from training activity, which retain the customer reference needed for billing and reconciliation.

The procedure reads these tables to establish whether any active training transaction depends on the AR identifiers passed in. Because the package is a validation utility, access is predominantly read-only; the documented metadata does not indicate any insert, update, or delete activity.

Usage Notes

CHECK_DELETE is designed to be called as a precondition check rather than as part of a normal transactional flow. Typical invocation points include:

• Oracle Forms personalizations or custom menu logic in Oracle Receivables customer and address maintenance screens, where the procedure is called before the standard delete executes.
• Custom PL/SQL or concurrent programs that purge or consolidate customer data and need to protect OTA bookings from orphaned references.
• Interfaces and data-conversion scripts that load AR customer data and must verify whether incoming changes conflict with existing OTA records.

ETRM reports zero packages referencing OTA_AR_DELETE, which indicates that there are no standard OTA package-to-package dependencies on this validation routine. Its consumers are therefore external to the OTA PL/SQL layer — principally forms, custom code, and integration scripts. Because the package is AUTHID CURRENT_USER, the invoking session must have direct select privileges on the OTA tables for the check to succeed; calls made from a session without such grants will fail with a privilege error rather than returning a validation result. Implementers extending the check should treat the documented interface as fixed, since altering the signature of CHECK_DELETE could break the AR-side delete logic that relies on it.