What this view is for
Project.core_details is the starting point for all project-based reporting.
Where:
- Project represents operational execution
This view defines the project as a business object and provides the identity and links needed to relate delivery activity back to opportunities, orders, customers and ultimately invoicing.
If you’re asking “what projects are we running, for whom, and how do they relate to the sales pipeline and revenue?” — this is where you begin.
Architectural maturity
This view is delivered as a cvw (collated view).
It is assembled from regional shards, allowing us to:
- Blend RPV/MDM-aligned tables where available
- Fall back to snapshot (mvw) sources where required
- Progressively improve quality and consistency without breaking consumers
This enables regional variation today while converging on a single logical Project object over time.
Level of detail (grain)
- One row per project
- Each row represents a single project within a company
- No aggregation, no duplication
- Safe to count, filter and join without inflating values
The view defines the existence of a project, not its financial or time-based measures.
What you’ll find in this view
core_details focuses on project identity and business context, not values.
Typical content includes:
- Project identifiers
- Company and customer references
- Descriptive project attributes (name)
- Link keys back to:
- Opportunities
- Orders
- Customers
- (where applicable) parent or related projects
It provides the bridge between sales intent, contractual commitment and operational delivery.
How to join this view
Every row includes an OBJECT_SEQ field.
OBJECT_SEQ is a paired identifier combining:
- Company identifier
- Project identifier
When joining to other Project views, always join on OBJECT_SEQ.
This ensures:
- Joins remain within the correct company
- Composite keys are handled consistently
- The pattern matches Busopp, Order and Invoice joins
- Regional shards remain logically unified
How this view is commonly used
Report writers typically use Project.core_details to:
- Count active or closed projects
- Filter projects by status, type or customer
- Anchor joins to:
- Project.meta_codes for classification
- Project.meta_dates for lifecycle timing
- Project.item_values for cost, revenue and forecast values
- Link projects back to:
- Orders (contractual context)
- Busopp (pipeline origin)
- Invoices (billed delivery)
It is rarely used on its own — it is the anchor for all project analysis.
What this view does not contain
By design, core_details does not include:
- Cost or revenue measures
- Hours or utilisation values
- Earned value calculations
- Currency conversion logic
Those live in the supporting item_values views to keep concerns separated and auditable.
Where this fits in a report build
A typical flow looks like:
- Start with Project.core_details to define the project set
- Add meta_dates for lifecycle and delivery timing
- Add meta_codes for classification and organisational context
- Bring in item_values for cost, revenue and forecast
- Join back to Orders, Busopp and Invoices for reconciliation
If a report needs to answer “what are we delivering, and how does it connect to revenue and pipeline?”, this view is the starting point.
Key takeaway
Project.core_details gives you one clean row per project and the links needed to trace delivery back through Orders, Opportunities and Customers.
Start here for operational delivery, build outward for value and context, and the project side of the Sales Pipeline will remain clear, consistent and auditable.