Search Results iby_offlinedb_pkg




Overview

IBY_OFFLINEDB_PKG is an Oracle Payments (IBY) PL/SQL package owned by the APPS schema. Its name indicates that it serves the offline payment processing and offline database layer of Oracle Payments, the module responsible for payment instruction creation, payment formatting, and settlement processing across Payables, Receivables, Payroll, and other source products. In Oracle EBS 12.1.1 and 12.2.2, the IBY schema-based architecture moved payment processing into a centralized framework, and packages such as IBY_OFFLINEDB_PKG provide the scheduling and persistence logic that supports batch-oriented, offline generation of payment records.

The package is classified as OTHER in the ETRM metadata, meaning it is not a formally published public API but an internal supporting package. Its status is VALID in the APPS schema. The bulk of its documented behavior concerns scheduling payment batches and individual payments, validating the existence of requests, batches, and instructions, and persisting payment transactions into the IBY transaction tables.

Key Procedures and Functions

The ETRM metadata documents eleven procedures and functions. No parameter lists are published, so only their purposes are described here.

  • SCHEDULECC — Schedules credit card payment processing for offline execution.
  • SCHEDULEPC — Schedules payment processing for a payment batch or payment process request context.
  • SCHEDULECCCANCEL — Schedules cancellation of credit card payments previously submitted for offline processing.
  • SCHEDULECCBATCH — Schedules a credit card batch for offline processing.
  • SCHEDULESET — Schedules a set of payments for offline handling; the general-purpose scheduling entry point.
  • SCHEDULESETOTHER — Schedules payment sets of a type other than the standard categories handled by SCHEDULESET.
  • SCHEDULESETCANCEL — Schedules cancellation of a payment set.
  • SCHEDULESETBATCH — Schedules a payment set at the batch level.
  • REQUESTEXISTS — Validation function that confirms whether a concurrent request already exists, used to prevent duplicate submissions.
  • BATCHEXISTS — Validation function that confirms whether a payment batch record already exists.
  • INSTREXISTS — Validation function that confirms whether a payment instruction record already exists.

Collectively, these routines implement an idempotent scheduling layer: the EXISTS functions guard against redundant scheduling, while the SCHEDULE* procedures write the appropriate offline records.

Tables Accessed

The package references the following tables, primarily through APPS synonyms:

  • IBY_BATCHES_ALL and IBY_BATCHES_S — Payment batch headers; the package reads batch state and writes scheduling/status information.
  • IBY_TRXN_CORE — The core payment transaction table where individual payment instructions are stored.
  • IBY_TRXN_EXTENDED — Extended attributes for payment transactions.
  • IBY_TRXN_SUMMARIES_ALL and IBY_TRXNSUMM_MID_S — Transaction summary and intermediate summary tables used to aggregate payment totals.
  • IBY_TANGIBLE — Tangible (non-electronic) payment details, relevant for printed or manually processed payments.
  • IBY_CREDITCARD — Credit card payment data supporting the credit card scheduling routines.
  • IBY_PAYEE — Payee information used during payment record construction.
  • IBY_BEPKEYS — Bank error/exception processing keys supporting payment error handling.
  • DUAL — Used by the EXISTS validation functions for lightweight existence checks.

Usage Notes

IBY_OFFLINEDB_PKG is invoked internally by the Oracle Payments payment processing flow, typically from the Payment Process Request (PPR) and payment batch lifecycle. It is commonly reached through concurrent programs that build and format payments, and through forms in the Payments Manager responsibility when a user submits, cancels, or reschedules a payment batch. Because it is an OTHER-classified package and not a published API, custom code should not call it directly; Oracle does not guarantee its signature across patches. The package is referenced by zero other packages in the ETRM dependency listing, confirming its role as a leaf-level utility consumed by higher-level IBY logic rather than a shared dependency. The dependency metadata shows the package body itself is self-referencing, which is typical of overloaded or mutually recursive internal routines.