Search Results csd_sc_work_entities_u1




Overview

CSD.CSD_SC_WORK_ENTITIES is a transactional table in the Oracle E-Business Suite 12.1.1 and 12.2.2 environments, residing in the CSD (Service) schema. As documented in the ETRM metadata, the table stores service code work entities, where each work entity defines the requirements for a repair to be performed. This positions the table as a reference-and-instance store that links a service code to specific work entity definitions used during depot repair, field service, and service order processing.

The object is classified as VALID and is registered under FND Design Data as CSD.CSD_SC_WORK_ENTITIES, indicating it is a recognized application-owned object that participates in the EBS data dictionary and standard audit conventions. The heuristic Data Vault classification derived from the foreign key structure is standalone. In Data Vault modeling terms, this suggests the table behaves primarily as a hub or reference table rather than a link table, since it carries a single outbound foreign key to CSD_SERVICE_CODES_B rather than multiple upstream relationships. Modelers should treat this as a suggestion only; the presence of repeatable WORK_ENTITY_ID1, WORK_ENTITY_ID2, and WORK_ENTITY_ID3 columns indicates a multi-valued attribute pattern that could alternatively be decomposed into a satellite.

Key Information Stored

The table contains 28 documented columns. The most operationally significant are listed below.

The distinction between the surrogate key and business key is important: SC_WORK_ENTITY_ID serves purely as a system-generated identifier, whereas SERVICE_CODE_ID combined with WORK_ENTITY_TYPE_CODE functions as the practical business lookup path, supported by the CSD_SC_WORK_ENTITIES_N1 index. No separate unique business-key index is documented beyond CSD_SC_WORK_ENTITIES_U1.

Common Use Cases and Queries

Typical usage centers on resolving which work entities apply to a given service code for repair estimation, work order generation, and reporting.

  • Retrieve all work entities for a service code: SELECT SC_WORK_ENTITY_ID, WORK_ENTITY_TYPE_CODE FROM CSD.CSD_SC_WORK_ENTITIES WHERE SERVICE_CODE_ID = :p_service_code_id;
  • Reverse lookup by primary key: SELECT * FROM CSD.CSD_SC_WORK_ENTITIES WHERE SC_WORK_ENTITY_ID = :p_id;
  • Filter by type within a service code using the N1 index: SELECT * FROM CSD.CSD_SC_WORK_ENTITIES WHERE SERVICE_CODE_ID = :p_id AND WORK_ENTITY_TYPE_CODE = :p_type;
  • Join to the parent service code table for descriptive reporting: SELECT w.SC_WORK_ENTITY_ID, s.SERVICE_CODE FROM CSD.CSD_SC_WORK_ENTITIES w, CSD.CSD_SERVICE_CODES_B s WHERE w.SERVICE_CODE_ID = s.SERVICE_CODE_ID;
  • Extract DFF data for extract/load programs by querying ATTRIBUTE_CATEGORY and the ATTRIBUTE1..15 segments.

Related Objects

  • CSD.CSD_SERVICE_CODES_B — referenced via SERVICE_CODE_ID; the immediate parent entity providing service code definitions.
  • CSD.CSD_SERVICE_CODES_TL — translation table commonly joined for language-specific service code descriptions.
  • CSD.CSD_REPAIR_ORDERS — repair order processing consumes work entity definitions.
  • CSD.CSD_REPAIR_LINES — line-level repair work frequently references applicable work entities.
  • FND_USER — joined on CREATED_BY and LAST_UPDATED_BY for audit reporting.
  • FND_LOGINS — joined on LAST_UPDATE_LOGIN.
  • Service / Depot Repair concurrent programs and the CSD Service APIs — read this table when generating work requirements.

Because the table is classified as standalone, no inbound foreign keys from other CSD tables are documented, meaning dependency flows outward toward service code and audit tables rather than inward.