Results for “status_lookup_code”

50+ results




Overview
Explore in AI Chat

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

Overview

FII_AP_AP_APPY_CHECK_LCV is a Financial Intelligence (FII) reporting view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes a denormalized, presentation-oriented projection of Oracle Payables payment and check data, purpose-built for the Oracle Financial Intelligence (formerly Daily Business Intelligence) analytical layer. Rather than requiring reporting consumers to join across the base Payables payment tables directly, this view supplies a single, stable interface that abstracts the underlying check and payment method relationships.

Because it is a view and not a table, no data is physically stored. The definition is resolved at query time, which means any filter applied by a report or extract is pushed down to the underlying base view and its constituent tables. This is significant for performance tuning in EBS environments where the check register is large.

Underlying Base Objects

The view is defined exclusively over a single underlying object: FIIBV_AP_AP_APPY_CHECK_LCV. The ETRM metadata records no additional referenced base tables, and the SELECT list confirms a straightforward one-to-one projection with no joins, filters, or aggregations in the view itself. The "B" and "BV" naming conventions indicate that FIIBV_AP_AP_APPY_CHECK_LCV is itself an FII Business View layer object, which in turn draws from Payables check and payment base entities.

The view text casts the first twelve projected columns as their native types and then supplies five NULL placeholders that map to USER_ATTRIBUTE1 through USER_ATTRIBUTE5. These descriptor columns are intentionally unpopulated in this view, preserving the column count and positional alignment expected by FII's generic reporting framework.

Key Columns

The columns fall into three functional groups. Identity and relationship columns include CHECK_PK (the surrogate primary key for the check record), CHECK_ID, CHECK_NAME, NAME, PAYMENT_METHOD_FK, and INSTANCE. INSTANCE identifies the source EBS instance, which matters in multi-org or consolidated reporting deployments. The descriptive column BANK_ACCOUNT_NAME supplies the human-readable disbursement bank account.

STATUS_LOOKUP_CODE is the column most relevant to the originating search. It carries the Payables lookup code reflecting the check or payment status — for example, values corresponding to issued, cleared, reconciled, voided, or stopped payments, depending on the seeded lookup types in the AP module. Because it is a lookup code and not a decoded description, reporting queries that require readable status text must join to the appropriate lookup view or table (such as FND_LOOKUP_VALUES) on LOOKUP_CODE with the correct LOOKUP_TYPE.

The temporal columns LAST_UPDATE_DATE, CREATION_DATE, and DELETION_DATE support incremental extraction and change-detection patterns. DELETION_DATE is particularly useful for detecting logically removed records without losing historical continuity. CHECK_DP is a derived or display-oriented field associated with the check record.

Common Use Cases and Queries

Typical consumers include FII dashboards, custom check registers, reconciliation extracts, and downstream data warehouse loads that stage Payables payment data. A standard status-filtered extract resembles:

  • SELECT check_id, check_name, bank_account_name, status_lookup_code, creation_date FROM apps.fii_ap_ap_appy_check_lcv WHERE status_lookup_code = :status;
  • SELECT status_lookup_code, COUNT(*) FROM apps.fii_ap_ap_appy_check_lcv GROUP BY status_lookup_code; — used to profile check volumes by status.
  • SELECT check_id, status_lookup_code FROM apps.fii_ap_ap_appy_check_lcv WHERE last_update_date >= :since; — incremental extraction for ETL.
  • Joining to fnd_lookup_values_vl on lookup_code = status_lookup_code to obtain the decoded status meaning for user-facing reports.

Because the view performs no filtering, all predicates — including INSTANCE and DELETION_DATE restrictions — should be supplied explicitly by the calling report to avoid full scans of the Payables check population.