Search Results get_max_line_num

Overview

PO_LINES_SV2 is a server-side PL/SQL package owned by APPS within the Oracle E-Business Suite Purchasing module. It belongs to the family of Purchasing "SV" (server validation/servicing) packages that expose line-level Application Program Interfaces for the PO_LINES entity. The package header declares AUTHID CURRENT_USER, meaning that its SQL executes under the privileges of the invoking schema rather than the definer, an important consideration for customizations that call the package directly.

Its documented purpose is to encapsulate line-level operations against purchase order lines so that forms, concurrent programs, and external interfaces can manipulate line data without duplicating business logic. The package is versioned as SV2, sitting alongside sibling packages such as PO_LINES_SV1 and PO_LINES_SV11; the header change history indicates that update_line() was subsequently moved into PO_LINES_SV11, leaving PO_LINES_SV2 with a narrower, primarily read-oriented surface in later releases. In ETRM 12.2.2 the object is classified as API classification "OTHER" and is referenced by two other packages.

Key Procedures and Functions

• get_max_line_num() — This function returns the maximum line number existing for a supplied purchase order header. It is the object most commonly associated with the search term "get_max_line_num," since callers use it to determine the next available line number before inserting a new PO line. Created 13-Jul-95, it accepts a PO header identifier and returns a NUMBER.
• update_line() — Documents the procedure that updates a purchase order line and performs associated update-related activities. Per the header change history, this routine was moved to PO_LINES_SV11 on 19-Mar-97, so in Release 12.x the authoritative implementation of line updates resides in the later SV package rather than here.
• NAME / RETRO_CHANGE_SHIPMENT — These entries appear in the documented procedure list for the package in 12.2.2. The retroactive_change routine described in the source excerpt updates the RETROACTIVE_DATE column in PO_LINES with SYSDATE and is invoked from ON-UPDATE triggers on the PO_LINES and PO_SHIPMENTS blocks of the Enter Purchase Orders form. RETRO_CHANGE_SHIPMENT applies the equivalent retroactive-date maintenance at the shipment/line-location level. The "NAME" entry reflects the package header declaration itself rather than a distinct callable routine.

Tables Accessed

• PO_LINES — The base transactional table for purchase order lines. It is read by get_max_line_num() to determine the highest existing line number and written by the retroactive-date logic to stamp RETROACTIVE_DATE.
• PO_LINES_ALL — The multilingual (_ALL) view/table underlying PO_LINES. Access through it ensures that line lookups respect the MLS translation model introduced in Release 11i and carried forward into 12.1.1 and 12.2.2.
• PO_LINE_LOCATIONS — The shipment and distribution schedule table. It is referenced by the retroactive shipment logic, which must propagate retroactive-date changes to the schedule level.

Access occurs through APPS synonyms, consistent with the AUTHID CURRENT_USER declaration.

Usage Notes

PO_LINES_SV2 is normally invoked indirectly. The core Purchasing forms — most notably Enter Purchase Orders — call these APIs during line entry and update, and the retroactive-date procedures are driven from block-level ON-UPDATE triggers rather than from user-initiated menu actions. For Release 12.1.1 and 12.2.2 custom development, get_max_line_num() remains the documented, supported entry point for retrieving the highest line number on a PO header, and is preferable to writing ad hoc MAX(line_num) queries against PO_LINES.

Because the package header is dated 2003 (POXPOL2S.pls 115.5) and several routines were relocated to PO_LINES_SV11, developers should treat PO_LINES_SV2 as a legacy compatibility surface. New line-maintenance work should target the current SV package generation, while calls to get_max_line_num() and the retroactive APIs may continue where existing code and form triggers depend on them.