Search Results create_requirement_line




Overview
Explore in AI Chat

Overview

CSFW_REQ_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite. The package encapsulates the create and delete operations for requirement headers and requirement lines used by the Customer Support / Field Service (CSF) requirement model. Requirement records represent demand for service parts or materials that must be fulfilled at a designated location, optionally tied to a service task. The package provides a programmatic, transaction-safe interface so that callers — Oracle Forms, concurrent programs, or custom code — do not need to manipulate the underlying requirement tables directly. The header comment indicates the source revision 120.1 dated 2006, aligning with the 12.1.1 codebase, and the same API surface is documented for 12.2.2. As a PUB package, its signatures are considered stable and supported for external invocation.

Key Procedures and Functions

  • CREATE_REQUIREMENT_HEADER — Creates a requirement header record. It accepts a task identifier and a location identifier, together with a standard descriptive flexfield attribute set (ATTRIBUTE1 through ATTRIBUTE15 and ATTRIBUTE_CATEGORY). It returns the generated header identifier along with error identifier and error message output parameters, allowing the caller to detect and handle failures without raising unhandled exceptions.
  • DELETE_REQUIREMENT_HEADER — Removes a requirement header identified by its header identifier. It returns error identifier and error message output parameters, enabling conditional error handling by the caller.
  • CREATE_REQUIREMENT_LINE — Creates a requirement line associated with an existing header. It accepts the header identifier, an inventory item identifier, a unit of measure, a quantity, a revision, and the same descriptive flexfield attribute set used at the header level. It returns an error identifier, error message, and the generated line identifier, giving the caller the key of the newly created row.
  • DELETE_REQUIREMENT_LINE — Removes a requirement line identified by its line identifier, returning error identifier and error message output parameters for caller-driven error handling.

All four procedures expose a consistent error-reporting convention rather than relying on propagated SQL exceptions. No return values are defined; every API is a procedure.

Tables Accessed

  • CSP_REQUIREMENT_HEADERS_S1 — The sequence-backed source for requirement header identifiers, referenced when CREATE_REQUIREMENT_HEADER generates a new header key.
  • CSP_REQUIREMENT_LINES — The base table holding requirement line rows; written by CREATE_REQUIREMENT_LINE and cleaned by DELETE_REQUIREMENT_LINE.
  • CSP_REQUIREMENT_LINES_S1 — The sequence providing line identifiers returned to the caller on line creation.
  • DUAL — Used for single-row scalar evaluations such as sequence next-value retrieval.

The package therefore writes into the CSP requirement header and line tables and reads sequence values to populate primary keys. No other application tables are documented as referenced.

Usage Notes

CSFW_REQ_PUB is the supported entry point whenever requirement headers or lines must be created or removed programmatically. Typical callers include Oracle Forms in the Customer Support and Field Service modules, concurrent programs performing bulk requirement maintenance, and custom PL/SQL that integrates external demand into the EBS requirement model. The procedure set does not document an update operation, so modifications to existing requirement headers or lines are expected to be handled through the relevant Forms or other APIs rather than this package. Because the API classification is PUB, signatures should be treated as stable in 12.1.1 and 12.2.2; nevertheless, callers should always inspect the returned error identifier and error message and commit or roll back their transaction accordingly. Note that the package is referenced by zero other packages according to the documented metadata, so it functions as a leaf-level API invoked directly by forms and custom code. The descriptive flexfield parameters should be populated only when the underlying requirement entity has a matching attribute configuration, and unused attributes should be passed as NULL.