Invoice: Core_Details

by

What this view is for

Invoice.core_details is the starting point for all invoice-based reporting.

Where:

  • Busopp represents sales intent
  • Order represents contractual commitment

Invoices represent delivered and billed reality.

This view defines the invoice as a business object and provides the identity and links needed to relate billing back to orders, opportunities, projects and customers.

If you’re asking “what has been invoiced, to whom, and how does it relate to the pipeline?” — this is where you begin.

Level of detail (grain)

  • One row per invoice
  • Each row represents a single invoice within a company
  • No aggregation, no duplication

This makes the view safe to count, filter and join without inflating values.

What you’ll find in this view

core_details focuses on invoice identity and context, not line values.

Typical content includes:

  • Invoice identifiers
  • Customer and contractual references
  • Link keys back to:
    • Orders
    • Opportunities
    • Projects
    • Customers

It provides the bridge between operational delivery and financial reporting.

How to join this view

Every row includes an OBJECT_SEQ field.

OBJECT_SEQ is a paired identifier combining:

  • Company identifier
  • Invoice identifier

When joining to other Invoice views, always join on OBJECT_SEQ.

This ensures:

  • Joins remain within the correct company
  • Composite keys are handled consistently
  • The pattern matches Busopp and Order joins

How this view is commonly used

Report writers typically use Invoice.core_details to:

  • Count invoices issued
  • Filter invoices by status or customer
  • Anchor joins to:
    • Invoice.meta_codes for classification
    • Invoice.meta_dates for billing and due dates
    • Invoice.item_values_lines for invoiced amounts
  • Link invoices back to orders and opportunities for pipeline reconciliation

It is rarely used on its own — it is the anchor for all invoicing analysis.

What this view does not contain

By design, core_details does not include:

  • Invoice line values
  • Aggregated revenue figures
  • Currency conversion logic
  • Payment or settlement calculations

Those live in the supporting views to keep concerns separated.

How invoices differ from orders

A few important distinctions:

  • One order may generate multiple invoices
  • Invoices reflect what has been billed, not what was ordered
  • Timing and value may differ from the original order

This makes invoices the authoritative source for recognised billing, not pipeline forecast.

Where this fits in a report build

A typical flow looks like:

  1. Start with Invoice.core_details to define the invoice set
  2. Add meta_dates for billing, due and posting timing
  3. Add meta_codes for classification and customer context
  4. Bring in item_values_lines for invoiced amounts
  5. Join back to Orders and Busopp for reconciliation and analysis

If a report needs to answer “what have we actually billed?”, this view is the starting point.

Key takeaway

Invoice.core_details gives you one clean row per invoice and the links needed to trace billed value back through Orders and Opportunities.

Start here for delivered revenue, build outward for context and value, and the invoicing side of the Sales Pipeline will remain clear and auditable.

Leave a Comment