Search Results pji_proj_extr_status




Overview
Explore in AI Chat

Overview

The PJI.PJI_PROJ_EXTR_STATUS table belongs to the Project Intelligence (PJI) product family within Oracle E-Business Suite. Its documented purpose is to record the extraction status for projects that have been extracted into the project performance-reporting model. In other words, it acts as a control and audit ledger that tells the EBS reporting layer whether a given project's transactional and financial data has been successfully pushed into the analytical structures used for performance reporting.

The metadata classifies this object as PJI – Project Intelligence (Obsolete), indicating that the product area itself has been superseded in later releases. Nevertheless, the table remains marked VALID in the schema, and it can still be queried in both 12.1.1 and 12.2.2 environments where historical Project Intelligence implementations persist. Its documented physical schema carries 17 columns and a single-column primary key, PJI_PROJ_EXTR_STATUS_PK, defined on PROJECT_ID. From a heuristic Data Vault modeling perspective, this table is best treated as a satellite rather than a hub or link: it is keyed by a single identifier and stores descriptive, time-stamped status attributes about that entity rather than representing a many-to-many relationship between entities. The Data Vault classification in the supplied metadata is listed as standalone, which is consistent with a satellite that has no enforced foreign-key dependencies outward.

Key Information Stored

The most significant columns capture the project identity, the extraction state, and the versioning of budget and forecast data used during extraction:

Common Use Cases and Queries

The primary operational use of this table is monitoring and troubleshooting the Project Intelligence extraction process. Administrators query it to confirm which projects have been extracted and which are still pending, and to reconcile version identifiers against the source budget and forecast versions.

A typical status check retrieves projects that are not yet fully extracted:

  • SELECT project_id, project_name, extraction_status, last_update_date FROM pji_proj_extr_status WHERE extraction_status <> 'COMPLETE';
  • Incremental extraction scoping: filter by ACTIVITY_MIN_GL_DATE or ACTIVITY_MIN_PA_DATE to identify projects with activity since the last run.
  • Purge management: SELECT project_id FROM pji_proj_extr_status WHERE purge_status = 'Y'; to locate purged projects.
  • Version reconciliation: compare COST_BUDGET_C_VERSION, REVENUE_BUDGET_C_VERSION, and forecast version columns against source tables to detect stale extractions.

Because the table is standalone with no enforced foreign keys, joins to project master data are performed logically on PROJECT_ID.

Related Objects

Although the documented relationship data marks this object as standalone, it functions within the broader Project Intelligence and Projects schema. Significant related objects include:

  • PJI_PROJ_EXTR_STATUS_PK / PJI_PROJ_EXTR_STATUS_U1 — The primary key constraint and unique index on PROJECT_ID that enforce row uniqueness.
  • PA_PROJECTS_ALL — The Projects master table, joined on PROJECT_ID to obtain authoritative project attributes.
  • PA_PROJECT_STATUSES and related PA status tables — Provide lifecycle context for EXTRACTION_STATUS and CLOSED_DATE interpretation.
  • Project Intelligence extraction and summary tables (PJI family) — Consume EXTRACTION_STATUS and version columns to populate the performance-reporting model.
  • Budget and forecast version tables in the Projects module — Source of the version identifiers stored in the *_C_VERSION and *_CO_VERSION columns.
  • GL and PA activity/transaction tables — Underpin the ACTIVITY_MIN_GL_DATE and ACTIVITY_MIN_PA_DATE values used for incremental loads.

Queries across these objects should always be joined on PROJECT_ID and scoped by PROJECT_ORGANIZATION_ID where operating-unit separation is required.