Search Results duration_uom_code




Overview

The view IBY_F_T_CRDT_APPS_ALL_VL is an Oracle EBS Payments (IBY) dictionary object owned by the APPS schema. It exposes credit application header information maintained by the Oracle Payments credit application framework, presenting translatable descriptive attributes alongside transactional header data. In Oracle EBS 12.1.1 and 12.2.2, the "_VL" suffix denotes a translation-enabled view — that is, a view that joins a base ("_B") table to its translation ("_TL") table and filters the translation rows by the session language using USERENV('LANG'). This design provides multilingual lookup semantics: business data is stored once in the base table, while name and description values are resolved per language from the translation table.

The view functions primarily as a reporting and integration surface. Rather than querying the base and translation tables separately, external systems, custom reports, Oracle BI Publisher data models, and PL/SQL consumers can read a single object that resolves translated values automatically. Because the view is defined over synonyms in the APPS schema, it provides the standard EBS layered-access pattern and inherits the security context of the underlying tables.

Underlying Base Objects

The view is defined with the following text:

  • IBY_F_T_CRDT_APPS_ALL_B — aliased CAB — supplies the transactional and descriptive columns including identifiers, status, financing attributes, XML references, and date fields.
  • IBY_F_T_CRDT_APPS_ALL_TL — aliased CATL — supplies the translatable NAME and DESCRIPTION columns.

The two objects are joined on CAB.CREDIT_APP_ID = CATL.CREDIT_APP_ID, with the additional predicate CATL.LANGUAGE = USERENV('LANG') to return the translation matching the current session language. Both are referenced as synonyms owned by APPS. The view exposes CAB.ROWID as ROW_ID, a convention used to give the view a pseudo-key for downstream processing.

Key Columns

Common Use Cases and Queries

Typical scenarios include reporting on active credit applications with their translated names and financing terms, integration with external financing systems that require the duration unit of measure, and validation of expiry status. A representative query follows:

  • Retrieve credit applications with duration and unit of measure:
    SELECT credit_app_id,
           name,
           financing_type_code,
           duration,
           duration_uom_code,
           interest_rate,
           expiration_date
    FROM   apps.iby_f_t_crdt_apps_all_vl
    WHERE  expiring_flag = 'Y'
    AND    org_id = :p_org_id;
  • Count applications by financing type and status:
    SELECT financing_type_code,
           credit_app_status_id,
           COUNT(*)
    FROM   apps.iby_f_t_crdt_apps_all_vl
    GROUP  BY financing_type_code,
              credit_app_status_id;
  • Join to payment group activity using the requested vs. submitted counts:
    SELECT credit_app_id,
           name,
           n_pg_requested,
           n_pg_submitted
    FROM   apps.iby_f_t_crdt_apps_all_vl
    WHERE  n_pg_requested > n_pg_submitted;

Because the view resolves translation by session language, consumers must ensure the correct language context is set before execution; otherwise the NAME and DESCRIPTION columns may return rows for an unexpected language or no rows at all. Queries should also respect the ORG_ID and security group constraints to maintain multi-org data isolation.