Results for “contingency_id”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

AR_DEFERRAL_REASONS is a Receivables (AR) module table that stores revenue contingency definitions—the configurable business rules that determine when revenue deferred at invoice time should subsequently be recognized, and under what circumstances it should expire. In Oracle EBS 12.1.1 and 12.2.2, this object functions as the reference or setup table behind revenue recognition deferral processing, allowing organizations to define named contingency policies once and attach them consistently to transactions, order lines, and interface data.

The table resides in the AR schema and is owned entirely by Oracle Receivables. Its documented primary key is AR_DEFERRAL_REASONS_PK, defined on CONTINGENCY_ID. A unique index, AR_DEFERRAL_REASONS_U1, spans CONTINGENCY_ID and ZD_EDITION_NAME, confirming that the design supports edition-based (ZD) deployments in 12.2.2 while keeping CONTINGENCY_ID as the surrogate key. From a Data Vault modeling perspective, the FK structure mined from related tables classifies this object as hub-leaning: CONTINGENCY_ID behaves as a durable business key referenced by multiple downstream satellites and transactional tables, while the descriptive columns (name, dates, event codes, policy flags) behave as satellite attributes.

Key Information Stored

The documented physical schema contains 16 columns. The most important are:

• CONTINGENCY_ID — the surrogate primary key (AR_DEFERRAL_REASONS_PK) and the value propagated to all referencing tables.
• CONTINGENCY_NAME — the user-facing identifier of the revenue contingency definition; this is the value users recognize when attaching a deferral policy.
• DESCRIPTION — a longer explanation of the contingency's purpose, typically surfaced in setup and lookup screens.
• NOTES — free-form internal commentary for the revenue policy.
• REVREC_EVENT_CODE — the revenue recognition event code that governs when deferred revenue is recognized.
• EXPIRATION_EVENT_CODE — the event code that triggers expiration of the contingency.
• EXPIRATION_DAYS — the interval, in days, after which the contingency expires if the recognition event has not occurred.
• POLICY_ATTACHED — a flag indicating whether a policy is bound to the contingency definition.
• START_DATE and END_DATE — the effective-dating window that controls when the contingency definition is valid for assignment.
• ZD_EDITION_NAME — the edition identifier used by 12.2.2 edition-based redefinition; it participates in the unique index AR_DEFERRAL_REASONS_U1.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard WHO audit columns present on virtually all AR transactional objects.

Note that CONTINGENCY_ID is the sole documented primary key; CONTINGENCY_NAME is not independently declared as a unique business key in the supplied metadata, even though it functions as the natural identifier in practice.

Common Use Cases and Queries

Typical uses include resolving a contingency ID to its descriptive name for reporting, auditing which deferral policies exist and which are currently effective, and joining contingency definitions to the transactions or order lines that reference them.

• Lookup by name: SELECT contingency_id, contingency_name, revocation_event_code FROM ar.ar_deferral_reasons WHERE contingency_name = :name;
• Effective-date validation: filter on START_DATE <= SYSDATE AND (END_DATE IS NULL OR END_DATE >= SYSDATE) to return only live contingencies.
• Reporting joins from transactional tables to the contingency name using CONTINGENCY_ID.
• Setup audits identifying entries where POLICY_ATTACHED is not set, or where EXPIRATION_DAYS is unexpectedly large or null.
• Interface reconciliation against AR_INTERFACE_CONTS_ALL before import, ensuring every staged CONTINGENCY_ID resolves to a valid setup row.

Related Objects

The FK relationship data confirms that AR_DEFERRAL_REASONS is referenced by the following significant objects via CONTINGENCY_ID:

• AR_LINE_CONTS_ALL (AR_LINE_CONTS_ALL.CONTINGENCY_ID) — the primary store of contingencies assigned to invoice lines.
• AR_INTERFACE_CONTS_ALL (AR_INTERFACE_CONTS_ALL.CONTINGENCY_ID) — the staging interface used for importing contingencies into Receivables.
• OE_ORDER_LINES_ALL (OE_ORDER_LINES_ALL.CONTINGENCY_ID) — order lines in Order Management that carry a receivable contingency.
• OE_ORDER_LINES_HISTORY (OE_ORDER_LINES_HISTORY.CONTINGENCY_ID) — the historical audit counterpart to OE_ORDER_LINES_ALL.
• OKL_STRM_TYPE_B (OKL_STRM_TYPE_B.CONTINGENCY_ID) — lease stream type definitions in Oracle Lease Management that reference Receivables contingencies.

These relationships establish AR_DEFERRAL_REASONS as the shared reference point for contingency-driven revenue deferral across Receivables, Order Management, and Lease Management.