Results for “sold_to_customer”

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

Overview

AR.AR_INTERIM_CASH_RCPT_LINES_ALL is a temporary staging table in the Oracle Receivables (AR) module. It is used to store QuickCash payment applications before they are validated, transferred, and committed to the permanent Receivables receipts schema. Within Oracle EBS 12.1.1 and 12.2.2, the table functions as an intermediary buffer: rows are inserted while an application is being assembled or reconciled, and subsequently processed to produce standard cash receipts and their associated application lines. Because records are transient by design, the table should be treated as operational scratch data rather than as an authoritative ledger of customer activity.

Under a heuristic Data Vault classification derived from the documented foreign-key structure, this object is best characterized as a link table. It sits at the intersection of several business entities — receipts, payment schedules, transactions, batch runs, and customer accounts — and carries a small amount of descriptive payload (amounts, rates, and application-specific attributes) alongside its identifying keys. The presence of a composite primary key spanning two identifiers, together with multiple outbound foreign keys, reinforces the link interpretation rather than a pure hub or satellite.

Key Information Stored

The table contains 66 documented columns in the 12.2.2 physical schema. The most operationally significant are those forming identifiers and application amounts:

• CASH_RECEIPT_ID and CASH_RECEIPT_LINE_ID — together these constitute the composite primary key AR_INTERIM_CASH_RECEIPT_LI_PK. They identify the interim receipt header and its individual application line respectively.
• PAYMENT_SCHEDULE_ID — references the installment within AR_PAYMENT_SCHEDULES_ALL against which the payment is being applied.
• CUSTOMER_TRX_ID and CUSTOMER_TRX_LINE_ID — link the application to the transaction header and line being settled.
• BATCH_ID — associates the line with a Receivables batch in AR_BATCHES_ALL, supporting batch-level processing and QuickCash runs.
• SOLD_TO_CUSTOMER — references HZ_CUST_ACCOUNTS, identifying the paying customer account.
• PAYMENT_AMOUNT and AMOUNT_APPLIED_FROM — the monetary values governing how much of the receipt is applied.
• DISCOUNT_TAKEN and DUE_DATE — capture settlement discounts and the due date contextual to the application.
• TRANS_TO_RECEIPT_RATE and INVOICE_CURRENCY_CODE — support multi-currency applications and the exchange rate from transaction to receipt currency.
• APPLIED_REC_APP_ID and APPLICATION_REF_TYPE — identify the resulting permanent application and the type of reference used.
• ORG_ID — anchors the row to a specific operating unit in a multi-org environment.

Standard audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the ATTRIBUTE_CATEGORY/ATTRIBUTE1..15 descriptor flexfields are also present. Business-key candidates are represented by the composite CASH_RECEIPT_ID plus CASH_RECEIPT_LINE_ID combination; the surrogate nature of these values means uniqueness is enforced by the primary key rather than by any descriptive natural key.

Common Use Cases and Queries

Typical use cases revolve around diagnosing QuickCash and automatic receipt application behavior, reconciling batch activity, and tracking how interim lines became permanent applications. A common query joins the interim lines to their parent receipts and to payment schedules to expose the amount applied per installment:

• Investigating why a QuickCash run did not fully apply: select rows where PAYMENT_AMOUNT differs from AMOUNT_APPLIED_FROM, or where APPLIED_REC_APP_ID is null.
• Batch reconciliation: aggregate by BATCH_ID to compare interim totals against the final receipts.
• Multi-currency variance analysis: inspect INVOICE_CURRENCY_CODE and TRANS_TO_RECEIPT_RATE for lines where the exchange rate caused an unexpected application amount.
• Customer-level reporting: filter on SOLD_TO_CUSTOMER to trace a specific account's interim entries.

Because the table is temporary, queries should generally be scoped to a processing window or batch and should not be relied upon for historical trends; historical application data resides in the permanent receipt and application tables.

Related Objects

The documented foreign keys identify the following principal relationships:

• AR_INTERIM_CASH_RECEIPTS_ALL — parent header via CASH_RECEIPT_ID; the primary one-to-many relationship.
• AR_PAYMENT_SCHEDULES_ALL — installment reference via PAYMENT_SCHEDULE_ID.
• RA_CUSTOMER_TRX_ALL and RA_CUSTOMER_TRX_LINES_ALL — transaction header and line via CUSTOMER_TRX_ID and CUSTOMER_TRX_LINE_ID.
• AR_BATCHES_ALL — batch reference via BATCH_ID.
• HZ_CUST_ACCOUNTS — customer account via SOLD_TO_CUSTOMER.

Downstream, the interim lines are consumed by Receivables receipt-application logic, which writes permanent records into the standard receipts and receivable applications tables. Interfaces such as the AutoCash and QuickCash processing routines read from this table during receipt creation and application.