Search Results check_rule_defined

Overview

OE_VERIFY_PAYMENT_PUB is a public PL/SQL API in the Oracle E-Business Suite Order Management module (APPS schema, AUTHID CURRENT_USER) that orchestrates the payment verification and credit checking that occurs before an order or order line is booked, shipped, or released. The package header, shipped under version control as OEXPVPMS.pls, states its purpose explicitly: it is called by Booking, Pre Ship, or Purchase Release processing, and by delayed requests logged when order or line level attributes change.

The core logic branches on whether an electronic payment instrument is associated with the order. If an electronic payment exists, the package invokes payment request authorization logic (OE_Verify_Payment_PUB.Payment_Request). If no electronic payment is present, control passes to OE_Credit_PUB.OE_Check_Available_Credit for credit limit checking. This decision point makes the package the single verification gateway through which Order Management validates a customer's financial standing before committing to fulfillment. Package-level globals such as G_credit_check_rule and G_init_calling_action record the rule selected and the originating action, while G_credit_check_flag supports credit card reversal scenarios.

Key Procedures and Functions

The documented API exposes 29 procedures and functions. The principal entry point is VERIFY_PAYMENT, which accepts an order header identifier, a calling action (BOOKING, SHIPPING, or null), an optional delayed-request indicator, and a risk evaluation flag, and returns message count, message data, and a return status. WHICH_RULE determines which verification rule applies for a given header, and CHECK_RULE_DEFINED reports whether that rule has been configured at the Order Type setup level.

Supporting routines include IS_ELECTRONIC_PAYMENT, which detects an electronic payment association; HOLD_EXISTS, RELEASE_VERIFY_HOLD, and APPLY_VERIFY_HOLD, which manage the verification holds placed on orders; and PAYMENT_REQUEST, which initiates the authorization request. CHECK_IPAYMENT_INSTALLED and GET_PRIMARY_PAY_METHOD and GET_PAY_METHOD_INFO provide environment and payment-method resolution. AUTHORIZE_PAYMENT and CHECK_REAUTHORIZE_ORDER drive authorization and reauthorization decisions.

Authorization tracking is handled by CHECK_TRXN_CAPTURED, FETCH_AUTHORIZATION_TRXN, FETCH_CURRENT_AUTH, FETCH_LAST_AUTH, and UPDATE_AUTHORIZATION_INFO. VALIDATE_REQUIRED_ATTRIBUTES enforces mandatory payment attributes. VOID_PAYMENT, the routine most relevant to users searching on "void_payment," supports reversal of a prior payment authorization, typically invoked when an order is cancelled or a payment must be rescinded before settlement.

Tables Accessed

The package reads and writes through APPS synonyms. Customer and site information is resolved from HZ_CUST_ACCOUNTS_ALL, HZ_CUST_ACCT_SITES_ALL (with HZ_CUST_ACCT_SITES), and HZ_CUST_SITE_USES_ALL. Payment instrument and method definitions come from IBY_FNDCPT_TX_EXTENSIONS, IBY_TANGIBLE, and AR_RECEIPT_METHODS. Order-related data is read from OE_ORDER_HEADERS, OE_CREDIT_CHECK_RULES, OE_DROP_SHIP_SOURCES, MTL_SYSTEM_ITEMS, and OE_IPAYMENT_TANGIBLE_S. Hold processing uses OE_HOLD_DEFINITIONS, OE_HOLD_RELEASES, and OE_HOLD_SOURCES, with OE_HOLD_RELEASES capturing the release of verification holds.

Usage Notes

OE_VERIFY_PAYMENT_PUB is typically invoked indirectly by the Order Management booking, shipping, and purchase release workflows rather than called directly from a form. The ETRM metadata records that the package is referenced by 29 other packages, reflecting its role as a shared service. Custom code integrating with order booking should call VERIFY_PAYMENT before committing an order to avoid bypassing credit and payment validation. When invoking VOID_PAYMENT, callers must ensure the order is in a state that permits reversal and should inspect the returned message count and return status. Delayed requests generated by attribute changes also route through this package, so its globals and rule resolution must be treated as session-sensitive.