#77 Add a dbt test to catch silent fiscal-period fallback (FY0 regression guard)

[Anonymous]

Originally created by: grynn-in

Context

silver_gl_entries derives fiscal_year/fiscal_period as coalesce(nullIf(fp.fiscal_year, 0), <derive from posting date>) — the fiscal-calendar join first, falling back to the accounting date. PR [#73] fixed the bug where a missed join left every row in FY0/P0 (ClickHouse fills unmatched LEFT-JOIN numerics with 0, defeating a plain coalesce), and PR [#76] fixed the underlying calendar_id mismatch so the join actually matches for the demo entities.

Problem

Both fixes are silent by design: if the calendar join ever breaks again (e.g. a new entity points at a calendar that isn't loaded, or a calendar_id rename), the row quietly falls back to date-derivation with no signal. The original FY0 symptom that surfaced this whole class of bug would be permanently suppressed — correct for calendar fiscal years, silently wrong for offset fiscal years.

Proposal

Add a dbt test that turns a future silent regression into a failing test. Options:

• A not_null / range test on the calendar-join output (assert fp.fiscal_year is populated for GL rows whose entity has a loaded fiscal calendar), or
• A row-count assertion that fallback usage is ~0 for entities that DO have a matching calendar (distinguish 'legitimately no calendar' from 'join broke'), or
• A relationships-style test that every silver_gl_entries entity/date resolves to a silver_fiscal_periods row when a calendar exists for that entity.

Surfaced in

Review of [#73] (and the [#76] follow-up).

[Anonymous]

Ticket changed by: grynn-in

• status: open --> closed