What this view is for
Project.meta_dates provides the date-based and lifecycle attributes for projects.
Where Project.core_details defines what a project is,
and Project.meta_codes defines how a project is classified,
Project.meta_dates defines when things happen in the life of a project.
If you’re asking “when did this project start?”, “when is it due to finish?”, or “when did its status change?” — this is where you look.
Architectural maturity
This view is delivered as a cvw (collated view).
It is assembled from regional shards, allowing us to:
- Blend RPV/MDM-aligned sources where available
- Fall back to snapshot (mvw) sources where required
- Harmonise regional date semantics into a single logical structure
- Improve temporal accuracy over time without breaking consumers
This allows regions to mature independently while exposing one consistent Project timeline model.
Level of detail (grain)
- One row per project per date attribute
- Each row represents a single dated event or milestone for a project
- No aggregation
- Multiple rows per project are expected (one per date type)
This design supports multiple meaningful dates without widening the table.
What you’ll find in this view
Each row contains:
- OBJECT_SEQ – the project identifier (company + project)
- META_TYPE – the category of date (e.g. LIFECYCLE, DELIVERY, COMMERCIAL)
- ATTRIBUTE – the name of the specific date
- CODE_VALUE – the date value
- VALUE_METADATA – descriptive or structured context (often JSON)
Typical examples include:
- Project start date
- Planned end date
- Actual end date
- Status effective date
- Contract start or end date
- Closure or cancellation date
This view standardises how project dates are exposed, regardless of how they are stored in source systems.
How to join this view
Always join to Project.core_details using:
OBJECT_SEQ
This ensures:
- Dates attach to the correct project
- Company boundaries are respected
- The join pattern matches Busopp, Order and Invoice
- Regional shard differences are abstracted away
In reports, this view is usually filtered or pivoted by META_TYPE and ATTRIBUTE.
How this view is commonly used
Report writers typically use Project.meta_dates to:
- Filter projects by start or end period
- Track project lifecycle stages over time
- Build timelines and Gantt-style views
- Support “as at” or “in period” reporting
- Anchor time intelligence in cost and revenue analysis
It is typically used alongside:
- Project.core_details (identity)
- Project.meta_codes (classification)
- Project.item_values (financials)
What this view does not contain
By design, meta_dates does not include:
- Numeric measures
- Categorical codes
- Financial values
- Derived duration calculations
It contains dates only, with meaning supplied by META_TYPE and ATTRIBUTE.
This keeps time logic separate from value logic.
How this differs from other Project views
- core_details = what the project is
- meta_codes = how it is classified
- meta_dates = when things happen
- item_values = what it costs or earns
Each view answers a different dimension of the same business object.
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 lifecycle timing
- Join Project.item_values for cost and revenue
- Apply calendar logic and measures
If a report needs to answer “when are projects starting, finishing, or changing state?”, this view provides the temporal structure to do that.
Key takeaway
Project.meta_dates gives you a consistent timeline for every project, regardless of regional source system differences.
Use it to reason about project lifecycle, schedule, and timing, and keep temporal meaning cleanly separated from classification and financial logic.