Search Results ap_check_stocks_all




Overview
Explore in AI Chat

Overview

The AP_CHECK_STOCKS_ALL table is a legacy data object within the Oracle E-Business Suite Payables (AP) module. Its primary historical purpose was to manage and track physical check stock used for generating payments to suppliers. This table functioned as a central repository for defining different batches or types of pre-printed check forms associated with specific bank accounts, including configuration for related accounting entries. However, as explicitly stated in the official ETRM documentation, this table is marked with the status "No Longer Used" in releases 12.1.1 and 12.2.2. This indicates that while the table structure remains in the database for potential upgrade compatibility, its business logic has been superseded by other application features, and it is not actively maintained or referenced by core payment processing workflows in these versions.

Key Information Stored

Based on the provided metadata, the table's structure reveals the type of information it was designed to hold. The primary identifier is the CHECK_STOCK_ID. A unique key constraint also existed on the combination of BANK_ACCOUNT_ID and NAME, enforcing unique check stock names per bank account. Critical foreign key relationships define its links to other modules: BANK_ACCOUNT_ID links to AP_BANK_ACCOUNTS_ALL, and CHECK_FORMAT_ID links to AP_CHECK_FORMATS. The table also stored several General Ledger (GL) code combination IDs (CCIDs) to define accounts for various payment-related scenarios, including FUTURE_PAY_CODE_COMBINATION_ID, BANK_CHARGES_CCID, BANK_ERRORS_CCID, and CASH_CLEARING_CCID. These columns underscore its role in configuring the accounting impact of check transactions.

Common Use Cases and Queries

Given its deprecated status, direct operational use cases or reporting against AP_CHECK_STOCKS_ALL in EBS 12.1.1/12.2.2 are non-existent and strongly discouraged. The table is considered obsolete. Any historical data present would be a relic from a prior implementation or version. Consequently, standard reporting or integration should not reference this object. If encountered during data analysis or a custom code review, the appropriate action is to investigate and migrate any logic to the current payment setup and bank model as defined in the Oracle Payables User Guide. Sample queries are not provided as they would serve no functional purpose in the current system.

Related Objects

The foreign key constraints detailed in the metadata clearly map the table's former integration points within the Payables schema. It was referenced by several transactional and setup tables, including AP_CHECKS_ALL (linking checks to a stock definition), AP_INV_SELECTION_CRITERIA_ALL (likely used in payment batch criteria), and AP_PBATCH_SET_LINES_ALL (related to payment batch sets). As a parent table, it was linked to key reference tables: AP_BANK_ACCOUNTS_ALL for bank details, AP_CHECK_FORMATS for layout, and GL_CODE_COMBINATIONS for accounting. The persistence of these foreign key constraints in the database schema, despite the table's obsolete status, is typical for maintaining referential integrity during application upgrades.