#185 Consolidation report: take expense sub-sections from the chart's declared sub_section, not from account-number prefixes

[Anonymous]

Originally created by: grynn-in

What's wrong

scripts/build_consolidation_report.py (around lines 163-167, 186-187 and 225) chooses the expense sub-sections (COGS, operating expenses, other) from D365 account-number prefixes (5, 6, 7/8). An ERPNext expense account id such as "Cost of Goods Sold - XX" matches none of them. It falls back to an "Expense" section that isn't in section_order.

Why it matters

With ERPNext enabled, those accounts land outside COGS, OpEx and every subtotal in the consolidation report. Gross profit and operating profit come out wrong, and nothing fails. konsolidat [#184] fixed the same problem for revenue.

Suggested fix

Classify the sub-section from the chart rather than from account-number prefixes. Once konsol [#182] (a group chart governed in konsol) lands, use its declared statement_section/sub_section. Until then, add a fallback that maps any unmatched expense account into operating expenses and lists it in the report's diagnostics.

Found in the review of [#184].

[Anonymous]

Originally posted by: grynn-in

Verdict: LIVE, confirmed. scripts/build_consolidation_report.py:163 still selects the expense sub-section by D365 account-number prefix:

("Expense", "Cost of Goods Sold", lambda a: a[:1] == "5" or a.startswith("6112")),

so a non-numeric ERPNext account id still falls through, exactly as described.

Worth re-scoping rather than patching the prefixes. Since konsol#182 the chart declares statement_section and sub_section per account, and the warehouse already classifies from the declaration rather than from code shapes — silver_main_accounts derives is_pnl/is_balance_sheet from statement_section. This script is now the only place left that infers meaning from account-number prefixes. Reading the declared sub-section fixes it for every chart, not just ERPNext's.

🤖 Triage against main — Claude Code · https://claude.ai/code/session_01P3Pf9835FeLeXjRrYTTZ1M

[Anonymous]

Originally posted by: grynn-in

Re-scoped — read the declaration rather than patching the prefixes

Still reproducible. scripts/build_consolidation_report.py:163:

("Expense", "Cost of Goods Sold", lambda a: a[:1] == "5" or a.startswith("6112")),

so a non-numeric ERPNext account id still falls through to a section that is not in section_order.

The fix should not be more prefixes. Since konsol#182 the chart declares statement_section and sub_section per account, and the rest of the stack already classifies from the declaration — silver_main_accounts derives is_pnl and is_balance_sheet from statement_section, and there is no prefix or range logic on account codes anywhere in the 106 dbt models.

This script is now the only place left in either repo that infers meaning from account-number shapes. Reading sub_section fixes it for every chart, not just ERPNext's, and removes the last instance of the pattern.

Check konsolidat#169 and [#170] first, though — all three are open against this same script, and the project notes record it as broken since F2. Decide whether it is still the delivery path before fixing three bugs in it.

🤖 Re-scoped 15 Sep 2026 against main — Claude Code · https://claude.ai/code/session_01P3Pf9835FeLeXjRrYTTZ1M

[Anonymous]

Originally posted by: grynn-in

Note on framing — this issue survives the ERP removal, but its premise needs rewording.

The ERP staging tree is being removed (konsolidat#221). This issue is framed as an ERPNext problem: "With ERPNext enabled, the expense accounts fall outside COGS/OpEx."

The defect is not about ERPNext. scripts/build_consolidation_report.py:163 chooses expense sub-sections from D365 account-number prefixes — so it misclassifies any chart whose account codes are not D365-shaped, which after this decision is every chart, since konsol's governed chart is the only source.

So it becomes more relevant, not less. The fix is unchanged and already noted: read the chart's declared sub_section, which every account carries since konsol#182. This is the last place in either repo inferring meaning from account-number shapes.

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