Results for “cz_psnode_propcompat_gens”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CZ_PSNODE_PROPCOMPAT_GENS is a Configurator (CZ) module table in the Oracle E-Business Suite database, owned by the CZ schema. According to ETRM metadata, it is classified as VALID and is described as being "used for client-side logic generation." In practical terms, the table serves as a staging and generation repository for the runtime logic that drives the Oracle Configurator user interface — specifically the property compatibility rules evaluated as a user navigates a configured model. Each row captures a generated compatibility fragment tied to a configuration node, its property, and the values that participate in that rule. This makes the table a working artifact of the Configurator's compilation/generation process rather than a master or transactional entity, and it is typically populated or refreshed when a model is compiled and published to the runtime environment.

The ETRM metadata records a heuristic Data Vault classification of standalone, meaning no clear hub, link, or satellite pattern was mined from the foreign-key structure. As a modeling suggestion, this indicates that the table behaves like a self-contained generation/detail table: it does hold foreign keys (PS_NODE_ID and ITEM_TYPE_ID), but the absence of additional mined relationships means it should be treated as a leaf-level, model-scoped artifact rather than a core integration entity. It does not appear to be the target of other foreign keys.

Key Information Stored

The documented physical schema contains 26 columns. The most significant are grouped below.

• Generation context: COMPAT_RUN identifies a particular generation/compilation run; COMPAT_FEAT identifies the compatibility feature or rule fragment produced by that run.
• Node identity and hierarchy: PS_NODE_ID (FK to CZ_PS_NODES), PARENT_ID, PS_NODE_NAME, PERSISTENT_PS_NODE_ID, and PERSISTENT_PARENT_ID capture the configuration node, its parent, and its persistent identity across model versions.
• Property attributes: PROPERTY_ID, PROPERTY_NAME, PROPERTY_VALUE, PROPERTY_VALUE_NUM, and VALUESOURCE hold the property under evaluation and its value(s), including a numeric variant and an indicator of where the value originated.
• Item context: ITEM_ID and ITEM_TYPE_ID (FK to CZ_ITEM_TYPES) tie the generated compatibility entry to the item and its type.
• Model reference: MODEL_REF_EXPL_ID links the row back to a model reference/explanation identifier.
• Lifecycle and audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, EFF_FROM, EFF_TO, EFF_MASK, SECURITY_MASK, DELETED_FLAG, and CHECKOUT_USER provide standard EBS audit, effective-dating, security, and checkout semantics.

No surrogate primary key column is enumerated in the documented metadata, and no unique business-key index is documented. In practice, uniqueness is scoped by generation run plus node and property, and the pair COMPAT_RUN + PS_NODE_ID + PROPERTY_ID behaves as the strongest business-key candidate. Because generation output is transient and can be regenerated, DELETED_FLAG and effective-dating columns are important for filtering to current, valid rows.

Common Use Cases and Queries

Typical uses revolve around diagnosing why a configuration model allows or disallows particular property combinations, and around validating that generation output is complete for a published model.

• Inspect generated rules for a node: join CZ_PSNODE_PROPCOMPAT_GENS to CZ_PS_NODES on PS_NODE_ID to list every property/value pair generated for a node.
• Find the newest generation run: filter on COMPAT_RUN and order by CREATION_DATE or LAST_UPDATE_DATE to isolate the latest compilation.
• Exclude superseded rows: apply DELETED_FLAG = 'N' and, where populated, restrict on EFF_FROM/EFF_TO against the current date.
• Locate numeric vs. text properties: use PROPERTY_VALUE_NUM for arithmetic comparisons and PROPERTY_VALUE for display, checking VALUESOURCE to distinguish user-entered from derived values.

A representative pattern is a query joining the table to CZ_PS_NODES and CZ_ITEM_TYPES:

• SELECT g.PS_NODE_NAME, g.PROPERTY_NAME, g.PROPERTY_VALUE, g.COMPAT_RUN FROM CZ_PSNODE_PROPCOMPAT_GENS g, CZ_PS_NODES n WHERE g.PS_NODE_ID = n.PS_NODE_ID AND g.DELETED_FLAG = 'N' ORDER BY g.COMPAT_RUN DESC;

Such queries are useful in support escalations, model validation scripts, and reconciliation reports comparing generated output against expected compatibility definitions.

Related Objects

The documented foreign-key relationships and the table's role as a generation artifact point to the following significant related objects:

• CZ_PS_NODES — joined via CZ_PSNODE_PROPCOMPAT_GENS.PS_NODE_ID → CZ_PS_NODES.PS_NODE_ID; provides the configuration node definition for each generated row.
• CZ_ITEM_TYPES — joined via CZ_PSNODE_PROPCOMPAT_GENS.ITEM_TYPE_ID → CZ_ITEM_TYPES.ITEM_TYPE_ID; supplies the item type context used in compatibility evaluation.
• CZ_PS_NODE_PROPERTIES (and the broader CZ_PS_NODE_* node-property family) — the source definitions from which property compatibility entries are generated.
• CZ_COMPATIBILITY_RULES and related CZ_PSNODE_PROPCOMPAT* sibling tables — the compatibility rule definitions that this generation table materializes for client-side evaluation.
• CZ_MODEL_REFERENCES (or the model reference entity behind MODEL_REF_EXPL_ID) — connects generated entries to the model reference/explanation they support.
• Configurator runtime and compilation components (e.g., the Configurator Java/runtime engine and the CZ_* publish/compile programs) — consumers of this generated data for client-side logic execution.

The absence of incoming foreign keys reinforces that CZ_PSNODE_PROPCOMPAT_GENS is a downstream generation target; it is read by runtime logic and by diagnostic reporting, not referenced as a parent by other tables.