Search Results iby_paygroup_pub




Overview
Explore in AI Chat

Overview

IBY_PAYGROUP_PUB is a public PL/SQL package in the APPS schema that forms part of the Oracle Payments (IBY) infrastructure in Oracle E-Business Suite 12.1.1 and 12.2.2. Its primary business function is the construction, validation, and persistence of payment groups and the payment instructions contained within them. During a payment run, Oracle Payments must transform selected documents payable (invoices, credit memos, and similar obligations) into discrete payment records, group those records according to the configured payment process profile, and hand the result to the disbursement and formatting layers. IBY_PAYGROUP_PUB provides the programmatic entry points that orchestrate this transformation, including document grouping logic, payment record creation and update, payment validation, central bank reporting, and the execution of pre- and post-payment hooks. The package carries a PUB classification, indicating that it is intended for supported external invocation rather than as a private implementation detail. The ETRM repository lists eighty-nine documented procedures and functions, and the package is referenced by five other public packages, confirming its role as a shared service within the IBY module.

Key Procedures and Functions

The documented entry points cluster into several functional areas:

  • Payment creation and maintenance: CREATEPAYMENTS, INSERTPAYMENTS, INSERTDOCINTOPAYMENT, UPDATEPAYMENTS, UPDATEDOCSWITHPAYMENTID, GETNEXTPAYMENTID, DELETE_PAYMENTTAB, and DELETE_PMTTABLE handle the assembly of payment records, the association of documents with payments, identifier generation, and cleanup of working tables.
  • Grouping and persistence: PERFORMDOCUMENTGROUPING applies the grouping rules that determine which documents share a payment; PERFORMDBUPDATES commits the resulting changes to the underlying payment and document tables.
  • Validation and hooks: PERFORMPAYMENTVALIDATIONS evaluates validation sets against candidate payments; PERFORMPREHOOKPROCESS and PERFORMPOSTHOOKPROCESS execute customer and product extensions at defined points in the payment lifecycle.
  • Special handling: PERFORMCENTRALBANKREPORTING supports regulatory reporting requirements; FLAGSEPARATEREMITADVICEPMTS identifies payments that require separate remittance advice; ADJUSTSISTERDOCSANDPMTS and ADJUSTSISTERDOCSANDPMTSPOST reconcile related documents and payments before and after processing.
  • Utility functions: GETNUMSUCCESSDOCSPERPAYMENT, GETFXAMOUNT, and GET_EMPLOYEE_FULL_NAME provide supporting calculations and lookups used during payment building.

Tables Accessed

The package reads and writes the core IBY payment tables through APPS synonyms, including IBY_PAYMENTS_ALL and IBY_DOCS_PAYABLE_ALL for the payment and document records themselves, IBY_PMT_CREATION_RULES for the rules governing payment formation, IBY_PAYMENT_PROFILES and IBY_VAL_ASSIGNMENTS for profile and validation configuration, and IBY_VALIDATION_SETS_VL and IBY_VALIDATIONSETS_PUB for validation execution. Party data is drawn from IBY_INTERNAL_PAYERS_ALL and IBY_EXTERNAL_PAYEES_ALL, with bank account details from CE_BANK_ACCOUNTS. Remittance configuration is read from IBY_REMIT_ADVICE_SETUP, service requests from IBY_PAY_SERVICE_REQUESTS, and hook payloads from IBY_HOOK_PAYMENTS_T and IBY_HOOK_DOCS_IN_PMT_T. Supplier information is obtained from AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL, with AP_SYSTEM_PARAMETERS_ALL supplying system-level defaults. Workflow events are raised into WF_EVENT_T.

Usage Notes

IBY_PAYGROUP_PUB is invoked principally by the Oracle Payments payment run and is called from within the disbursement layer, notably by IBY_DISBURSE_SUBMIT_PUB_PKG, IBY_DISBURSE_SINGLE_PMT_PKG, IBY_CHECKNUMBER_PUB, and IBY_SINGPAY_PUB. Standard users interact with its effects indirectly through the Payments Manager and payment process request concurrent programs rather than by calling the package directly. Customizations should restrict themselves to the documented public procedures and to the supported hook mechanisms (pre- and post-hook processing) so that payment grouping and validation behavior remains upgrade-safe. Direct DML against the underlying IBY tables is not supported and can corrupt payment state.