Search Results ar_cont_actions_u1




Overview

The AR.AR_CONT_ACTIONS_ALL table is a transactional configuration table within the Oracle Receivables (AR) module of Oracle E-Business Suite, holding the rules that map a revenue contingency to a revenue recognition event. In Oracle EBS 12.1.1 and 12.2.2 it functions as the driving definition behind contingency-based revenue recognition, where revenue is deferred or released only when a specified recognition action occurs within a defined time window. Each row defines, for a given contingency and operating unit, which revenue recognition event governs the timing of revenue release, whether a number of days applies, and the effective start and end dates of the rule.

From a Data Vault modeling perspective the metadata heuristic classifies this object as standalone, with no descriptive child tables and no outgoing foreign keys to other business entities. The practical modeling interpretation is that a business key of (CONTINGENCY_CODE, ORG_ID) behaves as a hub-like identifier, while the remaining attributes such as REVREC_EVENT_CODE, DAYS, START_DATE, and END_DATE are satellite-style descriptive payload attached to that key. The table is therefore best treated as a reference-to-reference association between the contingency lookup and the revenue recognition event lookup, scoped by operating unit rather than as a pure transactional fact.

Key Information Stored

The table contains eleven documented columns. The columns that carry business meaning are:

  • CONTINGENCY_CODE (VARCHAR2 30) — the contingency code, drawn from the AR_REVENUE_CONTINGENCIES lookup. Forms the first component of the primary key AR_CONT_ACTIONS_PK and of the unique index AR_CONT_ACTIONS_U1.
  • ORG_ID (NUMBER) — the organization (operating unit) identifier, the second component of both the primary key and the unique business-key index, ensuring rules are defined per operating unit.
  • REVREC_EVENT_CODE (VARCHAR2 30) — the revenue recognition event code, sourced from the AR_REVREC_EVENTS lookup, identifying which event triggers recognition.
  • DAYS (NUMBER) — the number of days associated with the contingency action, typically the deferral or qualifying period.
  • START_DATE (DATE) — the effective start date of the mapping.
  • END_DATE (DATE) — the effective end date of the mapping.

The remaining columns are standard WHO audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN. The surrogate primary key is AR_CONT_ACTIONS_PK on (CONTINGENCY_CODE, ORG_ID); the unique index AR_CONT_ACTIONS_U1 on the same (CONTINGENCY_CODE, ORG_ID) pairing confirms the business key. Because the PK and the unique index are identical, the table is best described as having a natural composite business key rather than a separate system-generated surrogate. The user query "ar_cont_actions_u1" refers directly to this unique index, which is the object consulted when validating uniqueness or tuning lookups by contingency and operating unit.

Common Use Cases and Queries

Typical scenarios include validating configured contingency rules, driving revenue recognition processing by joining the contingency and event codes to their lookups, and reporting on effective-dated recognition windows. The unique index AR_CONT_ACTIONS_U1 supports efficient single-row retrieval by contingency and org.

  • Retrieve active rules for an operating unit:

    SELECT contingency_code, revrec_event_code, days, start_date, end_date FROM ar.ar_cont_actions_all WHERE org_id = :org_id AND NVL(end_date, SYSDATE+1) >= SYSDATE;

  • Resolve a specific business-key combination using the unique index: WHERE contingency_code = :code AND org_id = :org_id.
  • Reporting joins to lookup views for contingency and revenue recognition event descriptions to produce a configuration audit.

Related Objects

The ETRM metadata records no outgoing foreign keys, so this table is structurally standalone; enrichment relies on lookup and operational joins rather than enforced constraints.

  • AR_REVENUE_CONTINGENCIES (lookup) — joined on CONTINGENCY_CODE.
  • AR_REVREC_EVENTS (lookup) — joined on REVREC_EVENT_CODE.
  • FND_USER — joined via CREATED_BY and LAST_UPDATED_BY.
  • FND_LOGINS — joined via LAST_UPDATE_LOGIN.
  • AR_CONT_ACTIONS_ALL (APPS synonym) — the application-layer synonym exposing the table to concurrent programs and forms.