Search Results payment_group

Overview

APPS.APFV_PAYMENT_SCHEDULES is a Business Intelligence System (BIS) view owned by the APPS schema in Oracle E-Business Suite, registered under FND Design Data SQLAP. It presents scheduled payment information for supplier invoices held in Oracle Payables. The view consolidates invoice header attributes, vendor details, payment schedule records, and early-payment discount terms into a single reporting structure, making it suitable for operational reporting, ad hoc queries, and downstream integration extracts. Its stated purpose is to show the invoice amount, the amount remaining, the scheduled payment, and the discounts available for early settlement. Status is VALID in the ETRM 12.2.2 metadata set, and the object is applicable to both 12.1.1 and 12.2.2 environments.

Because the view is defined with a leading APFV (rather than AP) prefix, it is intended as a reporting-facing object rather than a transactional interface. The presence of _LA and _DF columns indicates that certain fields are exposed through lookup-aware and descriptive-flexfield-aware logic at the view level.

Underlying Base Objects

The documented base objects referenced by APFV_PAYMENT_SCHEDULES are:

• AP_INVOICES_ALL (SYNONYM) — supplies invoice header data such as INVOICE_ID, INVOICE_NUMBER, INVOICE_DATE, and INVOICE_CURRENCY.
• AP_PAYMENT_SCHEDULES (SYNONYM) — supplies the payment schedule rows, including gross amount, amount remaining, due date, discounts, and payment priority.
• PO_VENDORS (VIEW) — supplies vendor-level attributes such as VENDOR_NUMBER and VENDOR_NAME, joined through the vendor site identifier.

The invoice-to-schedule relationship is one-to-many in the underlying model, since a single invoice may carry multiple scheduled payments. The view flattens this into a denormalized reporting shape.

Key Columns

• INVOICE_NUMBER, INVOICE_DATE, _LA:INVOICE_TYPE — invoice identity and type (lookup-aware).
• PAYMENT_NUMBER, _LA:PAYMENT_STATUS, _LA:PMT_METHOD_LOOKUP_CODE — payment identification, status, and payment method.
• VENDOR_NUMBER, VENDOR_NAME, VENDOR_SITE_ID — supplier and supplier site context.
• INVOICE_CURRENCY, PAYMENT_CURRENCY — the invoice-currency code and the currency in which the scheduled payment is denominated. These may differ when the payment is issued in a currency other than the invoice currency.
• PAYMENT_GROUP, PAYMENT_PRIORITY, HOLD_FLAG — payment batch grouping, priority, and hold status.
• GROSS_AMOUNT, AMOUNT_REMAINING — the original scheduled amount and the outstanding balance.
• DISCOUNT_DATE, DISCOUNT_AMOUNT_AVAILABLE, DISCOUNT_AMOUNT_REMAINING — first-tier early-payment discount terms.
• SECOND_DISCOUNT_DATE, SECOND_DISC_AMT_AVAILABLE, THIRD_DISCOUNT_DATE, THIRD_DISC_AMT_AVAILABLE — additional discount tiers.
• DUE_DATE, FUTURE_PAY_DUE_DATE — scheduled and adjusted due dates.
• INVOICE_ID, EXTERNAL_BANK_ACCOUNT_ID — surrogate keys for joins and bank account context.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — audit columns.

Common Use Cases and Queries

A frequent scenario is currency-aware payment analysis, since the searcher's term "payment_currency" maps directly to the PAYMENT_CURRENCY column. Typical usage includes reconciling invoice currency against payment currency, identifying scheduled payments in a given currency, and reviewing early-payment discount opportunities by due date.

Example: scheduled payments grouped by payment currency.

• SELECT payment_currency, COUNT(*) schedule_count, SUM(amount_remaining) outstanding FROM apps.apfv_payment_schedules GROUP BY payment_currency;

Example: payments where the payment currency differs from the invoice currency.

• SELECT invoice_number, vendor_name, invoice_currency, payment_currency, amount_remaining, due_date FROM apps.apfv_payment_schedules WHERE invoice_currency <> payment_currency;

Example: discounts still available.

• SELECT invoice_number, vendor_name, discount_date, discount_amount_remaining FROM apps.apfv_payment_schedules WHERE discount_amount_remaining > 0 ORDER BY discount_date;

Because the view is read-only and maintained by Oracle, it can be used safely in custom reports without risk to transactional data, though the underlying synonyms should be confirmed as valid before relying on the view in production.