Search Results pv_territory_assignment_online

Overview

PV.PV_TAP_BATCH_CHG_PARTNERS is a transactional staging table in the Oracle E-Business Suite Partner (PV) schema. It holds the updated partner information captured when either the PV_TERRITORY_ASSIGNMENT_ONLINE profile option is set to "No," or when partner information is updated from an application other than Partner Relationship Management (PRM). In such cases, changes are not applied online but are queued in this table for subsequent batch (concurrent) processing, which explains the presence of the PROCESSED_FLAG and the standard concurrent program WHO columns.

The object resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10. Under a heuristic Data Vault classification mined from the foreign-key structure, this object is modeled as a standalone entity — it neither functions as a hub, link, nor satellite, reflecting its role as an isolated staging buffer rather than a participant in a normalized relationship graph. This classification is a modeling suggestion only and does not imply an enforced Data Vault design in EBS.

Key Information Stored

The table contains fourteen documented columns. The most significant are listed below.

• PARTNER_ID (NUMBER) — The partner identifier and the surrogate primary key of the table (PV_TAP_BATCH_CHG_PARTNERS_PK). It is also the single column of the unique index PV_TAP_BATCH_CHG_PARTNERS_U1, making it the business-key candidate as well. This dual role distinguishes the surrogate PK from a purely natural business key.
• VAD_PARTNER_ID (NUMBER) — The party identifier for the relationship between a partner of type VAD and a vendor, capturing the associated party linkage.
• PROCESSED_FLAG (VARCHAR2) — Indicates the processing state of the queued change. This column anchors the nonunique index PV_TAP_BATCH_CHG_PARTNERS_N1 and is the primary driver of batch consumption logic.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — Standard concurrent program columns identifying the last concurrent request to update the record and the application/program context.
• OBJECT_VERSION_NUMBER (NUMBER) — Optimistic locking column used to detect concurrent modifications.
• SECURITY_GROUP_ID (NUMBER) — Security group identifier; this is the only documented foreign key, referencing FND_SECURITY_GROUPS.
• LAST_UPDATE_DATE, LAST_UPDATE_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — Standard WHO audit columns.

Common Use Cases and Queries

The principal use case is batch reconciliation of partner data. Administrators and developers query unprocessed rows to confirm which partner changes remain pending after an offline or external update.

To retrieve pending changes:

• SELECT PARTNER_ID, VAD_PARTNER_ID, REQUEST_ID, PROCESSED_FLAG FROM PV.PV_TAP_BATCH_CHG_PARTNERS WHERE PROCESSED_FLAG = 'N';

To identify changes submitted by a specific concurrent program run:

• SELECT * FROM PV.PV_TAP_BATCH_CHG_PARTNERS WHERE REQUEST_ID = :request_id;

To reconcile with the security group dimension:

• SELECT p.PARTNER_ID, g.SECURITY_GROUP_ID FROM PV.PV_TAP_BATCH_CHG_PARTNERS p, FND_SECURITY_GROUPS g WHERE p.SECURITY_GROUP_ID = g.SECURITY_GROUP_ID;

Reporting typically focuses on volume of staged changes, aging of unprocessed records by CREATION_DATE, and audit trails via the WHO and concurrent program columns.

Related Objects

The documented dependency data restricts explicit relationships to the following.

• FND_SECURITY_GROUPS — Referenced through the SECURITY_GROUP_ID foreign key; join is PV_TAP_BATCH_CHG_PARTNERS.SECURITY_GROUP_ID = FND_SECURITY_GROUPS.SECURITY_GROUP_ID.
• PV_TAP_BATCH_CHG_PARTNERS# — The shadow/editioning base object referenced by this table, present in the dependency list.

The metadata explicitly states that PV_TAP_BATCH_CHG_PARTNERS does not reference any other database object beyond the security group, and no additional referencing objects are documented. Consequently, all joins should be validated against the live data dictionary before use in production reporting.