Results for “customer_num”

24 results




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

Overview

The AP_SELECTED_INVOICE_CHECKS_ALL table resides in the AP (Payables) schema of Oracle E-Business Suite and is documented with the description "No Longer Used." It belongs to the Payables module and holds a status of VALID within the ETRM 12.2.2 data model. The table contains 46 documented columns and serves as a legacy structure associated with payment-batch and check-selection processing. Its primary key, AP_SELECTED_INVOICE_CHECKS_PK, is defined on the SELECTED_CHECK_ID column, and a unique index, AP_SELECTED_INVOICE_CHECKS_U1, is defined on the same column as a business-key candidate.

From a Data Vault modeling perspective, the heuristic classification for this object is satellite-leaning. This suggests the table primarily functions as a descriptive payload dependent on a parent business key rather than as an independent hub or a pure link table. Although Oracle officially designates the table as no longer used, it remains physically present and is still referenced by foreign keys from other objects, so historical understanding of its structure retains value for upgrade analysis, data migration, and legacy reporting.

Key Information Stored

Among the 46 columns, several categories stand out. Identification and selection attributes include SELECTED_CHECK_ID, the primary key and unique-index column, and CHECKRUN_NAME, which links a selected check to a specific payment run selection criteria record. Payee attributes include VENDOR_ID, VENDOR_SITE_ID, VENDOR_NUM, VENDOR_NAME, VENDOR_SITE_CODE, and CUSTOMER_NUM.

The surrogate primary key is SELECTED_CHECK_ID, while no separate business-key column beyond that unique index is documented. ORG_ID and TRANSFER_PRIORITY reflect multi-organization and sequencing concerns.

Common Use Cases and Queries

Because the table is labeled no longer used, primary use cases center on historical investigation and migration validation rather than active transaction processing. Analysts reconstruct payment batches by joining to AP_CHECKS_ALL on CHECK_ID to recover underlying check details.

SELECT sic.SELECTED_CHECK_ID, sic.CHECK_NUMBER, sic.CHECK_AMOUNT,
       sic.VENDOR_NAME, c.CHECK_DATE
FROM   ap.ap_selected_invoice_checks_all sic,
       ap.ap_checks_all c
WHERE  sic.CHECK_ID = c.CHECK_ID
AND    sic.CHECKRUN_NAME = :checkrun_name;

Reporting queries frequently filter on CHECKRUN_NAME to isolate a payment batch, or on STATUS_LOOKUP_CODE and VOID_FLAG to identify voided or ineligible selections. Reconciliation against AP_SELECTED_INVOICES_ALL uses SELECTED_CHECK_ID through the PAY_SELECTED_CHECK_ID and PRINT_SELECTED_CHECK_ID columns to trace which invoices contributed to a given check.

Related Objects

The following objects are the most significant references, based on documented foreign key relationships:

  • AP_INV_SELECTION_CRITERIA_ALL — joined via CHECKRUN_NAME, defining the selection run that produced each check.
  • AP_CHECKS_ALL — joined via CHECK_ID, providing authoritative check payment records.
  • AP_SELECTED_INVOICES_ALL — references this table through PAY_SELECTED_CHECK_ID and PRINT_SELECTED_CHECK_ID, linking invoices to selected checks.
  • PO_VENDORS and PO_VENDOR_SITES_ALL — joined via VENDOR_ID and VENDOR_SITE_ID for payee and address context.
  • AP_BANK_ACCOUNTS_ALL — joined via EXTERNAL_BANK_ACCOUNT_ID for bank account details.
  • FND_CURRENCIES — joined via CURRENCY_CODE for currency definition.
  • ECE_AP_CHECKS_INTERFACE and JL_AR_AP_SUP_AWT_CR_LTS — downstream references using SELECTED_CHECK_ID.

Together these relationships confirm that AP_SELECTED_INVOICE_CHECKS_ALL occupies a central, though legacy, position within the Payables payment selection data model.