Search Results ra_recur_interim




Overview
Explore in AI Chat

Overview

RA_RECUR_INTERIM is a temporary (interim) table in the Oracle Receivables (AR) module, owned by the AR schema. Its documented purpose is to hold invoices that are to be copied as part of the recurring invoice processing workflow. When a recurring invoice source is run, Oracle Receivables stages the qualifying transactions in this interim table before generating the copies, allowing the recurring process to select, validate, and duplicate the source transactions in a controlled manner. As a transient staging object, records are typically inserted, consumed, and purged within the lifecycle of a single recurring invoice generation request, identified by REQUEST_ID.

From a Data Vault modeling perspective — the classification provided here is heuristic, mined from the foreign-key structure — RA_RECUR_INTERIM is classified as standalone. It carries no documented foreign-key dependencies to other tables despite containing columns such as CUSTOMER_TRX_ID and NEW_CUSTOMER_TRX_ID that logically reference RA_CUSTOMER_TRX_ALL. This suggests that, were it modeled in a Data Vault, it would most naturally be treated as a satellite or transient staging structure rather than a true hub or link, since the identifiers it holds are sourced from the recurring copy process rather than being independently integrated.

Key Information Stored

The table is documented with 15 columns in the ETRM 12.2.2 schema. The most significant are:

  • CUSTOMER_TRX_ID — identifier of the source transaction to be copied. This column participates in both the primary key and the unique key.
  • TRX_NUMBER — transaction number of the source invoice; also part of the primary and unique keys.
  • NEW_CUSTOMER_TRX_ID — identifier assigned to the newly created (copied) transaction generated from the source.
  • TRX_DATE — transaction date to be applied to the copied invoice.
  • TERM_DUE_DATE — due date derived from the payment terms of the copied invoice.
  • TERM_DISCOUNT_DATE — discount date associated with the payment terms.
  • GL_DATE — accounting date carried into the generated transaction.
  • BILLING_DATE — billing date for the recurring copy.
  • DOC_SEQUENCE_VALUE — document sequence value supporting sequencing requirements.
  • REQUEST_ID — concurrent request identifier that ties the interim rows to a specific run of the recurring invoice program.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns used for concurrency control and auditing.

The surrogate primary key is defined by RA_RECUR_INTERIM_PK on the composite of (CUSTOMER_TRX_ID, TRX_NUMBER). A second unique index, RA_RECUR_INTERIM_UK1, is documented on the same column pair, reinforcing that combination as the business-key candidate for row uniqueness.

Common Use Cases and Queries

Because this is an internal transient table, direct reporting against it is uncommon, but DBAs and technical developers use it for troubleshooting, reconciliation, and debugging of recurring invoice generation. Typical scenarios include verifying which source invoices were staged for a given request, and confirming whether new transactions were created.

To inspect what was staged for a specific concurrent request:

  • SELECT customer_trx_id, trx_number, trx_date, gl_date, term_due_date, billing_date FROM ar.ra_recur_interim WHERE request_id = :request_id;
  • To reconcile staged sources against generated copies: SELECT r.customer_trx_id, r.trx_number, r.new_customer_trx_id FROM ar.ra_recur_interim r; and then join NEW_CUSTOMER_TRX_ID back to RA_CUSTOMER_TRX_ALL.
  • To detect orphaned interim rows left after a failed or incomplete run: query rows whose REQUEST_ID corresponds to a request not in a Completed phase, or where NEW_CUSTOMER_TRX_ID is null.

Related Objects

Although the mined relationship data labels this object standalone, its columns logically reference the core Receivables transaction tables and APIs used during recurring invoice processing: