Search Results pon_te_view_audit_pk

Overview

PON_TE_VIEW_AUDIT is a table in the PON (Sourcing) product schema of Oracle E-Business Suite, present in both release 12.1.1 and 12.2.2. As its ETRM description states, it is "a simple table keeping track of who viewed which message when." In practice, it functions as a lightweight read-receipt and audit trail for threaded sourcing messages, recording the association between a message thread entry, the party who viewed it, and the timestamp of that view. The table is owned by the PON schema, holds VALID status, and is documented with three columns in the 12.2.2 physical schema.

Under a heuristic Data Vault classification mined from its foreign-key structure, PON_TE_VIEW_AUDIT models as a link entity. It sits between two hubs — the message entry (PON_THREAD_ENTRIES) and the viewing party (HZ_PARTIES) — and resolves the many-to-many relationship between them, capturing the event of a view. This classification is a modeling suggestion derived from the FK topology rather than a physical implementation fact; the table itself is a conventional relational structure with a composite primary key.

Key Information Stored

The documented schema is deliberately narrow, comprising three columns and a composite primary key. The most important elements are:

• ENTRY_ID — Identifies the specific message or thread entry that was viewed. This column participates in the composite primary key (PON_TE_VIEW_AUDIT_PK) and is a foreign key to PON_THREAD_ENTRIES. It is the primary business-key candidate identifying the message side of the audit record.
• VIEWER_PARTY_ID — Identifies the party (person or organization) who performed the view. This column also participates in the composite primary key and is a foreign key to HZ_PARTIES. It is the business-key candidate identifying the actor side of the audit record.
• VIEW_DATE — The date and time at which the view occurred. Because it lies outside the primary key, it acts as a descriptive attribute of the link event rather than an identifying key, supporting chronological ordering and "when" reporting.

Together, ENTRY_ID and VIEWER_PARTY_ID form the surrogate composite primary key PON_TE_VIEW_AUDIT_PK, which enforces that a given party appears at most once per entry in the audit trail. There is no documented separate surrogate identifier such as a sequence-generated audit ID; the natural key is the composite of the two foreign keys.

Common Use Cases and Queries

Because the table records view activity, its principal use cases are read-receipt reporting, participation tracking in sourcing negotiations, and audit queries that establish whether a supplier or internal user has seen a given message.

• Determining whether a specific party has viewed a specific entry, using a join or subquery against ENTRY_ID and VIEWER_PARTY_ID.
• Listing all viewers of a thread entry, ordered by VIEW_DATE, to reconstruct the read sequence.
• Counting distinct viewers per entry to gauge message reach and engagement within a negotiation or sourcing event.
• Identifying entries with no recorded views, useful for follow-up or reminder workflows.

A representative query joining the audit table to its parent thread entries and to the party table follows:

• SELECT a.ENTRY_ID, a.VIEWER_PARTY_ID, a.VIEW_DATE FROM PON.PON_TE_VIEW_AUDIT a WHERE a.ENTRY_ID = :entry_id ORDER BY a.VIEW_DATE;
• SELECT t.ENTRY_ID, COUNT(DISTINCT a.VIEWER_PARTY_ID) AS viewer_count FROM PON.PON_THREAD_ENTRIES t LEFT JOIN PON.PON_TE_VIEW_AUDIT a ON a.ENTRY_ID = t.ENTRY_ID GROUP BY t.ENTRY_ID;

Related Objects

The table is tightly coupled to a small set of referenced objects. The most significant are:

• PON_THREAD_ENTRIES — Parent of the message entry; joined on PON_TE_VIEW_AUDIT.ENTRY_ID = PON_THREAD_ENTRIES.ENTRY_ID. This is the stronger side of the audit relationship.
• HZ_PARTIES — Registry of the viewing party; joined on PON_TE_VIEW_AUDIT.VIEWER_PARTY_ID = HZ_PARTIES.PARTY_ID. Links the audit record to the Trading Community Architecture party model.
• PON_TE_VIEW_AUDIT_PK — The composite primary key constraint enforcing uniqueness of ENTRY_ID and VIEWER_PARTY_ID.
• HZ_PERSON_PROFILES / HZ_ORGANIZATION_PROFILES — Commonly joined through HZ_PARTIES to resolve viewer names and contact details for reporting.
• PON sourcing message and negotiation APIs — Application logic that populates the audit table when messages are opened in the sourcing UI.

Because referential integrity is enforced to both PON_THREAD_ENTRIES and HZ_PARTIES, any purge or archival of thread entries should account for dependent rows in PON_TE_VIEW_AUDIT.