Search Results registry_id




Overview
Explore in AI Chat

Overview

APPS.POS_SUPP_PUB_HISTORY_V is a reporting and integration view in Oracle E-Business Suite (documented for 12.1.1 and 12.2.2) that exposes the history of supplier publication events. It records the moment a supplier record was published — for example, when supplier data is pushed to an external registry, portal, or third-party integration through the Supplier Lifecycle Management / supplier publishing framework. Each row represents one publication event, combining the publication history record with descriptive supplier attributes and the identity of the user who performed the publish.

The view is denormalized for convenience: rather than requiring the reporting or integration layer to join back to AP_SUPPLIERS, HZ_PARTIES, and FND_USER, it presents supplier name, registry number, supplier number, and the publishing user's login in a single flat structure. This makes it a natural source for operational dashboards, audit extracts, and outbound integration queries.

Underlying Base Objects

The documented base objects referenced by this view are:

  • POS_SUPP_PUB_HISTORY — the driving table, holding the publication event rows (event id, party id, publication date, publisher, detail, XML payload, audit columns, request id).
  • AP_SUPPLIERS — the supplier master, joined on party_id, supplying VENDOR_ID, PARTY_ID, and SEGMENT1 (supplier number).
  • HZ_PARTIES — the party/registry master, joined on party_id, supplying PARTY_NAME and PARTY_NUMBER.
  • FND_USER — the application user directory, joined on user_id = published_by, supplying the user name.
  • STANDARD (PACKAGE) and XMLTYPE (TYPE) — referenced for the XML payload handling of XMLCONTENT.

All joins are inner joins on party_id for the supplier/party objects and on user_id for FND_USER, meaning a publication row will only surface if a matching supplier, party, and user record exist.

Key Columns

Common Use Cases and Queries

Typical uses include auditing who published which supplier and when, monitoring publication activity by date range, and feeding integration or reconciliation reports. Because PUBLISHED_BY_NAME resolves the raw user id to a login, most user-facing queries select it directly.

SELECT supplier_name,
       registry_id,
       supplier_number,
       publication_date,
       published_by,
       published_by_name,
       publish_detail
FROM   apps.pos_supp_pub_history_v
WHERE  publication_date >= SYSDATE - 30
ORDER  BY publication_date DESC;

To track a single publisher's activity:

SELECT publication_event_id,
       supplier_name,
       publication_date,
       publish_detail
FROM   apps.pos_supp_pub_history_v
WHERE  published_by_name = :p_user_name;

For integration extracts, the XML payload is usually retrieved alongside the identifying columns:

SELECT publication_event_id,
       supplier_number,
       published_by_name,
       xmlcontent
FROM   apps.pos_supp_pub_history_v
WHERE  request_id = :p_request_id;

As with all APPS views, access should be granted through the appropriate responsibility or via a custom grant, and queries returning XMLCONTENT should be filtered narrowly to avoid excessive payload volume.