Search Results max_payment_amt_2




Overview

IBY_PAYMENT_FORMAT_VAL_PVT is a private PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It forms part of the payment instruction validation infrastructure within the Payments (IBY) module, and its declared AUTHID CURRENT_USER clause indicates that it executes with the privileges of the invoking user rather than the definer. The package encapsulates the format-specific validation rules that Oracle Payments applies to payment instructions before they are formatted and transmitted to a payment system. Within the Oracle Payments architecture, format validation is one of the last gating steps in the payment process: a payment instruction must pass these validations before the corresponding payment document or file can be produced. Because the package is classified as a private (PVT) API, it is not part of the public integration surface; instead it is called internally by the payment validation engine and by other packages in the validation stack. The documentation references two dependent packages that invoke it, confirming its role as a subordinate validation routine rather than an entry point for external callers.

The version header in the source, ibyfvvls.pls 120.10 2010/05/09, establishes that the same body has been carried forward largely unchanged across the 12.1.1 and 12.2.2 releases, so the behavioral contract described in ETRM applies to both versions.

Key Procedures and Functions

The package exposes 23 documented procedures, each responsible for a discrete validation or supporting operation against a payment instruction. Validation procedures generally accept a format name, an instruction identifier, and the standard error-collection parameters p_docErrorTab and p_docErrorRec, returning an error code and message to the caller.

  • SCHEDULE_NUMBER — validates the schedule number associated with the payment instruction.
  • SUPPLIER_TYPE — enforces employee versus non-employee payee rules by format. Certain formats (for example FVTPCCD, FVTIACHP, FVSPCCD) permit only non-employees; others (for example FVTPPPD, FVSPPPD, FVBLPPDP) permit only employees; a third group (for example FVTIACHB, FVBLNCR, FVSPNCR) requires that all payees be of one consistent type.
  • TREASURY_SYMBOLS_PROCESS — inserts treasury symbols together with the associated amount into FV_TP_TS_AMT_DATA so that maximum treasury symbol limits can subsequently be evaluated.
  • MAX_TREASURY_SYMBOLS — checks aggregate amounts against configured maximum treasury symbol thresholds.
  • AGENCY_ADDRESS and PAYEE_ADDRESS — validate the agency and payee address data required by the payment format.
  • MAX_PAYMENT_AMT and MAX_PAYMENT_AMT_2 — enforce maximum payment amount limits.
  • PAY_TAX_BENEFIT and PAY_SALARY_TRAVEL — apply payment-type rules for tax benefit and salary/travel payments.
  • PAYEE_SSN — validates the payee Social Security Number.
  • TAS_VALIDATION, AGENCY_LOCATION_CODE, and RTN_NUMBER — validate Treasury Account Symbol, agency location code, and bank routing number respectively.
  • PAY_ALONE_OPTION — verifies the pay-alone processing option.
  • DEPOSITER_ACC_NUM — validates the depositor account number, the term most frequently associated with user searches and payment-format troubleshooting.
  • ACCOUNT_TYPE and RFC_ID — validate the bank account type and the routing/format code identifier.
  • MANDATORY_PPD_PPDP_REASON_CODE — requires a reason code for the relevant PPD/PPDP formats.
  • LOG_ERROR_MESSAGES — writes accumulated validation failures to the transaction error table so they are visible to the user.

Tables Accessed

The package reads and writes a mix of payments, payables, banking, and federal financial tables through APPS synonyms:

Usage Notes

Because IBY_PAYMENT_FORMAT_VAL_PVT is a private package, it is not intended to be called directly from external integrations. It is invoked by the Oracle Payments format validation flow, typically when a user submits a payment instruction for formatting from the Payments workbench or when a validation concurrent program processes a batch of payment instructions. The procedures are designed to be executed in sequence under the control of the calling validation driver, which accumulates errors through the p_docErrorTab and p_docErrorRec parameters and then calls LOG_ERROR_MESSAGES to persist them. Custom code that extends payment format validation should follow the same pattern, passing an initialized error collection and honoring the returned x_error_code and x_error_mesg values. Troubleshooting searches such as "depositer_acc_num" generally lead to the DEPOSITER_ACC_NUM procedure, and failures reported against it should be traced to the underlying bank account setup in CE_BANK_ACCOUNTS and IBY_EXT_BANK_ACCOUNTS rather than to the package itself.