Search Results pos_cont_addr_request_u1

Overview

POS.POS_CONT_ADDR_REQUESTS is a transactional table within the Oracle E-Business Suite Procurement application, residing in the POS (Purchasing) schema. It stores information about supplier requests for contact-address links, such as adding a contact for an address, updating an address contact, or removing a contact from an address. In the Oracle Supplier Lifecycle Management and supplier registration flows, this table acts as the staging and tracking mechanism that captures pending or processed changes to the relationship between a supplier contact and a supplier address (party site) before those changes are committed to the master data model in the Trading Community Architecture (TCA).

From a heuristic Data Vault modeling perspective, this object is best classified as a link entity. It does not behave as a hub because it does not anchor its own long-lived business key; rather, its surrogate key (CONT_ADDR_REQUEST_ID) identifies a relationship event between a supplier mapping, a contact party, and a party site, and the foreign keys connect distinct hubs. It is not a pure satellite either, because it carries its own identity and status/type attributes that describe the request event rather than describing an existing hub. The link classification reflects the table's role as the associative record joining contacts, addresses, and supplier mappings through a request lifecycle.

Key Information Stored

The table contains 13 documented columns. The most operationally significant are the following:

• CONT_ADDR_REQUEST_ID (NUMBER) — The surrogate primary key, uniquely identifying each contact-address link request. It is the column behind the unique index POS_CONT_ADDR_REQUEST_U1 (the business-key candidate documented in the schema), so it is the natural candidate for a downstream deterministic key.
• MAPPING_ID (NUMBER) — Identifier of the supplier mapping, tying the request back to the POS_SUPPLIER_MAPPINGS registry. Indexed by the nonunique index POS_CONT_ADDR_REQUEST_N1.
• CONTACT_PARTY_ID (NUMBER) — Identifier of the contact party in HZ_PARTIES.
• CONTACT_REQ_ID (NUMBER) — Identifier of the associated contact request in POS_CONTACT_REQUESTS.
• PARTY_SITE_ID (NUMBER) — Identifier of the party site (address) in HZ_PARTY_SITES.
• ADDRESS_REQ_ID (NUMBER) — Identifier of the associated address request in POS_ADDRESS_REQUESTS.
• REQUEST_STATUS (VARCHAR2 30) — The lifecycle status of the request (for example, pending, approved, rejected, or processed). Indexed by POS_CONT_ADDR_REQUEST_N3, making it a common filter predicate.
• REQUEST_TYPE (VARCHAR2 30) — The type of request, such as add, update, or remove of a contact-address link. Indexed by POS_CONT_ADDR_REQUEST_N2.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard Who columns for auditability, capturing the creating and last-updating user, timestamps, and login context.

Three nonunique indexes (N1 on MAPPING_ID, N2 on REQUEST_TYPE, N3 on REQUEST_STATUS) indicate that queries are frequently executed by supplier mapping, by request category, and by workflow status respectively.

Common Use Cases and Queries

Typical scenarios include monitoring the progress of supplier registration or supplier modification requests, auditing which contact-address changes are pending approval, and reconciling request records against the master TCA tables after publishing. A representative query retrieving pending link requests for a given supplier mapping is:

• SELECT CONT_ADDR_REQUEST_ID, CONTACT_PARTY_ID, PARTY_SITE_ID, REQUEST_TYPE, REQUEST_STATUS FROM POS.POS_CONT_ADDR_REQUESTS WHERE MAPPING_ID = :p_mapping_id AND REQUEST_STATUS = 'PENDING';
• Status roll-up reporting: SELECT REQUEST_STATUS, COUNT(*) FROM POS.POS_CONT_ADDR_REQUESTS GROUP BY REQUEST_STATUS; to gauge workload or backlog.
• Type analysis: filter on REQUEST_TYPE (add/update/remove) to isolate address-contact removals for impact assessment.
• Audit joins: combine with POS_CONTACT_REQUESTS and POS_ADDRESS_REQUESTS on CONTACT_REQ_ID and ADDRESS_REQ_ID to reconstruct the full request context for a supplier.

Related Objects

The table participates in the following documented foreign-key relationships, and the parent objects are the principal related entities:

• POS.POS_SUPPLIER_MAPPINGS — joined on MAPPING_ID; the supplier mapping registry that governs the supplier record.
• HZ_PARTIES — joined on CONTACT_PARTY_ID; the TCA party representing the contact.
• POS.POS_CONTACT_REQUESTS — joined on CONTACT_REQ_ID; the parent contact request driving the change.
• HZ_PARTY_SITES — joined on PARTY_SITE_ID; the address/party site being linked or unlinked.
• POS.POS_ADDRESS_REQUESTS — joined on ADDRESS_REQ_ID; the parent address request.

The APPS synonym APPS.POS_CONT_ADDR_REQUESTS is the standard access point, and the table does not reference any other database objects beyond these parents; the unique index POS_CONT_ADDR_REQUEST_U1 underpins the primary-key access path used throughout the supplier request processing flow.