Search Results iex_repossessions_u1




Overview

The IEX_REPOSSESSIONS table in the Oracle E-Business Suite IEX (Advanced Collections) schema records repossession activity associated with delinquent customer obligations. Each row captures a single repossession event, linking a delinquency to the customer account, the specific asset recovered, the assessed asset value, and a set of workflow flags governing credit and service holds. In Oracle EBS 12.1.1 and 12.2.2, this object resides in the APPS_TS_TX_DATA tablespace and is owned by the IEX schema, making it part of the transactional collections data model used by Advanced Collections agents and collectors.

From a Data Vault modeling perspective, the metadata classifies this object heuristically as standalone, with the primary key IRN_PK defined on REPOSSESSION_ID. The presence of foreign key references to IEX_DELINQUENCIES_ALL and HZ_CUST_ACCOUNTS, combined with descriptive columns such as UNPAID_REASON_CODE, REASON_CODE, and DISPOSITION_CODE, suggests this table functions primarily as a satellite or detail entity anchored to delinquency and customer hub entities rather than a pure transaction link.

Key Information Stored

The 51-column structure centers on the surrogate primary key REPOSSESSION_ID, which is enforced by the unique index IEX_REPOSSESSIONS_U1 in the APPS_TS_TX_IDX tablespace. Since only this single-column unique index is documented, REPOSSESSION_ID is the sole business-key candidate; all other columns are descriptive or foreign-key attributes.

Standard EBS who-columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the Program who-columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE) are also present, along with the ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 descriptive flexfield segments.

Common Use Cases and Queries

Collections analysts commonly query this table to list repossessions by delinquency or customer account, to report on asset recovery value, and to drive hold-approval workflows. A typical join pattern leverages the nonunique index:

SELECT r.repossession_id, r.repossession_date, r.asset_number, r.asset_value
FROM   iex.iex_repossessions r
WHERE  r.delinquency_id = :p_delinquency_id;

Reporting queries frequently aggregate asset value by disposition code or remarket flag, and reconciliation routines join on CUST_ACCOUNT_ID to HZ_CUST_ACCOUNTS to confirm customer ownership. Workflow-driven queries filter on the CREDIT_HOLD_APPROVED_FLAG or SERVICE_HOLD_APPROVED_FLAG columns to identify pending approvals.

Related Objects

The most significant related objects, based on documented foreign keys and dependencies, include:

  • IEX_DELINQUENCIES_ALL – referenced via DELINQUENCY_ID; the parent delinquency case.
  • HZ_CUST_ACCOUNTS – referenced via CUST_ACCOUNT_ID; the customer account record.
  • FND_SECURITY_GROUPS – referenced via SECURITY_GROUP_ID for data security resolution.
  • IEX_REPOS_OBJECTS – references REPOSSESSION_ID back to this table, capturing recovered object detail.
  • FND_CONCURRENT_REQUESTS, FND_APPLICATION, and FND_CONCURRENT_PROGRAM – referenced by the Program who-columns for audit lineage.