Invoice: Meta_Codes

by

What this view is for

Invoice.meta_codes provides the classification, status and commercial context for invoices.

If:

  • Invoice.core_details defines what the invoice is

then meta_codes explains how the invoice should be interpreted, including its status, type, numbering context, payment terms and links back to upstream objects.

This view is essential for understanding why an invoice looks the way it does and how it should be treated in reporting.

Level of detail (grain)

  • Multiple rows per invoice
  • One row per code attribute

This view is intentionally long and thin.
A single invoice will appear multiple times — once for each coded attribute.

This structure allows invoice classifications to evolve without changing the schema.

What you’ll find in this view

Each row represents a single coded attribute for an invoice and typically includes:

  • OBJECT_SEQ – the paired company + invoice identifier
  • META_TYPE – the category of the code
  • ATTRIBUTE – the specific attribute name
  • A value payload (often code + description)

The meaning of any value always comes from the META_TYPE + ATTRIBUTE combination.

How to join this view

Every row includes OBJECT_SEQ, consistent with all Invoice views.

Always join Invoice.meta_codes to Invoice.core_details using OBJECT_SEQ.

This ensures:

  • Attributes stay aligned to the correct invoice
  • Cross-company joins are avoided
  • Join patterns remain consistent across the Sales Pipeline model

Working with the long, thin structure

Like other meta_codes views, this table is designed for flexibility rather than immediate consumption.

In most reports, you will want to:

  1. Filter to the code types you actually need
  2. Create a combined attribute identifier
  3. Pivot to a wide, report-friendly shape

Creating a combined code attribute

Because META_TYPE provides essential context, it is strongly recommended to combine it with ATTRIBUTE.

Example (Power Query):

= Table.AddColumn(
    Source,
    "CODE_ATTRIBUTE",
    each [META_TYPE] & "_" & [ATTRIBUTE],
    type text
)

This avoids ambiguity (for example, multiple status-related codes) and makes pivoting predictable.

Pivoting to a wide attributes table

Once combined, pivoting allows you to:

  • Turn each CODE_ATTRIBUTE into a column
  • Reduce each invoice to a single row
  • Work with explicit, recognisable fields in visuals and filters

This shape is typically far easier to work with in reports.

Codes Helper for slicers

For slicers, it is often cleaner to build a small Codes Helper table rather than slicing directly from the long-thin data.

A Codes Helper:

  • Provides a distinct list of codes and descriptions
  • Avoids bringing invoice grain into slicers
  • Keeps filtering behaviour predictable

The same helper pattern used for Busopp and Order applies here.

Codes currently available in Invoice meta_codes

The following META_TYPE / ATTRIBUTE combinations are available:

META_TYPEATTRIBUTE
STATUSINVOICE_VERSION
STATUSROWSTATE
STATUSSEND_STATUS
STATUSCREATE_STATE
TYPEINVOICE_TYPE
TYPEPRICE_ADJUSTMENT
TYPECORRECTION_REASON_ID
NUMERATIONCURRENCY
NUMERATIONTAX_ID_TYPE
TERMSPAY_TERM_ID
TERMSPAY_TERM_BASE_DATE
TERMSWAY_PAY_ID
LINK_KEYCUSTOMER_ID
LINK_KEYPRU_CODE
LINK_KEYORDER_NO
LINK_KEYPROJECT_ID

How these are typically used

These attributes support questions such as:

  • What state is the invoice in (created, sent, corrected)?
  • Is this a standard invoice, adjustment or correction?
  • Which currency and tax regime applies?
  • What payment terms govern the invoice?
  • Which customer, order or project does this invoice relate to?

They are commonly paired with:

  • Invoice.meta_dates for billing and due timing
  • Invoice.item_values_lines for invoiced amounts
  • A Codes Helper table for slicers

Things to watch out for

  • Don’t assume one row equals one invoice — always consider grain
  • Always anchor joins through Invoice.core_details using OBJECT_SEQ
  • Be deliberate about which attributes you pivot and expose

If invoice counts change unexpectedly after adding codes, revisit joins and shaping first.

Where this fits in a report build

A typical flow is:

  1. Start with Invoice.core_details
  2. Join Invoice.meta_codes for classification and context
  3. Shape or pivot attributes as required
  4. Add meta_dates and item_values_lines for timing and value

This keeps identity, classification, timing and value clearly separated.

Key takeaway

Invoice.meta_codes is your authoritative catalogue of invoice status, type and commercial context.

Shape it deliberately, preserve meaning via META_TYPE + ATTRIBUTE, and use helpers for slicers — and invoice reporting stays flexible without becoming fragile.

Leave a Comment