Search Results delete_class

Overview

OKC_CLASS_PUB is the public (PUB-classified) PL/SQL API package for the Oracle Contracts (OKC) module, responsible for managing contract class definitions and their associated metadata within Oracle E-Business Suite 12.1.1 and 12.2.2. Contract classes are the foundational categorization construct in Oracle Contracts: every contract, template, and contract-related document is created against a class that governs its behavior, its numbering scheme, its applicable clauses, and its rules. OKC_CLASS_PUB exposes the supported, upgrade-safe interface through which external callers — primarily the Contracts forms, concurrent programs, and customer extensions — create, modify, lock, and remove these class definitions. The package is declared AUTHID CURRENT_USER and is owned by APPS, with the header comment indicating it originated from the OKCPCLSS.pls source file. It acts as a thin public wrapper over the internal private implementation package OKC_CLASS_PVT, to which it delegates the actual business logic; the clsv_rec_type and clsv_tbl_type subtypes visible in the specification are re-exported directly from that private package, confirming the layered design.

Key Procedures and Functions

• ADD_LANGUAGE — Transliteration utility that propagates the package's seed data and messages into additional installed languages. It is normally invoked by the standard EBS language installation process rather than by application code.
• INSERT_CLASS — Creates new contract class definitions. Two overloads are provided: one accepting a single record and one accepting a table (collection) of records, enabling bulk creation.
• UPDATE_CLASS — Modifies existing contract class definitions, again offered in both single-record and table-based overloads.
• LOCK_CLASS — Acquires a pessimistic lock on one or more class records so that concurrent sessions cannot modify the same definition simultaneously. Provided in record and table overloads.
• DELETE_CLASS — Removes a contract class definition. This is the procedure most relevant to the "delete_class" search term, and it is the standard supported route for deleting class metadata rather than issuing direct DML against the underlying tables.
• VALIDATE_CLASS — Performs validation of class data prior to persistence, returning the standard x_return_status, x_msg_count, and x_msg_data messaging outputs.

Eleven documented entry points exist in total when the overloaded variants are counted. Every procedure follows the Oracle API conventions: p_api_version for version control, p_init_msg_list defaulting to OKC_API.G_FALSE, and the standard three-output error-handling triad.

Tables Accessed

The ETRM metadata for this object does not enumerate specific base tables, as the package delegates all SQL to OKC_CLASS_PVT. In practice, the private layer operates against the OKC core class tables — principally OKC_CLASSES (the class header definition), OKC_CLASS_EVENTS, OKC_CLASS_TEMPLATES, and the class-to-clause mapping tables such as OKC_CLASS_CLAUSES — together with OKC_CLASSES_TL for the language-specific (translatable) columns maintained by ADD_LANGUAGE. Contract classes carry a large number of descriptive and behavioral attributes, including document type, numbering and versioning rules, approval and signing behavior, and default party roles, so writes performed through this API fan out across the class schema. Because access is mediated by the private package, customers should not assume a fixed one-table mapping; the definitive list of affected objects must be derived from OKC_CLASS_PVT.

Usage Notes

OKC_CLASS_PUB is the supported integration point for contract class maintenance. It is invoked from the Contracts class setup forms, from concurrent programs that load or migrate class definitions, and from custom PL/SQL extensions that need to create or retire classes programmatically. The referenced-by count is zero, meaning no other shipped package in the ETRM inventory depends on it directly — it is a terminal, external-facing API. Callers must supply a valid p_api_version, pass p_init_msg_list as appropriate, and always inspect x_return_status for the value FND_API.G_RET_STS_SUCCESS before proceeding, using x_msg_count and x_msg_data or FND_MSG_PUB to retrieve any errors. A typical delete_class invocation should be preceded by an explicit LOCK_CLASS call when concurrent maintenance is possible. Direct DML against the underlying class tables is strongly discouraged, as it bypasses validation, locking, and any dependent processing performed by the private layer.