Search Results delete_requirement_lines




Overview
Explore in AI Chat

Overview

CSP_REQUIREMENT_LINES_PVT is a private PL/SQL package owned by APPS that supports the Oracle E-Business Suite supply chain planning and order management data model, specifically the maintenance of requirement line records associated with demand and supply planning activities. A requirement line represents a single item-demand or item-supply entry, including the item, unit of measure, required quantity, ship-complete flag, likelihood, revision, sourcing organization and subinventory, ordered quantity, order line, reservation, and order-by date. The package encapsulates the create, update, and delete operations that keep these rows consistent with the underlying base table.

The package is declared as AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking session rather than the definer, and thus relies on the caller's access to the referenced tables and synonyms. It follows the standard EBS private-API convention, exposing a strongly typed record structure (Requirement_Line_Rec_Type) whose attributes map one-to-one to the columns of the requirement lines entity, together with a default fetch size constant (G_DEFAULT_NUM_REC_FETCH, set to 30) used in bulk retrieval operations. Attribute columns 1 through 15 are carried in the record for descriptive flexibility, and the last-update audit columns follow the standard EBS WHO conventions.

Key Procedures and Functions

  • CREATE_REQUIREMENT_LINES — Inserts new requirement line rows for a requirement header. It accepts the requirement line record type, derives audit columns, and persists a new line with its item, quantity, sourcing, and scheduling information.
  • UPDATE_REQUIREMENT_LINES — Modifies existing requirement line rows, including changes to quantities, dates, likelihood, revision, sourcing, or descriptive attributes. The last-updated audit fields are refreshed on each successful update.
  • DELETE_REQUIREMENT_LINES — Removes requirement line rows identified by their requirement line identifier, supporting the cancellation or completion of demand and supply entries. This is the procedure most directly relevant to the user's search for "delete_requirement_lines".

Note that this is a PVT (private) API. It is not intended as a public extension point, and Oracle does not warrant its signature or behavior across releases or patches. Parameter lists are deliberately not reproduced here; callers should reference the installed package specification for the authoritative interface.

Tables Accessed

The documented table reference for this package is the APPS synonym PLITBLM, a materialized view used within the Advanced Planning and Supply Chain (CSP) schema for retrieved planning and item demand information. Through this synonym, the package reads the planning data required to validate, construct, and reconcile requirement line records, and it writes requirement line changes back to the appropriate base tables underlying the requirement lines entity. The record definition exposes the full column set, including REQUIREMENT_LINE_ID, REQUIREMENT_HEADER_ID, INVENTORY_ITEM_ID, UOM_CODE, REQUIRED_QUANTITY, ORDERED_QUANTITY, ORDER_LINE_ID, and RESERVATION_ID, confirming that the package operates on both the header-line relationship and inventory, order, and reservation cross-references.

Usage Notes

CSP_REQUIREMENT_LINES_PVT is invoked internally by the supply chain planning and order management application modules rather than by end users directly. It is typically called from Oracle Forms-based maintenance screens and from concurrent programs that process planning requirements in batch. The ETRM metadata records that the package is referenced by eight other packages, indicating extensive internal reuse across the CSP product family. In Oracle EBS 12.1.1 and 12.2.2, its behavior is consistent; the source header (cspvrqls.pls 115.8) reflects a mature, stable code line. Oracle support guidance for defects in planning requirement data is to raise a service request rather than to modify or call the private API from custom code, because the interface is unsupported and may change during patching. Where custom extensions are unavoidable, developers should prefer the corresponding public APIs or wrap calls defensively, re-validating the specification after every application of an EBS patch or upgrade.