Search Results top_node_flag

Overview

FII_FC_TYPE_ASSGNS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the Financial Intelligence (FII) product family. Financial Intelligence provides the analytical and hierarchical data structures used by Oracle Financial Analytics and related financial reporting components. This view exposes Financial Category type assignments — that is, the mapping between a Financial Category type code and the specific Financial Category (or dimension hierarchy top node) that it resolves to, together with an indicator identifying whether the assignment represents a top node.

Because the object is a view rather than a table, it carries no independent storage and is always read in the context of its underlying base objects. It is primarily consumed by concurrent programs, reporting queries, and integration extracts that need a normalized, denormalized-ready list of financial category assignments. Status of the object is VALID in the documented environments (Oracle EBS 12.1.1 and 12.2.2).

Underlying Base Objects

The view is defined as a UNION ALL of two branches, and therefore draws on multiple underlying objects:

• FII_FIN_CAT_TYPE_ASSGNS — the documented base table. It stores the persisted Financial Category type assignments and supplies the columns FIN_CAT_TYPE_CODE, FIN_CATEGORY_ID, and TOP_NODE_FLAG in the first branch of the union.
• FII_FINANCIAL_DIMENSIONS — joined in the second branch to obtain D.DBI_HIER_TOP_NODE_ID, restricted to rows where DIMENSION_SHORT_NAME = 'GL_FII_FIN_ITEM'.
• FND_LOOKUP_VALUES_VL — the standard Oracle Application Object Library lookup view, restricted by LOOKUP_TYPE LIKE 'FII_FIN_CAT_TYPE_CODE', supplying LOOKUP_CODE as the financial category type code in the second branch.

The second branch contributes synthetic rows in which TOP_NODE_FLAG is NULL, effectively surfacing top-node level assignments derived from the GL_FII_FIN_ITEM dimension and the FII_FIN_CAT_TYPE_CODE lookup set rather than from the assignment table. The UNION ALL preserves duplicates by design; consumers should not assume uniqueness across the combined result set.

Key Columns

• FIN_CAT_TYPE_CODE — the Financial Category type code. In the first branch this comes from FII_FIN_CAT_TYPE_ASSGNS; in the second it is sourced from the lookup code of the FND_LOOKUP_VALUES_VL row under lookup type FII_FIN_CAT_TYPE_CODE.
• FIN_CATEGORY_ID — the identifier of the assigned Financial Category. In the persisted branch it is the category assignment identifier; in the derived branch it is the DBI hierarchy top node identifier from FII_FINANCIAL_DIMENSIONS.
• TOP_NODE_FLAG — a flag indicating that the assignment corresponds to a top node of the hierarchy. It is populated from the base table in the first branch and explicitly set to NULL in the second branch, which is a useful discriminator when consumers need to separate persisted assignments from derived top-node rows.

Common Use Cases and Queries

Typical uses include validating Financial Category configuration before running Financial Intelligence extracts, reconciling lookup-driven top nodes against persisted assignments, and feeding downstream analytics with a consolidated assignment list. Because the view is a UNION ALL, filtering by FIN_CAT_TYPE_CODE or by TOP_NODE_FLAG is common to isolate the relevant branch.

List all assignments for a given category type:

• SELECT fin_cat_type_code, fin_category_id, top_node_flag FROM apps.fii_fc_type_assgns_v WHERE fin_cat_type_code = :p_type_code;

Isolate persisted assignments only, excluding the derived top-node rows:

• SELECT fin_cat_type_code, fin_category_id FROM apps.fii_fc_type_assgns_v WHERE top_node_flag IS NOT NULL;

Isolate top-node assignments contributed by the GL_FII_FIN_ITEM dimension and the FII_FIN_CAT_TYPE_CODE lookup set:

• SELECT fin_cat_type_code, fin_category_id FROM apps.fii_fc_type_assgns_v WHERE top_node_flag IS NULL;

Because the view carries no indexes of its own, filter predicates should be applied against the underlying columns to allow the optimizer to push them into the base tables and the FND_LOOKUP_VALUES_VL access path where possible. Queries joining this view to other FII or GL objects should drive from the filtered view side to avoid unnecessary full scans of the union branches.