Results for “pv_partner_accesses”

50+ results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PV_PARTNER_ACCESSES is a table owned by the PV schema within the Oracle E-Business Suite Partner Management module. It stores channel team member information, associating individual resources with partner organizations and recording the access rights those resources hold. In Oracle EBS 12.1.1 and 12.2.2, this table is central to channel-facing security and partner relationship modeling, where a resource — typically an employee or channel manager — must be linked to one or more partners in order to view or act upon partner data.

The table is classified as VALID and carries 34 documented columns. Its primary key constraint, PV_PARTNER_ACCESS_PK, is built on the PARTNER_ACCESS_ID column, giving each row a stable surrogate identifier. Applying a Data Vault modeling heuristic, the mined relationship structure suggests PV_PARTNER_ACCESSES behaves as a standalone object with link-like characteristics: it resolves the many-to-many association between a partner and a resource while also holding descriptive access attributes. It is not modeled as a dependent satellite of another PV entity, because no parent foreign key other than the security group reference was identified.

Key Information Stored

The most significant columns in PV_PARTNER_ACCESSES fall into three groups: identity, relationship, and access control.

  • PARTNER_ACCESS_ID — the surrogate primary key enforced by PV_PARTNER_ACCESS_PK, unique per access record.
  • PARTNER_ID — identifies the partner organization whose channel team is being defined.
  • RESOURCE_ID — identifies the team member, typically a resource from Oracle Resource Management.
  • ACCESS_TYPE — the classification of the access granted to the resource. This is the principal business attribute of the row.
  • KEEP_FLAG — indicates whether the access assignment is retained when team structures change.
  • CREATED_BY_TAP_FLAG — records whether the association was created through the partner access process automation path.
  • VAD_PARTNER_ID — a secondary partner reference used in value-added distribution or indirect partner hierarchies.
  • SECURITY_GROUP_ID — a foreign key to FND_SECURITY_GROUPS that scopes the record to a security group, supporting Oracle's multi-organization access control.
  • OBJECT_VERSION_NUMBER — optimistic locking column used by the Oracle framework during concurrent updates.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard audit columns maintained across all Oracle EBS transactional tables.
  • REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context columns, indicating which batch process inserted or last modified the row.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the flexible descriptive flexfield columns reserved for customer-defined extensions.

Two additional unique indexes document business-key candidates: PV_PARTNER_ACCESSES_U1 on PARTNER_ACCESS_ID, and both PV_PARTNER_ACCESSES_U2 and PV_PARTNER_ACCESSES_U3 enforcing uniqueness on the PARTNER_ID/RESOURCE_ID pair. The presence of both U2 and U3, in reversed column order, reflects composite index strategies that optimize lookups from either direction. Any query or interface that inserts into this table should respect the uniqueness of the partner-resource combination.

Common Use Cases and Queries

The table is queried most often to answer two questions: which resources belong to a partner's channel team, and what access level each holds. A typical reporting query joins the table to partner and resource master data:

  • Listing all team members for a given partner: SELECT resource_id, access_type, keep_flag FROM pv_partner_accesses WHERE partner_id = :partner_id;
  • Determining which partners a resource can access: SELECT partner_id, access_type FROM pv_partner_accesses WHERE resource_id = :resource_id;
  • Auditing security-group scoping by joining SECURITY_GROUP_ID to FND_SECURITY_GROUPS.
  • Reconciling rows created by concurrent programs using PROGRAM_ID and REQUEST_ID.
  • Identifying access grants that are not marked with KEEP_FLAG when reviewing team cleanup.

Because the table carries a full audit and concurrent-program footprint, it is also a common source in troubleshooting queries that trace when a channel team assignment changed and which batch was responsible.

Related Objects

The FK graph for PV_PARTNER_ACCESSES is deliberately narrow, indicating a self-contained access ledger with a small set of dependents.

  • FND_SECURITY_GROUPS — referenced by PV_PARTNER_ACCESSES.SECURITY_GROUP_ID, providing the security grouping that governs row visibility.
  • AS_PARTNER_ACCESSES — holds a foreign key back to PV_PARTNER_ACCESSES.PARTNER_ACCESS_ID, meaning the AS (Partner Access, sales-related) table depends on these rows and cannot exist without them.
  • PV_PARTNER_ACCESS_PK — the primary key constraint, and PV_PARTNER_ACCESSES_U1, U2, and U3, the unique indexes that together define row identity and the partner-resource uniqueness rule.
  • Partner and resource master data — the PARTNER_ID and RESOURCE_ID columns are the join keys used throughout Partner Management reporting, even where no hard foreign key constraint is documented.

When integrating or extending Partner Management, PV_PARTNER_ACCESSES should be treated as the authoritative record of channel team membership and should be modified only through supported APIs or concurrent programs, so that the associated access tables remain consistent.