Search Results pos_address_request_n2

Overview

POS.POS_ADDRESS_REQUESTS is a transactional table within the Oracle E-Business Suite Procurement Outsourcing (POS) schema, used to stage and track supplier address change requests submitted through the Supplier Portal and related sourcing workflows. The table records the intent and payload of requests to add, update, or remove a supplier address, along with the address attributes themselves and usage flags that indicate how the address applies across Payables, Purchasing, and RFQ activity. It is owned by the POS schema, resides in the APPS_TS_TX_DATA tablespace, and has a documented status of VALID in both Oracle EBS 12.1.1 and 12.2.2; the physical schema carries 33 columns.

From a heuristic modeling standpoint, the table's foreign-key structure suggests a hub-leaning classification, with MAPPING_ID and PARTY_SITE_ID anchoring it to supplier mapping and party site reference data. In practice it behaves largely as a satellite around the supplier mapping, capturing the request lifecycle and descriptive address content associated with each mapping.

Key Information Stored

The surrogate primary key is ADDRESS_REQUEST_ID, enforced by the unique index POS_ADDRESS_REQUEST_U1. This is distinct from any business identifier: no alternate unique business key is documented, so ADDRESS_REQUEST_ID serves as the sole documented unique key. The most significant columns include:

• ADDRESS_REQUEST_ID — surrogate identifier of the request; primary key and join target for dependent child tables.
• MAPPING_ID — identifier of the supplier mapping; also indexed by POS_ADDRESS_REQUEST_N1.
• PARTY_SITE_ID — identifier of the party site the request pertains to, linking to HZ_PARTY_SITES.
• REQUEST_STATUS — current lifecycle status of the request; indexed by POS_ADDRESS_REQUEST_N3.
• REQUEST_TYPE — the request category (add, update, or remove); indexed by POS_ADDRESS_REQUEST_N2, the index referenced in the user's search.
• HAS_BACKING_DOC — flag indicating whether current backing documents exist for the request.
• PARTY_SITE_NAME and the ADDRESS_LINE1 through ADDRESS_LINE4, CITY, POSTAL_CODE, STATE, PROVINCE, COUNTY, and COUNTRY columns — the descriptive address payload carried with the request.
• EMAIL_ADDRESS, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION, FAX_AREA_CODE, and FAX_NUMBER — contact details associated with the requested address.
• RFQ_FLAG, PAY_FLAG, PUR_FLAG, and PRIMARY_PAY_FLAG — usage flags indicating how the address applies to RFQ, payment, purchasing, and primary payment purposes.
• Audit columns CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, and END_DATE_ACTIVE — standard EBS who-columns and date-effectivity control.

Common Use Cases and Queries

Typical use cases include monitoring the approval pipeline of supplier address changes, reporting on outstanding requests by status or type, and reconciling requested address data against the master party site record. Reporting against request volume and type is supported by the non-unique index on REQUEST_TYPE, while status-driven dashboards benefit from the index on REQUEST_STATUS.

• Pending requests by type: SELECT REQUEST_TYPE, REQUEST_STATUS, COUNT(*) FROM POS.POS_ADDRESS_REQUESTS GROUP BY REQUEST_TYPE, REQUEST_STATUS;
• Requests linked to a supplier mapping: SELECT * FROM POS.POS_ADDRESS_REQUESTS WHERE MAPPING_ID = :mapping_id;
• Requests awaiting action: SELECT ADDRESS_REQUEST_ID, PARTY_SITE_NAME, REQUEST_TYPE FROM POS.POS_ADDRESS_REQUESTS WHERE REQUEST_STATUS = :status;

Related Objects

The table participates in a hub-leaning relationship set. It references POS.POS_SUPPLIER_MAPPINGS on MAPPING_ID and HZ_PARTY_SITES on PARTY_SITE_ID. Several child tables reference it via ADDRESS_REQUEST_ID: POS_ACNT_ADDR_REQ, POS_ADDRESS_NOTES, and POS_CONT_ADDR_REQUESTS. Joining these children to POS_ADDRESS_REQUESTS on ADDRESS_REQUEST_ID returns the notes, accounts, and contacts attached to each address request. In integrated reporting, POS_SUPPLIER_MAPPINGS supplies the supplier identity, while HZ_PARTY_SITES provides the consolidated party site definition against which requested address values are validated.