Search Results edw_trd_partner_pkg




Overview
Explore in AI Chat

Overview

EDW_TRD_PARTNER_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite. Its name and object classification place it within the Enterprise Data Warehouse (EDW) family of utilities that supply the Oracle EBS Operational Data Store and analytical reporting layer. The "TRD_PARTNER" component identifies the package as a foreign-key resolution layer for "trading partners" — that is, suppliers and customers — which EBS holds as distinct but related entities in the Trading Community Architecture (TCA).

The package serves a narrow, well-defined purpose: it returns the primary key (foreign key) value for a partner entity given a supplied business identifier. This pattern is common in EDW extract, transform, and load (ETL) code, where staging records arrive keyed only by a legacy identifier and the surrogate key from the transactional tables must be resolved before a fact or dimension row can be written.

Key Procedures and Functions

The ETRM metadata documents five callable units in the package, classified under API type OTHER:

  • SUPPLIER_FK — resolves the supplier identifier to its foreign-key value, allowing EDW loads to link a staging record to the correct AP supplier record.
  • SUPPLIER_SITE_FK — resolves the supplier site identifier, providing the more granular purchasing or pay-site key that some EDW facts require in addition to the supplier key.
  • CUSTOMER_FK — returns the customer foreign key, used when staging data identifies the customer by a business-level name or number rather than the TCA party key.
  • CUSTOMER_SITE_FK — resolves the customer site (ship-to or bill-to location) foreign key, giving the site-level granularity required for order and receipt analysis.
  • PARTY_FK — resolves the TCA party foreign key, the highest-level trading-community identifier from which both supplier and customer relationships derive. This is the common denominator for partners that appear on both sides of the transaction.

The uniform _FK suffix confirms that each unit is a lookup function returning a key value rather than a maintenance procedure that writes data. No parameter lists are reproduced in the documentation, and none should be presumed.

Tables Accessed

The single documented table reference is EDW_LOCAL_INSTANCE, accessed through an APPS synonym. This table stores instance-level configuration data for the EDW environment. The package almost certainly queries it to obtain the local instance or organization identifier that scopes the foreign-key lookups, ensuring results are correct for the specific instance or ledger being loaded. No other tables are recorded in the dependency metadata; any additional lookups performed inside the function bodies are not exposed in the documentation and are therefore not asserted here.

Usage Notes

EDW_TRD_PARTNER_PKG is an internal EDW utility rather than a user-facing API. It is not referenced by any database object of record outside the package itself, and the metadata shows no form, concurrent program, or workflow depending directly upon it. Instead, it is one of the packages referenced by ten other packages, indicating that it exists to be called by higher-level EDW extraction and transformation routines.

Typical invocation occurs during batch ETL: a staging package calls SUPPLIER_FK, SUPPLIER_SITE_FK, CUSTOMER_FK, CUSTOMER_SITE_FK, or PARTY_FK once per source record to translate legacy identifiers into EBS surrogate keys before inserting into warehouse tables. Because the functions perform read-only lookups against EDW configuration and partner data, they are safe to call repeatedly within a load cycle and carry no transactional side effects. Developers extending EDW code should call these functions rather than writing ad hoc key-resolution SQL, as doing so preserves the package's centralized join logic and its instance-scoping behavior. The package is not intended for direct invocation from forms or end-user concurrent requests, and the source is fully wrapped in the standard EDW fashion, so behavior must be inferred from documented dependencies and the deployed build.