Search Results ocm_credit_request_update_pub




Overview
Explore in AI Chat

Overview

OCM_CREDIT_REQUEST_UPDATE_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite. It belongs to the Credit Management (OCM) module, which governs customer creditworthiness evaluation, credit request submission, and credit limit administration. The package provides the packaged interface through which credit request records are created, modified, retrieved, and transitioned between approval states. As a PUB (public) API, it is intended for invocation by external callers — other application modules, forms, and custom integrations — rather than being restricted to internal use. It abstracts the underlying data manipulation logic against the credit management base tables, ensuring that validation, attribute defaulting, and status handling remain consistent regardless of the calling context. Because credit decisions in Order Management, Accounts Receivable, and Leasing depend on accurate, current credit request data, this package acts as a controlled gateway to those records. Its validity status in both 12.1.1 and 12.2.2 confirms it is a supported, shipped component rather than a deprecated or stub object.

Key Procedures and Functions

The documented interface exposes three entry points:

  • UPDATE_CREDIT_REQUEST — The primary maintenance routine. It applies changes to an existing credit request record, accepting the identifying keys and the attributes to be modified. It is the standard mechanism for amending credit request details such as requested limits, guarantor information, or descriptive data prior to or during the approval cycle.
  • GET_CREDIT_REQUEST_REC — A retrieval routine that returns the current contents of a credit request record. It is used by callers that need to read the persisted state of a request before deciding whether to update it, display it, or pass it onward to downstream processing.
  • UPDATE_CREDIT_REQUEST_STATUS — A focused routine that changes only the workflow or approval status of a credit request. Separating status transitions from general attribute updates allows approval engines and workflow activities to advance a request without risking unintended modification of its business data.

Consistent with Oracle's API conventions and the FND_API dependency shown in the metadata, these routines are expected to follow the standard API return-status pattern (success, expected error, unexpected error) and to raise or return errors rather than silently failing.

Tables Accessed

The package operates against the following tables, referenced through APPS synonyms:

  • AR_CMGT_CREDIT_REQUESTS — The core credit request entity. This is the principal read/write target for all three procedures, holding the request header and its credit-related attributes.
  • AR_CMGT_GUARANTOR_DATA — Stores guarantor records associated with a credit request. It is accessed when guarantor details form part of the update or retrieval payload.
  • FND_USER — The EBS application user repository. It supports identification of the user performing or owning the transaction, typically for created-by/updated-by auditing context.
  • PER_ALL_PEOPLE_F — The HR people table, used to resolve person-level details such as the requester or contact associated with a credit request.
  • PLITBLM — The PL/SQL integer table type used for passing arrays of identifiers or statuses into and out of the API.

Usage Notes

OCM_CREDIT_REQUEST_UPDATE_PUB is referenced by three other packages — AR_CMGT_CREDIT_REQUEST_API, LNS_PARTICIPANTS_PUB, and OKL_LEASE_APP_PVT — indicating that credit request maintenance is consumed by Accounts Receivable credit management, Leasing participants processing, and lease application workflows respectively. The self-reference in the dependency list reflects internal calls between the package specification and body. Typical invocation points include Credit Management setup and transaction forms, workflow-driven status advancement during credit approval, and custom PL/SQL integrations that must register or amend credit requests programmatically. Because the package depends on FND_API, callers should initialize the standard API context and inspect the returned status before committing. Direct DML against the underlying AR_CMGT tables should be avoided in favour of this API so that validation and audit behaviour remain intact.