Search Results pos_contact_requests




Overview
Explore in AI Chat

Overview

POS_CONTACT_REQUESTS is a transactional table in the POS schema of Oracle E-Business Suite (validated on 12.1.1 and 12.2.2), owned by the iSupplier Portal module. It stores supplier contact requests — records of changes that a supplier user submits against the contact information held for a supplier, supplier site, or supplier contact party. In iSupplier Portal, trading partners are prevented from directly editing master supplier data; instead, they register a request, which is routed to the buying organization for review, approval, or rejection. Each row therefore represents the state of one such request, including the proposed contact attributes and the workflow status that governs its lifecycle.

From a Data Vault modeling perspective, the mined FK structure classifies this table as satellite-leaning. It carries descriptive, request-specific attributes (names, phone, fax, e-mail, status) attached to a parent supplier mapping and to an HZ_PARTIES contact, rather than acting as a pure junction or a durable business hub. This is a heuristic suggestion rather than a documented Oracle classification, but it is useful when mapping POS objects into an analytics or warehouse layer.

Key Information Stored

The table is defined with 29 columns. The following are the most significant for functional and reporting purposes:

Common Use Cases and Queries

Typical reporting includes an open-request backlog for supplier administrators, audit trails of contact changes, and reconciliation of approved requests to the resulting HZ_PARTIES contact record. A representative query joins the request to its owning mapping and to the contact party:

  • SELECT r.contact_request_id, r.request_type, r.request_status, r.email_address, r.phone_number FROM pos.pos_contact_requests r WHERE r.request_status = 'PENDING';
  • SELECT r.contact_request_id, m.mapping_id, p.party_name, r.first_name, r.last_name FROM pos.pos_contact_requests r JOIN pos.pos_supplier_mappings m ON m.mapping_id = r.mapping_id JOIN hz.hz_parties p ON p.party_id = r.contact_party_id;
  • Ageing analysis using CREATION_DATE against LAST_UPDATE_DATE to measure approval cycle time.
  • Exception reports on HAS_BACKING_DOC = 'N' or requests with missing mandatory phone and e-mail attributes.
  • Detail extraction joined to POS_CONT_ADDR_REQUESTS on CONTACT_REQ_ID = CONTACT_REQUEST_ID for the address lines belonging to the same request.

Related Objects

The following objects are most significant when working with POS_CONTACT_REQUESTS:

  • POS_SUPPLIER_MAPPINGS — parent supplier-user mapping; referenced by POS_CONTACT_REQUESTS.MAPPING_ID.
  • HZ_PARTIES — TCA party master; referenced by POS_CONTACT_REQUESTS.CONTACT_PARTY_ID for the contact identity.
  • POS_CONT_ADDR_REQUESTS — child table holding address-level request lines; references POS_CONTACT_REQUESTS via CONTACT_REQ_ID.
  • HZ_CONTACT_POINTS and HZ_PERSON_PROFILES — downstream TCA tables that receive approved name, phone, fax, and e-mail changes.
  • POS_SUPPLIER_USERS — the portal account context (via MAPPING_ID) that raised the request.
  • WF_ITEM_ACTIVITY_STATUSES / Oracle Workflow — holds the approval routing associated with REQUEST_STATUS transitions.
  • POZ_SUPPLIERS_V and POZ_SUPPLIER_SITES_V — supplier and site views commonly used alongside the request for administrative reporting.