Search Results build_printed_instructions




Overview
Explore in AI Chat

Overview

IBY_BUILD_INSTRUCTIONS_PUB_PKG is the public PL/SQL package within the Oracle Payments (IBY) module of Oracle E-Business Suite that drives the creation of payment instructions. It is the programmatic entry point used by the payment instruction creation program, executing as a concurrent program, and it is responsible for assembling payment documents — both printed and electronic — from payment service requests generated by calling applications. The package header carries the identifier ibypayis.pls and is dated 2008 in the shipped 12.1.1 and 12.2.2 file systems, indicating it is a long-standing component of the Oracle Payments architecture. Its classification within ETRM is OTHER, reflecting that it is a public API surface rather than a seeded concurrent program or form-bound library. The package mediates between a calling application's payment obligations and the internal bank account from which funds will be disbursed, ensuring that payments are grouped, validated, and formatted according to the applicable payment profile before being released to print or transmission.

Key Procedures and Functions

  • BUILD_PMT_INSTRUCTIONS — The top-level procedure of the payment instruction creation program. It runs as a concurrent program and orchestrates the entire build cycle, accepting the calling application identifier and payment service request identifier, the internal bank account, the payment profile, zero-payment allowance, payment date, and anticipated value date. It returns the standard concurrent program error buffer and return code.
  • BUILD_PRINTED_INSTRUCTIONS — Builds payment instructions destined for printed output, producing formatted payment documents. This is the procedure most commonly associated with the search term build_printed_instructions.
  • BUILD_ELECTRONIC_INSTRUCTIONS — Builds payment instructions for electronic transmission, generating the payment file content rather than a printed document.
  • REBUILD_PMT_INSTRUCTION — Regenerates a previously created payment instruction, typically after a change in payment parameters or a failed prior build.
  • MOVEINSTRTODEFERREDSTATUS — Moves payment instructions into a deferred status, removing them from the active build or transmission queue.
  • GET_PAYREQ_ID — Retrieves the payment service request identifier associated with the calling application's reference.
  • GET_PAYDOC_ID — Retrieves the payment document identifier for a given instruction context.
  • GET_INT_BANK_ACCT_ID — Returns the internal bank account identifier used as the disbursement source.
  • GET_INSTRUCTION_ATTRIBUTES — Returns the attribute set describing a payment instruction.
  • PRINT_DEBUGINFO — Emits diagnostic information to assist with troubleshooting build failures.

Tables Accessed

  • IBY_PAY_INSTRUCTIONS_ALL — The primary table holding payment instruction records. The build procedures insert and update rows here as instructions are created, modified, or moved to deferred status.
  • IBY_PAY_SERVICE_REQUESTS — Stores the payment service requests submitted by calling applications. The package reads this table to identify the payment obligations that must be converted into instructions.
  • PLITBLM — A standard PL/SQL table used for in-memory parameter passing and batching during processing.

Usage Notes

IBY_BUILD_INSTRUCTIONS_PUB_PKG is normally invoked indirectly. In standard Oracle Payments flows, the Build Payments concurrent program calls BUILD_PMT_INSTRUCTIONS, which in turn dispatches to BUILD_PRINTED_INSTRUCTIONS or BUILD_ELECTRONIC_INSTRUCTIONS depending on the payment profile and payment method configured. The procedure signature intentionally includes the p_args10 through p_args100 parameters mandated for any stored procedure submitted from Oracle Forms as a concurrent request, bringing the total argument count to one hundred. Custom code should call only the documented public procedures and must respect the calling application identifier and payment service request identifier contract; the building program communicates results back to the calling application using that request identifier. The package is referenced by one other package within APPS, reinforcing that direct calls are rare outside the supported Oracle Payments build path. WHERE the metadata does not document parameter lists, integrators should obtain signatures from the deployed package specification rather than assuming argument order.