Search Results validate_source

Overview

FUN_TRADING_RELATION is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the Financials family of packages associated with intercompany and intracompany trading partners, providing the underlying resolution logic used to identify and validate the customer or supplier entities that participate in a trading relationship. The package is declared with AUTHID CURRENT_USER, meaning its SQL statements execute under the privileges of the calling session rather than the definer, and it exposes a small, focused public API composed of four documented program units. In the ETRM classification it is tagged as OTHER, reflecting that it is a supporting utility package rather than a standalone business API. Its principal responsibility is to translate a supplied source indicator and organizational context into concrete trading partner identifiers — customer account, site, or supplier identifiers — that downstream intercompany transactions, invoices, and trade relations can use.

Key Procedures and Functions

• validate_source — Accepts a source value and confirms that it is a recognized, permissible input. This is the entry-point validation routine invoked before other lookups are attempted, ensuring that subsequent resolution logic operates on a supported source designation. The user search term "validate_source" corresponds directly to this function.
• get_customer — Retrieves customer information for a given trading relationship context, returning a Boolean success indicator and, on a successful match, the customer account identifier, customer account site identifier, and site use identifier through its output parameters. It resolves the correct customer entity from the transactional and trading partner legal entity and organization identifiers supplied by the caller.
• get_supplier — Performs the analogous resolution for the supplier side of a trading relationship, returning the vendor identifier and pay site identifier. Unlike the customer lookup, it additionally accepts a transaction date, reflecting the date-sensitive nature of supplier site and payment relationship resolution.
• get_relation — Documented as a procedure (spelled "PROCEDUTE" in the source header), it retrieves the trading relation itself, tying the transactional entity and trading partner entity together. It is the routine most closely associated with the FUN_TRADE_RELATIONS table that gives the package its name.

Tables Accessed

The package reads and writes a defined set of tables through APPS synonyms. Customer resolution draws on HZ_CUST_ACCOUNTS_ALL, HZ_CUST_ACCT_SITES_ALL, and HZ_CUST_SITE_USES_ALL for account, site, and site-use data. Supplier resolution uses AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL. Mapping tables FUN_CUSTOMER_MAPS and FUN_SUPPLIER_MAPS supply the linkage between trading partner definitions and their corresponding customer or supplier records, while FUN_TRADE_RELATIONS holds the core trading relationship data. FND_LOOKUP_VALUES is used for validation of source and related lookup-coded values, consistent with the role of validate_source. These tables collectively support the package's mandate of resolving and validating trading partner entities.

Usage Notes

FUN_TRADING_RELATION is a low-level utility that is typically invoked indirectly rather than called directly by end users. The metadata records that it is referenced by five other packages, indicating it serves as a shared dependency for higher-level intercompany and trading partner processing. It is commonly reached from Oracle Forms–based setup and transaction entry flows requiring trading partner defaults, from concurrent programs that generate or reconcile intercompany transactions and invoices, and from custom extensions that need to resolve a customer or supplier for a given trading context. Because the functions return Boolean values and expose outputs solely through OUT parameters, callers in SQL contexts must wrap them in PL/SQL blocks. The AUTHID CURRENT_USER declaration means callers must hold appropriate privileges on the underlying HZ, AP, FND, and FUN objects. Custom code should invoke validate_source before attempting get_customer, get_supplier, or get_relation to ensure the source input is acceptable.