Search Results validate_required_user_attrs

Overview

POS_VENDOR_REG_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the Supplier Registration and supplier onboarding workflow. It is part of the Oracle iSupplier / Supplier Lifecycle Management (SLM) functionality delivered under the POS module prefix. The package encapsulates the business logic required to submit, approve, and reject supplier registration requests, to enforce uniqueness and validity rules on supplier data, and to dispatch notifications to approvers and registration requesters.

Unlike a formal public API such as AP_VENDOR_PUB_PKG, POS_VENDOR_REG_PKG is classified as an OTHER package, meaning it is an internal implementation package rather than a supported interface. It operates as a supporting layer within the supplier registration flow, bridging the self-service registration pages with the underlying supplier master tables in Oracle Payables and Oracle Trading Community Architecture.

Key Procedures and Functions

The package exposes eleven documented procedures and functions. The core workflow procedures are SUBMIT_SUPPLIER_REG, which initiates a supplier registration request; APPROVE_SUPPLIER_REG, which processes approval actions and finalizes the registration; and REJECT_SUPPLIER_REG, which handles rejection of a pending registration. Together these drive the state transitions of a registration record through the POS_ACNT_GEN_REQ or related request tables.

Two procedures manage outbound communications: SEND_SAVE_FOR_LATER_NTF generates a save-for-later notification, and NOTIFY_BANKING_APPROVER routes notifications to the banking approver when bank account information requires review.

Several functions perform validation and uniqueness checks used during data entry and submission. These include IS_OU_ID_VALID, IS_SUPPLIER_NUMBER_UNIQUE, IS_TAXPAYER_ID_UNIQUE, IS_DUNS_NUM_UNIQUE, and IS_TAXREGNUM_UNIQUE. These functions verify that the operating unit is valid and that key registration identifiers such as supplier number, taxpayer ID, DUNS number, and tax registration number are not duplicated.

The remaining documented member, VALIDATE_REQUIRED_USER_ATTRS, enforces mandatory user-defined attributes configured through the supplier attribute page configuration, ensuring the request contains all required registration data before submission.

Tables Accessed

The package reads and writes to a documented set of APPS synonyms. Supplier master data is accessed through AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL, which hold the supplier header and site records created upon approval. Trading Community Architecture tables including HZ_PARTIES, HZ_PARTY_USG_ASSIGNMENTS, HZ_CLASS_CODE_RELATIONS, and HZ_CODE_ASSIGNMENTS are used to maintain the party model and classification relationships associated with the supplier. Registration workflow records are stored in POS_ACNT_GEN_REQ, POS_ADDRESS_REQUESTS, POS_BUS_CLASS_REQS, and POS_ATTRPG_CONFIG, the last of which governs configurable attribute pages. Configuration and setup data are resolved from EGO_DATA_LEVEL_B for data level security and EGO_PAGES_TL for page labels. User and notification context is obtained from FND_USER and FND_PROFILE_OPTION_VALUES, while supporting documentation is linked through FND_ATTACHED_DOCUMENTS.

Usage Notes

POS_VENDOR_REG_PKG is referenced by two other packages: AP_VENDOR_PUB_PKG and POS_REQUEST_UTILS_PKG. These references indicate that supplier registration and approval actions performed through the public supplier API or the registration request utilities ultimately invoke the logic inside POS_VENDOR_REG_PKG. The package is therefore typically executed indirectly rather than called directly by administrators. It is invoked from the supplier registration web pages, from approval and rejection processing, and from utility code that prepares and validates registration requests.

Because the package is not a documented public API, direct calls from custom code are discouraged; customizations should invoke the supported wrapper entry points such as AP_VENDOR_PUB_PKG or the registration request utilities. The validation functions such as IS_SUPPLIER_NUMBER_UNIQUE and IS_TAXREGNUM_UNIQUE may still be useful as reference logic for implementing compatible duplicate-check behavior in extensions.