Search Results pos_acnt_gen_req_n1

Overview

POS.POS_ACNT_GEN_REQ is a transactional table in the Oracle E-Business Suite POS (Point of Sale / Supplier Banking) schema that stores supplier bank account registration and change requests. It functions as the primary staging record for account request metadata submitted through the supplier self-service and payables flows, holding the linkage between a supplier mapping, an external bank account, and a temporary (unvalidated) bank account identifier prior to final approval and activation. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, consistent with the standard configuration for high-volume transactional data.

From a dimensional modeling perspective, the heuristic Data Vault classification for this table is satellite-leaning. This suggests it is best modeled as a satellite attached to a core supplier or mapping hub, capturing descriptive and referential attributes (bank account identifiers, mapping references, and object versioning) rather than acting as an independent business hub or an associative link between two hubs.

Key Information Stored

The table contains ten documented columns. The surrogate primary key is ACCOUNT_REQUEST_ID, a NUMBER(15) that uniquely identifies each account request and is enforced by the unique index POS_ACNT_GEN_REQ_U1 on the APPS_TS_TX_IDX tablespace. This column is the business-key candidate recognized in the documented schema.

• ACCOUNT_REQUEST_ID — Surrogate primary key; unique identifier for the account request record.
• MAPPING_ID — Foreign key to POS_SUPPLIER_MAPPINGS, associating the request with a supplier-to-bank mapping. Indexed non-uniquely through POS_ACNT_GEN_REQ_N1.
• EXT_BANK_ACCOUNT_ID — Foreign key to IBY_EXT_BANK_ACCOUNTS; the approved external bank account once the request is finalized.
• TEMP_EXT_BANK_ACCT_ID — Foreign key to IBY_TEMP_EXT_BANK_ACCTS; the temporary staging bank account used during validation before promotion.
• OBJECT_VERSION_NUMBER — Optimistic locking column used to detect concurrent updates.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard Who columns providing audit and ownership metadata for every row.

Common Use Cases and Queries

Typical use cases include auditing supplier bank account change history, reconciling pending requests against approved external accounts, and reporting on request volume by supplier mapping. A baseline query retrieves all attributes for a given request:

• SELECT ACCOUNT_REQUEST_ID, MAPPING_ID, EXT_BANK_ACCOUNT_ID, TEMP_EXT_BANK_ACCT_ID, CREATION_DATE FROM POS.POS_ACNT_GEN_REQ WHERE ACCOUNT_REQUEST_ID = :request_id;
• Joining to POS_SUPPLIER_MAPPINGS on MAPPING_ID to report requests by supplier.
• Joining to IBY_EXT_BANK_ACCOUNTS on EXT_BANK_ACCOUNT_ID to validate approved account details.
• Joining to IBY_TEMP_EXT_BANK_ACCTS on TEMP_EXT_BANK_ACCT_ID to inspect staged account data awaiting validation.
• Filtering on CREATION_DATE and CREATED_BY for audit and compliance reporting.

Related Objects

The object participates in a small but well-defined dependency graph:

• POS_SUPPLIER_MAPPINGS — Referenced via MAPPING_ID; the parent mapping record.
• IBY_EXT_BANK_ACCOUNTS — Referenced via EXT_BANK_ACCOUNT_ID; holds finalized external bank account data.
• IBY_TEMP_EXT_BANK_ACCTS — Referenced via TEMP_EXT_BANK_ACCT_ID; holds temporary staging data.
• POS_ACNT_ADDR_SUMM_REQ — References this table via ACCOUNT_REQUEST_ID; carries address summary request details.
• APPS.POS_ACNT_GEN_REQ — The APPS-layer synonym/view through which application code typically accesses the table.

The table does not reference any other database object beyond the three foreign keys listed above, confirming its role as a dependent satellite entity within the POS banking request model.