Search Results pos_contact_request_n1

Overview

POS.POS_CONTACT_REQUESTS is a transactional table in the Oracle E-Business Suite Procurement module (schema POS), documented as VALID in ETRM for releases 12.1.1 and 12.2.2. It stores information about supplier contact requests raised through the supplier lifecycle — specifically requests to add a contact, update an existing contact, or remove a contact associated with a supplier mapping. Each row represents a single pending, approved, or rejected contact change request, holding both the workflow state (REQUEST_STATUS, REQUEST_TYPE) and a flattened snapshot of the proposed contact attributes (name, email, phone, fax, job title, and so on). Because these requests originate from supplier self-service or buyer-initiated registration flows, the table acts as the staging and audit surface between supplier-facing input and the master contact records ultimately consolidated in the Trading Community Architecture (HZ) tables.

From a Data Vault modeling perspective, the mined relationship structure suggests a satellite-leaning classification. The table is keyed by a surrogate CONTACT_REQUEST_ID and carries descriptive, time-stamped attributes; its foreign keys to POS_SUPPLIER_MAPPINGS and HZ_PARTIES are consistent with a satellite hanging off supplier-mapping and party hubs, with the request lifecycle columns supplying the descriptive payload.

Key Information Stored

• CONTACT_REQUEST_ID — surrogate primary key (POS_CONTACT_REQUEST_PK) and the column behind the unique index POS_CONTACT_REQUEST_U1. This is the business-key candidate searched by users looking up a single request.
• MAPPING_ID — foreign key to POS_SUPPLIER_MAPPINGS; identifies the supplier mapping the request belongs to.
• CONTACT_PARTY_ID — foreign key to HZ_PARTIES; identifies the existing contact party being modified.
• REQUEST_STATUS and REQUEST_TYPE — the workflow state and the nature of the request (add, update, or remove a contact).
• HAS_BACKING_DOC — flag indicating whether the request is supported by current backing documents.
• Contact identity fields — CONTACT_TITLE, FIRST_NAME, MIDDLE_NAME, LAST_NAME, JOB_TITLE.
• Communication fields — EMAIL_ADDRESS, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION, FAX_AREA_CODE, FAX_NUMBER.
• Standard Who columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — for audit and change tracking.
• CREATE_USER_ACCOUNT and DO_NOT_DELETE — control flags governing user-account provisioning and record deletion protection.

Non-unique indexes (POS_CONTACT_REQUEST_N1 through N3) support lookups by MAPPING_ID, REQUEST_TYPE, and REQUEST_STATUS respectively, reflecting the common filtering dimensions.

Common Use Cases and Queries

Typical scenarios include reporting pending supplier contact change requests by status, tracing a supplier's contact history, and driving approval workflows. A representative query joins the table back to its supplier mapping:

• List all open requests for a supplier: SELECT CONTACT_REQUEST_ID, REQUEST_TYPE, REQUEST_STATUS FROM POS.POS_CONTACT_REQUESTS WHERE MAPPING_ID = :mapping_id;
• Filter by workflow state: SELECT * FROM POS.POS_CONTACT_REQUESTS WHERE REQUEST_STATUS = 'PENDING';
• Look up a single request by its unique key: SELECT * FROM POS.POS_CONTACT_REQUESTS WHERE CONTACT_REQUEST_ID = :id;
• Audit changes over time using the CREATION_DATE and LAST_UPDATE_DATE columns.

Related Objects

• POS.POS_SUPPLIER_MAPPINGS — referenced via MAPPING_ID; the parent supplier mapping.
• HZ_PARTIES — referenced via CONTACT_PARTY_ID; the contact party record.
• POS.POS_CONT_ADDR_REQUESTS — the child table referencing this table via CONTACT_REQ_ID, holding address-level request detail.

These relationships place POS_CONTACT_REQUESTS at the intersection of supplier registration, TCA party data, and approval workflow processing.