Search Results ar_cont_actions_pk




Overview

AR_CONT_ACTIONS_ALL is a Receivables (AR) module table in the Oracle E-Business Suite that maps contingency definitions to revenue recognition events. It defines, per operating unit, the sequence of contingency codes and the associated revenue recognition (RevRec) events that govern how revenue is deferred, released, or recognized in the Oracle Receivables revenue recognition engine. The table sits within the AR revenue recognition sub-model that supports contingent revenue arrangements, where revenue recognition is conditioned upon events such as acceptance, delivery, or milestone completion. Its role is to establish the timing rule (offset in days plus validity window) linking a contingency and the RevRec event that satisfies it.

Recorded Primary Key is AR_CONT_ACTIONS_PK, defined as (CONTINGENCY_CODE, ORG_ID), and a unique business-key index AR_CONT_ACTIONS_U1 exists on the same (CONTINGENCY_CODE, ORG_ID) combination. Heuristic Data Vault classification (mined from the FK structure) is standalone; as a modeling suggestion, this object can be treated as a hub/satellite combination where the business key is (CONTINGENCY_CODE, ORG_ID) and the descriptive attributes (DAYS, START_DATE, END_DATE, audit columns) form the satellite. No natural parent link is documented, so the object is largely self-contained within the AR revenue configuration set.

Key Information Stored

Eleven columns are documented in the physical schema. The most significant are:

  • CONTINGENCY_CODE — the contingency identifier; part of the composite primary key and the unique business key. Determines which contingency rule the AR revenue engine applies.
  • REVREC_EVENT_CODE — the revenue recognition event that must occur to release the contingency; the mapping target that drives recognition timing.
  • DAYS — the offset, in days, applied relative to the trigger to compute the recognition date.
  • START_DATE and END_DATE — the effective validity window for the contingency-to-event mapping.
  • ORG_ID — the operating unit discriminator; part of the primary key and unique business key, enforcing multi-org partitioning of rules.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS WHO audit columns used for change tracking and interfaces.

The surrogate identity is the composite primary key (CONTINGENCY_CODE, ORG_ID); the unique index AR_CONT_ACTIONS_U1 confirms these two columns as the business-key candidates.

Common Use Cases and Queries

Typical scenarios include reviewing active contingency-to-event rules for a given operating unit, validating effective-date overlaps, and reconciling deferred revenue schedules. A common query pattern retrieves all mappings for a contingency:

  • SELECT contingency_code, revrec_event_code, days, start_date, end_date FROM ar.ar_cont_actions_all WHERE org_id = :org_id AND contingency_code = :code;
  • Effective-date check: select rows where SYSDATE BETWEEN start_date AND NVL(end_date, SYSDATE) to isolate currently active rules.
  • Reporting joins on REVREC_EVENT_CODE against revenue recognition event setup tables, joined with ORG_ID, to describe the recognition trigger.
  • Audit/history reporting using LAST_UPDATE_DATE and LAST_UPDATED_BY to track configuration changes over time.

Related Objects

Because the metadata documents no foreign-key relationships (standalone classification), related objects are inferred from the business-key columns rather than enforced RI: