Search Results csd_service_codes_b_u2

Overview

CSD.CSD_SERVICE_CODES_B is the foundational base table of the Oracle E-Business Suite (EBS) Service Codes entity, owned by the CSD schema (Service / Depreciation and service-related modules). It stores the master list of service codes used across service management, repair, and depot repair processing. Each row represents a single, uniquely identifiable service code that can be associated with domains and work entities, allowing the E-Business Suite to classify, group, and route service activity in a standardized manner. The table is a core reference (validation) object: transactional and setup tables throughout CSD and ISC (Service/Internet Service Center) point to a row in CSD_SERVICE_CODES_B to indicate which service code applies to a given transaction, bulletin, repair job, or work entity.

The table is stored in the APPS_TS_INTERFACE tablespace with PCT Free 10, and in the documented 12.2.2 physical schema it comprises 26 columns, including a standard WHO/audit block, a descriptive flexfield block, and effective date range columns. From a Data Vault modeling perspective, the mined foreign-key topology suggests this object is hub-leaning: it holds the durable business key (SERVICE_CODE) at its core, with several dependent tables referencing it. This classification is a modeling suggestion only; the physical implementation remains a classical EBS setup/reference table with surrogate key, audit columns, and DFF attributes.

Key Information Stored

The table's most important columns fall into three groups — identity, business content, and audit/extension:

• SERVICE_CODE_ID (NUMBER) — the surrogate primary key, enforced by the unique index CSD_SERVICE_CODES_B_PK1. All child tables join on this column.
• SERVICE_CODE (VARCHAR2(30)) — the human-readable business key; unique via index CSD_SERVICE_CODES_B_U2. This is the value users select and recognize, distinct from the internal surrogate ID. Two candidate business keys therefore exist: SERVICE_CODE_ID (PK/U1) and SERVICE_CODE (U2).
• ACTIVE_FROM and ACTIVE_TO (DATE) — define the effective window during which the service code is valid for use. These support date-effective lookups and prevent expired codes from being selected on new transactions.
• OBJECT_VERSION_NUMBER — the standard optimistic-locking column, incremented on each update to detect concurrent modifications.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns, with foreign-key relationships to FND_USER and FND_LOGINS, enabling traceability of who created, changed, or last touched each row.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 (VARCHAR2(150)) — the descriptive flexfield structure definition and segment columns, allowing customers to extend the service code with site-specific attributes without schema changes.

No other columns are documented in the ETRM metadata; the table is intentionally lean, and its richer relationships are carried by child/associative tables rather than by additional base columns.

Common Use Cases and Queries

Typical usage centers on validation, reporting, and integration. A frequent pattern is resolving the surrogate ID for a given business code, or listing all currently active codes for LOV or reporting purposes:

• Active service code lookup — joining the base table to child tables to filter transactions by a date-effective window: SELECT service_code_id, service_code FROM csd.csd_service_codes_b WHERE service_code = :p_code AND TRUNC(SYSDATE) BETWEEN active_from AND NVL(active_to, SYSDATE);
• Mapping codes to repair/work entities — joining CSD_SC_WORK_ENTITIES or CSD_REPAIR_JOB_XREF on SERVICE_CODE_ID to report which service codes are assigned to which operational entities.
• Domain association reporting — joining CSD_SC_DOMAINS on SERVICE_CODE_ID to enumerate the domains a service code belongs to.
• Bulletin and depot repair reporting — joining CSD_BULLETIN_SCS and ISC_DR_SERVICE_CODE_MV on SERVICE_CODE_ID to aggregate service activity by code.
• DFF extraction — selecting ATTRIBUTE_CATEGORY and ATTRIBUTE1…15 to surface customer-specific descriptive flexfield data in downstream reports.

Because SERVICE_CODE is unique, queries should generally resolve to a single row; for expiry checks, always apply the ACTIVE_FROM/ACTIVE_TO predicate to avoid stale codes.

Related Objects

The following tables reference CSD_SERVICE_CODES_B via SERVICE_CODE_ID and represent the most significant dependencies:

• CSD_BULLETIN_SCS — links service codes to bulletins (SERVICE_CODE_ID → CSD_SERVICE_CODES_B).
• CSD_SC_WORK_ENTITIES — associates work entities to service codes, the primary mechanism for assigning operational scope.
• CSD_SC_DOMAINS — associates domains to service codes.
• CSD_RO_SERVICE_CODES — service code assignments within repair order processing.
• CSD_REPAIR_JOB_XREF — cross-reference of repair jobs to service codes.
• ISC_DR_SERVICE_CODE_MV — a materialized view aggregating depot repair activity by service code, typically used for reporting and performance.

Collectively these form the service-code integration surface in CSD; upstream maintenance of CSD_SERVICE_CODES_B rows is the prerequisite for any of these child tables to carry meaningful data.