Search Results lock_qa_process

Overview

OKC_QA_CHECK_LIST_PUB is the public application programming interface for the Quality Assurance check list functionality within Oracle Contracts (OKC) in Oracle E-Business Suite 12.1.1 and 12.2.2. The package belongs to the APPS schema and is classified as a public (PUB) API, meaning it is designed for external invocation by forms, concurrent programs, workflows, and custom extensions. Its role is to expose a stable, supported interface over the internal quality assurance validation logic implemented in the private packages of the OKC module.

In Oracle Contracts, quality assurance check lists represent structured sets of questions or verification criteria applied to contract terms, deliverables, or processes. The public package provides the entry point through which callers create, modify, lock, validate, and delete these check lists and their associated definitions. It conforms to the Oracle Application Object Library API standards, most notably the FND_API error-handling and message-stack conventions, and it delegates the substantive business rules to the underlying private packages OKC_QA_CHECK_LIST_PVT, OKC_QCL_PVT, OKC_QLP_PVT, and OKC_QPP_PVT, as well as the general OKC_API utility package.

Key Procedures and Functions

The package exposes thirty-one documented procedures and functions, organized primarily as CRUD-style operations over three principal entities: check lists, quality assurance processes, and quality assurance parameters.

• CREATE_QA_CHECK_LIST — creates a new quality assurance check list definition, accepting header and attribute information and returning the generated identifier.
• UPDATE_QA_CHECK_LIST — modifies an existing check list, applying the supplied attribute changes through the API layer.
• DELETE_QA_CHECK_LIST — removes a check list definition, subject to the module's referential and status rules.
• LOCK_QA_CHECK_LIST — places a lock on a check list record to prevent concurrent modification during an update transaction.
• VALIDATE_QA_CHECK_LIST — performs validation of check list data and returns errors through the standard FND_API message stack.
• CREATE_QA_PROCESS, UPDATE_QA_PROCESS, DELETE_QA_PROCESS, LOCK_QA_PROCESS, VALIDATE_QA_PROCESS — the equivalent lifecycle operations for quality assurance processes associated with check lists.
• CREATE_QA_PARM, UPDATE_QA_PARM, DELETE_QA_PARM, LOCK_QA_PARM, VALIDATE_QA_PARM — the lifecycle operations for quality assurance parameters used to configure check list and process behavior.
• ADD_LANGUAGE — creates translated (MLS) rows for the check list entities, supporting multilingual deployment.

The remaining documented procedures provide supporting internal API operations consistent with this pattern. Parameter lists are not reproduced here; callers should obtain the exact signatures from the ETRM-published package specification for the target release.

Tables Accessed

The documented table reference for this package is PLITBLM, an APPS synonym over an underlying table used by the OKC quality assurance data model. In practice, the package performs its DML through the OKC_QA_CHECK_LIST_PVT and related private packages, which own the direct reads and writes against the OKC check list, process, and parameter tables (including their _TL translation tables populated by ADD_LANGUAGE). This layering isolates the public API from physical table structures and ensures that validation, defaulting, and auditing logic is applied consistently.

Usage Notes

OKC_QA_CHECK_LIST_PUB is normally invoked indirectly. Oracle Forms in the Contracts suite and the associated concurrent programs call the public API rather than manipulating tables directly, and any custom code extending quality assurance functionality should do likewise. Callers must adhere to the standard API contract: initialize the FND_API global variables, supply a meaningful caller identifier, check the returned x_return_status, and inspect the FND_MSG_PUB message stack for errors before committing. The LOCK procedures should be called before UPDATE or DELETE to serialize concurrent access, and transactions should be committed only after all constituent API calls for a logical business event have completed successfully. Because the package is referenced by no other documented APPS packages, it functions as a top-level integration point rather than an internal dependency, reinforcing its intended use as the supported entry point for quality assurance check list maintenance in Oracle Contracts.