Search Results get_payreq_list

Overview

The APPS.IBY_DISBURSE_SUBMIT_PUB_PKG package is a public PL/SQL API within the Oracle Payments (IBY) module of Oracle E-Business Suite. It owns the application logic that assembles payments into disbursement service requests and submits them to the payment system for processing. In effect, it is the bridge between payment instruction records created upstream (for example through Payment Process Requests and pay runs) and the downstream disbursement engine that communicates with payment systems, formats, and financial institutions.

The package is classified as OTHER in the ETRM catalog and is owned by the APPS schema. Its business role is to take a selected set of documents payable and their associated payee, bank account, payment method, and payment profile data, consolidate them into a payment service request, and hand that request to the disbursement submission flow. Because it is a public package with a stable interface, it is invoked both by seeded Oracle Payments components and by other public APIs in the IBY family, including IBY_ASSIGN_PUB, IBY_BUILD_INSTRUCTIONS_PUB_PKG, IBY_CHECKNUMBER_PUB, IBY_DISBURSEMENT_COMP_PUB, IBY_DISBURSE_SINGLE_PMT_PKG, and IBY_PAYGROUP_PUB. Dependency metadata places this package among the core hubs of the disbursement submodule.

Key Procedures and Functions

The ETRM metadata documents twenty-three procedures and functions across the package specification and body. The primary entry point is SUBMIT_PAYMENT_PROCESS_REQUEST, which drives submission of a payment process request for disbursement. Several routines support payment request lifecycle management: INSERT_PAYREQ creates a payment service request record; GETNEXTPAYREQID allocates the next request identifier; and GET_PAYREQ_LIST and GET_PAYREQ_STATUS retrieve existing requests and their processing status. Document-level persistence is handled by INSERT_PAYREQ_DOCUMENTS, GETNEXTDOCUMENTPAYABLEID, and GETNEXTDOCUMENTPAYABLELINEID, which insert documents payable and obtain their primary and line identifiers. Validation and derivation logic is provided by CHECKIFDUPLICATE (duplicate detection), DERIVEPAYEEIDFROMCONTEXT and DERIVEEXACTPAYEEIDFROMCONTEXT (payee identification from context), and DERIVEDISTINCTACCESSTYPSFORREQ with INSERTDISTINCTACCESSTYPSFORREQ, which determine and persist distinct access types for a request. Profile and payment document handling is covered by SET_PROFILE_ATTRIBS, GET_PROFILE_PROCESS_ATTRIBS, and CHECKIFDEFAULTPMTDOCONPROFILE. Status guards include CHECKIFPMTSINMODIFIEDSTATUS and CHECKIFPMTSINMODBANKACCSTATUS, while PRINT_DEBUGINFO provides diagnostic output. DELETE_DOCSPAYTAB removes documents payable from the working table.

Tables Accessed

The package reads and writes a wide set of IBY and common application tables. Payment core data is stored in IBY_PAY_SERVICE_REQUESTS (submission requests), IBY_DOCS_PAYABLE_ALL and its sequence view IBY_DOCS_PAYABLE_ALL_S (documents payable), and IBY_DOCUMENT_LINES with IBY_DOCUMENT_LINES_S (document line detail). Payee and bank information comes from IBY_EXTERNAL_PAYEES_ALL, IBY_EXT_BANK_ACCOUNTS_V, CE_BANK_ACCOUNTS, CE_BANK_BRANCHES_V, and CE_PAYMENT_DOCUMENTS. Configuration and control tables include IBY_PAYMENT_METHODS_B, IBY_PAYMENT_PROFILES, IBY_SYS_PMT_PROFILES_B, IBY_PMT_CREATION_RULES, IBY_PROCESS_FUNCTIONS, IBY_PROCESS_ORGS, and IBY_GEN_DOCS_PAYABLE. Diagnostics and setup lookups rely on FND_LOG and FND_APPLICATION.

Usage Notes

IBY_DISBURSE_SUBMIT_PUB_PKG is invoked in three principal ways. First, seeded Oracle Payments concurrent programs and flows — notably Payment Process Request submission and pay-run disbursement — call its submission routines internally. Second, it is called by other public IBY packages during assignment, instruction building, check numbering, and disbursement completion. Third, extensions and custom code may invoke it when submitting payments programmatically, for example to re-drive a failed request or to submit documents assembled outside the standard payment process request. The package is documented as VALID and is referenced by six dependent packages. Custom callers should rely on the public routines and should not bypass validation procedures such as CHECKIFDUPLICATE or the status guards, since these protect against duplicate submissions and modifications to payments in disallowed states.