Search Results ce_payment_documents




Overview

CE.CE_PAYMENT_DOCUMENTS is a Cash Management (CE) base table that stores the definition and inventory of payment documents used by an organization to issue payments from its internal bank accounts. A payment document in Oracle EBS is the physical or electronic instrument — a numbered check, a manual check, a wire transfer form, or an electronic format — against which payments are created during the payment process. The table holds both the descriptive setup of each document (name, category, paper stock, remittance stub rules) and the numeric range inventory that governs document numbering and consumption.

The table is owned by the CE schema and is VALID in both 12.1.1 and 12.2.2. The documented physical schema for 12.2.2 exposes 37 columns. The presence of the standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) plus OBJECT_VERSION_NUMBER confirms this is an OAF-managed, multi-org-aware transactional setup entity maintained through the Cash Management payment document definition UI.

From a dimensional modeling perspective, the FK metadata classifies this table heuristically as standalone. This suggests the object is best modeled as a satellite-like reference entity attached to the internal bank account and payment instruction context, rather than as a pure hub or link. Modeling it as a standalone satellite is a reasonable design suggestion, since it holds descriptive attributes keyed by a surrogate identifier rather than acting as an associative junction.

Key Information Stored

The surrogate primary key is PAYMENT_DOCUMENT_ID, which uniquely identifies each payment document record and is the join key used throughout the payment and reconciliation schema. Business-key candidates center on the document name and category combination, and on the numbering attributes that must remain unique per document.

The most significant columns include:

Common Use Cases and Queries

Typical queries retrieve active documents for a given internal bank account, audit document number consumption for void and reissue reconciliation, or join to payment instructions to resolve format details.

  • List active payment documents for an account: SELECT PAYMENT_DOCUMENT_ID, PAYMENT_DOCUMENT_NAME, PAYMENT_DOC_CATEGORY FROM CE_PAYMENT_DOCUMENTS WHERE INTERNAL_BANK_ACCOUNT_ID = :p_account AND (INACTIVE_DATE IS NULL OR INACTIVE_DATE > SYSDATE);
  • Track remaining document numbers: compare LAST_ISSUED_DOCUMENT_NUMBER against LAST_AVAILABLE_DOCUMENT_NUMBER to flag documents nearing exhaustion.
  • Join documents to their payment instructions: SELECT d.PAYMENT_DOCUMENT_NAME, d.FORMAT_CODE, i.PAYMENT_INSTRUCTION_NAME FROM CE_PAYMENT_DOCUMENTS d, IBY_PAY_INSTRUCTIONS_ALL i WHERE d.PAYMENT_INSTRUCTION_ID = i.PAYMENT_INSTRUCTION_ID;
  • Reporting identifies manual-only documents via MANUAL_PAYMENTS_ONLY_FLAG and remittance configuration via ATTACHED_REMITTANCE_STUB_FLAG.

Related Objects

The documented FK relationship anchors this object to the payments subsystem:

  • IBY_PAY_INSTRUCTIONS_ALL — joined on PAYMENT_INSTRUCTION_ID; the sole documented foreign key and the primary parent for format and instruction context.
  • CE_PAYMENT_DOCUMENTS is referenced during payment creation and formatting, so records in payment and reconciliation tables carry PAYMENT_DOCUMENT_ID as a lookup.
  • Internal bank account definitions, referenced through INTERNAL_BANK_ACCOUNT_ID, supply the account-side context.
  • The Cash Management payment document definition UI and the Payments API layer consume this table to validate document availability and numbering during payment processing.

Consumers should always filter on INACTIVE_DATE to exclude retired documents from operational use while preserving them for historical reporting.