Search Results update_persons

Overview

PO_MASS_UPDATE_REQ_GRP is a group-type PL/SQL package in the APPS schema that supports the Oracle Purchasing feature for mass updating of personnel assignments on requisitions and purchase orders. Its business purpose is to allow organizations to reassign the Preparer, Approver, or Requestor on a range of documents in a single operation, rather than editing each document individually. This capability is essential when a buyer or requester leaves the organization, changes roles, or when responsibility for a class of documents must be transferred to another individual.

The package operates as a thin group wrapper. According to the documented package header comments, a SQL script named POXMUR.sql calls the procedure PO_Mass_Update_Req_GRP.Update_Persons, which in turn calls the private worker procedure PO_Mass_Update_Req_PVT.DO_Update. The group layer therefore exists to expose the mass update logic for external invocation while delegating the substantive update work to the private API.

The package version header indicates an inclusion level of noship and a last modification date of 2008/01/09, meaning the object remained stable across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The ETRM metadata reports exactly one documented program unit for this package:

• UPDATE_PERSONS — The sole documented public procedure. Per the embedded package comments, it calls PO_Mass_Update_Req_PVT.Do_Update to update the Preparer, Approver, or Requestor according to the input received from the Update_Person parameter value set. Documented input parameters include p_update_person (identifies which role is being updated), p_old_personid and p_new_personid (the person being replaced and the replacement), p_document_type (INTERNAL or PURCHASE), p_document_no_from and p_document_no_to (the document number range), p_date_from and p_date_to (the date range), and p_commit_interval (the commit batching frequency). Documented output parameters are p_msg_data (encoded message data), p_msg_count (the number of messages on the API message list), and p_return_status (the return status, which may be 'S', 'E', or 'U' for Success, Error, or Unexpected error).

The procedure follows the standard EBS message-list pattern, meaning callers should inspect p_return_status and retrieve messages via the FND_MSG_PUB APIs when a non-success status is returned.

Tables Accessed

The ETRM metadata for this package does not list any tables referenced through APPS synonyms. This is consistent with its role as a group wrapper: all direct DML against Purchasing tables is performed inside PO_Mass_Update_Req_PVT.DO_Update rather than in the group body itself. The private worker performs the actual updates to the requisition and purchase order records that store the Preparer, Approver, and Requestor person identifiers. Because this package exposes no documented table dependencies, DBAs assessing the impact of the mass update operation should examine the private package for the authoritative table list.

Usage Notes

The package is invoked in the context of a mass update request for requisitions and purchase orders. The documented call chain originates from the POXMUR.sql script, which suggests the routine is driven by a concurrent program or a standard submission mechanism rather than directly from a form's client-side code. Typical invocation scenarios include:

• A concurrent program or Standard Request Submission job that accepts the update person type, old and new person IDs, document type, document and date ranges, and commit interval as parameters.
• The Oracle Purchasing mass update personnel user interface, where the parameters supplied through the Update_Person value set map directly to the procedure arguments.
• Custom or extension code that needs to reassign document ownership in bulk, provided it respects the document type restriction of INTERNAL and PURCHASE and handles p_return_status and the API message list correctly.

The user's search term "update_persons" corresponds precisely to this package's only documented entry point. Because the metadata records zero inbound package references, PO_Mass_Update_Req_GRP is best understood as a top-level integration point rather than a utility called by other PL/SQL objects.