Search Results validate_input

Overview

APPS.IEX_PAYMENTS_PUB is a public PL/SQL package body in the Oracle E-Business Suite Advanced Collections (IEX) application, registered under application ID 695. It exposes the payments application programming interface used by Oracle EBS Release 12.1.1 and 12.2.2 to create and query collections payment records. The package serves as the supported integration point through which external modules, forms, and batch processes submit payment information for delinquent customers, including payer identification and payment application against receivables activity. Its API classification is PUB, indicating that the procedures are intended for documented, supported invocation by other code rather than for internal-only use. The package header defines the strongly typed records and PL/SQL tables — including PMT_REC_TYPE, PMTDTLS_TBL_TYPE, and PMTINSTR_REC_TYPE — that carry payment header details, payment detail lines, and payment instrument attributes into the API. Private validation logic, illustrated by the internal validate_input procedure, enforces domain constraints on inbound parameters before any database changes are attempted, raising FND_API.G_EXC_ERROR with the standardized IEX_BAD_API_INPUT message when input fails validation. Debug tracing is emitted through IEX_DEBUG_PUB and FND_LOG when the runtime logging level permits, and package globals capture FND_GLOBAL session identifiers together with the IEX_ONLINE_CCPAY profile option value.

Key Procedures and Functions

• CREATE_PAYMENT — The primary public entry point for submitting a new collections payment. It accepts the payment header record, the payment detail table, and the payment instrument record, validates the supplied values, and persists the resulting payment and its associated cross-reference rows. Validation failures raise the standard FND_API error exception and populate the FND message stack with the offending API parameter name.
• GET_PAYER_INFO — A query-oriented public routine that returns payer information for a given payment or customer context, supporting callers that must resolve the paying party before or after payment creation.

Both procedures are documented in the ETRM 12.2.2 metadata. The internal validate_input procedure is not part of the public contract but is material to understanding the package, since it demonstrates that CREATE_PAYMENT rejects null or unrecognized PAYMENT_TARGET values, accepting only ACCOUNTS, INVOICES, CNSLD, and CONTRACTS before proceeding to further checks such as total amount verification.

Tables Accessed

• IEX_PAYMENTS_S — The base payment entity; CREATE_PAYMENT inserts and maintains payment rows here.
• IEX_DEL_PAY_XREF_S — Cross-reference linking payments to delinquency records.
• IEX_PAY_RECEIPT_XREF_S — Cross-reference associating payments with receipts.
• IEX_RECEIPT_NUMBER_S — Sequence source for generating receipt numbers.
• IEX_DELINQUENCIES — Delinquency data consulted to validate and contextualize the payment.
• HZ_PARTIES — TCA party records used to resolve payer identity.
• DUAL and PLITBLM — Utility references used for scalar computation and PL/SQL table handling.

Usage Notes

IEX_PAYMENTS_PUB is invoked from Collections forms, concurrent programs, and custom extensions that need to record or retrieve payment data. The ETRM metadata records one dependent package referencing it, so custom code should treat CREATE_PAYMENT and GET_PAYER_INFO as the stable interface and avoid direct DML against the underlying IEX payment tables. Callers must supply fully populated typed records and handle FND_API.G_EXC_ERROR, inspecting the FND message stack for the failing parameter identified by the IEX_BAD_API_INPUT token.