Search Results leaf_flag




Overview
Explore in AI Chat

Overview

The view XNC_ORD_ORDERTYP_NAV belongs to the XNC — Sales for Communications product family in Oracle EBS 12.1.1 and 12.2.2. Within the ETRM metadata, XNC is flagged as Obsolete, and this view is documented with the description: "View used to define the attribute fields for an AK object for construction of the Order Navigator tree." In practical terms, XNC_ORD_ORDERTYP_NAV is a navigation-tree helper view rather than a transactional reporting view. It does not return order data itself; instead it synthesizes a fixed set of node definitions that an AK (Oracle Application Framework/Application Kit) object consumes to render the "Order Navigator" hierarchical tree used by the Sales for Communications order console.

The view supplies the label, key, icon, parent linkage, and leaf indicator required for each navigational node. Its role in EBS integration is therefore limited to UI tree construction and metadata enrichment rather than data extraction, reconciliation, or interface staging.

Underlying Base Objects

According to the documented view text, XNC_ORD_ORDERTYP_NAV is defined over a single referenced base object: XNC_NAV_NODE_TYPES_V, joined to DUAL. Notably, the ETRM "Referenced base objects" section lists none documented, and the "Implementation/DBA Data" note records that the view is Not implemented in this database. This is consistent with its Obsolete XNC status — the view may exist only in historical or customized instances of Sales for Communications.

The relationship to XNC_NAV_NODE_TYPES_V is through a correlated filter: every union branch selects icon and root-key attributes from the node-types view where NODE_TYPE = 'ORDER_TYPE' and ROOT_KEY = 'XNC_ORDERS_STATUS'. The five UNION branches therefore reuse the same source row from XNC_NAV_NODE_TYPES_V, varying only the literal node key, label, and appended status classification.

Key Columns

  • NODE_KEY — Unique identifier for each navigational node. The view emits five fixed literals: 1-NEW, 2-OPEN, 3-ERROR, 4-CANCELLED, and 5-CLOSED.
  • LABEL — Display text for each node: "NEW ORDERS", "OPEN ORDERS", "ERROR ORDERS", "CANCELLED ORDERS", and "CLOSED ORDERS".
  • NODE_TYPE — Always the literal 'ORDER_TYPE', identifying the node classification used by the AK object.
  • PARENT_NODE_TYPE — Fixed to 'ROOT', placing each of the five status nodes directly beneath the tree root.
  • ICON_NAME — Sourced from XNC_NAV_NODE_TYPES_V; provides the icon rendered beside each node.
  • PARENT_NODE_KEY — Sourced from XNC_NAV_NODE_TYPES_V as NT.ROOT_KEY, equal to XNC_ORDERS_STATUS, linking the nodes to the parent root.
  • LEAF_FLAG — Hard-coded to 'N', indicating these nodes are expandable and not terminal leaves.

Common Use Cases and Queries

Because the view supplies fixed, literal-driven rows, its primary use case is inspection or verification of the Order Navigator tree structure — confirming which status nodes appear and how they are keyed. Administrators diagnosing a missing or mislabelled navigator node can query the view directly to confirm expected values.

A representative query lists the full node set:

  • SELECT node_key, label, node_type, parent_node_key, leaf_flag FROM xnc_ord_ordertyp_nav ORDER BY node_key;

To confirm the icon and parent linkage inherited from the node-types source, a join-aware query can be run against XNC_NAV_NODE_TYPES_V. Because the view is documented as Obsolete and not implemented in the reference database, queries should be validated per instance. Where the view is absent, the equivalent result set can be reconstructed from XNC_NAV_NODE_TYPES_V with explicit literals for the five status nodes. Integration use is minimal given the view's UI-oriented purpose.