Search Results revenue_category_code

Overview

PJI_EXP_EVT_TYPES_V is a summarization view registered under the PJI – Project Intelligence product family, a module classified as obsolete in Oracle EBS 12.1.1 and 12.2.2. The view consolidates two distinct classification taxonomies used within Oracle Projects: expenditure types and event types. Its purpose is to present a unified list of type identifiers, type names, and their associated revenue category codes, enabling downstream reporting components to resolve a single lookup against both expenditure and event classifications without issuing two independent queries. The view is documented in ETRM as "not implemented in this database," which indicates that it is a shipped metadata definition rather than a physically deployed object in every environment; its presence depends on whether the Project Intelligence schema components were installed. Because the module is obsolete, the view should be treated as legacy infrastructure retained for backward compatibility rather than as a supported integration point for new development. The column most frequently associated with this view in user searches is REVENUE_CATEGORY_CODE, which is the common attribute joining the two source branches of the UNION ALL.

Underlying Base Objects

The view text is defined as a UNION ALL over two Oracle Projects base tables:

• PA_EXPENDITURE_TYPES – supplies EXPENDITURE_TYPE_ID, EXPENDITURE_TYPE, and REVENUE_CATEGORY_CODE.
• PA_EVENT_TYPES – supplies EVENT_TYPE_ID, EVENT_TYPE, and REVENUE_CATEGORY_CODE.

Each branch projects three columns, with the identifier and name columns drawn from different source columns but aligned positionally so that the UNION ALL produces a homogeneous three-column result set. ETRM documentation records no additional referenced base objects beyond these two tables, and the owner is left unspecified in the metadata. Because UNION ALL (rather than UNION) is used, rows are not deduplicated across the two branches; an expenditure type and an event type that share the same name or revenue category code will both appear. This is significant when the view is used for aggregation, since counts can double if the caller assumes a single consolidated dimension. The absence of an explicit type discriminator column means consumers cannot distinguish an expenditure-type row from an event-type row based on the view output alone.

Key Columns

• EXPENDITURE_TYPE_ID / EVENT_TYPE_ID – the primary identifiers from the respective base tables, occupying the first position of the result set. The documentation labels this column group simply as "ID," reflecting the positional alignment of the two source identifiers.
• EXPENDITURE_TYPE / EVENT_TYPE – the descriptive name of the type as defined in PA_EXPENDITURE_TYPES or PA_EVENT_TYPES respectively.
• REVENUE_CATEGORY_CODE – the column referenced in the user's search. It carries the revenue category classification attached to each expenditure type and event type, and is the shared attribute that makes the UNION ALL semantically meaningful. In Oracle Projects, the revenue category code drives revenue generation and revenue budget logic, so resolving it correctly for a given type is essential to revenue reporting.

Common Use Cases and Queries

Typical usage involves joining the view to transactional or budgeting tables to obtain the revenue category code for a given type, or listing all types belonging to a specific revenue category. A representative query is:

• SELECT revenue_category_code, expenditure_type FROM pji_exp_evt_types_v WHERE revenue_category_code = :code;
• SELECT DISTINCT revenue_category_code FROM pji_exp_evt_types_v ORDER BY 1; — enumerate available revenue categories across both taxonomies.
• SELECT v.expenditure_type, v.revenue_category_code FROM pji_exp_evt_types_v v WHERE v.expenditure_type_id = :id; — resolve a single expenditure type.

Caution is warranted: because the object may not be implemented in a given database and belongs to an obsolete module, production queries should be validated against the environment and, where possible, redirected to PA_EXPENDITURE_TYPES and PA_EVENT_TYPES directly. Absent a discriminator column, queries that must separate expenditure types from event types should query the base tables rather than this view.