Search Results oe_line_payment_security




Overview
Explore in AI Chat

Overview

OE_LINE_PAYMENT_SECURITY is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema. It resides within the Oracle Order Management (OE) module and is closely associated with the Payment and Collections (PC) security framework. Its primary business purpose is to enforce Payment Card Industry (PCI) driven security rules over payment information captured at the order line level. In releases 12.1.1 and 12.2.2, Order Management supports the capture of payment instrument data against order lines, and this package governs the permissible combinations and masking of that data according to configured constraints.

The object is classified as OTHER under the ETRM API classification scheme, indicating that it is an internal utility package rather than a published, externally callable API. The package body is documented as VALID and exposes thirty-three documented constructs, though these are predominantly the standard descriptive flexfield (DFF) and WHO column accessors that support the underlying security logic. The package references OE_PC_CONSTRAINTS, the table that stores payment constraint definitions used to validate and secure payment information.

Key Procedures and Functions

The documented procedures and functions fall into three recognizable groups. The first group comprises DFF accessors: ATTRIBUTE1 through ATTRIBUTE15 and CONTEXT. These provide read access to the descriptive flexfield segments that carry payment-related security attributes on the order line payment record. They exist so that constraint evaluation logic can interrogate flexfield values without hard-coding column references.

The second group comprises WHO column accessors: CREATED_BY, and related audit-oriented helpers that expose the creation context of a payment record. These support auditing and traceability of secured payment data.

The third and functionally most significant group comprises PAYMENT_LEVEL_CODE, PAYMENT_TYPE_CODE, and PAYMENT_TRX. PAYMENT_LEVEL_CODE identifies the hierarchical level at which a payment applies, distinguishing order-level from line-level payment instruments. PAYMENT_TYPE_CODE identifies the category of payment instrument being secured. PAYMENT_TRX provides the transactional handle or record reference needed to apply security verification to a specific payment transaction. Together these three constructs represent the core security evaluation surface of the package.

No parameter lists are documented in the ETRM metadata; consumers should treat the callable signatures as internal and subject to change.

Tables Accessed

OE_PC_CONSTRAINTS is the single documented table referenced through APPS synonyms. This table holds the payment constraint definitions that determine which payment combinations are permitted, which are restricted, and what level of masking or access restriction applies. The package reads these constraints to validate payment data captured on order lines. Because the object type is a package body, direct DML against OE_PC_CONSTRAINTS is plausible for administrative operations, but the documented evidence supports constraint evaluation rather than maintenance as the primary purpose.

Usage Notes

OE_LINE_PAYMENT_SECURITY is not referenced by any database object per the dependency metadata; it is invoked at runtime rather than being compiled into other stored objects. It is referenced by 65 other packages, indicating broad internal reuse across Order Management processing. It depends on OE_PC_CONSTRAINTS_ADMIN_PVT and OE_PC_GLOBALS, confirming integration with the administrative and global configuration layers of the Payment and Collections security framework, and on FND_API, OE_MSG_PUB, FND_GLOBAL, and OE_DEBUG_PUB for error handling, messaging, session context, and diagnostics.

Typical invocation occurs through Order Management forms, order entry and import workflows, and concurrent programs that create or modify order lines. It is not intended for direct customer invocation. Customizations should call the supported OE_ORDER_PUB and OE_LINE_PAYMENT_UTIL APIs instead of this package, as its signatures and behavior are not part of the public API contract.