Search Results payment_request

Overview

APPS.IBY_PAY_REQUEST_SEC_V is a security-filtered view over the Oracle Payments payment service request repository. In Oracle EBS 12.1.1 and 12.2.2, the Payments module stores payment requests (payment batches, payment instructions, and their processing instructions) in the base table IBY_PAY_SERVICE_REQUESTS. Rather than exposing that table directly, IBY_PAY_REQUEST_SEC_V applies both organization-level and payment-function-level access control so that a user querying the view sees only those payment requests that fall within their assigned security profile and their authorized payment functions. The view is therefore the preferred access path for reporting, diagnostics, and integration logic that must respect Payments security, and it is the object most commonly located when searching for the term "payment_request".

Underlying Base Objects

The view is defined over the synonym IBY_PAY_SERVICE_REQUESTS (the physical table appears as IBY_PAY_SERVICE_REQUESTS), and it additionally references IBY_PROCESS_ORGS, IBY_PROCESS_FUNCTIONS, the security views CE_SECURITY_PROFILES_V and IBY_USER_PAY_FUNS_SEC_V, and the PL/SQL packages FND_ACCESS_CONTROL_UTIL, FND_GLOBAL, FND_PROFILE, MO_GLOBAL, and XTR_USER_ACCESS. Two EXISTS clauses drive the filtering: the first matches rows in IBY_PROCESS_ORGS having OBJECT_TYPE = 'PAYMENT_REQUEST' against the (organization_id, organization_type) pairs returned by CE_SECURITY_PROFILES_V; the second matches rows in IBY_PROCESS_FUNCTIONS having OBJECT_TYPE = 'PAYMENT_REQUEST' against the payment functions returned by IBY_USER_PAY_FUNS_SEC_V. A row is returned only when both EXISTS conditions are satisfied, so the view is effectively an inner join of the source request with the caller's security entitlements. The join key on both sides is PAYMENT_SERVICE_REQUEST_ID, which is exposed in the view as PAYMENT_SERVICE_REQUEST_ID.

Key Columns

• PAYMENT_SERVICE_REQUEST_ID — primary identifier of the payment service request; the key used by downstream processes and by the security EXISTS clauses.
• CALLING_APP_ID / CALL_APP_PAY_SERVICE_REQ_CODE — the calling application and its own request code, linking the Payments request back to the originating application (for example, Payables or Receivables).
• PAYMENT_SERVICE_REQUEST_STATUS / PROCESS_TYPE — current lifecycle status and processing instruction type of the request.
• INTERNAL_BANK_ACCOUNT_ID / PAYMENT_PROFILE_ID — disbursement account and payment profile used for the request.
• MAXIMUM_PAYMENT_AMOUNT / MINIMUM_PAYMENT_AMOUNT — value thresholds governing which documents may be paid, with ALLOW_ZERO_PAYMENTS_FLAG indicating zero-value tolerance.
• DOCUMENT_REJECTION_LEVEL_CODE / PAYMENT_REJECTION_LEVEL_CODE / REQUIRE_PROP_PMTS_REVIEW_FLAG — controls for rejection handling and proposed-payment review.
• ORG_TYPE and the fifteen ATTRIBUTE fields — organizational context and the standard EBS descriptive flexfield columns.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, OBJECT_VERSION_NUMBER — audit and optimistic-locking columns.
• REQUEST_ID — Concurrent Manager request identifier associated with the record.

Common Use Cases and Queries

Typical uses include listing the payment requests visible to the current user, verifying why a given request is or is not visible under a security profile, and reconciling Payments activity by calling application or processing type. Because the view already encapsulates the FND security logic, queries need no additional org or function predicates.

• List recent visible payment requests: SELECT payment_service_request_id, calling_app_id, payment_service_request_status, process_type FROM iby_pay_request_sec_v ORDER BY creation_date DESC;
• Find requests by calling application: SELECT payment_service_request_id, call_app_pay_service_req_code, request_id FROM iby_pay_request_sec_v WHERE calling_app_id = :app_id;
• Retrieve amount and profile controls: SELECT payment_service_request_id, internal_bank_account_id, payment_profile_id, minimum_payment_amount, maximum_payment_amount FROM iby_pay_request_sec_v WHERE process_type = :type;
• Diagnose visibility: compare a row returned by the unrestricted base table with the result from this view to determine whether organization or payment-function security is excluding it.

As with all Oracle Payments security views, results depend on the profile options and security profile assignments of the connecting user, so reports intended for a broad audience should be run under a user whose entitlements span the required organizations and payment functions.