What this view is for
Order.core_details is the starting point for all order-based reporting.
Where Busopp represents sales intent, Orders represent contracted commitments.
This view defines the order as a business object and provides the identity and links needed to connect it back to opportunities and forward to invoicing.
If you’re asking “what work has been formally ordered, and how does it relate to the wider pipeline?” — this is where you start.
Level of detail (grain)
- One row per customer order
- Each row represents a single order within a company
- No aggregation, no duplication
This makes the view safe to count, filter and join without risk of inflating values.
What you’ll find in this view
core_details focuses on order identity and context, not metrics.
Typical content includes:
- Order identifiers
- High-level order descriptors
- Link keys back to:
- The originating opportunity (where applicable)
- The customer
- Related projects
It provides the connective tissue between sales intent and delivery.
How to join this view
Every row includes an OBJECT_SEQ field.
OBJECT_SEQ is a paired identifier combining:
- Company identifier
- Order identifier
When joining to other Order views, always join on OBJECT_SEQ.
This:
- Ensures joins remain within the correct company
- Avoids manual handling of composite keys
- Keeps the join pattern consistent with Busopp and Invoice
How this view is commonly used
Report writers typically use Order.core_details to:
- Count and track active orders
- Filter orders by status or ownership
- Anchor joins to:
Order.meta_codesfor categorisationOrder.meta_datesfor delivery and contractual timingOrder.item_values_linesfor order value
- Connect orders back to opportunities and forward to invoices
It is rarely used alone — it is the anchor point for all order analysis.
What this view does not contain
By design, core_details does not include:
- Order line values
- Aggregated financials
- Currency conversion logic
- Detailed delivery or invoicing dates
Those live in the supporting views to keep responsibilities clear and modular.
How orders differ from opportunities
A few important distinctions to keep in mind:
- An opportunity may never become an order
- One opportunity may result in multiple orders
- Orders represent formal contractual commitment, not forecast
This makes Order.core_details the authoritative source for committed pipeline.
Where this fits in a report build
A typical flow looks like:
- Start with Order.core_details to define the order set
- Add meta_dates to understand contractual and delivery timing
- Add meta_codes for categorisation and slicing
- Bring in item_values_lines to analyse order value
- Join to Invoice views for fulfilment and billing analysis
If a report needs to distinguish forecast from commitment, this view is usually the dividing line.
Key takeaway
Order.core_detailsgives you one clean row per customer order and the links needed to trace it through the Sales Pipeline.Start here for committed work, build outward for context and value, and the rest of the Order model will fall into place naturally.