Search Results pos_acnt_addr_req_pk

Overview

The POS_ACNT_ADDR_REQ table is a core transactional object within the POS — iSupplier Portal module of Oracle E-Business Suite (validated across 12.1.1 and 12.2.2). It stores supplier bank account and address assignment requests, acting as the persistence layer for supplier self-service changes submitted through the iSupplier Portal. When a supplier user updates banking details or assigns a party-site address, the request is captured here before validation, approval, and propagation to the master supplier records.

The table resides in the POS schema and is registered as VALID in the ETRM repository. Its physical schema documents 12 columns and a single primary key constraint, POS_ACNT_ADDR_REQ_PK, defined on ASSIGNMENT_REQUEST_ID. A second unique index, POS_ACNT_ADDR_REQ_U1, also spans ASSIGNMENT_REQUEST_ID, confirming it as the business-key candidate.

From a Data Vault modeling perspective, the mined foreign-key structure classifies this object as satellite-leaning. It carries descriptive request-state attributes (status, type) and change-tracking columns, and it depends on several parent entities rather than serving as an independent hub. This suggests treating it as a satellite attached to a supplier/address hub composite, with links to the mappings and address-request domains.

Key Information Stored

The table is intentionally narrow. The most significant columns are:

• ASSIGNMENT_REQUEST_ID — Surrogate primary key and unique business-key candidate; uniquely identifies each bank account / address assignment request.
• MAPPING_ID — Foreign key to POS_SUPPLIER_MAPPINGS, tying the request to a supplier-to-account mapping.
• ADDRESS_REQUEST_ID — Foreign key to POS_ADDRESS_REQUESTS, linking the request to its underlying address change.
• PARTY_SITE_ID — Foreign key to HZ_PARTY_SITES, referencing the TCA party site affected by the assignment.
• REQUEST_STATUS — Lifecycle state of the request (e.g., pending, approved, rejected).
• REQUEST_TYPE — Distinguishes account versus address assignment requests.
• OBJECT_VERSION_NUMBER — Optimistic locking column used by the OAF/iSupplier UI.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard WHO audit columns capturing who created and last modified each request.

The surrogate key should not be confused with the foreign-key references; the business identity of a request is expressed through the combination of MAPPING_ID, ADDRESS_REQUEST_ID, and PARTY_SITE_ID.

Common Use Cases and Queries

Typical scenarios include auditing supplier-submitted banking changes, tracking pending address assignments, and reconciling iSupplier requests against TCA party sites. A representative query joining parents is:

• SELECT r.ASSIGNMENT_REQUEST_ID, r.REQUEST_TYPE, r.REQUEST_STATUS, r.PARTY_SITE_ID, m.MAPPING_ID FROM POS.POS_ACNT_ADDR_REQ r JOIN POS.POS_SUPPLIER_MAPPINGS m ON r.MAPPING_ID = m.MAPPING_ID WHERE r.REQUEST_STATUS = 'PENDING';
• Reporting on request volumes by CREATION_DATE for compliance dashboards.
• Locating all requests tied to a specific HZ_PARTY_SITES.ROWID via PARTY_SITE_ID.
• Joining to POS_ACNT_ADDR_SUMM_REQ on ASSIGNMENT_REQUEST_ID for summary-level reporting.

Related Objects

The following objects are directly related through documented foreign keys:

• POS_SUPPLIER_MAPPINGS — joined via MAPPING_ID.
• POS_ADDRESS_REQUESTS — joined via ADDRESS_REQUEST_ID.
• HZ_PARTY_SITES — joined via PARTY_SITE_ID.
• POS_ACNT_ADDR_SUMM_REQ — references this table via ASSIGNMENT_REQUEST_ID.

Together these establish POS_ACNT_ADDR_REQ as the linking transactional record between supplier mappings, address requests, and TCA party sites.