Search Results spec_revision

Overview

APPS.CE_HEADER_INTERFACE_ERRORS_PKG is a small, utility-oriented PL/SQL package body belonging to the Cash Management (CE) module of Oracle E-Business Suite. Its purpose is to centralize error logging for the bank statement header interface. When inbound bank statement data is loaded into the CE_HEADER_INTERFACE staging area — whether through the Bank Statement Open Interface, a custom loader, or a reconciliation program — records that fail validation must be captured so that they can be reviewed and corrected. This package provides the standard insert and delete operations against the CE_HEADER_INTERFACE_ERRORS table that record such failures. The package is classified in ETRM as "OTHER," indicating that it is an internal implementation package rather than a formal public API, and it is referenced by one other package in the application schema. It carries no business logic beyond row maintenance; its value lies in standardizing how error rows are written, including defaulting conventions and audit columns.

Key Procedures and Functions

The package exposes five documented program units, comprising two revision-reporting functions and three data-manipulation procedures.

• SPEC_REVISION — Returns the revision string of the package specification. In the documented source it returns the global G_spec_revision, the conventional Oracle Applications mechanism for exposing a version marker so that callers or diagnostic utilities can identify which package revision is installed.
• BODY_REVISION — Returns the revision string of the package body, sourced from the $Revision keyword embedded in the header comment. Together with SPEC_REVISION it supports version verification and dependency diagnosis.
• INSERT_ROW — Documented in two overloaded forms. The first writes an error row using the application short name defaulted internally to 'CE'. The second accepts an explicit application short name, allowing errors originating from other application contexts to be logged. Both forms populate the statement number, bank account number, and message name columns, defaulting any null input to the literal 'NONE', and stamp the creation date from SYSDATE and the creating user from FND_GLOBAL.USER_ID (defaulting to -1 when no session user exists).
• DELETE_ROW — Removes error rows for a given statement number and bank account number. The deletion predicate deliberately also matches rows whose bank account number is 'NONE', ensuring that header-level errors recorded without an account can be cleared alongside account-specific errors.

Tables Accessed

The package touches a single table, CE_HEADER_INTERFACE_ERRORS, accessed through the APPS synonym. INSERT_ROW performs inserts into this table, supplying the application short name, statement number, bank account number, message name, creation date, and created-by columns. DELETE_ROW performs a conditional delete keyed on statement number and bank account number. The table serves as a persistent error repository for bank statement header interface processing; rows written here signal that a candidate statement header could not be accepted, and the message name column carries the identifier of the diagnostic message explaining the failure.

Usage Notes

This package is an internal helper rather than a user-facing API. It is most commonly invoked from the bank statement open interface and statement reconciliation programs when header-level validation fails, and from any custom loader that stages data into CE_HEADER_INTERFACE_ERRORS. Because the insert procedures encapsulate the 'NONE' defaulting convention and the audit column population, callers should use them rather than issuing direct SQL, ensuring consistency with Oracle's own error rows. The delete procedure is typically called during reprocessing or cleanup, after a user has corrected the underlying statement data and the prior error entry is no longer relevant. Two operational cautions apply. First, DELETE_ROW removes rows matching the supplied statement number whenever the bank account number matches or is 'NONE'; a statement number that is reused across accounts could therefore clear more rows than intended. Second, the 'NONE' sentinel is a literal value, so a legitimate account or statement literally named 'NONE' would collide with the defaulting scheme. Custom code should treat this package as a stable but undocumented utility and avoid extending it in place; new error-handling logic is better placed in a custom package that calls these procedures. The revision functions can be queried to confirm the installed package version when troubleshooting statement interface failures.