Search Results pos_contact_request_pk

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:

• CONTACT_REQUEST_ID — surrogate primary key, enforced by POS_CONTACT_REQUEST_PK and uniquely indexed by POS_CONTACT_REQUEST_U1. This is the single business-key candidate documented in the metadata.
• MAPPING_ID — foreign key to POS_SUPPLIER_MAPPINGS; ties the request to the specific supplier user-to-supplier/site mapping that originated it.
• CONTACT_PARTY_ID — foreign key to HZ_PARTIES; identifies the contact party record the request applies to in the Trading Community Architecture model.
• REQUEST_STATUS and REQUEST_TYPE — the workflow state (for example pending, approved, rejected) and the nature of the requested change.
• HAS_BACKING_DOC — flag indicating whether supporting documentation accompanies the request.
• CONTACT_TITLE, FIRST_NAME, MIDDLE_NAME, LAST_NAME — the proposed name and salutation values for the contact.
• JOB_TITLE, DEPARTMENT — organizational attributes of the contact.
• EMAIL_ADDRESS, URL — electronic contact details.
• PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION and FAX_AREA_CODE, FAX_NUMBER — decomposed voice and facsimile numbers.
• ALT_CONTACT_NAME, ALT_AREA_CODE, ALT_PHONE_NUMBER — an alternate contact and telephone number supplied with the request.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, CREATE_USER_ACCOUNT — standard EBS WHO columns and the portal account that raised the request.
• DO_NOT_DELETE — a protective flag used to preserve referential integrity for requests that must not be purged.

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.