Search Results minimum_payment_amount

Overview

IBY_PAY_SERVICE_REQUESTS is a core table within the Oracle Payments (IBY) module of Oracle E-Business Suite, holding the metadata that defines a payment service request. A payment service request is the configuration record through which a calling application — most commonly Payables, Receivables, or Payroll — declares how its payment documents should be processed by the payments engine. It binds a calling application and an application-defined request code to the processing rules, bank account, payment profile, amount thresholds, and rejection behavior that govern batch payment instruction creation.

The table participates in the standard Oracle Payments processing flow: documents are selected for a payment service request, payment instructions are generated against it, and payment documents are produced. Because internal bank accounts and payment profiles are attached to the request, the record effectively controls which disbursement account funds a given payment run and which payment format and validation rules apply.

From a Data Vault modeling perspective, the metadata classifies this object as satellite-leaning. This is a heuristic classification, but it aligns with the table's structure: the primary key is a surrogate identifier, the record carries descriptive and behavioral attributes, and the table sits at the center of a large set of foreign-key relationships rather than functioning as a pure reference hub or pure association link.

Key Information Stored

The table is physically owned by the IBY schema and contains 39 documented columns in ETRM 12.2.2. The most significant columns are:

• PAYMENT_SERVICE_REQUEST_ID — the surrogate primary key, backed by IBY_PAY_SERVICE_REQUESTS_PK. This is the value propagated into child tables.
• CALLING_APP_ID and CALL_APP_PAY_SERVICE_REQ_CODE — the business-key candidate pair, enforced by unique index IBY_PAY_SERVICE_REQUESTS_U2. Together they identify the owning application and its internal request code.
• PAYMENT_SERVICE_REQUEST_STATUS — the current state of the request.
• PROCESS_TYPE — the processing mode applied to documents submitted through the request.
• INTERNAL_BANK_ACCOUNT_ID — foreign key to CE_BANK_ACCOUNTS, identifying the internal disbursement bank account.
• PAYMENT_PROFILE_ID — foreign key to IBY_ACCT_PMT_PROFILES_B, the payment profile controlling format and validation.
• MINIMUM_PAYMENT_AMOUNT and MAXIMUM_PAYMENT_AMOUNT — the accepted payment amount range.
• PAYMENT_DOCUMENT_ID, CREATE_PMT_INSTRUCTIONS_FLAG, and ALLOW_ZERO_PAYMENTS_FLAG — behavior flags governing instruction and document creation.
• DOCUMENT_REJECTION_LEVEL_CODE, PAYMENT_REJECTION_LEVEL_CODE, and REQUIRE_PROP_PMTS_REVIEW_FLAG — control how validation failures and rejected payments are handled.
• OBJECT_VERSION_NUMBER plus the standard who-columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) — concurrency control and audit.
• ATTRIBUTE_CATEGORY through ATTRIBUTE15 — the flexible descriptive flexfield.

The presence of both the surrogate PK and the (CALLING_APP_ID, CALL_APP_PAY_SERVICE_REQ_CODE) unique index means integrators should key external lookups on the natural pair and reserve the surrogate for internal joins.

Common Use Cases and Queries

Typical reporting and diagnostic scenarios include identifying all payment service requests for a given application, retrieving the bank account and profile assigned to a request, and tracing payment instructions or payable documents back to their originating request.

SELECT psr.payment_service_request_id,
       psr.calling_app_id,
       psr.call_app_pay_service_req_code,
       psr.payment_service_request_status,
       psr.process_type,
       psr.internal_bank_account_id,
       psr.payment_profile_id
  FROM iby.iby_pay_service_requests psr
 ORDER BY psr.creation_date;

SELECT ii.payment_instruction_id,
       ii.payment_service_request_id,
       psr.call_app_pay_service_req_code
  FROM iby.iby_pay_instructions_all ii,
       iby.iby_pay_service_requests   psr
 WHERE ii.payment_service_request_id = psr.payment_service_request_id
   AND psr.payment_service_request_status = :status;

Additional uses include reconciling the count of payable documents against a request, verifying amount thresholds before a payment batch is released, and validating that a required payment profile is active prior to instruction creation.

Related Objects

The table is heavily referenced and participates in several documented foreign-key relationships:

• CE_BANK_ACCOUNTS — joined via INTERNAL_BANK_ACCOUNT_ID.
• IBY_ACCT_PMT_PROFILES_B — joined via PAYMENT_PROFILE_ID.
• IBY_DOCUMENTS_PAYABLE_H — child table joined via PAYMENT_SERVICE_REQUEST_ID.
• IBY_PAY_INSTRUCTIONS_ALL — child table joined via PAYMENT_SERVICE_REQUEST_ID.
• IBY_HOOK_PAYMENTS_T — referencing table joined via PAYMENT_SERVICE_REQUEST_ID.

Together these objects form the operational backbone of Oracle Payments: the request defines the rules, the documents and instructions instantiate the work, and the bank account and profile resolve the financial and formatting context.