Search Results get_line_type

Overview

PO_LINE_TYPES_SV is the server-side application programming interface package for Oracle Purchasing line types. It encapsulates the business logic that governs how line type definitions are retrieved, validated, and applied when purchasing document lines are created or processed. The package is declared with AUTHID CURRENT_USER and resides in the APPS schema, exposing callable procedures and functions to any session that holds execute privilege on it. Its principal role is to centralize line type behavior so that Oracle Forms, concurrent programs, and custom extensions do not re-implement the same rules independently.

Line types in Oracle Purchasing determine fundamental characteristics of a document line, including whether the line is amount-based or quantity-based, what category and unit of measure default to the line, whether the line represents an outside operation, and how receiving and receiving close tolerances behave. PO_LINE_TYPES_SV makes these determinations available programmatically and enforces the requirement that a line type be active before it is used.

Key Procedures and Functions

The ETRM metadata documents the following callable units within the package:

• get_line_type_def — Retrieves the line type dependant defaults associated with a given line type identifier. Documented defaults include the order type lookup code (amount or quantity), category, unit of measure, unit price, the outside operation flag, the receiving flag, and the receive close tolerance. Several of these values are passed as IN OUT parameters so that the caller may supply an existing value and receive the line type default where applicable.
• get_line_type — The procedure corresponding to the search term "get_line_type." It returns line type information for a supplied line type identifier, providing the lookup data needed by callers that resolve a line type without necessarily requesting the full set of document defaults.
• val_line_type — Validates whether a given line type is still active. It returns a Boolean result and is used as a gate before a line type is accepted for use on a document line.
• is_outside_processing — Indicates whether a line type is classified as outside processing, which affects sourcing and receiving behavior on the resulting document line.
• is_outside_processing_item and outside_processing_items_exist — Determine whether a specific item, or any item within a given context, is associated with outside processing.
• transactions_exist — Reports whether transactions exist for the line type being examined, which is relevant when considering whether a line type may be modified or deleted.

Tables Accessed

Table access is performed through APPS synonyms and includes:

• PO_LINE_TYPES and PO_LINE_TYPES_B — The base and translated definition tables for line types, read to obtain the attributes returned by get_line_type and get_line_type_def and to determine active status for val_line_type.
• PO_LINES_ALL and PO_LINES_ARCHIVE_ALL — Purchasing document lines, consulted to determine whether existing or archived lines reference a line type, supporting transactions_exist and related validation.
• PO_REQUISITION_LINES_ALL — Requisition lines, examined where line type usage must be confirmed against requisition demand.
• MTL_SYSTEM_ITEMS — Item master information, used by the outside processing item checks to resolve an item's attributes.
• DUAL — Used for single-row lookups and constant evaluation.

Usage Notes

PO_LINE_TYPES_SV is invoked predominantly from Oracle Purchasing forms when a user selects or changes a line type on a document line, allowing the form to populate dependent fields from the retrieved defaults. It is also referenced by other server-side packages; the ETRM metadata records six dependent packages, indicating that line type resolution is a shared service across Purchasing and related modules. Custom extensions should call these APIs rather than querying the line type tables directly, because the package encapsulates the active-status validation and the outside processing determinations that direct SQL would bypass. As with all APPS server-side APIs, callers should obtain the standard FND_API style error handling behavior expected of the surrounding transaction and avoid committing within the API call.