Search Results compare_table




Overview
Explore in AI Chat

Overview

PO_DOCUMENT_REVISION_GRP is a PL/SQL group (GRP) package in the Oracle E-Business Suite Procurement module (APPS schema). Its primary business function is to determine whether a purchasing document requires a new revision, and to compare a document's current transactional tables against their archived counterparts in order to detect differences. This package underpins Oracle Purchasing's document revision control mechanism, ensuring that revisions are created and tracked correctly when purchasing documents such as purchase orders, quotations, and their associated lines, shipments, and distributions are modified.

The package header carries the CVS revision marker POXDOCRB.pls 120.4.12010000.2, indicating it belongs to the Purchasing document revision family of database objects. It incorporates a global debug flag sourced from the profile option AFLOG_ENABLED, so logging behavior can be controlled at runtime.

Key Procedures and Functions

The documented package exposes five named procedures and functions. Three are highlighted in the ETRM metadata:

  • CHECK_REV_DIFF — The core routine that evaluates differences between a document's live data and its archived data to decide whether a revision difference exists. It drives the revision-detection decision logic.
  • COMPARE (internally referenced as Compare_Table) — Compares an individual document element (header, line, line location, or distribution) between the transactional and archive tables, returning a flag indicating whether the element is different. It accepts document identifiers, a document subtype, an element type, line and line-location identifiers, and a cancel-check flag.
  • NAME — The package's naming/identification routine used in the revision workflow.

In addition, the source declares Check_New_Revision, a procedure that determines whether a new revision number must be generated for a given document. It accepts an API version, document type and subtype, document identifier, and table name, and returns a return status, the document revision number, and a message. This procedure is the entry point that orchestrates the revision decision, invoking the comparison logic to establish whether the document has materially changed. Private helper functions PO_Archive_Check and Release_Archive_Check support the archive verification performed during comparison.

Tables Accessed

The package reads and writes across the paired transactional and archive tables that make up the purchasing document model. Documented references include PO_HEADERS and PO_HEADERS_ALL with PO_HEADERS_ARCHIVE; PO_LINES and PO_LINES_ALL with PO_LINES_ARCHIVE; PO_LINE_LOCATIONS; PO_DISTRIBUTIONS and PO_DISTRIBUTIONS_ALL with PO_DISTRIBUTIONS_ARCHIVE and PO_DISTRIBUTIONS_ARCHIVE_ALL. These pairs are central to the compare operation, since the package must reconcile live rows against archived snapshots to identify changes.

Supporting configuration and organizational tables are also accessed: FINANCIALS_SYSTEM_PARAMETERS and FINANCIALS_SYSTEM_PARAMS_ALL (for system-level revision and archive options), and PO_GA_ORG_ASSIGNMENTS and PO_GA_ORG_ASSIGNMENTS_ARCHIVE (for organization assignment data). The archive-check helper functions rely on the *_ARCHIVE variants to confirm whether a document has a valid archived copy before comparison proceeds.

Usage Notes

PO_DOCUMENT_REVISION_GRP is an internal group package invoked by higher-level Purchasing APIs rather than called directly by end users. It is referenced by four other packages, which typically call Check_New_Revision during document save, submission, or approval flows to establish whether a revision increment is warranted. The Compare_Table routine is executed for each affected document element as part of that determination.

The debug logging controlled by AFLOG_ENABLED makes the package suitable for troubleshooting revision discrepancies in development and test environments. Because comparison is performed against archive tables, the package should be invoked only after the relevant archive records exist; the PO_Archive_Check and Release_Archive_Check functions guard this precondition. In releases 12.1.1 and 12.2.2 the package operates unchanged in principle, with table access routed through APPS synonyms consistent with the shared EBS schema model.