Menu ▾ ▴

#210 Triage of all 23 open issues (15 Sep): 4 to close, 4 to re-scope, 4 groupings that change the work order

open
nobody
None
2026-09-15
2026-09-15
Anonymous
No

Originally created by: grynn-in

Triage of all 23 open issues in this repo against main, 15 September 2026. Each verdict is backed by a check against current source or the running stack; per-issue comments carry the evidence. Nothing was closed — this is a recommendation for review.

Recommend closing (4) — now closed

issue verdict
#172 Stale. SP-SEASONAL_RETAIL-P1…-P12 all present; the missing P12 weight exists. The konsol#182 T5 run already recorded "#172 not reproduced".
#179 Superseded by [#198]. gold_business_combination_journal posts an opening_balance line for exactly this gap. Close referencing [#198], not as fixed — no deal has been submitted, so it is proven in design only.
#180 Superseded by [#198]. gold_business_disposal_journal carries a derecognised role over every non-equity balance-sheet account. Same caveat.
#182 Stated cause gone. The blocker was assert_d365_gl_vouchers_balance failing on 927 demo rows; the demo was removed by konsol#127 and the stack now has no D365 data at all (epm_raw.gl_entries → Code: 60, Unknown table). The suite will fail differently now. Re-run before writing a new issue.

Recommend re-scoping (4)

issue verdict
#57 Live as a spec, unbuilt. But cluster sharding may be solving a scale problem that Frappe multi-site now addresses differently. Re-confirm as wanted before scheduling.
#90 Live as written (9 files still reference abctl) but overtaken: ELT/ETL leaves scope under the multi-tenant decision. Needs a keep-or-close decision, not a fix.
#92 Half done. _validate_references and _validate_positive_rate exist; the equity-account guard does not. And the guard should probably now test fx_method = 'historical' rather than account type — on the current chart 21 accounts are declared historical and only 6 are equity leaves.
#185 Live, but patching D365 prefixes is the wrong fix. The chart declares statement_section/sub_section, and silver_main_accounts already classifies from the declaration. This script is the last place inferring meaning from account-number shapes.

Confirmed live, unchanged (10, plus the 4 filed today = 14)

#149 (seeds/ is gone, 22 doc files still reference it) · #169, #170 (see grouping below) · #171 (gold_entity_ownership.sql:54) · #173 (stg_erpnext__trial_balance.sql:48) · #174 (staging/README.md:81 still says no sign convention is defined) · #181 · #187 · #190 (silver_budget_entries.sql:21-22) · #204

Plus #206–#209, filed today.

Not verified (1)

#178 — I could not confirm the stale-model condition without a selective build against a live warehouse. Left as written.

Four groupings that change the work order

  1. The variance path is three issues — [#187] (FULL OUTER JOIN under join_use_nulls=0), [#206] (filters scenario_id = 'BUDGET', so konsol-authored budgets never arrive), konsol#214 (consumers sum across budget scenarios). Same models; three passes if done separately. [#174] (budget sign convention) should land after them, not before.

  2. join_use_nulls = 0 is one root cause, two issues — [#187] and [#190]. It is already a standing trap in the project notes, which suggests it recurs until a macro makes the safe form the easy one.

  3. Three issues target one script — [#169], [#170], [#185] against build_consolidation_report.py, which the project notes record as broken since F2. Decide whether that script is still the delivery path before fixing three bugs in it. [#170]'s first item (sparse gold_balance_sheet) is a warehouse property and should be split out if the script is retired.

  4. #171 and konsol#210 share a root cause. Both come from build_date_from_year_period, which forces the fiscal year to be the calendar year and clamps the period to 1–12. EPM Fiscal Year now declares real period dates and supports 13-period and 4-4-5. Reading the declaration fixes both at once.

Highest leverage

#181. CI runs dbt parse plus three unittests — no dbt build, no dbt test, no integration run. [#182]'s blocker went stale unnoticed precisely because nothing runs the suite, and the project's own notes record that dbt parse does not validate SQL. Several issues here become self-confirming once it lands.

🤖 Claude Code · https://claude.ai/code/session_01P3Pf9835FeLeXjRrYTTZ1M

Related

Tickets: #169
Tickets: #170
Tickets: #174
Tickets: #182
Tickets: #185
Tickets: #187
Tickets: #190
Tickets: #198
Tickets: #206

Discussion


Log in to post a comment.