Search Results iex_writeoffs_n1

Overview

IEX.IEX_WRITEOFFS is the transactional master table within the Oracle E-Business Suite Collections (Advanced Collections / IEX) module that stores writeoff records. A writeoff in this context represents the formal decision to remove a delinquent receivable or obligation from the active collections portfolio, either as a bad-debt adjustment, a settlement, or a credit-driven closure. Each row captures the identity of the party, the delinquency or case that gave rise to the writeoff, the monetary amount, the currency, the approval path, and the resulting disposition. The table is owned by the IEX schema and resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10.

From a Data Vault modeling perspective, the heuristic classification for this object is standalone. It does not function as a pure hub (business keys are not the sole content), nor as a classical link (multiple foreign keys coexist with descriptive measures), and not as a satellite (it carries its own surrogate primary key). The practical guidance is to treat it as a source of both hub-like identity (WRITEOFF_ID) and satellite-like descriptive context (amounts, dates, reasons, approval flags).

Key Information Stored

The surrogate primary key is WRITEOFF_ID, enforced by the unique index IEX_WRITEOFFS_U1 on APPS_TS_TX_IDX. This column is also the sole documented business-key candidate. Among the 63 documented columns, the most significant for functional and reporting purposes are:

• WRITEOFF_ID — surrogate identifier; the only unique index column.
• PARTY_ID — foreign key to HZ_PARTIES, identifying the customer or party subject to the writeoff.
• CUST_ACCOUNT_ID — foreign key to HZ_CUST_ACCOUNTS, linking to the receivables account.
• DELINQUENCY_ID — foreign key to IEX_DELINQUENCIES_ALL, tying the writeoff to the underlying delinquency record.
• CAS_ID — foreign key to IEX_CASES_ALL_B, tying the writeoff to a collections case.
• WRITEOFF_TYPE and WRITEOFF_REASON — classification and narrative justification.
• WRITEOFF_AMOUNT and WRITEOFF_CURRENCY_CODE — monetary value and denomination.
• WRITEOFF_DATE and WRITEOFF_REQUEST_DATE — effective date vs. request date.
• WRITEOFF_PROCESS — the process or workflow that produced the writeoff.
• APPROVER_ID — the individual who approved the writeoff.
• ACTIVE_FLAG and OBJECT_VERSION_NUMBER — status and optimistic-locking control columns.
• OBJECT_CODE and OBJECT_ID — polymorphic reference into IEX_CASE_OBJECTS.

Common Use Cases and Queries

Typical reporting scenarios include aging and exposure analysis of written-off balances, approval audit trails, and reconciliation against the collections case and delinquency records. A common query joins the table to its principal parents:

• Listing all writeoffs for a customer account: SELECT w.WRITEOFF_ID, w.WRITEOFF_AMOUNT, w.WRITEOFF_DATE FROM IEX.IEX_WRITEOFFS w WHERE w.CUST_ACCOUNT_ID = :cust_account_id AND w.ACTIVE_FLAG = 'Y';
• Writeoffs tied to a delinquency: join on DELINQUENCY_ID to IEX_DELINQUENCIES_ALL.
• Writeoffs associated with a collections case: join on CAS_ID to IEX_CASES_ALL_B.
• Approval reporting by approver: filter on APPROVER_ID and aggregate WRITEOFF_AMOUNT by currency.
• Index-driven filtering: the non-unique indexes IEX_WRITEOFFS_N1 through N7 cover WRITEOFF_TYPE, PARTY_ID, CAS_ID, APPROVER_ID, OBJECT_CODE/OBJECT_ID, CUST_ACCOUNT_ID, and DELINQUENCY_ID, making these the preferred predicate columns.

Related Objects

The table participates in the following documented relationships:

• IEX.IEX_DELINQUENCIES_ALL — referenced via DELINQUENCY_ID.
• IEX.IEX_CASES_ALL_B — referenced via CAS_ID.
• HZ.HZ_CUST_ACCOUNTS — referenced via CUST_ACCOUNT_ID.
• HZ.HZ_PARTIES — referenced via PARTY_ID.
• FND.FND_SECURITY_GROUPS — referenced via SECURITY_GROUP_ID, supporting multi-org security.
• IEX.IEX_WRITEOFF_OBJECTS — child table referencing WRITEOFF_ID.
• IEX.IEX_CASE_OBJECTS — polymorphic target for OBJECT_CODE/OBJECT_ID.

These relationships make IEX_WRITEOFFS a central point for writeoff-level reconciliation across the Collections, Receivables, and Trading Community data models.