Search Results csf_r_sched_request_pk

Overview

CSF_R_SCHED_REQUESTS is a Field Service (CSF) transactional table that stores scheduler requests in Oracle E-Business Suite 12.1.1 and 12.2.2. Each row represents a discrete scheduling request processed by the Field Service Scheduler, capturing the parameters, planning options, and outcome of an automated or user-initiated scheduling run. The table sits at the center of the scheduling engine, holding request-level attributes that drive resource assignment, spare part planning, and route optimization.

Based on the foreign key structure mined from the metadata, the table exhibits a hub-leaning Data Vault classification. This is a modeling suggestion: SCHED_REQUEST_ID functions as a durable business key around which satellite attributes (plan mode, spares likelihood, customer confirmation) and link relationships (request tasks, message tokens, request filters) are organized. The table is owned by the CSF schema and is marked VALID in the documented 12.2.2 physical schema, comprising 32 columns.

Key Information Stored

The surrogate primary key is SCHED_REQUEST_ID, enforced by CSF_R_SCHED_REQUEST_PK and reinforced by the unique index CSF_R_SCHED_REQUESTS_U1, which also serves as the primary business-key candidate. The most significant columns include:

• SCHED_REQUEST_ID — surrogate primary key uniquely identifying each scheduler request.
• SCHED_REQUEST_NAME — user-facing name or label for the request.
• CONCURRENT_REQUEST_ID — links the scheduler request to the concurrent manager run that produced it.
• RESULT_FLAG — outcome status of the scheduling request.
• PLANMODE — planning mode governing how the scheduler evaluates the request.
• PARENT_REQUEST_ID — self-referencing pointer for hierarchical or dependent requests.
• SPARES_LIKELIHOOD / SPARES_LIKLIHOOD — likelihood that spare parts are required (both spellings appear in the documented column list).
• SPARES_SOURCE / SPARES_MANDATORY — origin and enforcement flag for spare part requirements.
• EXTENDED_EFFORT — planned effort duration for the request.
• ROUTE_BASED_FLAG — indicates whether routing logic applies.
• CHANGED_OPTION_START / CHANGED_OPTION_END / CHANGED_PLANNED_START / CHANGED_PLANNED_END — original versus revised scheduling windows.
• CUSTOMER_CONF_RCVD — indicates whether customer confirmation was received.
• TARGET_STATUS_ID — desired task status targeted by the request.
• SECURITY_GROUP_ID — references FND_SECURITY_GROUPS for multi-org security.
• OBJECT_VERSION_NUMBER — optimistic locking column.

Standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and PROGRAM_* columns provide audit and concurrent program context.

Common Use Cases and Queries

Typical uses include monitoring concurrent scheduling runs, diagnosing failed or partial scheduling results, and reporting on request throughput and spares demand.

• List recent requests with their outcome and concurrent request linkage:

  SELECT SCHED_REQUEST_ID, SCHED_REQUEST_NAME, RESULT_FLAG,
         CONCURRENT_REQUEST_ID, LAST_UPDATE_DATE
  FROM   CSF.CSF_R_SCHED_REQUESTS
  WHERE  LAST_UPDATE_DATE >= SYSDATE - 7
  ORDER BY LAST_UPDATE_DATE DESC;

• Trace tasks generated by a specific request by joining to CSF_R_REQUEST_TASKS on SCHED_REQUEST_ID.
• Identify requests requiring spares:

  SELECT SCHED_REQUEST_ID, SCHED_REQUEST_NAME, SPARES_LIKELIHOOD
  FROM   CSF.CSF_R_SCHED_REQUESTS
  WHERE  SPARES_MANDATORY = 'Y';

• Analyze revised versus original scheduling windows using the CHANGED_* columns for slip reporting.
• Correlate with FND_CONCURRENT_REQUESTS via CONCURRENT_REQUEST_ID to audit scheduler job history.

Related Objects

• CSF_R_REQUEST_TASKS — child table; joins on SCHED_REQUEST_ID (FK).
• CSF_R_REQUEST_FILTERS — child table filtering request scope; joins on SCHED_REQUEST_ID.
• CSF_R_REQUEST_VALUES — child table holding request parameter values; joins on SCHED_REQUEST_ID.
• CSF_R_MESSAGE_TOKENS — stores scheduler messages; joins on MESSAGE_ID.
• FND_SECURITY_GROUPS — parent reference through SECURITY_GROUP_ID for security group scoping.
• FND_CONCURRENT_REQUESTS — logical join via CONCURRENT_REQUEST_ID for concurrent program diagnostics.
• FND_CONCURRENT_PROGRAMS — joined via PROGRAM_APPLICATION_ID and PROGRAM_ID for program identification.