Releases: fivetran/dbt_stripe
v0.15.1 dbt_stripe
Bug Fixes
- Updated the logic in
stripe__line_item_enhanced
to properly bring in refund data by adjusting the joins on balance transactions, refunds and charges.- Since charges and refunds are both types of balance transactions, included an additional join between refunds and balance transactions to bring in refunds at the same level as charges.
- Updated balance transactions join on
connected_account_id
andsource_relation
to look at both charge and refund balance transactions.
- Updated balance transactions join on
- Fixed
fee_amount
logic to sum together charge and refund amounts.- Coalesced
fee_amount
with zero for invoice-only (non-header) rows and updated downstream summing logic accordingly.
- Coalesced
- Updated
transaction_type
logic to not only bring incharge
, but also returncharge + refund
if the balance transaction has a charge and a refund associated with it, orpayment intent + refund
if the refund balance transaction is not yet tied to a charge.
- Since charges and refunds are both types of balance transactions, included an additional join between refunds and balance transactions to bring in refunds at the same level as charges.
Under the Hood
- Modified the consistency tests to better compare differences between production and development rows.
Full Changelog: v0.15.0...v0.15.1
v0.15.0 dbt_stripe
Breaking Changes
- Updated
stripe__balance_transactions
to correctly handle multiple disputes on the same transaction:- Adjusted
customer_facing_amount
to reflect thedispute_amount
of the latest dispute (if the transaction is not a charge or refund and is associated with any disputes) (PR #92). - Added the following the dispute-related columns (PR #92):
latest_dispute_amount_won
: Latest disputed amount that was won in favor of the merchant.latest_dispute_amount_lost
: Latest disputed amount that was lost and returned to the customer.latest_dispute_amount_under_review
: Latest disputed amount that is currently under review by the bank.latest_dispute_amount_needs_response
: Latest disputed amount that currently needs a response (the dispute has been filed but the merchant has not yet responded with evidence).latest_dispute_amount_warning_closed
: Latest disputed amount that is currently of statuswarning_under_closed
(early fraud warning being closed due to no formal dispute).latest_dispute_amount_warning_under_review
: Latest disputed amount that is currently of statuswarning_under_review
(card issuer suspects possible fraud but hasn't yet escalated the situation to a full dispute).latest_dispute_amount_warning_needs_response
: Latest disputed amount that is currently of statuswarning_needs_response
(early fraud warning has been escalated into formal dispute and/or card issuer has requested more information).dispute_count
: Count of disputes raised against this transaction. If > 1, join indispute
data for additional information on each dispute.
- Adjusted the
dispute_id
anddispute_reason
fields to aggregate together data from multiple disputes if present. They have been renamed todispute_ids
anddispute_reasons
in the following models (PR #88):stripe__balance_transactions
stripe__activity_itemized_2
stripe__balance_change_from_activity_itemized_3
stripe__ending_balance_reconciliation_itemized_4
- Adjusted
Under the Hood
- Updated
dispute
seed data to test the above changes (PR #92). - Added additional validation tests on the affected models from above (PR #92).
Contributors
Full Changelog: v0.14.1...v0.15.0
v0.14.1 dbt_stripe
PR #89 includes the following updates:
Bug Fixes
- Addressed a potential
Divide by 0
error in calculatingunit_amount
in thestripe__line_item_enhanced
model. Now, if the denominatorinvoice_line_item.quantity
is 0,unit_amount
will also be 0.
Under the Hood
- Expanded the
consistency_line_item_enhanced_count
test to also validate potential changes tounit_amount
sums. - Adjusted the
invoice_line_item
seed data to include cases wherequantity
= 0 in order to test the above bug fix.
Full Changelog: v0.14.0...v0.14.1
v0.14.0 dbt_stripe
PR #82 includes the following updates:
Feature Updates
- Addition of the
stripe__line_item_enhanced
model. This model constructs a comprehensive, denormalized analytical table that enables reporting on key revenue, subscription, customer, and product metrics from your billing platform. It’s designed to align with the schema of the*__line_item_enhanced
model found in Stripe, Recharge, Recurly, Shopify, and Zuora, offering standardized reporting across various billing platforms. To see the kinds of insights this model can generate, explore example visualizations in the Fivetran Billing Model Streamlit App. Visit the app for more details.- This model is currently disabled by default. You may enable it by setting the
stripe__standardized_billing_model_enabled
astrue
in yourdbt_project.yml
.
- This model is currently disabled by default. You may enable it by setting the
Relevant Upstream Updates (dbt_stripe_source v0.12.0)
- Addition of the following new staging models and accompanying upstream references:
stg_stripe__discount
(required for downstreamdbt_stripe
model transformations)stg_stripe__product
(enabled by default, but can be disabled by setting thestripe__using_subscriptions
variable tofalse
)
Under the Hood
- Added consistency test within integration_tests for the
stripe__line_item_enhanced
model. - Updated the
quickstart.yml
to include theproduct
source table as a requirement for thestripe__using_subscriptions
variable.
Full Changelog: v0.13.0...v0.14.0
v0.13.0 dbt_stripe
PR #78 includes the following updates:
🚨 Breaking Changes 🚨
- Renamed folder
stripe_reports
tostripe_financial_reports
to be more descriptive of the contents.⚠️ If you are using folder names to scope out configs, runs, etc., you will need to update the folder name.
Bug fixes
- Updated model
int_stripe__date_spine
to accommodate cases when modelstripe__balance_transactions
has no records.- Previously, the date spine relied on
stripe__balance_transactions
to set date bounds, which caused errors if empty. Now, the model defaults to a one-month range in such cases.
- Previously, the date spine relied on
Under the hood
- Updated structure of model
int_stripe__date_spine
for improved performance and maintainability.
Full Changelog: v0.12.0...v0.13.0
v0.12.0 dbt_stripe
PR #75 includes the following updates:
🚨 Breaking Changes 🚨
- No longer filters out deleted customers in
stripe__customer_overview
.- Persists
is_deleted
field to differentiate between deleted and active customers. - Note that this is a 🚨 breaking change 🚨, as previously filtered-out records will appear in
stripe__customer_overview
.
- Persists
Feature Updates
- Adds the
phone
column tostripe__customer_overview
.
Under the Hood
- Included auto-releaser GitHub Actions workflow to automate future releases.
- Updated the maintainer PR template to resemble the most up to date format.
Full Changelog: v0.11.0...v0.12.0
v0.11.0 dbt_stripe
PR #69 contains the following updates:
🚨 Breaking Changes 🚨
- Prefixed the following fields based on their corresponding upstream source to maintain clarity:
Previous Name | New Name |
---|---|
created_at | balance_transaction_created_at |
available_on | balance_transaction_available_on |
currency | balance_transaction_currency |
amount | balance_transaction_amount |
fee | balance_transaction_fee |
net | balance_transaction_net |
type | balance_transaction_type |
source | balance_transaction_source_id |
reporting_category | balance_transaction_reporting_category |
description | balance_transaction_description |
Updates
-
Introduced the following new models, named after the Stripe reports that they follow. These models help reproduce reports available in the Stripe Reporting API. The reports introduced in this update include:
- stripe__activity_itemized_2
- stripe__balance_change_from_activity_itemized_3
- stripe__ending_balance_reconciliation_itemized_4
- stripe__payout_itemized_3
-
Updated the
stripe__balance_transactions
with the following changes:reporting_category
has been updated to pull directly from the titular column. If noreporting_category
exists, it then falls to sort based on balance transactiontype
in accordance to the Stripe documentation.- Added the following fields:
- dispute fields
- transfer fields
- additional payout fields
- additional customer fields
- additional card fields
- additional charge fields
- additional invoice fields
- Updated
customer_facing_amount
to include for refunds and disputes as well - Updated
charge_id
to charge, refund, then dispute objects consecutively
Under the Hood
- Incorporated the new
fivetran_utils.drop_schemas_automation
macro into the end of each Buildkite integration test job. - Updated the pull request templates.
Full Changelog: v0.10.1...v0.11.0
v0.10.1 dbt_stripe
PR #61 contains the following changes:
Documentation Updates
- Updated the Metadata pivot documentation to be more clear that these variables only affect the
dbt_stripe_source
staging models. - Added reference to the new
stripe__card_metadata
andstripe__invoice_line_item_metadata
metadata variables that are available in the latest source package update.
Under the Hood
- Updated the
card
andinvoice_line_item
seed files to be consistent with the source package versions. Specifically to include the metadata fields. - Added a new BuildKite run statement to test a few of the metadata variables.
Full Changelog: v0.10.0...v0.10.1
v0.10.0 dbt_stripe
PR #60 includes the following changes:
🚨 Breaking Changes 🚨:
- Unwrapped
total_*
fields from the for loop instripe__daily_overview
to reduce compute required for previous for-loops - Add
account_id
inint_stripe__account_rolling_totals
for use as part of the join in the case where more than 1account_id
exists.
Under the Hood
- Intermediate model materializations have changed from ephemeral to table to reduce the compute required for the complexity of calculations.
v0.9.0 dbt_stripe
#56 includes the following changes:
🚨 Breaking Changes 🚨:
stripe__subscription_line_items
has been removed. To recreate it, simply filterstripe__invoice_line_items
for wheresubscription_id
is not null.- The
stripe__weekly_overview
,stripe__quarterly_overview
, andstripe__monthly_overview
models have been removed as they can be recreated directly from thestripe__daily_overview
by rolling up the date grain. - The
stripe__invoice_line_item
andstripe__subscription_line_items
have been renamed tostripe__invoice_line_item_details
andstripe__subscription_details
. - Following the addition of the new
pricing
source table which may replace theplan
table depending on whether you migrated to the Price API (Stripe doc here.), the following columns instripe__invoice_line_items
have been updated. This package will draw the respective columns from theprice
object by default if it exists. However, if you still have and wish to keep usingplan
, you can setstripe__using_price
to False. For more please see the README
Previous Name | New Name |
---|---|
plan_is_active | price_plan_is_active |
plan_amount | price_plan_amount |
plan_interval | price_plan_interval |
plan_interval_count | price_plan_interval_count |
plan_nickname | price_plan_nickname |
plan_product_id | price_plan_product_id |
-
In addition,
stripe__plan_metadata
variable has been renamed tostripe__price_plan_metadata
-
Variables have been prefixed with
stripe__
so they can be used globally.
Previous Name | New Name |
---|---|
using_invoices | stripe__using_invoices |
using_credit_notes | stripe__using_credit_notes |
using_payment_method | stripe__using_payment_method |
using_livemode | stripe__using_livemode |
using_invoice_line_sub_filter | stripe__using_invoice_line_sub_filter |
using_subscriptions | stripe__using_subscriptions |
using_subscription_history | stripe__using_subscription_history |
using_price | stripe__using_price |
- In the
stripe__subscription_details
model,start_date
has been updated tostart_date_at
to follow our standard naming practices.
🎉 Feature Updates 🎉
- Introducing the new model
stripe__invoice_details
. - Updated the models
stripe__daily_overview
with additional daily and rolling metrics. subscription_item_id
has been added to thestripe__invoice_line_items
model.- Added the ability to union datasets across different schemas or databases. A new column populating each model called
source_relation
will specify the source of each record.
For more information please refer to the README and stripe.yml
Full CHANGELOG: v0.8.0...v0.9.0