AR_PAYMENT_SCHEDULES_ALL
Schema: ARtransactionOU-striped (ORG_ID)The open-receivables engine — one row per transaction installment AND one row per receipt, carrying original and remaining amounts, due date, and closure state; what aging, DSO, and collections analytics read
Transactions AND receipts both write rows here, with opposite signs (debits positive, credits and receipts negative), and split terms produce several installments per transaction — filter CLASS before aging AR
CLASS separates the row kinds (invoice, credit memo, receipt…) per the data dictionary's own enumeration; STATUS moves OP to CL when the remaining amount reaches zero. Open AR is the STORED remaining amount — the deliberate contrast with the quantity side, where open is always arithmetic.
What the badges mean
- Schema: INV
- Schema: the Oracle product schema that owns the table (INV, ONT, WSH, PO, BOM, WIP, MRP, MSC, AR, AP, GL, HR, APPLSYS) — tells you which product family the object belongs to, not who can query it.
- master
- Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or an APPS-schema view.
- OU-striped (ORG_ID)
- Rows are scoped to an operating unit. A landed extract carries every operating unit’s rows — filter or join on
ORG_ID, and don’t confuse it withORGANIZATION_ID(see the quirks guide). - Per inventory org
- Rows are scoped to an inventory organization (plant or warehouse) via
ORGANIZATION_ID— a different partition from OU-striped tables (see the quirks guide). - Language-striped
- The table carries a
LANGUAGEcolumn (a _TL translation table or FND_LOOKUP_VALUES) — one row per language. Filter to oneLANGUAGEor a join multiplies rows (see the quirks guide). - View
- This is an APPS-schema convenience view, not a physical table. Extract the base tables it joins instead — views can be slow at scale and aren't guaranteed stable across patches.
Structural facts — how the table is partitioned, not a trap by itself
Join & extract hazards — verify before you rely on this
Fields
18 fields · 1 key
18 fields.
| # | Field | Description | Type | Flags |
|---|---|---|---|---|
| 1 | PAYMENT_SCHEDULE_ID | Surrogate key of the schedule row | NUMBER | Primary-key field |
| 2 | ORG_ID | Operating unit | NUMBER | |
| 3 | CUSTOMER_TRX_ID | The transaction — populated on transaction rows, NULL on receipt rows | NUMBER | |
| 4 | CASH_RECEIPT_ID | The receipt — populated on receipt rows | NUMBER | |
| 5 | CUSTOMER_ID | The customer account | NUMBER | |
| 6 | CUSTOMER_SITE_USE_ID | The bill-to site use | NUMBER | |
| 7 | CLASS | Row kind — INV, DM, GUAR, CM, DEP, CB, PMT, BR (per the data dictionary's enumeration); PMT rows are receipts | VARCHAR2 | |
| 8 | STATUS | OP while open, CL once the remaining amount reaches zero | VARCHAR2 | |
| 9 | DUE_DATE | When the installment falls due — the aging date | DATE | The table's primary analysis date — a real DATE column, no conversion needed |
| 10 | TRX_DATE | The transaction date, denormalized | DATE | |
| 11 | TRX_NUMBER | The document number, denormalized | VARCHAR2 | |
| 12 | AMOUNT_DUE_ORIGINAL | Original amount — debits positive, credits and receipts NEGATIVE (the sign convention) | NUMBER | |
| 13 | AMOUNT_DUE_REMAINING | The open amount — stored, not arithmetic; what aging sums | NUMBER | |
| 14 | AMOUNT_APPLIED | Amount applied to date | NUMBER | |
| 15 | TERMS_SEQUENCE_NUMBER | The installment number — split terms produce several rows per transaction | NUMBER | |
| 16 | INVOICE_CURRENCY_CODE | Currency of the amounts | VARCHAR2 | |
| 17 | GL_DATE | The accounting date | DATE | |
| 18 | ACTUAL_DATE_CLOSED | When the row actually closed | DATE |
Field provenance: hand-curated. 1 key field.
Boilerplate SQL
Starting point for reading AR_PAYMENT_SCHEDULES_ALL on Databricks — real DATE columns need no conversion, and the org anchor is already in place. The optional LAST_UPDATE_DATE watermark is included. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.
7 parameters not filled: <catalog>, <schema>, <operating_unit_id>, <PAYMENT_SCHEDULE_ID>, <DATE_FROM>, <DATE_TO>, <watermark>
-- ============================================================
-- Table : AR_PAYMENT_SCHEDULES_ALL — The open-receivables engine — one row per transaction installment AND one row per receipt, carrying original and remaining amounts, due date, and closure state; what aging, DSO, and collections analytics read
-- Purpose: Column-selected read of AR_PAYMENT_SCHEDULES_ALL — auto-generated from field metadata
-- Grain : One row per operating unit (ORG_ID) + PAYMENT_SCHEDULE_ID
-- Caution: Transactions AND receipts both write rows here, with opposite signs (debits positive, credits and receipts negative), and split terms produce several installments per transaction — filter CLASS before aging AR
-- Notes : Auto-generated skeleton for Oracle EBS R12 data landed in your lakehouse. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
t.PAYMENT_SCHEDULE_ID AS "Surrogate key of the schedule row",
t.ORG_ID AS "Operating unit",
t.CUSTOMER_TRX_ID AS "The transaction — populated on transaction rows, NULL on receipt rows",
t.CASH_RECEIPT_ID AS "The receipt — populated on receipt rows",
t.CUSTOMER_ID AS "The customer account",
t.CUSTOMER_SITE_USE_ID AS "The bill-to site use",
t.CLASS AS "Row kind — INV, DM, GUAR, CM, DEP, CB, PMT, BR (per the data dictionary's enumeration); PMT rows are receipts",
t.STATUS AS "OP while open, CL once the remaining amount reaches zero",
t.DUE_DATE AS "When the installment falls due — the aging date",
t.TRX_DATE AS "The transaction date, denormalized",
t.TRX_NUMBER AS "The document number, denormalized",
t.AMOUNT_DUE_ORIGINAL AS "Original amount — debits positive, credits and receipts NEGATIVE (the sign convention)",
t.AMOUNT_DUE_REMAINING AS "The open amount — stored, not arithmetic; what aging sums",
t.AMOUNT_APPLIED AS "Amount applied to date",
t.TERMS_SEQUENCE_NUMBER AS "The installment number — split terms produce several rows per transaction",
t.INVOICE_CURRENCY_CODE AS "Currency of the amounts",
t.GL_DATE AS "The accounting date",
t.ACTUAL_DATE_CLOSED AS "When the row actually closed"
FROM <catalog>.<schema>.AR_PAYMENT_SCHEDULES_ALL t
WHERE
t.ORG_ID = <operating_unit_id> -- operating unit (MOAC does not filter extracts)
-- AND t.PAYMENT_SCHEDULE_ID = <PAYMENT_SCHEDULE_ID>
-- AND t.DUE_DATE >= DATE '<DATE_FROM>'
-- AND t.DUE_DATE <= DATE '<DATE_TO>'
-- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>' -- WHO watermark, bulk-stamped by batch jobs; see quirks guide #who-columns
ORDER BY t.PAYMENT_SCHEDULE_ID;Verified September 2026
Relationships
Diagram of 1-hop neighbors — join details below. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.
Join details
ON AR_PAYMENT_SCHEDULES_ALL.CUSTOMER_TRX_ID = RA_CUSTOMER_TRX_ALL.CUSTOMER_TRX_ID AND AR_PAYMENT_SCHEDULES_ALL.ORG_ID = RA_CUSTOMER_TRX_ALL.ORG_IDON AR_PAYMENT_SCHEDULES_ALL.CASH_RECEIPT_ID = AR_CASH_RECEIPTS_ALL.CASH_RECEIPT_ID AND AR_PAYMENT_SCHEDULES_ALL.ORG_ID = AR_CASH_RECEIPTS_ALL.ORG_IDON AR_PAYMENT_SCHEDULES_ALL.CUSTOMER_ID = HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID
More Financials tables
- GL_JE_HEADERSJournal headers — one row per journal within a batch, carrying ledger, source, category, period, posting status, and control totals; where every subledger's accounting lands
- GL_JE_LINESJournal lines — the atomic debit/credit rows against account combinations; the source of trial-balance and account-activity analytics
- RA_CUSTOMER_TRX_ALLReceivables transaction headers — invoices, credit and debit memos, chargebacks, and deposits share the table, classified by transaction type; the revenue-document anchor of order-to-cash
- RA_CUSTOMER_TRX_LINES_ALLReceivables transaction lines — product lines, tax, and freight share the table by line type, with quantities, selling price, and the extended amount revenue analytics sum
- AP_INVOICE_DISTRIBUTIONS_ALLSupplier invoice distributions — one row per GL-account allocation of an invoice line; the spend-to-account grain payables accounting posts from
- AP_INVOICE_LINES_ALLSupplier invoice lines — the R12-new layer between header and distributions, carrying line type, amount, and the purchase-order and receipt matching references