Menu ▾ ▴

#208 The NCI account is declared in two places: var('ic_nci_account') in dbt and consolidation_groups.nci_account from konsol

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

Originally created by: grynn-in

What happened

The account that receives the minority owners' share of an eliminated intragroup balance is configured in two places that cannot see each other.

In dbt, as a project var with a pseudo-account default:

{# macros/ic_helpers.sql:38 #}
{% macro ic_nci_account() %}{{ var('ic_nci_account', 'NCI') }}{% endmacro %}

with the comment: "A pseudo-account like DISPOSAL; set var ic_nci_account to post it to a chart account instead."

In konsol, since konsol#202, as a declared account on the Consolidation Group root: nci_account, a Link → Main Account validated as a Published leaf of the group's chart, synced to epm_gold.consolidation_groups, and already read by the deal journals (23 references across gold_business_combination_journal, gold_business_disposal_journal, gold_goodwill_amortisation_journal).

So the acquisition journal posts NCI to the declared chart account while the IC elimination posts it to the pseudo-account 'NCI', unless someone also sets the var to match. Nothing checks that they agree.

Why this now matters more

Under the multi-tenant direction (user decision, 15 Sep 2026: the dbt project moves into the Frappe app, ELT/ETL stays out), the var becomes the wrong home by construction rather than merely by preference.

Today dbt_project.yml is one file per deployment, regenerated by konsol's dbt_config.py, so a per-tenant value already cannot live there. Once dbt is app code, it is one file shipped identically to every tenant, and a project var can only ever hold a product-wide default — never a customer's chart account.

Everything tenant-specific has to be data in the site. consolidation_groups.nci_account already is exactly that, which makes this a straight deletion of the second source rather than a migration.

Root cause

ic_nci_account predates the Consolidation Policy. The pseudo-account was the right answer when no chart account was declared; konsol#202 supplied the declaration and the var was not retired.

Suggested fix

Read the declared account, keep the pseudo-account only as the fallback when the group has not declared one:

  • In ic_helpers.sql, resolve per group from epm_gold.consolidation_groups.nci_account (the root row, data_area_id = '') the way ic_difference_account already is in gold_ic_eliminations.
  • Fall back to the existing pseudo-account when the root declares nothing, so behaviour is unchanged for a group that has not configured it.
  • Retire var('ic_nci_account'), or keep it only as the fallback's value rather than as the answer.
  • A singular test that a group declaring nci_account gets its own account in gold_ic_eliminations, failing on main.

ic_difference_account is the pattern to copy — same table, same root row, already resolved per group.

Repro

Declare nci_account on a Consolidation Group root, build, and compare the NCI lines in gold_ic_eliminations with those in gold_business_combination_journal: different accounts for the same concept.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P3Pf9835FeLeXjRrYTTZ1M

Related

Tickets: #211

Discussion

  • Anonymous

    Anonymous - 2026-09-15

    Originally posted by: grynn-in

    Fixed by PR [#211].

     

    Related

    Tickets: #211

  • Anonymous

    Anonymous - 2026-09-15

    Ticket changed by: grynn-in

    • status: open --> closed
     

Log in to post a comment.