Search Results document_version




Overview

GR_DISPATCH_HISTORY_V is a reporting and inquiry view owned by the APPS schema in Oracle E-Business Suite, defined within the Process Manufacturing Regulatory Management (GR) product family. It presents a denormalized, read-only perspective of the GR_DISPATCH_HISTORY base table, enriched with descriptive attributes drawn from Oracle's Trading Community Architecture (HZ), document management (FND_DOCUMENTS), system items (MTL), and lookup infrastructure (FND_LOOKUPS). The view exists to support operational and regulatory reporting where users must audit which compliance documents were dispatched to which recipients, when, and by what method.

Because Oracle EBS stores dispatch history at a normalized level—recording IDs and lookup codes rather than human-readable values—queries against the base table require extensive joins. GR_DISPATCH_HISTORY_V encapsulates those joins, exposing resolved party names, party site addresses, document file names, version labels, and decoded lookup meanings in a single relational source. This makes it suitable for custom concurrent programs, Oracle Reports, BI Publisher data templates, and ad hoc SQL used by regulatory compliance teams.

The presence of the DOCUMENT_CATEGORY column is particularly relevant to users searching on "document_category." The column is sourced from FND_DOCUMENTS.DOC_ATTRIBUTE_CATEGORY, which is the descriptive flexfield context that classifies a document—such as a Safety Data Sheet (SDS), label, or regulatory submission. This categorization enables grouping and filtering of dispatch records by document class.

Underlying Base Objects

The view is defined over the following documented base objects:

  • GR_DISPATCH_HISTORY (synonym) — the primary fact table holding dispatch transaction records.
  • FND_DOCUMENTS_VL (view) — the document repository, supplying file name, description, and document flexfield attributes.
  • EDR_FILES_B (synonym) — the EDR (Engineering Data Repository) file metadata table, providing version labels via an outer join on FND_DOCUMENT_ID.
  • HZ_PARTIES (synonym) — the TCA party master, providing recipient name, number, and party type.
  • HZ_PARTY_SITES (synonym) — the TCA party site, providing site name, site number, and addressee.
  • MTL_SYSTEM_ITEMS_B (synonym) — the item master, supplying the CAS_NUMBER attribute for the dispatched item.
  • FND_LOOKUP_VALUES (synonym) — used twice (aliases LK1 and LK2) to decode DISPATCH_METHOD_CODE and CREATION_SOURCE.

The join to EDR_FILES_B is an outer join, reflecting that not every dispatch record necessarily references a versioned EDR file. All other joins are inner joins, so a dispatch record will not appear unless the corresponding item, party, party site, and lookup values exist.

Key Columns

Common Use Cases and Queries

The most frequent use of this view is regulatory audit reporting: listing all dispatches for a given period, grouped by document category, recipient, or dispatch method. A typical query is shown below.

SELECT dispatch_history_id,
       document,
       document_category,
       document_type,
       recipient,
       recipient_site_name,
       date_sent,
       dispatch_method_display
FROM   apps.gr_dispatch_history_v
WHERE  document_category = :p_category
AND    date_sent BETWEEN :p_from AND :p_to
ORDER BY date_sent DESC;

Other common patterns include reconciling all documents sent to a specific customer (filtering on RECIPIENT or RECIPIENT_NUMBER), identifying dispatches made by a particular automated source using CREATION_SOURCE_DISPLAY, and tracing document versions for a regulated item via CAS_NUMBER or INVENTORY_ITEM_ID. Because the view already resolves lookup meanings, no additional join to FND_LOOKUPS is required in user queries.

For performance, filter on indexed base columns such as DISPATCH_HISTORY_ID, DOCUMENT_ID, or DATE_SENT where possible, and avoid unbounded full scans of the view in high-volume environments.