#60 ERPNext dbt staging models fail on fresh deploy (epm_raw tables missing)

[Anonymous]

Originally created by: vinuneeru

Problem

Running dbt build on a fresh deployment (or any deployment without Airbyte connected) fails with 7 errors on all ERPNext staging models:

Failure in model stg_erpnext__gl_entries
  DB::Exception: Unknown table expression identifier 'epm_raw.gl_entry'

Failure in model stg_erpnext__fiscal_periods
  DB::Exception: Unknown table expression identifier 'epm_raw.fiscal_year'

... (5 more similar errors)

Affected models:

• stg_erpnext__gl_entries
• stg_erpnext__accounts
• stg_erpnext__legal_entities
• stg_erpnext__exchange_rates
• stg_erpnext__budget_entries
• stg_erpnext__fiscal_periods
• stg_erpnext__trial_balance

Root cause: The epm_raw tables (gl_entry, company, fiscal_year, etc.) are created by Airbyte when it first syncs ERPNext data. On a fresh deployment with no Airbyte connection, these tables don't exist, so all ERPNext staging models fail.

dbt_project.yml includes erpnext in erp_sources unconditionally, so these models always run even with no ERPNext data.

Impact

• deploy.sh exits with code 1 on the dbt step, making the deploy appear to fail even though the app is fully functional
• 169 models are skipped (downstream of the failing ERPNext models)

Suggested Fix

Option A — Guard with on_schema_change / source freshness: Wrap ERPNext staging models with a check that skips if the source tables don't exist.

Option B — Make erp_sources opt-in: Remove erpnext from the default erp_sources var in dbt_project.yml. Users add it only after configuring Airbyte:

vars:
  erp_sources: ['d365_fo']  # add 'erpnext' after Airbyte is configured

Option C — Create empty placeholder tables in clickhouse/init-db.sql: Pre-create the epm_raw tables with the correct schema so staging models can compile and return zero rows until Airbyte populates them.

Option C is likely the lowest-friction fix — the init-db.sql already runs on ClickHouse startup and could include CREATE TABLE IF NOT EXISTS epm_raw.gl_entry ... stubs.

[Anonymous]

Originally posted by: grynn-in

Additional evidence from a fresh macOS one-click deploy — the cascade is bigger than just the 7 staging errors.

Because the canonical models union all over var('erp_sources') (defaulted to [d365_fo, erpnext] in dbt_project.yml), the 7 failing stg_erpnext__* models drag the entire downstream actuals/consolidation lineage into SKIP:

Done. PASS=73 WARN=0 ERROR=7 SKIP=169 NO-OP=0 TOTAL=249

Among the 169 skipped is gold_trial_balance — the fact table the Excel =EPM()/=K.EPM() API (konsol.api.epm_batch, scenario actuals) reads. So on a clean deploy the demo's actuals are simply not queryable from Excel/Cube.

Workaround that produces a clean build (demo data is D365-only):

dbt build --vars '{erp_sources: [d365_fo]}' --exclude path:models/staging/erpnext
# Done. PASS=190 WARN=0 ERROR=4 SKIP=42

Suggested fixes (any one): default erp_sources to [d365_fo] for the demo profile; ship empty/stub epm_raw ERPNext tables in the seed so staging yields 0 rows; or make the canonical union skip sources whose relations don't exist. The dbt_init step in deploy.sh runs a bare dbt build, so today every fresh deploy hits this.

[Anonymous]

Ticket changed by: grynn-in

• status: open --> closed