Search Results case_type

Overview

The PL/SQL package body APPS.IBY_CE_BATCH_RECON_PKG provides the integration bridge between Oracle Payments (IBY) payment instructions and Oracle Cash Management (CE) bank statement reconciliation in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Its central purpose is the automated reconciliation of IBY payment instructions against bank statement lines at the payment batch level. As noted in the package header comments, the logic was copied from AP_RECONCILIATION_PKG (version 115.43), which performed the analogous function for legacy Oracle Payables payment batches, and was re-engineered to support the R12 payment instruction model.

Cash Management supports only automatic reconciliation at the batch level, with no manual clearing for these transactions. The package therefore performs amount proration across the transactions within an instruction — mirroring the approach used in Payables — and then invokes product-level APIs at the individual transaction level so that each product can execute its own business logic. A significant constraint documented in the header is that, although R12 payment instructions can span multiple currencies and organizations, CE batch reconciliation supports only a single currency per batch, and organizations are not considered during the reconciliation. The package also exposes a module name used by the application debugging framework (iby.plsql.IBY_CE_BATCH_RECON_PKG) and declares a global abort exception, G_abort_it, for terminating processing abnormally.

Key Procedures and Functions

• PAYMENT_INSTRUCTION_CLEARING — The primary public procedure, invoked by Cash Management to clear an IBY payment instruction against matched bank statement activity. It accepts the payment instruction identifier along with accounting, cleared, and actual value dates; transaction, error, and charge amounts in the bank currency; bank currency code; exchange rate type, date, and rate between the payment and functional currencies; a matched flag; a pass-in mode returned to CE; and the statement line identifier. The procedure prorates the reconciled amounts across the payment instruction's transactions and calls downstream product APIs for transaction-level processing.
• PAYMENT_INSTRUCTION_UNCLEARING — Reverses a prior clearing action, restoring the payment instruction and its transactions to an unreconciled state when a bank statement line is unmatched or corrected.

The package additionally contains a private helper function, Case_Type, which accepts the bank, payment, and functional currency codes and returns a currency-case classification. This classification drives the correct proration and exchange-rate handling logic, since the relationship between bank, payment, and functional currencies determines how amounts must be converted and distributed. Its presence reflects the CASE_TYPE search context: it is an internal determination used by the clearing and unclearing routines.

Tables Accessed

The package reads and writes the following tables through APPS synonyms:

• IBY_PAY_INSTRUCTIONS_ALL and IBY_PAYMENTS_ALL — the payment instruction and payment records being reconciled or uncleared.
• IBY_PAY_SERVICE_REQUESTS — payment service request records associated with the instruction.
• AP_CHECKS and AP_CHECKS_ALL — the underlying Payables payment documents, accessed for amount and status information.
• AP_PAYMENT_HISTORY — payment action history used to validate and update document state.
• AP_SYSTEM_PARAMETERS — Payables system options influencing reconciliation behavior.
• CE_CASHFLOWS and CE_CASHFLOW_ACCT_H — Cash Management cashflow records and their accounting history, which are created or updated to reflect clearing.
• CE_PAYMENT_TRANSACTIONS — the CE payment transaction rows representing cleared or uncleared items.
• CE_SECURITY_PROFILES_GT — a global temporary table used for security profile filtering.

Usage Notes

IBY_CE_BATCH_RECON_PKG is an internal integration API rather than an end-user-facing component. It is normally invoked by the Cash Management reconciliation engine — either through the Automatic Reconciliation concurrent program or the reconciliation workflow — when matching statement lines to R12 payment instruction batches. It is referenced by one other package in the ETRM metadata, confirming its role as a called dependency rather than a top-level entry point. Extension developers should not call PAYMENT_INSTRUCTION_CLEARING or PAYMENT_INSTRUCTION_UNCLEARING directly unless they fully replicate the CE calling context, including valid statement line identifiers and correct bank-currency amounts. Because clearing performs proration and then delegates to product APIs, any custom logic required during reconciliation is more appropriately implemented in the downstream product hooks than in this package. The version stamp (120.7.12010000.2, dated 2008) indicates the package has remained stable across the 12.1.1 and 12.2.2 releases.