Search Results po_terms_sv




Overview
Explore in AI Chat

Overview

PO_TERMS_SV is a PL/SQL package body owned by the APPS schema that provides the terms and conditions validation and comparison logic used throughout the Oracle Purchasing module. Its principal role is to retrieve, evaluate, and compare payment terms and freight terms associated with purchasing documents — purchase orders, purchase agreements, quotations, and shipments — and to determine whether the terms recorded on a document match the terms defined at the supplier site, supplier, or organization level. The package exposes a programmatic API surface that other EBS components call when they must reconcile local (document-level) terms against global (vendor- or system-level) terms, and it returns descriptive messages explaining any discrepancy. It is classified as an OTHER API, indicating it is an internal utility package rather than a formally documented public interface. In Oracle EBS 12.1.1 and 12.2.2 the object is VALID and is required for correct evaluation of supplier terms during purchasing and receiving transactions.

Key Procedures and Functions

The documented package body contains 13 procedures and functions. The most significant entry points are:

  • GET_GLOBAL_TERMS_CONDITIONS — Retrieves the terms and conditions defined at the global (external) level, typically the payment terms and freight terms held against the supplier or supplier site record. It supplies the baseline against which document-level terms are evaluated.
  • GET_LOCAL_TERMS_CONDITIONS — Retrieves the terms and conditions recorded locally on the purchasing document itself, such as the terms carried on the purchase order header.
  • COMPARE_TERMS_CONDITIONS — Performs the core comparison between global and local terms. This function evaluates the values supplied by the two preceding routines and determines whether they are consistent, returning a status that callers use to decide whether a mismatch must be surfaced to the user.
  • SET_TERMS_COMPARISON_MSG — Constructs and registers the comparison result message, using the FND_MESSAGE and FND_NEW_MESSAGES infrastructure so that mismatch notifications can be presented in the standard EBS message format.
  • NAME — The documented package name accessor, returning the identifier of the package for diagnostic and logging purposes.

All documented routines route diagnostic output through ASN_DEBUG and FND_LOG, and raise or translate errors via FND_MESSAGE. Parameter lists are not enumerated here; callers should consult the package specification in the EBS instance for exact signatures.

Tables Accessed

The package reads and writes data through APPS synonyms, principally against PO_HEADERS_ALL (for purchase order header and terms information), AP_TERMS (the payment terms definition table, source of the valid terms codes and their attributes), ORG_FREIGHT (organization-level freight terms defaults), and FND_NEW_MESSAGES (for registering comparison messages). DBMS_SQL and DUAL are used for dynamic SQL execution and single-row database queries. Through its dependency tree, the package also participates in logic supplied by PO_CORE_S, PO_LOCATIONS_S, PO_MESSAGE_S, PO_VENDORS_SV, HR_LOCATIONS, RCV_SHIPMENT_HEADER_SV, and RCV_SHIPMENT_OBJECT_SV, which is consistent with its role in evaluating supplier and location terms during procurement and receiving.

Usage Notes

PO_TERMS_SV is not referenced by any database object, but it is invoked by 12 other packages within the Purchasing application. It is typically called indirectly when a user enters, defaults, or modifies terms on a purchasing document in the Purchasing forms, when purchase order and quotation records are validated, and during supplier and receipt processing where term consistency matters. Because it is designated an OTHER API rather than a publicly supported interface, custom code should not depend on its signatures, which Oracle may change without notice; customizations should instead replicate the validation through supported APIs or the underlying AP_TERMS and PO_HEADERS_ALL tables. Diagnostics can be enabled via FND_LOG and the profile options managed through FND_PROFILE when investigating discrepancies between global and local terms.