Search Results pos_supplier_mappings




Overview
Explore in AI Chat

Overview

The POS_SUPPLIER_MAPPINGS table resides in the POS schema and belongs to the iSupplier Portal product family within Oracle E-Business Suite, documented across releases 12.1.1 and 12.2.2. It serves as the central reference structure that associates supplier parties and supplier registration requests with the various supplier lifecycle requests raised through the iSupplier Portal. In practical terms, the table acts as the anchor record that ties a registered supplier—or a prospective supplier party in the trading community model—to the discrete registration, address, contact, business classification, and product or service requests generated during supplier onboarding and maintenance.

From a data modeling perspective, the ETRM metadata classifies this object heuristically as a hub within a Data Vault construct. This classification is supported by its position at the center of a star of foreign key relationships: the table holds the principal identifiers (mapping, party, vendor, and supplier registration) while multiple dependent tables reference back to it through MAPPING_ID. The hub interpretation suggests that POS_SUPPLIER_MAPPINGS represents the durable, business-key-anchored core of supplier registration identity, around which transactional request detail would typically be modeled as satellite structures.

Key Information Stored

The physical schema comprises nine documented columns. The most significant are summarized below.

The distinction between the surrogate MAPPING_ID and the unique business columns SUPPLIER_REG_ID and VENDOR_ID is important for integration and ETL design: natural-key matching should generally target the registration or vendor identifier rather than the surrogate.

Common Use Cases and Queries

Typical reporting and integration scenarios center on tracing which requests belong to a given supplier registration. A join to the registration header is common:

  • Attaching all address, contact, and business classification requests to their parent registration: SELECT m.MAPPING_ID, m.PARTY_ID, m.VENDOR_ID FROM POS_SUPPLIER_MAPPINGS m JOIN POS_SUPPLIER_REGISTRATIONS r ON m.SUPPLIER_REG_ID = r.SUPPLIER_REG_ID.
  • Resolving the master party for a supplier through HZ_PARTIES via PARTY_ID to obtain party name and party number for downstream reporting.
  • Counting dependent requests per mapping by aggregating across POS_ADDRESS_REQUESTS, POS_CONTACT_REQUESTS, and POS_BUS_CLASS_REQS on MAPPING_ID.
  • Data-quality checks confirming uniqueness of VENDOR_ID and SUPPLIER_REG_ID, since both carry unique indexes.

Related Objects

The table is joined to two parent references and is referenced by seven dependent request tables.

  • HZ_PARTIES — joined on POS_SUPPLIER_MAPPINGS.PARTY_ID; supplies party identity.
  • POS_SUPPLIER_REGISTRATIONS — joined on POS_SUPPLIER_MAPPINGS.SUPPLIER_REG_ID; the registration parent.
  • POS_ACNT_ADDR_REQ — reference via MAPPING_ID (account address requests).
  • POS_ACNT_GEN_REQ — reference via MAPPING_ID (account general requests).
  • POS_ADDRESS_REQUESTS — reference via MAPPING_ID.
  • POS_BUS_CLASS_REQS — reference via MAPPING_ID (business classification requests).
  • POS_CONTACT_REQUESTS — reference via MAPPING_ID.
  • POS_CONT_ADDR_REQUESTS — reference via MAPPING_ID (contact address requests).
  • POS_PRODUCT_SERVICE_REQUESTS — reference via MAPPING_ID (product and service requests).

These relationships establish POS_SUPPLIER_MAPPINGS as the pivotal hub through which supplier registration activity across the iSupplier Portal is consolidated.