Search Results pos_supplier_mapping_u1

Overview

POS.POS_SUPPLIER_MAPPINGS is a transactional reference table within the Oracle E-Business Suite Procurement and Supplier Lifecycle Management area, owned by the POS schema. It functions as a central cross-reference that associates supplier requests and supplier registrations with their corresponding supplier parties and PO vendors in the Trading Community Architecture (TCA) model. As documented in ETRM for releases 12.1.1 and 12.2.2, the table exists to let other supplier profile request tables resolve the supplier party or supplier registration that a given request ultimately produced. Because it links multiple independent entities rather than extending a single parent, its heuristic Data Vault classification is a hub, and it can be modeled as such, with MAPPING_ID serving as the primary business key referenced by dependent registration and request tables.

Key Information Stored

The table is defined with nine columns and resides in the APPS_TS_TX_DATA tablespace, while its indexes are stored in APPS_TS_TX_IDX. The most significant columns are:

• MAPPING_ID (NUMBER, 15) — the surrogate primary key (POS_SUPPLIER_MAPPING_PK) and the column through which downstream registration tables join.
• PARTY_ID — the party identifier of the supplier party in TCA, foreign-keyed to HZ_PARTIES and indexed by the nonunique POS_SUPPLIER_MAPPING_N1 index.
• VENDOR_ID — the vendor identifier of the PO vendor, enforced as a business key through the unique index POS_SUPPLIER_MAPPING_U4.
• SUPPLIER_REG_ID — the registration identifier of the supplier registration or request, foreign-keyed to POS_SUPPLIER_REGISTRATIONS and enforced as a business key through the unique index POS_SUPPLIER_MAPPING_U3.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard Who columns providing audit history.

The presence of unique indexes on SUPPLIER_REG_ID and VENDOR_ID confirms that the table maintains a one-to-one mapping between a supplier registration and its resulting vendor or party, with MAPPING_ID acting purely as the surrogate identifier (POS_SUPPLIER_MAPPING_U1).

Common Use Cases and Queries

The primary practical use is resolving a supplier registration to the party and vendor records created for it, or reverse-resolving from a vendor or party back to the originating registration. Typical reporting patterns include:

• Joining SUPPLIER_REG_ID to POS_SUPPLIER_REGISTRATIONS to report the status of registrations that have completed vendor and party creation.
• Joining PARTY_ID to HZ_PARTIES to retrieve the supplier party name alongside the vendor for reconciliation reporting.
• Aggregating request activity across the dependent request tables, each of which joins on MAPPING_ID, to determine how many bank, address, contact, or business-classification requests are associated with a given registration.

A representative query is: SELECT m.mapping_id, m.supplier_reg_id, m.party_id, m.vendor_id FROM pos.pos_supplier_mappings m WHERE m.vendor_id = :vendor_id; The row is the natural starting point for tracing everything a supplier registration generated.

Related Objects

POS_SUPPLIER_MAPPINGS participates in a hub-and-spoke relationship with supplier registration and request tables. It references two objects directly: HZ_PARTIES through PARTY_ID and POS_SUPPLIER_REGISTRATIONS through SUPPLIER_REG_ID. It is referenced by numerous supplier profile request tables via their MAPPING_ID foreign keys, including POS_ACNT_ADDR_REQ, POS_ACNT_GEN_REQ, POS_ADDRESS_REQUESTS, POS_BUS_CLASS_REQS, POS_CONTACT_REQUESTS, POS_CONT_ADDR_REQUESTS, and POS_PRODUCT_SERVICE_REQUESTS. Through these foreign keys, the table acts as the common anchor that ties each supplier setup request type to the registration that produced it and to the TCA party and PO vendor that resulted from it, making it a pivotal object for supplier onboarding analysis and data lineage tracing in both 12.1.1 and 12.2.2.