Search Results include_all_flag




Overview

HZ_CREDIT_USAGE_RULES_V is an Oracle E-Business Suite Receivables (AR) view owned by the APPS schema and defined in the 12.1.1 and 12.2.2 releases. It presents credit usage rule records configured within Oracle Credit Management and joins them to lookup definitions so that the usage type is exposed in a user-readable form. The view surfaces the columns of the underlying HZ_CREDIT_USAGE_RULES table together with the lookup meaning for the usage type, allowing reporting, integration, and diagnostic queries to consume credit usage rule configuration without separately resolving the AR_CC_CREDIT_USAGE_TYPE lookup. Because it is a view rather than a table, it stores no data of its own and imposes no additional storage or maintenance overhead. Its primary role is to provide a denormalized, read-only presentation of credit usage rule setup for concurrent programs, custom reports, OAF pages, and ad-hoc SQL.

Underlying Base Objects

The view is defined over two referenced objects:

  • HZ_CREDIT_USAGE_RULES (SYNONYM) — the base credit usage rules entity, aliased as CUR in the view definition, which supplies every column except the lookup meaning.
  • AR_LOOKUPS (VIEW) — the Receivables lookup view, aliased as AL, which supplies the lookup meaning used to translate the usage type code into a descriptive value.

The two objects are joined in the view text on CUR.USAGE_TYPE = AL.LOOKUP_CODE with the predicate AL.LOOKUP_TYPE = 'AR_CC_CREDIT_USAGE_TYPE'. The view exposes CUR.ROWID as the ROW_ID column along with all standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN), the concurrent program context columns (PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, REQUEST_ID), and the fifteen descriptive flexfield attributes. The lookup meaning is projected as USAGE_TYPE_MEANING. This join structure means the view returns one row per credit usage rule whose usage type has a corresponding enabled lookup entry of type AR_CC_CREDIT_USAGE_TYPE, making the lookup a prerequisite for row visibility.

Key Columns

  • CREDIT_USAGE_RULE_ID — primary identifier for each credit usage rule.
  • CREDIT_USAGE_RULE_SET_ID — identifies the credit usage rule set to which the rule belongs, linking rules to their grouping.
  • USAGE_TYPE — the lookup code defining the credit usage type; joined to the AR_CC_CREDIT_USAGE_TYPE lookup type.
  • USAGE_TYPE_MEANING — the translated meaning of the usage type code, sourced from AR_LOOKUPS.MEANING.
  • USER_CODE — the user-assigned code associated with the credit usage rule.
  • EXCLUDE_FLAG — indicates whether the rule operates as an exclusion rather than an inclusion.
  • INCLUDE_ALL_FLAG — indicates whether all applicable entries are included by the rule; this is the column most frequently referenced by users searching for this view.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — descriptive flexfield context and segment columns available for customer-specific extensions.
  • ROW_ID, WHO columns, and concurrent program columns — audit and integration metadata inherited from the base table.

Common Use Cases and Queries

The view is typically queried to review credit usage rule configuration, to determine which rule sets include all entries, and to translate usage type codes for output. A representative query listing inclusion rules for a rule set is:

SELECT CREDIT_USAGE_RULE_ID, CREDIT_USAGE_RULE_SET_ID, USAGE_TYPE, USAGE_TYPE_MEANING, USER_CODE, INCLUDE_ALL_FLAG, EXCLUDE_FLAG FROM APPS.HZ_CREDIT_USAGE_RULES_V WHERE INCLUDE_ALL_FLAG = 'Y' ORDER BY CREDIT_USAGE_RULE_SET_ID;

A second common pattern resolves the descriptive text for a specific usage type while excluding excluded rules:

SELECT CREDIT_USAGE_RULE_ID, USAGE_TYPE_MEANING, USER_CODE FROM APPS.HZ_CREDIT_USAGE_RULES_V WHERE USAGE_TYPE = :p_usage_type AND NVL(EXCLUDE_FLAG,'N') = 'N';

Because the view is a simple projection and join with no complex logic, it is safe for use in BI Publisher data templates, custom concurrent programs, and integration extracts, and it can be queried directly against the APPS schema without needing to reproduce the lookup join manually.