Search Results build_electronic_instructions

Overview

IBY_BUILD_INSTRUCTIONS_PUB_PKG is the public PL/SQL package within the Oracle Payments (IBY) module responsible for creating payment instructions from payment service requests. It is the core engine behind the Oracle Payments instruction build process, translating a caller's request for payment into one or more payment instructions that are subsequently formatted, validated, and transmitted to a payment system or printer. The package sits on the boundary between the payment service request model and the underlying instruction data model, and it is exposed as a public API for consumption by both Oracle E-Business Suite applications and registered external calling applications.

In Oracle EBS 12.1.1 and 12.2.2 the package is owned by APPS and classified as an OTHER API. Its principal entry point, build_pmt_instructions, is designed to run as a concurrent program, generating instructions in batch according to processing criteria supplied by the caller. The header comment documents that the procedure accepts a calling application identifier, a calling-application payment request identifier (which must be unique from that application's perspective and is used by the build program to communicate results back), the internal bank account to pay from, a payment profile, a zero-payment allowance flag, a payment date, and an anticipated value date. The remaining positional parameters exist solely to satisfy the requirement that concurrent-enabled stored procedures submitted from Oracle Forms expose one hundred total arguments. Standard concurrent outputs x_errbuf and x_retcode report success or failure.

Key Procedures and Functions

The ETRM metadata documents ten procedures and functions within the package:

• BUILD_PMT_INSTRUCTIONS — the top-level procedure of the payment instruction creation program; runs as a concurrent program and drives instruction creation from the supplied processing criteria.
• REBUILD_PMT_INSTRUCTION — regenerates a previously built payment instruction, supporting corrections and reprocessing scenarios.
• MOVEINSTRTODEFERREDSTATUS — transitions an instruction into a deferred status, typically when processing cannot complete immediately.
• GET_PAYREQ_ID — returns the payment service request identifier associated with an instruction or build context.
• GET_PAYDOC_ID — returns the payment document identifier linked to the instruction.
• GET_INT_BANK_ACCT_ID — returns the internal bank account identifier used for the payment.
• GET_INSTRUCTION_ATTRIBUTES — retrieves the attribute set associated with a payment instruction.
• PRINT_DEBUGINFO — emits diagnostic information useful when troubleshooting the build process.
• BUILD_ELECTRONIC_INSTRUCTIONS — the variant that builds instructions destined for electronic transmission to a payment system; this is the procedure most commonly associated with the build_electronic_instructions search term.
• BUILD_PRINTED_INSTRUCTIONS — the variant that builds instructions destined for printed output, such as cheque or remittance printing.

Tables Accessed

The package operates against the following documented tables through APPS synonyms:

• IBY_PAY_INSTRUCTIONS_ALL — the primary instructions table; the build procedures insert and update instruction rows here, while the rebuild and status procedures amend existing rows.
• IBY_PAY_SERVICE_REQUESTS — holds the payment service requests raised by calling applications; the build process reads requests and writes back completion or error status against the calling application's request identifier.
• PLITBLM — a PL/SQL table used internally for bulk processing and collection handling during the build.

Usage Notes

build_pmt_instructions is normally invoked as a concurrent program rather than called directly in interactive code, and it is referenced by one other package within the Oracle Payments codebase. Electronic instruction building is reached through BUILD_ELECTRONIC_INSTRUCTIONS, which reflects the same build semantics for payment systems rather than printed documents. Custom code that needs instruction creation should call the public procedures with the documented criteria — calling application, service request identifier, bank account, payment profile, dates, and zero-payment flag — and must respect the calling-application uniqueness requirement on the payment request identifier so that the build program can report status correctly. Because output is only communicated through the concurrent error buffer and return code, callers should inspect these values after every invocation. Debug output from PRINT_DEBUGINFO should be enabled only during diagnostics, as it produces significant log volume in high-volume payment runs.