Search Results writeoff_object_id

Overview

The IEX_WRITEOFF_OBJECTS table is a Collections (IEX) module entity in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores the granular objects associated with a writeoff transaction. Its purpose is to record which specific business entities — contracts, consolidated invoices, consolidated invoice lines, or receivables transactions — are being written off, and at what level the writeoff occurs. According to the ETRM documentation, writeoffs may occur at three distinct levels, and this table is described as OKL (Oracle Lease and Finance Management / Contracts) specific: contracts carrying a delinquent case can be written off, and all consolidated invoices within a contract can likewise be written off.

From a heuristic Data Vault modeling perspective, the metadata classifies this table as standalone, which suggests treating it as an independent satellite or reference structure rather than a pure hub or link. In practice, the table behaves as a detail/driver table anchored to a parent writeoff header, qualified by the WRITEOFF_OBJECT_ID surrogate primary key.

Key Information Stored

The table exposes 41 documented columns. The most operationally significant columns include:

• WRITEOFF_OBJECT_ID — the surrogate primary key (index IEX_WRITEOFF_OBJECTS_PK1) and the sole documented unique business-key candidate (IEX_WRITEOFF_OBJECTS_U1).
• WRITEOFF_ID — foreign key to IEX_WRITEOFFS, linking each object row to its parent writeoff record.
• CONTRACT_ID — identifies the contract being written off at the contract level.
• CONS_INVOICE_ID and CONS_INVOICE_LINE_ID — identify the consolidated invoice and its line when the writeoff targets invoice-level objects.
• TRANSACTION_ID — the underlying transaction reference associated with the writeoff object.
• CUSTOMER_TRX_ID and CUSTOMER_TRX_LINE_ID — links to the receivables transaction and line in Oracle Receivables.
• ADJUSTMENT_AMOUNT and ADJUSTMENT_REASON_CODE — the monetary value and the reason captured for the writeoff adjustment.
• RECEVIABLES_ADJUSTMENT_ID — the identifier of the receivables adjustment created (note the documented spelling).
• WRITEOFF_TYPE_ID, WRITEOFF_TYPE, and WRITEOFF_STATUS — classify the writeoff and track its processing state.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, enforcing multi-tenant/security partitioning.
• Standard audit and concurrency columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and OBJECT_VERSION_NUMBER, plus the request/program columns REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE for concurrent processing traceability, and the ATTRIBUTE1–ATTRIBUTE15 descriptive flexfield columns.

Common Use Cases and Queries

Common scenarios include reconciling writeoff amounts against receivables adjustments, reporting outstanding writeoffs by contract or consolidated invoice, and auditing writeoff activity for a delinquent case.

A typical join retrieves writeoff details with their parent header:

SELECT o.WRITEOFF_OBJECT_ID, o.WRITEOFF_ID, o.CONTRACT_ID, o.CONS_INVOICE_ID, o.ADJUSTMENT_AMOUNT, o.WRITEOFF_STATUS FROM IEX.IEX_WRITEOFF_OBJECTS o, IEX.IEX_WRITEOFFS w WHERE o.WRITEOFF_ID = w.WRITEOFF_ID;

A reporting query aggregates writeoff amounts by reason code:

SELECT ADJUSTMENT_REASON_CODE, SUM(ADJUSTMENT_AMOUNT) FROM IEX.IEX_WRITEOFF_OBJECTS GROUP BY ADJUSTMENT_REASON_CODE;

Filtering by SECURITY_GROUP_ID is essential in multi-org implementations to respect data partitioning.

Related Objects

• IEX_WRITEOFFS — the parent writeoff table; joined via WRITEOFF_ID.
• FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID for security partitioning.
• OKC_CONTRACTS (or equivalent OKL contract entity) — related via CONTRACT_ID.
• RA_CUSTOMER_TRX / RA_CUSTOMER_TRX_LINES — receivables transactions referenced by CUSTOMER_TRX_ID and CUSTOMER_TRX_LINE_ID.
• AR_ADJUSTMENTS — the receivables adjustment created, identified by RECEVIABLES_ADJUSTMENT_ID.
• IEX_WRITEOFF_TYPES — lookup providing WRITEOFF_TYPE_ID and WRITEOFF_TYPE.
• FND_CONCURRENT_REQUESTS — traceable via REQUEST_ID and program columns.