Search Results iby_f_t_crdt_app_st_h




Overview
Explore in AI Chat

Overview

The table IBY_F_T_CRDT_APP_ST_H is a core data object within the Oracle E-Business Suite Payments (IBY) module. It functions as a history table, specifically designed to audit and track all status changes for credit applications processed through the system. In the context of Oracle EBS 12.1.1 and 12.2.2, this table is critical for maintaining a complete audit trail, enabling users to review the progression of a credit application from its initial submission through various approval or rejection states. Its role is to ensure data integrity, support compliance requirements, and facilitate troubleshooting by providing a historical record of every state transition.

Key Information Stored

The table's primary purpose is to log each instance a credit application's status is updated. The metadata indicates the primary key is STATUS_HISTORY_ID, which uniquely identifies each historical record. The core data points stored for each status change event include the CREDIT_APP_ID, which links the history entry to the specific credit application in the IBY_F_T_CRDT_APPS_ALL_B table. Crucially, it stores both the OLD_STATUS_ID and the NEW_STATUS_ID, which are foreign keys to the IBY_F_CRDT_APP_STATUS_B table, capturing the exact before-and-after states of the application. While the provided metadata does not list all columns, a typical history table in this context would also include standard audit columns such as CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, and LAST_UPDATED_BY to record who made the change and when.

Common Use Cases and Queries

The primary use case is auditing and reporting on the lifecycle of credit applications. Support and business analysts query this table to understand why an application is in its current state, to identify bottlenecks in the approval process, or to verify procedural compliance. A common reporting query would join this history table to the main application and status tables to produce a timeline for a specific application or a summary report of all status transitions within a date range.

  • Sample Query for Application History:
    SELECT app.CREDIT_APP_ID, old_st.STATUS_CODE OLD_STATUS, new_st.STATUS_CODE NEW_STATUS, hist.CREATION_DATE
    FROM IBY_F_T_CRDT_APP_ST_H hist,
    IBY_F_T_CRDT_APPS_ALL_B app,
    IBY_F_CRDT_APP_STATUS_B old_st,
    IBY_F_CRDT_APP_STATUS_B new_st
    WHERE hist.CREDIT_APP_ID = app.CREDIT_APP_ID
    AND hist.OLD_STATUS_ID = old_st.STATUS_ID
    AND hist.NEW_STATUS_ID = new_st.STATUS_ID
    AND app.CREDIT_APP_ID = :p_app_id
    ORDER BY hist.CREATION_DATE;

Related Objects

As defined by its foreign key relationships, IBY_F_T_CRDT_APP_ST_H is intrinsically linked to several key tables in the Payments schema. Its most critical relationship is with the master table IBY_F_T_CRDT_APPS_ALL_B, which holds the current details of each credit application. It also has two separate foreign key relationships to the lookup table IBY_F_CRDT_APP_STATUS_B: one for the old status (OLD_STATUS_ID) and one for the new status (NEW_STATUS_ID). This table is likely referenced by standard Oracle Payments reports and may be accessed by custom APIs or extensions built for credit application workflow monitoring and auditing.