Search Results party_fk




Overview

EDW_TRD_PARTNER_PKG is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that belongs to the Oracle E-Business Suite Trading Community and Enterprise Data Warehouse (EDW) integration layer. Its business function is to resolve surrogate foreign key identifiers for trading partners — suppliers, supplier sites, customers, customer sites, and parties — into the canonical key values used by the EDW / Business Intelligence foundation schemas. The package header carries the source control signature poafktps.pls 120.0, indicating that it originated within the Procurement (PO) family of database objects, which is consistent with the supplier-centric nature of its first two functions. In the context of a search for supplier_fk, this package is the authoritative public API through which downstream code obtains the EDW foreign key value associated with a given vendor or vendor site.

Key Procedures and Functions

The documented public interface exposes five functions. None of them perform transactional DML; each returns a VARCHAR2 foreign key string derived from the operational identifier passed in.

  • SUPPLIER_FK — The function of primary interest. It accepts a vendor identifier and returns the corresponding EDW surrogate foreign key for that supplier. This is the standard entry point for reporting and extraction logic that must translate an AP_SUPPLIERS/PO_VENDORS vendor ID into an EDW partner key.
  • SUPPLIER_SITE_FK — Returns the EDW foreign key for a specific supplier site. Because a supplier may have many sites, this function additionally accepts an operating unit (ORG_ID) context and derives the site-level key with that organization qualification.
  • CUSTOMER_FK — Returns the EDW foreign key corresponding to a Receivables customer account identifier.
  • CUSTOMER_SITE_FK — Returns the EDW foreign key for a customer site, keyed on the site-use identifier rather than the account identifier.
  • PARTY_FK — Returns the EDW foreign key for a Trading Community Architecture (TCA) party, providing the highest-level partner abstraction shared by both supplier and customer records.

All five functions carry an optional instance-code parameter, allowing the caller to request the key for a specific EDW source instance; when omitted, the local instance context is assumed. Each function is also declared with PRAGMA RESTRICT_REFERENCES (…, WNDS, WNPS, RNPS), confirming that they write neither database state nor package state and read no package state — an assurance that they may safely be invoked from SQL statements, views, and function-based indexes.

Tables Accessed

Per the documented metadata, the only table referenced by this package through APPS synonyms is EDW_LOCAL_INSTANCE. This table supplies the instance-code-to-local-instance mapping used to interpret the optional p_instance_code parameter and to determine the default instance when that parameter is null. Because the package is declared with restrictive purity pragmas and is documented as referencing no transactional tables, resolution of the underlying trading-partner data is delegated to the EDW staging and key-mapping layer rather than performed against base EBS entity tables within this package.

Usage Notes

EDW_TRD_PARTNER_PKG is a reference-resolution utility invoked predominantly from EDW and Business Intelligence extraction routines, custom reports, and data-migration scripts. It is referenced by ten other packages, indicating that it sits beneath a shared key-resolution layer rather than being called directly by end-user forms. Practical invocation patterns include:

  • Calling EDW_TRD_PARTNER_PKG.SUPPLIER_FK(:vendor_id) inside a SELECT to project the EDW supplier key onto operational procurement data.
  • Calling SUPPLIER_SITE_FK with an explicit ORG_ID when the extract must be partitioned by operating unit.
  • Using PARTY_FK to reconcile supplier and customer records that resolve to the same TCA party.

Because the functions are pure and SQL-callable, they are safe to embed in views and BI repository queries; however, callers should supply the instance code explicitly in multi-instance or multi-organization deployments to avoid relying on the local-instance default resolved from EDW_LOCAL_INSTANCE. As with all APPS-owned EDW packages, the interface should be treated as internal and subject to change between EBS releases.