Search Results pos_sbd_pkg




Overview
Explore in AI Chat

Overview

POS_SBD_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Supplier Banking Detail (SBD) and supplier account management functionality used by Oracle Payables, iSupplier Portal, and the Supplier Lifecycle Management flows. Its primary business purpose is to manage the lifecycle of external payee bank accounts and payment instruments associated with suppliers and buyers, including account creation, update, approval, rejection, prenotification, removal, and the propagation of payment preferences. The package thus underpins the secure handling of supplier banking data in the Procure-to-Pay cycle, ensuring that only validated bank accounts and assignments become eligible for payment generation.

The object metadata confirms the package is VALID and classifies it as an "OTHER" API rather than a public, fully supported interface. It maintains internal dependencies on SYS.STANDARD and is referenced by POS_PROFILE_CHANGE_REQUEST_PKG, indicating that profile-driven change requests invoke this package to apply banking changes. It is itself referenced by one other package, reflecting its role as a lower-level utility within the POS module's supplier banking subsystem.

Key Procedures and Functions

The documented interface exposes sixteen procedures and functions, organized around supplier operations and buyer (internal approver) operations:

Tables Accessed

The package reads and writes Oracle Payments and supplier master data through APPS synonyms:

Usage Notes

POS_SBD_PKG is typically invoked indirectly rather than called directly by end users. It is triggered from the supplier banking detail forms in iSupplier Portal and Oracle Payables, from concurrent programs that process account requests and approvals, and from POS_PROFILE_CHANGE_REQUEST_PKG when profile changes require banking data updates. Because the ETRM classification is OTHER, the package is not a formally supported public API; customizations should avoid direct invocation where a supported API exists, and any call must respect the same validation, duplicate-check, and approval sequencing enforced internally. In 12.1.1 and 12.2.2 the underlying table structures are consistent, with 12.2.x Online Patching considerations applying to any extension code layered on top of this package.