Search Results po_document_revision_grp




Overview
Explore in AI Chat

Overview

PO_DOCUMENT_REVISION_GRP is a server-side PL/SQL package owned by APPS and declared with AUTHID CURRENT_USER. It belongs to the Purchasing (PO) module and implements group-level Application Program Interfaces that manage revision control for purchasing documents. The package determines whether a document requires a new revision number by comparing the current state of a purchasing document against its most recently archived version. Its header comment identifies it as the home of line-level APIs supporting revision processing, with MassUpdate_Releases() documented as a primary entry point.

The central business purpose is to prevent unnecessary revision increments. When a purchasing document is archived, the archive retains the revision number that existed at archive time. If the live document still carries that same revision number, no net change requiring a new revision has occurred. If the numbers differ, the document has already been revised since archiving, and the routine exits. This logic safeguards revision integrity across the standard Purchasing document types (PO, PA, Standard, Planned, Blanket, Contract) and releases (Scheduled, Blanket).

Key Procedures and Functions

The ETRM metadata documents five procedures and functions, three of which are named in the excerpt: NAME, COMPARE, and CHECK_REV_DIFF. The user's search term, "check_rev_diff", maps directly to the CHECK_REV_DIFF procedure.

  • CHECK_REV_DIFF — The procedure most closely associated with the package's revision-difference logic. It evaluates whether the live document differs from its archived counterpart to a degree that warrants a revision increment. It forms the decision point that drives revision numbering for the affected document types and subtypes.
  • COMPARE — Performs the column-by-column comparison between live purchasing tables and their corresponding archive tables. The package documentation describes the comparison regime explicitly, indicating that specific tables are checked per document type, with the option to restrict comparison to a single table for performance.
  • NAME — A helper routine, typically used to resolve or validate the document or revision name, supporting the identification of the document being evaluated.
  • Check_New_Revision — Documented in the package source as returning the new revision number when an increment is required. It verifies whether the document's revision_num matches the latest archived version's revision_num (identified by LATEST_EXTERNAL_FLAG = 'Y').
  • MassUpdate_Releases() — Listed in the package header as a key function/procedure, supporting bulk revision handling for releases.

Tables Accessed

The package reads both live and archive purchasing tables through APPS synonyms. Document headers and lines are examined via PO_HEADERS, PO_HEADERS_ALL, PO_HEADERS_ARCHIVE, PO_LINES, PO_LINES_ALL, and PO_LINES_ARCHIVE. Shipment and pricing data is checked through PO_LINE_LOCATIONS, while distribution data is read from PO_DISTRIBUTIONS, PO_DISTRIBUTIONS_ALL, PO_DISTRIBUTIONS_ARCHIVE, and PO_DISTRIBUTIONS_ARCHIVE_ALL. For releases, PO_RELEASES is compared against its archived form. Organizational context is derived from PO_GA_ORG_ASSIGNMENTS and PO_GA_ORG_ASSIGNMENTS_ARCHIVE, and system-level defaults come from FINANCIALS_SYSTEM_PARAMETERS and FINANCIALS_SYSTEM_PARAMS_ALL. The archive tables provide the baseline revision state; the live tables provide the current state; the comparison determines whether CHECK_REV_DIFF should signal a new revision.

Usage Notes

This package is a group (GRP) API typically invoked from the Purchasing forms, concurrent programs that perform mass release updates or archiving, and custom extensions built on the revision framework. Because the package comment explicitly instructs developers to keep the comparison logic synchronized with the archiving routine in /src/xit/porar.lpc, any customization or upgrade affecting revision logic must verify both locations. In EBS 12.1.1 and 12.2.2, the package remains under APPS with AUTHID CURRENT_USER, and it is referenced by four other packages, indicating it is a foundational dependency for revision-related processing across the purchasing schema.