Search Results request_value_id

Overview

CSF_R_REQUEST_VALUES is a transactional table in the CSF (Field Service) product schema of Oracle E-Business Suite, present and valid in both release 12.1.1 and 12.2.2. Its documented purpose is to store the values of the filters associated with scheduled service requests. In functional terms, the table acts as the value store that satisfies filter parameters defined for a given scheduling request: each row captures a single parameter-value pairing tied to a parent scheduling request and to the filter parameter it fulfills. This makes it a supporting detail table within the Field Service scheduling and request-filtering subsystem rather than a master or reference entity.

The ETRM metadata classifies this object heuristically as standalone under its Data Vault mining rules. In practice, however, the table's three foreign keys to CSF_R_FILTER_PARAMS_B, CSF_R_SCHED_REQUESTS, and FND_SECURITY_GROUPS indicate that it behaves as a link/satellite-style detail table attached to those parents. The most accurate modeling suggestion is therefore a satellite or link record keyed on its surrogate primary key, resolving many-to-many context between filter definitions and scheduled requests.

Key Information Stored

The table contains eleven documented columns. The most significant are:

• REQUEST_VALUE_ID — the surrogate primary key, uniquely identifying each filter-value record. It is enforced by the CSF_R_REQUEST_VALUES_PK constraint.
• SCHED_REQUEST_ID — foreign key to CSF_R_SCHED_REQUESTS, identifying the parent scheduling request whose filter context this row belongs to.
• FILTER_PARAM_ID — foreign key to CSF_R_FILTER_PARAMS_B, identifying which filter parameter definition the value is populating.
• PARAM_VALUE — the actual value supplied for the referenced filter parameter; this is the principal business payload of the row.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enforcing multi-org / data-group security partitioning of the record.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the OAF/BC4J framework to detect concurrent updates.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO columns capturing audit lineage and last-touch information.

No unique business-key index beyond the surrogate primary key is documented; the natural business key is the combination of SCHED_REQUEST_ID and FILTER_PARAM_ID.

Common Use Cases and Queries

Typical usage centers on reconstructing the filter criteria applied when a scheduling request was submitted, and on validating that every required filter parameter has a corresponding value. Common reporting queries join the table to its filter parameter parent to resolve the parameter name alongside the stored value:

• Retrieve all filter values for a given request: SELECT REQUEST_VALUE_ID, FILTER_PARAM_ID, PARAM_VALUE FROM CSF.CSF_R_REQUEST_VALUES WHERE SCHED_REQUEST_ID = :p_sched_request_id;
• Resolve parameter names: join FILTER_PARAM_ID to CSF_R_FILTER_PARAMS_B to obtain the parameter's descriptive name.
• Detect missing filter values: outer-join from CSF_R_FILTER_PARAMS_B to this table and filter for NULL PARAM_VALUE rows.
• Audit access: filter by SECURITY_GROUP_ID to respect data-group partitioning in custom reports.

Because the table carries OBJECT_VERSION_NUMBER, care should be taken when updating PARAM_VALUE; the OAF framework expects this value to be incremented to preserve concurrency control.

Related Objects

• CSF_R_SCHED_REQUESTS — parent by SCHED_REQUEST_ID; the primary request context.
• CSF_R_FILTER_PARAMS_B — parent by FILTER_PARAM_ID; defines the filter parameters being valued.
• FND_SECURITY_GROUPS — parent by SECURITY_GROUP_ID; governs data security grouping.
• CSF_R_REQUEST_VALUES_PK — the primary key constraint on REQUEST_VALUE_ID.
• Standard FND WHO audit columns (CREATED_BY et al.) reference FND_USER indirectly.