Skip to content

Partition retained earnings window functions by source_relation - #233

Open
porkedchop wants to merge 1 commit into
fivetran:mainfrom
porkedchop:fix/retained-earnings-partition-source-relation
Open

porkedchop wants to merge 1 commit into
fivetran:mainfrom
porkedchop:fix/retained-earnings-partition-source-relation

Conversation

@porkedchop

Copy link
Copy Markdown

Resolves #232

Please provide your name and company

Bishop Kammeraad

Describe what this PR changes and how it addresses the linked issue or feature request.

In int_quickbooks__retained_earnings, moves partition_by_source_relation from the order by to the start of the four window functions, with has_other_partitions='no'. When unioning connections the windows now render partition by source_relation, so the running sum and lag stay within each connection. With a single connection the macro renders nothing and the output is unchanged.

How did you validate the changes introduced within this PR, and what warehouse did you use for testing?

DuckDB with two copies of the integration test data unioned through quickbooks_union_schemas. The Net Income Adjustment period_ending_balance for 2026-02-01 goes from 122920 to 61460 for each connection, matching the single connection result. For 2020-01-01, qb2 goes from beginning -600 / ending -1200 to beginning 0 / ending -600. quickbooks__general_ledger_by_period has 7396 rows before and after. The single connection integration test output is unchanged. dbt build passes in both setups.

This edits the same period_beginning_converted_balance line as #231, so whichever merges second needs a one-line rebase.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] int_quickbooks__retained_earnings windows are not partitioned by source_relation when unioning connections

1 participant