What this view is for
Project.item_values provides the numeric and financial measures for projects.
Where:
- Project.core_details defines what a project is
- Project.meta_codes defines how it is classified
- Project.meta_dates defines when things happen
- Project.item_values defines what it costs, earns, or is expected to earn
If you’re asking:
“how much has this project cost?”,
“how much revenue has it generated?”, or
“what is the current forecast or contingency?” — this is where you look.
Architectural maturity
This view is delivered as a cvw (collated view).
It is assembled from multiple value components, representing different financial perspectives on a project:
- Cost
- Revenue
- Expense
- Forecast
- Contingency
In addition, regional variants exist for some components (notably Cost and Revenue), reflecting differences in source systems and maturity.
The collated view allows us to:
- Blend RPV/MDM-aligned sources where available
- Fall back to snapshot (mvw) sources where required
- Harmonise regional value models into a single logical structure
- Improve financial consistency over time without breaking consumers
This enables progressive convergence on a single Project value model, despite heterogeneous regional sources.
Level of detail (grain)
This is an item table.
- One row per project per item per value attribute per component
- Each row represents a single numeric fact about a specific project item
- Multiple rows per project are expected
- No aggregation
Projects are decomposed into items (for example activities, resources, or transactions), and values are recorded at that level.
Each row is uniquely identified by:
- OBJECT_SEQ – the project identifier (company + project)
- ITEM_KEY – the identifier of the project item
- META_TYPE – the value category (e.g. COST, REVENUE, FORECAST)
- ATTRIBUTE – the specific value meaning (e.g. ACTUAL, BASELINE, PLANNED)
This allows multiple value streams (cost, revenue, forecast, contingency) to coexist at item level without collision.
Components represented
Project.item_values brings together numeric measures from several value perspectives:
Cost
Values associated with the cost of delivering a project, such as:
- Actual cost
- Planned or baseline cost
- Labour or resource cost
- Direct and indirect costs
Revenue
Values associated with revenue earned or recognised on a project, such as:
- Invoiced revenue
- Earned revenue
- Planned revenue
Expense
Values linked to expense booking and allocation.
Forecast
Values representing predicted future cost or revenue, such as:
- Forecast cost
- Forecast revenue
- Remaining estimate
Contingency
Values associated with contingency planning, such as:
- Risk allowance
- Contingency reserve
Regional variants
Where regional implementations differ (particularly for Cost and Revenue), those variants are:
- Normalised into the same META_TYPE / ATTRIBUTE structure
- Exposed through the same OBJECT_SEQ and ITEM_KEY
- Collated into a single logical Project.item_values view
This avoids forcing consumers to reason about region-specific value logic.
What you’ll find in this view
Each row contains:
- OBJECT_SEQ – the project identifier (company + project)
- ITEM_KEY – the project item identifier
- META_TYPE – the category of value (e.g. COST, REVENUE, FORECAST)
- ATTRIBUTE – the specific value meaning (e.g. ACTUAL, PLANNED, BASELINE)
- OBJECT_META – the numeric value
- OBJECT_METADATA – structured context (often JSON), such as currency, units or provenance
Together, these describe:
which project,
which item within the project,
what type of value,
and how much.
Aggregation and summation
The values in Project.item_values are atomic, additive financial measures.
This means they can be:
- Safely summed across items
- Safely summed across projects
- Safely summed across time (when combined with Project.meta_dates)
- Grouped by classifications from Project.meta_codes
There is:
- No hidden duplication
- No pre-aggregation
- No mixed grains within a single META_TYPE / ATTRIBUTE combination
As long as joins are made using:
- OBJECT_SEQ (project)
- ITEM_KEY (item)
- Appropriate META_TYPE / ATTRIBUTE filters
the values can be reliably aggregated for reporting.
How to join this view
Always join to Project.core_details using:
OBJECT_SEQ
When joining to item-level supporting views (such as item-level dates or codes), also join on:
ITEM_KEY
This ensures:
- Values attach to the correct project
- Values attach to the correct project item
- Company boundaries are respected
- Regional shards remain logically unified
- The join pattern matches Busopp, Order and Invoice
How this view is commonly used
Report writers typically use Project.item_values to:
- Analyse project cost and revenue
- Compare actuals against forecast or baseline
- Build margin and performance measures
- Support earned value and financial health reporting
- Feed time-series analysis when combined with Project.meta_dates
It is typically used with:
- Project.core_details
- Project.meta_codes
- Project.meta_dates
meta_dates supplies when the value applies;
item_values supplies how much.
What this view does not contain
By design, item_values does not include:
- Descriptive project attributes
- Categorical classifications
- Date logic or calendar intelligence
- Aggregated roll-ups
It contains atomic numeric facts only, structured by meaning and component.
Where this fits in a report build
A typical pattern looks like:
- Start with Project.core_details
- Join Project.meta_codes for classification
- Join Project.meta_dates for period and lifecycle
- Join Project.item_values for cost, revenue and forecast
- Build measures and comparisons
If a report needs to answer “how is this project performing financially?”, this view provides the factual basis.
Key takeaway
Project.item_values is an item-level fact view.
It provides a unified financial picture of each project across:
Cost, Revenue, Expense, Forecast and Contingency — including regional variants —
at the level of individual project items identified by ITEM_KEY.
Use it to answer “how much, for which part of the project?”,
and combine it with meta_dates to answer “when does that value apply?”,
keeping project performance granular, consistent and auditable.