Search Results pos_address_requests




Overview
Explore in AI Chat

Overview

The POS_ADDRESS_REQUESTS table, owned by the POS schema, is the core transactional object behind supplier address requests in the Oracle E-Business Suite iSupplier Portal module. It stores the working record of an address change or addition submitted by a supplier through the self-service portal, capturing the proposed address content, its processing status, its linkage to a supplier mapping and a trading partner site, and the flags that determine where the requested address may be used within procurement and payment flows. In the seeded 12.1.1 and 12.2.2 data models the table is documented as VALID with 33 columns.

The object sits between supplier registration data and the master address repositories. Each row is anchored by a surrogate primary key, ADDRESS_REQUEST_ID, enforced through the POS_ADDRESS_REQUEST_PK constraint and the unique index POS_ADDRESS_REQUEST_U1. Because the table both references upstream supplier and party-site entities and is in turn referenced by several dependent detail and audit tables, its FK structure suggests a hub-leaning Data Vault classification: it behaves like a durable business key container at the center of a narrow constellation of link and satellite relationships, rather than a pure transactional detail table.

Key Information Stored

The most operationally significant columns fall into identity, workflow, address content, contact, and usage-flag groups.

Common Use Cases and Queries

Typical reporting and operational scenarios include monitoring pending address requests, auditing approved changes against HZ_PARTY_SITES, and validating that payment-relevant addresses carry the correct flags. A representative query pattern joins the request to its supplier mapping and party site, filtering on status:

  • Open request dashboards — SELECT ADDRESS_REQUEST_ID, MAPPING_ID, PARTY_SITE_NAME, REQUEST_STATUS FROM POS_ADDRESS_REQUESTS WHERE REQUEST_STATUS = 'PENDING'.
  • Payment-address reconciliation — filter on PAY_FLAG = 'Y' and PRIMARY_PAY_FLAG = 'Y' to confirm a single primary pay site per supplier mapping.
  • Change-history auditing — join to POS_ADDRESS_NOTES and POS_CONT_ADDR_REQUESTS on ADDRESS_REQUEST_ID to assemble reviewer comments and contact changes.
  • Flag completeness reporting — group by MAPPING_ID and count RFQ_FLAG, PUR_FLAG, and PAY_FLAG combinations to find mappings lacking any usable address.

Related Objects

The relationship data identifies the most significant dependent and referenced objects:

  • POS_SUPPLIER_MAPPINGS — referenced via POS_ADDRESS_REQUESTS.MAPPING_ID; supplies the supplier-to-party context.
  • HZ_PARTY_SITES — referenced via PARTY_SITE_ID; the TCA trading partner site that acts as the master site record.
  • POS_ACNT_ADDR_REQ — child table joined on ADDRESS_REQUEST_ID, holding account-level address request detail.
  • POS_ADDRESS_NOTES — child table joined on ADDRESS_REQ_ID, storing request comments and feedback.
  • POS_CONT_ADDR_REQUESTS — child table joined on ADDRESS_REQ_ID, storing contact-level address request detail.

Collectively these relationships position POS_ADDRESS_REQUESTS as the hub of the iSupplier Portal address-request sub-model, with HZ_PARTY_SITES providing the TCA integration point and the three child tables supplying account, contact, and commentary detail.