Search Results get_change_request_group_id




Overview
Explore in AI Chat

Overview

CLN_PO_CHANGE_RESPONSE_PKG is an APPS-owned PL/SQL package within the Oracle E-Business Suite Procurement family, belonging to the CLN (Supply Chain / Procurement Collaboration) module. Its business purpose is to process supplier responses to purchase order change requests. When a buyer modifies an existing purchase order and that change is transmitted to the supplier through the collaboration framework, the supplier can accept, reject, or propose alternate terms. This package translates those inbound responses into the appropriate EBS transactional updates and collections-related bookkeeping.

The package is classified under the ETRM documentation as an OTHER API type, meaning it is an internal supporting package rather than a formally published public API. It nonetheless forms a critical part of the change management and supplier acknowledgement loop, ensuring that acknowledgement codes, change request groupings, and collection history records remain consistent with the supplier's declared intent.

Key Procedures and Functions

The ETRM metadata documents five procedures and functions within this package. Parameter lists are intentionally not reproduced here; the descriptions below reflect documented purpose only.

  • SET_ATTRIBUTES_OF_WORKFLOW — Populates workflow-related attributes used when the change response is routed through Oracle Workflow. It prepares the context values required for subsequent workflow notifications and processing steps.
  • GET_CHANGE_REQUEST_GROUP_ID — A function that retrieves the change request group identifier associated with a given response. This grouping ties multiple line-level changes into a single logical change request for acknowledgement and audit purposes.
  • SET_REQUEST_GRP_ID_AND_COLL_ID — Assigns or stores the request group identifier and the collection identifier onto the working record, linking the response to the appropriate collaboration grouping.
  • CALC_ACKCODE_CONDITIONALLY — Conditionally derives the acknowledgement code for the change response. The acknowledgement code reflects the supplier's disposition of the change and is only recalculated where the business rules require it.
  • GET_ADDITIONAL_DATA — A function that returns supplementary data required during response processing, such as descriptive or reference values needed downstream by forms or workflow.

Tables Accessed

The package operates against both transactional PO tables and CLN collection history tables, accessed through APPS synonyms.

  • PO_HEADERS_ALL and PO_RELEASES_ALL — Read to retrieve the affected purchase order header and release context for the change request.
  • PO_CHANGE_REQUESTS — The central repository of PO change requests; the package reads and updates rows here to record the supplier response.
  • CLN_COLL_HIST_HDR and CLN_COLL_HIST_DTL — Collection history header and detail tables that record the collaboration exchange, including the transmitted change and the received response.
  • CLN_GENERIC_S — The CLN generic sequence, used to obtain surrogate keys for newly created collection history or response records.
  • DUAL — Used for single-row PL/SQL computations and sequence or constant retrieval.

Usage Notes

CLN_PO_CHANGE_RESPONSE_PKG is not intended for direct invocation by end users. It is referenced by the CLN_PO_CHANGE_RESPONSE_LINE_V view and by exactly one other package, and it is normally called from within the CLN collaboration flow — typically from supplier-facing forms or from concurrent programs that ingest supplier responses. Because the ETRM metadata records only five documented entry points and lists no public API classification, customizations should not call these procedures directly unless the dependency chain is fully understood. In Oracle EBS 12.1.1 and 12.2.2 the package's validity and dependency structure are identical; the primary difference to observe is the underlying table and view definitions, which follow the standard 12.1.1 versus 12.2.x naming and partitioning conventions. Extensions should be layered through supported APIs or views rather than by modifying this package.