Search Results okl_setuppqualitys_pvt




Overview

OKL_SETUPPQUALITYS_PVT is a private PL/SQL package in the Oracle E-Business Suite Lease Management (OKL) module, part of Oracle's Enterprise Contract and Transaction Management (ETRM) suite. It provides the internal data-access and validation logic that supports the public package OKL_PDT_QUALITYS_PUB, which manages product quality specifications in the lease product definition (PDT) hierarchy. Quality specifications allow lessors to associate measurable conditions—such as creditworthiness, residual value thresholds, or item condition criteria—with a lease product template or quote, ensuring that transactions generated from that template comply with pre-defined constraining rules. The package is declared AUTHID CURRENT_USER and marked PRIVATE, meaning it is not a supported integration point; rather it is the implementation layer invoked by the corresponding public API, thereby enforcing a controlled separation between the caller-facing contract and the underlying DML operations.

Key Procedures and Functions

The package declares three procedures, all of which operate on the public record and table types defined in OKL_PDT_QUALITYS_PUB (aliased internally as PQYV_REC_TYPE and PQYV_TBL_TYPE):

  • GET_REC — Retrieves a single quality specification record. It accepts an inbound record structure and returns the populated record along with a boolean flag indicating whether any data was found and a return status code. This is the query path used by the public API when reading a quality specification for display or processing.
  • INSERT_PQUALITYS — Performs the creation of a new product quality specification row. It follows the standard EBS API calling convention, accepting API version and message-list initialization parameters and returning return status, message count, and message data. The inbound record is validated and persisted, and the resulting record is returned to the caller.
  • UPDATE_PQUALITYS — Modifies an existing quality specification record, using the same parameter conventions as INSERT_PQUALITYS and returning the updated record to the caller.

All three procedures participate in the shared message-stack error-handling model defined by OKL_API, using the package-level error tokens described below.

Tables Accessed

The package operates against the product quality specification base table exposed to APPS, referenced through the PQYV_REC_TYPE record structure defined in OKL_PDT_QUALITYS_PUB. The GET_REC procedure reads this table via a unique-key lookup, while INSERT_PQUALITYS and UPDATE_PQUALITYS write to it. Although the package works with a typed record rather than explicit table references in the header, the underlying DML targets the OKL quality specification table and its associated date-effective columns. The date columns are the reason the package defines the G_DATES_MISMATCH, G_START_DATE, G_PAST_RECORDS, and G_INVALID_DATES error tokens: on insert and update, the procedures validate end-date/start-date consistency and reject records whose effective range conflicts with already-stored past records, returning the corresponding message token for translation by the public API.

Usage Notes

Because OKL_SETUPPQUALITYS_PVT is classified as PRIVATE, it should never be called directly from custom code, concurrent programs, or forms. The supported entry point is the public package OKL_PDT_QUALITYS_PUB, which internally delegates to these procedures; two other packages reference it within the ETRM stack. Typical invocation flows originate from the Lease Management product-definition setup screens, where a user creates or maintains quality specifications, and from any programmatic creation of lease products/quotes that trigger quality validation. The constant G_DATES_MISMATCH that appears in a search of this object corresponds to the error token 'OKL_DATES_MISMATCH' (line 8), which is raised when supplied start and end dates for a quality specification conflict with each other; this message is surfaced through the standard EBS message dictionary. All calls return messages via the OKL API message stack, so callers should check X_RETURN_STATUS and then drain X_MSG_COUNT messages using the standard FND_MSG_PUB.GET loop.