Search Results fun_trade_rel_source

Overview

FUN_TRADING_RELATION is a PL/SQL package body owned by the APPS schema that maintains Oracle E-Business Suite trading partner relationships used by the Financials intercompany and intracompany processing flows. Its role is to resolve the trading relationship that exists between a source (transaction) operating unit and a target (trading partner) operating unit, expressed as a row in FUN_TRADE_RELATIONS. Trading relationships are the foundational configuration record that enables intercompany invoicing, intercompany payables, and the associated balancing and reconciliation processes in Oracle Payables, Oracle Receivables, and General Ledger.

The package exposes a set of resolution and validation routines that are consumed by both standard EBS flows and customer extensions. The header comment in the source carries the identifier $Header: funtraderelb.pls 120.12 2006/05/15 14:04:49 ashikuma noship $, which reflects a long-lived component of the Financials family, and its classification in the ETRM repository is OTHER, indicating it is not registered as a public open interface but is nonetheless referenced by other application packages.

Logging follows the standard FND_LOG framework. The package defines constants for the statement, procedure, event, exception, error, and unexpected levels and uses the path prefix FUN.PLSQL.funtraderelb.FUN_TRADING_RELATION_PKG. to write diagnostic messages when the runtime debug level enables them.

Key Procedures and Functions

• VALIDATE_SOURCE — An internal function that validates a supplied trading relationship source code against the FND_TRADE_REL_SOURCE lookup type in FND_LOOKUP_VALUES. It returns a Boolean result and is intended to be called only by GET_CUSTOMER and GET_SUPPLIER. Failures are trapped, logged at the unexpected level, and re-raised through APP_EXCEPTION.
• GET_CUSTOMER — Returns the trading relationship applicable to a customer-side trading partner. It relies on VALIDATE_SOURCE to confirm the source value before performing relationship resolution.
• GET_SUPPLIER — Returns the trading relationship applicable to a supplier-side trading partner, using the same source validation path.
• GET_RELATION — The core resolution routine. It accepts a source code, a relationship type, the transaction and trading partner legal entity identifiers, optional and required organization identifiers on both sides, and returns the relationship identifier together with a success indicator and message data. This is the routine most commonly located by searches for "get_relation."

Tables Accessed

• FUN_TRADE_RELATIONS — The primary table holding configured trading relationship records; read during resolution.
• FUN_CUSTOMER_MAPS and FUN_SUPPLIER_MAPS — Mapping tables that associate customers and suppliers with trading relationships.
• FND_LOOKUP_VALUES — Provides the FUN_TRADE_REL_SOURCE lookup values used by VALIDATE_SOURCE.
• HZ_CUST_ACCOUNTS_ALL, HZ_CUST_ACCT_SITES_ALL, and HZ_CUST_SITE_USES_ALL — Receivables trading partner account, site, and site-use data used for customer-side resolution.
• AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL — Payables supplier and supplier site data used for supplier-side resolution.

Usage Notes

FUN_TRADING_RELATION is invoked programmatically rather than through a dedicated concurrent program. It is referenced by five other packages in the APPS schema, which typically call GET_RELATION to obtain the relationship ID required for downstream intercompany transactions. Custom code should call the public routines on the specification and must supply the required organization and legal entity identifiers, since GET_RELATION defines certain parameters as mandatory and others as optional. Because errors are propagated via APP_EXCEPTION, callers should include standard exception handling. Debug output is governed by FND_LOG levels, so enabling the appropriate runtime level is the recommended route for diagnosing resolution failures.