Search Results pji_fp_aggr_pjp1




Overview
Explore in AI Chat

Overview

PJI_FP_AGGR_PJP1 is a table owned by the PJI schema within the Oracle E-Business Suite Project Intelligence (PJI) module. Its documented purpose is precise: it is a mirror of PJI_FP_XBS_ACCUM_FROM used during summarization. In other words, this is a working staging structure that the Project Intelligence summarization engine populates and reads while it rolls raw project transaction data up into aggregated fact tables consumed by the PJI analytical reporting layer. It is not an end-user-facing reporting object; it is an engine-internal accumulation table.

Under the metadata's heuristic Data Vault classification, the object is recorded as standalone. This should be read as a modeling suggestion rather than a normative constraint. Because the table carries both descriptive dimensions (project, element, time, currency, plan version) and a wide array of additive cost, revenue, and hour measures, it behaves compositionally like a satellite keyed to a business-process grain, even though the mined FK structure did not surface a canonical hub or link. Analysts modeling this object externally should treat WORKER_ID and RECORD_TYPE as the grain-defining composite and wrap their own hub/link constructs around it.

This object is present and valid in both Oracle EBS 12.1.1 and 12.2.2. The documented physical schema exposes 79 columns, reflecting the breadth of financial measures PJI must accumulate across labor, equipment, commitments, and plan-versus-actual perspectives.

Key Information Stored

Among the 79 documented columns, the most operationally significant group by function:

Common Use Cases and Queries

Typical usage is diagnostic rather than ad hoc. The most common patterns are:

  • Verifying a summarization run: filter by WORKER_ID and RECORD_TYPE to inspect exactly what a worker accumulated before it wrote downstream. SELECT WORKER_ID, RECORD_TYPE, PROJECT_ID, SUM(RAW_COST) FROM PJI.PJI_FP_AGGR_PJP1 GROUP BY WORKER_ID, RECORD_TYPE, PROJECT_ID;
  • Reconciling source to aggregate: join back to PJI_FP_XBS_ACCUM_FROM on the shared grain columns to detect drift between the mirror and its source.
  • Data-quality sweeps: SELECT COUNT(*) FROM PJI.PJI_FP_AGGR_PJP1 WHERE RATE_DANGLING_FLAG = 'Y' OR TIME_DANGLING_FLAG = 'Y'; surfaces records that failed reference lookups.
  • Plan-versus-actual analysis: comparing RAW_COST against ACT_RAW_COST plus ETC_RAW_COST grouped by PLAN_VERSION_ID and PLAN_TYPE_CODE.
  • Commitment reporting: aggregating the four committed-cost columns by project and period to reproduce PJI commitment views.

Related Objects

The documented foreign keys tie this table to the RBS dimensional model:

  • PA_RBS_ELEMENTS — joined via PJI_FP_AGGR_PJP1.RBS_ELEMENT_ID → PA_RBS_ELEMENTS.RBS_ELEMENT_ID; supplies element names and hierarchy attributes.
  • PA_RBS_VERSIONS_B — joined via PJI_FP_AGGR_PJP1.RBS_VERSION_ID → PA_RBS_VERSIONS_B.RBS_VERSION_ID; identifies which RBS version the row was accumulated against.
  • PJI_FP_XBS_ACCUM_FROM — the source table this object mirrors; the primary reconciliation partner.
  • PA_PROJECTS_ALL and PA_PROJECT_ELEMENTS — referenced through PROJECT_ID and PROJECT_ELEMENT_ID for descriptive joins.
  • PA_PLAN_VERSIONS / PA_PLAN_TYPES — resolved through PLAN_VERSION_ID and PLAN_TYPE_ID / PLAN_TYPE_CODE.

Because the object is classified as standalone, no dependent child tables were mined; it should be treated as a terminal accumulation structure consumed by PJI fact-loading programs rather than as a parent for further normalization.