Search Results compatibility_class_code

Overview

WSH_FTE_COMP_CLASSES is a reference table owned by the WSH (Shipping Execution) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the classification values that govern how compatibility constraints — rules that determine whether particular items, orders, or containers may be co-loaded or co-shipped — are treated when they are violated. Each row defines a compatibility class and the severity of the outcome, expressed as either an "Error", which aborts the fulfillment or shipping process, or a "Warning", which allows the process to continue while recording the exception. In this role the table functions as the master lookup for constraint severity, and it is referenced directly by the shipping compatibility constraint definitions maintained through the Freight and Transportation Execution components of Oracle Shipping.

The documented heuristic Data Vault classification places this object as a standalone structure; in Data Vault terms it is best modeled as a hub-like reference entity, since it holds a stable business code (COMPATIBILITY_CLASS_CODE) and is not a transactional link or satellite. It therefore acts as a small dimension against which compatibility constraints are evaluated at runtime.

Key Information Stored

The table's documented physical schema contains 29 columns. The most functionally significant are:

• COMPATIBILITY_CLASS_ID — the surrogate primary key, enforced by WSH_FTE_COMP_CLASSES_PK, and the value used by child tables to reference a class.
• COMPATIBILITY_CLASS_CODE — the business-key candidate, enforced by unique index WSH_FTE_COMP_CLASSES_U2 together with ZD_EDITION_NAME; this is the user-facing code that identifies the classification.
• CONSTRAINT_VIOLATION — the value that determines whether a violation of the class results in an "Error" (process abort) or a "Warning" (process continues), and is the core decision attribute of the table.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard Oracle EBS descriptive flexfield columns, available for client-specific extensions of the compatibility class definition.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns recording row creation and modification.
• PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, REQUEST_ID — concurrent program context columns identifying the process that last inserted or updated the row.
• ZD_EDITION_NAME — the editioning column used in the 12.2 online patching architecture; it participates in both unique indexes (WSH_FTE_COMP_CLASSES_U1 on COMPATIBILITY_CLASS_ID and ZD_EDITION_NAME, and WSH_FTE_COMP_CLASSES_U2 on COMPATIBILITY_CLASS_CODE and ZD_EDITION_NAME).

The distinction between the surrogate key and the business key matters in reporting: COMPATIBILITY_CLASS_ID is stable for joins, while COMPATIBILITY_CLASS_CODE is the value understood by users and configuration owners.

Common Use Cases and Queries

The primary use case is decoding compatibility violations during shipping execution so that users see a meaningful classification rather than a numeric identifier. A typical reporting join resolves the classification for each configured constraint:

• Listing all compatibility classes and their severity: SELECT compatibility_class_code, constraint_violation FROM wsh.wsh_fte_comp_classes ORDER BY compatibility_class_code;
• Identifying classes that abort the process: SELECT compatibility_class_id, compatibility_class_code FROM wsh.wsh_fte_comp_classes WHERE constraint_violation = 'Error';
• Resolving constraints to their class: SELECT c.constraint_id, c.compatibility_class_id, k.compatibility_class_code, k.constraint_violation FROM wsh.wsh_fte_comp_constraints c, wsh.wsh_fte_comp_classes k WHERE c.compatibility_class_id = k.compatibility_class_id;
• Edition-aware lookups on 12.2 should restrict or group by ZD_EDITION_NAME to avoid duplicate rows returned across editioned data.

Typical reports include compatibility rule inventories, exception trend analyses grouped by class severity, and validation scripts confirming that every constraint references a valid class.

Related Objects

• WSH_FTE_COMP_CONSTRAINTS — the principal dependent table; its COMPATIBILITY_CLASS_ID foreign key references WSH_FTE_COMP_CLASSES, so every constraint is tied to exactly one class. This is the only documented foreign key relationship.
• WSH_FTE_COMP_CONSTRAINTS_PK / constraint-related indexes — supporting structures on the child table that drive the join path.
• Shipping Execution setup and validation concurrent programs (PROGRAM_ID / REQUEST_ID context) that populate and maintain these configuration rows.
• Descriptive flexfield definitions associated with ATTRIBUTE_CATEGORY and ATTRIBUTE1–15, which extend the table for site-specific requirements.
• FND_APPLICATION / application registration objects identifying WSH as the owning product for the table and its lookup values.