Giter Club home page Giter Club logo

dbt_stripe's Introduction

Stripe Transformation dbt Package (Docs)

📣 What does this dbt package do?

  • Produces modeled tables that leverage Stripe data from Fivetran's connector in the format described by this ERD and build off the output of our stripe source package.
  • Enables you to better understand your Stripe transactions. The package achieves this by performing the following:
    • Enhance the balance transaction entries with useful fields from related tables.
    • Generate a metrics tables allow you to better understand your account activity over time or at a customer level. These time-based metrics are available on a daily, weekly, monthly, and quarterly level.
  • Generates a comprehensive data dictionary of your source and modeled Stripe data through the dbt docs site.

The following table provides a detailed list of all models materialized within this package by default.

TIP: See more details about these models in the package's dbt docs site.

model description
stripe__balance_transactions Each record represents a change to your account balance, enriched with data about the transaction.
stripe__invoice_details Each record represents an invoice, enriched with details about the associated charge, customer, and subscription data.
stripe__invoice_line_item_details Each record represents an invoice line item, enriched with details about the associated charge, customer, subscription, and pricing data.
stripe__daily_overview Each record represents, per day, a summary of daily totals and rolling totals by transaction type (balances, payments, refunds, payouts, and other transactions). You may use this model to roll up into weekly, quarterly, monthly, and other time grains. You may also use this model to create a MRR report.
stripe__subscription_details Each record represents a subscription, enriched with customer details and payment aggregations.
stripe__customer_overview Each record represents a customer, enriched with metrics about their associated transactions. Transactions with no associated customer will have a customer description of "No associated customer".
stripe__activity_itemized_2 This report displays balance transactions alongside associated customer, charge, refund, fee, and invoice details, useful for Interchange Plus (IC+) pricing users.
stripe__balance_change_from_activity_itemized_3 This report functions like a bank statement for reconciling your Stripe balance, especially beneficial for treating Stripe as a bank account for accounting purposes. It offers a detailed breakdown of transactions affecting your balance.
stripe__ending_balance_reconciliation_itemized_4 This reports models after Stripe's payout reconciliation reports, helping match bank account payouts with related transactions. It provides details for automatic payouts and transactions that hadn't settled as of the report's end date. This report is only available for users with automatic payouts enabled and optimized for those who prefer to reconcile the transactions included in each payout as a settlement batch.
stripe__payout_itemized_3 This report represents payouts with information on expected arrival dates and status, akin to a bank statement for reconciling your Stripe balance, particularly useful for accounting purposes.
stripe__line_item_enhanced 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.

Example Visualizations

Curious what these models can do? Check out example visualizations from the stripe__line_item_enhanced model in the Fivetran Billing Model Streamlit App, and see how you can use these models in your own reporting. Below is a screenshot of an example report—explore the app for more.

Streamlit Billing Model App

🎯 How do I use the dbt package?

Step 1: Prerequisites

To use this dbt package, you must have the following:

  • At least one Fivetran Stripe connector syncing data into your destination.
  • A BigQuery, Snowflake, Redshift, Databricks, or PostgreSQL destination.

Databricks Dispatch Configuration

If you are using a Databricks destination with this package you will need to add the below (or a variation of the below) dispatch configuration within your dbt_project.yml. This is required in order for the package to accurately search for macros within the dbt-labs/spark_utils then the dbt-labs/dbt_utils packages respectively.

dispatch:
  - macro_namespace: dbt_utils
    search_order: ['spark_utils', 'dbt_utils']

Step 2: Install the package

Include the following stripe package version in your packages.yml file:

TIP: Check dbt Hub for the latest installation instructions or read the dbt docs for more information on installing packages.

packages:
  - package: fivetran/stripe
    version: [">=0.14.0", "<0.15.0"]

Do NOT include the stripe_source package in this file. The transformation package itself has a dependency on it and will install the source package as well.

Step 3: Define database and schema variables

By default, this package runs using your destination and the stripe schema. If this is not where your stripe data is (for example, if your stripe schema is named stripe_fivetran), add the following configuration to your root dbt_project.yml file:

vars:
    stripe_database: your_destination_name
    stripe_schema: your_schema_name 

Step 4: Disable models for non-existent sources

This package takes into consideration that not every Stripe account utilizes the invoice, invoice_line_item, payment_method, payment_method_card, plan, price, subscription, or credit_note features, and allows you to disable the corresponding functionality. By default, all variables' values are assumed to be true with the exception of credit_note. Add variables for only the tables you want to disable or enable respectively:

# dbt_project.yml

...
vars:
    stripe__using_invoices:        False  #Disable if you are not using the invoice and invoice_line_item tables
    stripe__using_payment_method:  False  #Disable if you are not using the payment_method and payment_method_card tables
    stripe__using_subscriptions:   False  #Disable if you are not using the subscription and plan/price tables.
    stripe__using_credit_notes:    True   #Enable if you are using the credit note tables.

(Optional) Step 5: Additional configurations

Expand to view configurations

Enabling Standardized Billing Model

This package contains the stripe__line_item_enhanced model which 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 Recurly, Recharge, Stripe, 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. For the time being, this model is disabled by default. If you would like to enable this model you will need to adjust the stripe__standardized_billing_model_enabled variable to be true within your dbt_project.yml:

vars:
  stripe__standardized_billing_model_enabled: true # false by default.

Unioning Multiple Stripe Connectors

If you have multiple Stripe connectors you would like to use this package on simultaneously, we have added the ability to do so. Data from disparate connectors will be unioned together and be passed downstream to the end models. The source_relation column will specify where each record comes from. To use this functionality, you will need to either set the stripe_union_schemas or stripe_union_databases variables. Please also make sure the single-source stripe_database and stripe_schema variables are removed.

# dbt_project.yml

...
config-version: 2

vars:
    stripe_union_schemas: ['stripe_us','stripe_mx'] # use this if the data is in different schemas/datasets of the same database/project
    stripe_union_databases: ['stripe_db_1','stripe_db_2'] # use this if the data is in different databases/projects but uses the same schema name

Leveraging Plan vs Price Sources

Customers using Fivetran with the newer Stripe Price API will have a price table, and possibly a plan table if that was used previously. Therefore to accommodate two different source tables we added logic to check if there exists a price table by default. If not, it will leverage the plan table. However if you wish to use the plan table instead, you may set stripe__using_price to false in your dbt_project.yml to override the macro.

# dbt_project.yml

...
config-version: 2

vars:
  stripe__using_price: false #  True by default. If true, will look `price ` table. If false, will look for the `plan` table. 

Leveraging Subscription Vs Subscription History Sources

For Stripe connectors set up after February 09, 2022 the subscription table has been replaced with the new subscription_history table. By default this package will look for your subscription data within the subscription_history source table. However, if you have an older connector then you must configure the stripe__using_subscription_history to false in order to have the package use the subscription source rather than the subscription_history table.

Please note that if you have stripe__using_subscription_history enabled then the package will filter for only active records.

vars:
    stripe__using_subscription_history: False  # True by default. Set to False if your connector syncs the `subscription` table instead. 

Setting your timezone

This packages leaves all timestamp columns in the UTC timezone. However, there are certain instances, such in the daily overview model, that timestamps have to be converted to dates. As a result, the timezone used for the timestamp becomes relevant. By default, this package will use the UTC timezone when converting to date, but if you want to set the timezone to the time in your Stripe reports, add the following configuration to your root dbt_project.yml:

vars:
  stripe_timezone: "America/New_York" # Replace with your timezone

Running on Live vs Test Customers

By default, this package will run on non-test data (where livemode = true) from the source Stripe tables. However, you may want to include and focus on test data when testing out the package or developing your analyses. To run on only test data, add the following configuration to your root dbt_project.yml file:

vars:
    stripe_source:
        stripe__using_livemode: false  # Default = true

Including sub Invoice Line Items

By default, this package will filter out any records from the invoice_line_item source table which include the string sub_. This is due to a legacy Stripe issue where sub_ records were found to be duplicated. However, if you highly utilize these records you may wish they be included in the final output of the stg_stripe__invoice_line_item model. To do, so you may include the below variable configuration in your root dbt_project.yml:

vars:
    stripe_source:
        stripe__using_invoice_line_sub_filter: false # Default = true

Pivoting out Metadata Properties

Oftentimes you may have custom fields within your source tables that is stored as a JSON object that you wish to pass through. By leveraging the metadata variable, this package will pivot out fields into their own columns within the respective staging models from the dbt_stripe_source package. The metadata variables accept dictionaries in addition to strings.

Additionally, you may alias your field if you happen to be using a reserved word as a metadata field, any otherwise incompatible name, or just wish to rename your field. Below are examples of how you would add the respective fields.

The metadata JSON field is present within the customer, charge, card, invoice, invoice_line_item, payment_intent, payment_method, payout, plan, price, refund, and subscription source tables. To pivot these fields out and include in the respective downstream staging model, add the relevant variable(s) to your root dbt_project.yml file like below.

vars: 
  stripe__account_metadata:
    - name: metadata_field
    - name: another_metadata_field
    - name: and_another_metadata_field
  stripe__charge_metadata:
    - name: metadata_field_1
  stripe__card_metadata:
    - name: metadata_field_10
  stripe__customer_metadata:
    - name: metadata_field_6
      alias: metadata_field_six
  stripe__invoice_metadata: 
    - name: metadata_field_2
  stripe__invoice_line_item_metadata: 
    - name: metadata_field_20
  stripe__payment_intent_metadata:
    - name: incompatible.field
      alias: rename_incompatible_field
  stripe__payment_method_metadata:
    - name: field_is_reserved_word
      alias: field_is_reserved_word_xyz
  stripe__payout_metadata:
    - name: 123
      alias: one_two_three
  stripe__price_plan_metadata: ## Used for both Price and Plan sources
    - name: rename_price
      alias: renamed_field_price
  stripe__refund_metadata:
    - name: metadata_field_3
  stripe__subscription_metadata:
    - name: 567
      alias: five_six_seven

Alternatively, if you only have strings in your JSON object, the metadata variable accepts the following configuration as well.

vars:
    stripe__subscription_metadata: ['the', 'list', 'of', 'property', 'fields'] # Note: this is case-SENSITIVE and must match the casing of the property as it appears in the JSON

Change the build schema

By default, this package builds the stripe staging models within a schema titled (<target_schema> + _stg_stripe) in your destination. If this is not where you would like your stripe staging data to be written to, add the following configuration to your root dbt_project.yml file:

models:
    stripe_source:
      +schema: my_new_schema_name # leave blank for just the target_schema

Change the source table references

If an individual source table has a different name than the package expects, add the table name as it appears in your destination to the respective variable:

IMPORTANT: See this project's dbt_project.yml variable declarations to see the expected names.

vars:
    stripe_<default_source_table_name>_identifier: your_table_name 

(Optional) Step 6: Orchestrate your models with Fivetran Transformations for dbt Core™

Expand for details

Fivetran offers the ability for you to orchestrate your dbt project through Fivetran Transformations for dbt Core™. Learn how to set up your project for orchestration through Fivetran in our Transformations for dbt Core setup guides.

🔍 Does this package have dependencies?

This dbt package is dependent on the following dbt packages. Please be aware that these dependencies are installed by default within this package. For more information on the following packages, refer to the dbt hub site.

IMPORTANT: If you have any of these dependent packages in your own packages.yml file, we highly recommend that you remove them from your root packages.yml to avoid package version conflicts.

packages:
    - package: fivetran/stripe_source
      version: [">=0.12.0", "<0.13.0"]

    - package: fivetran/fivetran_utils
      version: [">=0.4.0", "<0.5.0"]

    - package: dbt-labs/dbt_utils
      version: [">=1.0.0", "<2.0.0"]

    - package: dbt-labs/spark_utils
      version: [">=0.3.0", "<0.4.0"]

🙌 How is this package maintained and can I contribute?

Package Maintenance

The Fivetran team maintaining this package only maintains the latest version of the package. We highly recommend you stay consistent with the latest version of the package and refer to the CHANGELOG and release notes for more information on changes across versions.

Contributions

A small team of analytics engineers at Fivetran develops these dbt packages. However, the packages are made better by community contributions!

We highly encourage and welcome contributions to this package. Check out this dbt Discourse article on the best workflow for contributing to a package!

🏪 Are there any resources available?

  • If you have questions or want to reach out for help, please refer to the GitHub Issue section to find the right avenue of support for you.
  • If you would like to provide feedback to the dbt package team at Fivetran or would like to request a new dbt package, fill out our Feedback Form.
  • Have questions or want to be part of the community discourse? Create a post in the Fivetran community and our team along with the community can join in on the discussion!

dbt_stripe's People

Contributors

antoon-r avatar bpei-dc avatar dylanbaker avatar erikmag avatar fivetran-catfritz avatar fivetran-chloe avatar fivetran-jamie avatar fivetran-joemarkiewicz avatar fivetran-reneeli avatar fivetran-sheringuyen avatar johnf avatar kristin-bagnall avatar lewisdavies avatar markmacardle avatar nachimehta avatar uttam17 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dbt_stripe's Issues

[Feature] Add `paid_out_of_bound` boolean to better identify invoices paid outside of Stripe

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

There is a paid_out_of_bound value in the Stripe API that flags whether an invoice was marked as "Paid outside of Stripe" which is helpful to be able to isolate invoices where the funds weren't collected through Stripe directly.

Link to the API docs: https://stripe.com/docs/api/invoices/object#invoice_object-paid_out_of_band

In my specific use case, I was trying to understand why invoices were marked as paid, but had no charge record. Upon further investigation, this could be due a few different scenarios:

  1. Invoice was paid in full or partially by discounts
  2. Invoice was paid in full or partially by applied balances
  3. Invoice was marked as paid due to the amount is below the min charge amount.
  4. Invoice received a credit note
  5. Invoice was marked as paid outside of Stripe

It would greatly simplify any logic needed to identify each scenario by including the Boolean.

Describe alternatives you've considered

I started to play around with logic based on the invoice.amount_due value to check why no charge was created to clearly show the different scenarios. Right now the solution would be to evaluate whether the discount, applied balance, min charge or credit note covered the entire invoice and then anything remaining would be assumed as Paid Outside of Stripe.

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

No response

[Bug] stripe__daily_overview run exceeds memory

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

The stripe__daily_overview model times out when run. The fix probably will be similar to what was done in our Recurly package.

image (2)

A customer raised this issue in dbt slack. https://getdbt.slack.com/archives/C01D1R2JLLA/p1677259324297449

Relevant error log or model output

No response

Expected behavior

A clean run

dbt Project configurations

n/a

Package versions

v0.9.0

What database are you using dbt with?

bigquery

dbt Version

v1.4.1

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Bug] Timezone conversion doesn't work on postgres

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

When trying to set the timezone I get an error.

PostgreSQL doesn't have a convert_timezone function. If you look at dbt_packages/dbt_utils/macros/cross_db_utils/current_timestamp.sql you will see that they use something like
({{ column }} at time zone '{{ var("stripe_timezone") }}')::{{dbt_utils.type_timestamp()}} instead

Relevant error log or model output

07:21:34  Database Error in model stripe__customer_overview (models/stripe__customer_overview.sql)
07:21:34    function convert_timezone(unknown, timestamp without time zone) does not exist
07:21:34    LINE 63:     convert_timezone('Sydney/Australia', created_at)
07:21:34                 ^
07:21:34    HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
07:21:34    compiled SQL at target/run/stripe/models/stripe__customer_overview.sql
07:21:34

Expected behavior

No error and timezones should be converted

dbt Project configurations

vars:
using_invoices: false
using_subscriptions: false
using_credit_notes: false
stripe_timezone: "Sydney/Australia"
stripe_schema: stripe_load
stripe_database: dwh_prod

Package versions

packages:

  • package: fivetran/stripe_source
    version: [">=0.5.0", "<0.6.0"]

  • package: fivetran/stripe
    version: [">=0.6.0", "<0.7.0"]

What database are you using dbt with?

postgres

dbt Version

nstalled version: 1.0.4
latest version: 1.0.4

Up to date!

Plugins:

  • postgres: 1.0.4 - Up to date!

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Feature] Databricks Support

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

The Stripe package currently does not support Databricks as a destination. We will want to make any necessary changes to this package (and the source) to ensure the package works on a Databricks destination.

Additionally, this will be a good update to also incorporate the PR #38 updates as Databricks support should be a breaking change.

Describe alternatives you've considered

Not using Databricks which is not an ideal workaround.

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

No response

How to adjust models?

After changing the metadata variables I saw not all columns are showing in the destination transformation schema. So I went and edit them myself in dbt_packages/stripe/models. however it did not do anything, not even with --full-refresh. I guess this is somewhat related to dbt_packages being in .gitignore.
Am I allowed to change it? if I change it - will it work?

I don't want to break stuff.

The changes I've done to the dbt_project.yml are:

  • stripe__charge_metadata: ['extras', 'product', 'userid']
  • stripe__invoice_metadata: ['extras', 'product', 'userid']
  • stripe__subscription_metadata: ['extras', 'userid']
  • stripe__customer_metadata: ['userid']

[Feature Request] Adding timezone variable to cast datetime into specific timezones

Context

Currently the stripe data is ingested as UTC and transformed as UTC as well (AFAIK), which causes the numbers to mismatch with the Stripe dashboard.

Proposal

Adding a new (optional) variable that will cast any DATETIME or DATE fields into a specific timezone. Eg. for stripe_customer_overview model, add a new field like:
DATETIME(customer.created_at, '{{ var("timezone") }}') as created_at_tz.

That way, the original created_at datetime in UTC is still preserved, and the end user has the option to use created_at_tz for a localized timezone.

Similarly for stripe_daily_overview, adding date_tz columns for the WITH statements -- daily_balance_transactions and daily_failed_charges, as well as optionally joining on date_tz if a timezone var is present.

Add table rename at the end of each refresh

Some tables take a long time to refresh, like:

09:12:05  119 of 175 START table model cdp_stripe.stripe__invoice_line_items ............. [RUN]
09:15:08  119 of 175 OK created table model cdp_stripe.stripe__invoice_line_items ........ [SELECT in 183.45s]

During this time - the table is not available to query in prod.
One way to resolve this is to run in the end:

DROP TABLE IF EXISTS cdp_stripe.stripe__invoice_line_items_prod;
ALTER TALBE cdp_stripe.stripe__invoice_line_items rename to cdp_stripe.stripe__invoice_line_items_prod;

Is there such a way to do it when each table is ready?

[Bug] update date_spine model to accommodate empty `stripe__balance_transactions`

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

Same issue as fivetran/dbt_quickbooks#118

We need to add coalesces both the first_date and last_date to ensure the spine is not working with Nonetype values.

Relevant error log or model output

Database Error in model int_stripe__date_spine (models/intermediate/int_stripe__date_spine.sql)

Invalid datetime string "None"

Expected behavior

Date spine and its downstream models should not fail

the daily overview model includes non-balance-transaction data so it's still valuable to have even with no balance transaction records

dbt Project configurations

na

Package versions

na

What database are you using dbt with?

postgres, redshift, snowflake, bigquery, databricks

dbt Version

na

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Investigate] Discrepancy between line item amounts and invoice amounts

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

In our internal Stripe data, we've noticed that not all amounts in the line item table tie up to the amounts in the invoice table, when summed up to the invoice grain. So far it's been identified that it ties to a subscription amount found in the price_plan table.

We should confirm whether this is something buggy with our data, or if this is indeed expected and we should make adjustments in our logic.

Relevant error log or model output

No response

Expected behavior

Invoice line item amounts sum up to the amounts in the invoice table

dbt Project configurations

na

Package versions

na

What database are you using dbt with?

other (mention it in "Additional Context")

dbt Version

na

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Bug] Error in tmp models due to metadata type json

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

Tmp models returns an error because cannot cast metadata dimension which is passed as json type instead of string.
Metadata dimension used to be string but most recent Fivetran tables turned it into json.

Relevant error log or model output

Database Error in model stg_stripe__invoice_line_item_tmp (models/tmp/stg_stripe__invoice_line_item_tmp.sql)
  Invalid cast from JSON to STRING at [94:26]
  compiled Code at target/run/stripe_source/models/tmp/stg_stripe__invoice_line_item_tmp.sql

Expected behavior

The tmp models should cast metadata fields as string with to_json() function to convert the value to a JSON string before casting it to a string.

The package should generate the output tables without errors.

dbt Project configurations

name: 'dbzaps'
version: '1.0.0'
config-version: 2

This setting configures which "profile" dbt uses for this project.

profile: 'default'

These configurations specify where dbt should look for different types of files.

The source-paths config, for example, states that models in this project can be

found in the "models/" directory. You probably won't need to change these!

model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

target-path: "target" # directory which will store compiled SQL files
clean-targets: # directories to be removed by dbt clean

  • "target"
  • "dbt_packages"

Configuring models

Full documentation: https://docs.getdbt.com/docs/configuring-models

models:

Applies to all files under models/bilateralstimulation/

dbzaps:
bilateralstimulation:
staging:
materialized: view
intermediate:
materialized: ephemeral
marts:
+materialized: table

Fivetran Stripe | Bilateral Stimulation

vars:
stripe_union_schemas: ['stripe_bilateralstimulation_de','stripe_bilateralstimulation_us','stripe_bilateralstimulation'] # use this if the data is in different schemas/datasets of the same database/project

Package versions

packages:

  • package: fivetran/stripe
    version: 0.10.1

What database are you using dbt with?

bigquery

dbt Version

dbt Version: 1.4 (latest)

Additional Context

Screenshot 2023-05-17 at 08 15 29

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Feature] DuckDB Support

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

I propose adding support for the DuckDB database engine in the fivetran/stripe package. DuckDB is an in-memory analytical database that is gaining popularity due to its speed and efficiency.

However, when trying to use the fivetran/stripe package with the dbt-duckdb adapter, I encountered an error related to the + operator not being supported for adding an interval to a string in DuckDB, similar to Postgres.

Describe alternatives you've considered

No response

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

https://github.com/jwills/dbt-duckdb

BUG - date_add does not exist

Are you a current Fivetran customer?

Peter, Humi :)

Describe the bug

Might just be me misusing but:

On model stripe__balance_transactions getting error:

Postgres error: function pg_catalog.date_add("unknown", integer, timestamp with time zone) does not exist

Weird because dbt_utils was properly installed

Installing dbt-labs/[email protected]
  Installed from version 0.7.4
  Up to date!

Steps to reproduce

  1. Add fivetran/stripe version 0.5.1 to packages.yml
  2. dbt deps
  3. dbt run --models stripe

Expected behavior

Project variables configuration

# Name your project! Project names should contain only lowercase characters
# and underscores. A good package name should reflect your organization's
# name or the intended use of these models
name: 'my_new_project'
version: '0.20.2'
config-version: 2

# This setting configures which "profile" dbt uses for this project.
profile: 'default'

# These configurations specify where dbt should look for different types of files.
# The `source-paths` config, for example, states that models in this project can be
# found in the "models/" directory. You probably won't need to change these!
source-paths: ["models"]
analysis-paths: ["analysis"]
test-paths: ["tests"]
data-paths: ["data"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

target-path: "target"  # directory which will store compiled SQL files
clean-targets:         # directories to be removed by `dbt clean`
    - "target"
    - "dbt_modules"

vars:
    stripe_schema: landing_stripe
    stripe_database: warehouse
    stripe_timezone: "America/Toronto"

# Configuring models
# Full documentation: https://docs.getdbt.com/docs/configuring-models

# In this example config, we tell dbt to build all models in the example/ directory
# as tables. These settings can be overridden in the individual model files
# using the `{{ config(...) }}` macro.
models:
  my_new_project:
      # Applies to all files under models/example/
      example:
          materialized: view
  stripe:
    +schema: _stripe
  stripe_source:
    +schema: _stripe_source

Package Version

  - package: fivetran/stripe_source
    version: 0.4.4
  - package: fivetran/stripe
    version: 0.5.1

Warehouse

  • BigQuery
  • Redshift
  • Snowflake
  • Postgres
  • Databricks
  • Other (provide details below)

Additional context

Screenshots

Please indicate the level of urgency

Need to get solved by EOW
Are you interested in contributing to this package?

  • Yes, I can do this and open a PR for your review.
  • Possibly, but I'm not quite sure how to do this. I'd be happy to do a live coding session with someone to get this fixed.
  • No, I'd prefer if someone else fixed this. I don't have the time and/or don't know what the root cause of the problem is.

Your package relies on older versions of dbt-utils, which means our project is stuck on an older version

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

Your package relies on older versions of dbt-utils, which means ours is stuck on an older version.

Describe alternatives you've considered

No response

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

No response

[Bug] livemode_predicate generates invalid SQL on Redshift: cannot cast type character varying to boolean

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

livemode generates invalid sql and it fails with cannot cast type character varying to boolean

the predicates generated is

where cast(livemode as BOOLEAN ) = True

whereas redshift would unfortunately need something like

where decode(livemode, 'true', true, 'false', false) = true

Relevant error log or model output

03:57:16  Database Error in model stg_stripe__transfer (models/stg_stripe__transfer.sql)
03:57:16    cannot cast type character varying to boolean
03:57:16    compiled Code at target/run/stripe_source/models/stg_stripe__transfer.sql

Expected behavior

Should generate valid SQL

dbt Project configurations

Not relevant for this model

Package versions

  • package: fivetran/stripe
    version: 0.12.0

What database are you using dbt with?

redshift

dbt Version

1.5.4

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Bug] Latest Version of Stripe does not reference latest stripe_source

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

For some reason the latest version of the stripe package does not reference the latest version of the stripe_source package. We should update this accordingly.

Relevant error log or model output

No response

Expected behavior

The package references the latest version of the source pacakge.

dbt Project configurations

N/A

Package versions

packages:

  • package: fivetran/stripe
    version: [">=0.7.0", "<0.8.0"]

What database are you using dbt with?

bigquery

dbt Version

1.1.1

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[Bug] Issue with stripe source on dbt run

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

When I try to dbt run for the first time, I get the following error because the stripe subscription table does not exist.

Database Error in model stg_stripe__subscription_tmp (models/tmp/stg_stripe__subscription_tmp.sql)
relation "stripe.subscription" does not exist
LINE 7: from "db"."stripe"."subscription"
             ^
 compiled SQL at target/run/stripe_source/models/tmp/stg_stripe__subscription_tmp.sql
Done. PASS=32 WARN=0 ERROR=1 SKIP=4 TOTAL=37

In my database, Fivetran does not export a table named subscription but instead the following tables.

subscription_history
subscription_discount
subscription_item
subscription_tax_rate

Is there an easy fix for this?

Relevant error log or model output

No response

Expected behavior

This should either look for a table with another name or build properly.

dbt Project configurations

Using the latest dbt version as of 28th March and have only installed the stripe package.

Package versions

packages:
  - package: fivetran/stripe
    version: [">=0.6.0", "<0.7.0"]

What database are you using dbt with?

postgres

dbt Version

dbt installed version: 1.0.4

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

[FEATURE] metadata columns does not appear summary tables

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

I want to add some columns from the metadata column into some of the summary tables:

stripe__balance_transactions
stripe__invoice_details
stripe__invoice_line_item_details
stripe__subscription_details
stripe__customer_overview

With the exception of stripe__customer_overview adding the following vars in dbt_project.yml did not help:

  stripe__charge_metadata: ['col1', 'col2', 'col3', 'col4'] 
  stripe__invoice_metadata: ['col1', 'col2', 'col3', 'col4']
  stripe__subscription_metadata: ['col1', 'col2', 'col3', 'col4']
  stripe__customer_metadata: ['col1']

For now, I did the same as here , adding manually

{% if var('stripe__charge_metadata',[]) %}
      {% for metadata in var('stripe__charge_metadata') %}
          ,charge.{{ metadata }} as charge_{{ metadata }}
      {% endfor %}
    {% endif %}

    {% if var('stripe__customer_metadata',[]) %}
      {% for metadata in var('stripe__customer_metadata') %}
          ,customer.{{ metadata }} as customer_{{ metadata }}
      {% endfor %}
    {% endif %}

    {% if var('stripe__charge_metadata',[]) %}
      {% for metadata in var('stripe__charge_metadata') %}
          ,refund_charge.{{ metadata }} as refund_charge_{{ metadata }}
      {% endfor %}
    {% endif %}

To files like stripe__balance_transactions.sql

Relevant error log or model output

No error was reported as dbt run and test work.

Expected behavior

Columns col1, col2, col3, col4 appear in:

stripe__balance_transactions
stripe__invoice_details
stripe__invoice_line_item_details
stripe__subscription_details

Column col1 appears in (it is):
stripe__customer_overview

dbt Project configurations

# Name your project! Project names should contain only lowercase characters
# and underscores. A good package name should reflect your organization's
# name or the intended use of these models
name: 'fivetran_dbt'
version: '1.0.0'
config-version: 2

# This setting configures which "profile" dbt uses for this project.
profile: 'fivetran_dbt'

# These configurations specify where dbt should look for different types of files.
# The `model-paths` config, for example, states that models in this project can be
# found in the "models/" directory. You probably won't need to change these!
model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

target-path: "target"  # directory which will store compiled SQL files
clean-targets:         # directories to be removed by `dbt clean`
  - "target"
  - "dbt_packages"


# Configuring models
# Full documentation: https://docs.getdbt.com/docs/configuring-models

# In this example config, we tell dbt to build all models in the example/ directory
# as tables. These settings can be overridden in the individual model files
# using the `{{ config(...) }}` macro.
models:
  fivetran_dbt:
  stripe:
  stripe_source:

vars:
  using_schedules: False
  stripe_source:
    stripe_database: dkall
    stripe_schema: stripe
  stripe_database: dkall
  stripe_schema: stripe
  stripe__subscription_history: True
  stripe_source:
    stripe__using_invoice_line_sub_filter: false
  stripe__charge_metadata: ['col1', 'col2', 'col3', 'col4'] 
  stripe__invoice_metadata: ['col1', 'col2', 'col3', 'col4']
  stripe__subscription_metadata: ['col1', 'col2', 'col3', 'col4']
  stripe__customer_metadata: ['col1']

Package versions

packages:
  - package: fivetran/stripe
    version: [">=0.10.0", "<0.11.0"]

What database are you using dbt with?

redshift

dbt Version

Core:
  - installed: 1.5.1
  - latest:    1.5.1 - Up to date!

Plugins:
  - postgres: 1.5.1 - Up to date!
  - redshift: 1.5.4 - Up to date!


Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

BUG - Unneeded `order by`s reduce performance

Are you a current Fivetran customer?

Yes, Mark MacArdle, data engineer at Bought By Many.

Describe the bug

Most of the cleaned tables end with an order by (eg stripe__balance_transactions.sql). Ordering is an expensive operation but it won't be retained when users query the table. As it doesn't add anything the ordering should be removed.

Steps to reproduce
Look at the queries in the models folder.

Package Version

0.4.1

Please indicate the level of urgency

Very low

Are you interested in contributing to this package?

  • Yes, I can do this and open a PR for your review.
  • Possibly, but I'm not quite sure how to do this. I'd be happy to do a live coding session with someone to get this fixed.
  • No, I'd prefer if someone else fixed this. I don't have the time and/or don't know what the root cause of the problem is.

[Feature] Stripe report folder should be renamed to Stripe financial reports

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

A minor minor syntax thing our PM suggested-- the correct name of these reports should be Stripe financial reports. Let's make this edit in our next batch of updates

Describe alternatives you've considered

No response

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

No response

[Bug] Errors when extracting JSON values

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

I'm trying to use the metadata list variables, e.g. stripe__plan_metadata, to specify the fields to extract but I'm seeing two distinct error pattens:

  • For fields with a full stop, e.g. feature.id, the package tries to use the same value as a column name. This fails because column names can't contain ..
  • I have another field called set. Snowflake expects this to set a session variable, which causes an error.

Relevant error log or model output

-- plan.id
10:51:08  Database Error in model stg_stripe__plan (models/stg_stripe__plan.sql)
10:51:08    001003 (42000): SQL compilation error:
10:51:08    syntax error line 224 at position 21 unexpected '.'.
10:51:08    syntax error line 227 at position 24 unexpected '('.
10:51:08    syntax error line 227 at position 51 unexpected ','.
10:51:08    syntax error line 227 at position 53 unexpected ''feature.id''.
10:51:08    syntax error line 229 at position 11 unexpected 'as'.
10:51:08    compiled SQL at target/run/stripe_source/models/stg_stripe__plan.sql

-- set
10:48:51  Database Error in model stg_stripe__plan (models/stg_stripe__plan.sql)
10:48:51    001003 (42000): SQL compilation error:
10:48:51    syntax error line 259 at position 14 unexpected 'set'.
10:48:51    compiled SQL at target/run/stripe_source/models/stg_stripe__plan.sql

Expected behavior

Ideally, columns should be created from the metadata with valid names. However, I imagine there are a ton of corner cases regarding character substitution and reserved keywords.

An alternative approach would be to pass metadata fields to the final models without modification. This would let users parse the values in a separate view.

dbt Project configurations

vars:
stripe__plan_metadata:
- archived
- feature.handle
- feature.id
- feature.type
- generated
- limit
- plan.id
- plan.handle
- set
- version

Package versions

packages:

  • package: fivetran/stripe
    version: 0.7.1

What database are you using dbt with?

snowflake

dbt Version

Core:

  • installed: 1.2.1
  • latest: 1.2.1 - Up to date!

Plugins:

  • snowflake: 1.2.0 - Up to date!

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

Invoice Line Item is not guaranteed to be unique

- name: invoice_line_item_id

From customer:
The stripe connector has ingested the data and I run the dbt job and get an error that the invoice line item id is not unique. I look at the data and, sure enough, it is not unique.

I email Stripe support. The long and the short of it is for invoice line items made before their 2019-12-03 API update the id field is not guaranteed to be unique. They told me that for items like this I really should be using the unique_id field for a unique id 🙄 .

This can be identified by the prefix on the id. If it is sli_ it is old and potentially not unique and should use the unique_id field which is guaranteed unique and is prefixed with il_.

I think this could be handled in the dbt module about how invoice_line_item_id is selected.

[Feature] currency field to be pulled through to invoice_line_items

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

We are charging multiple currencies through our stripe account and the invoice_line_items table does not have the currency field propagated through, even though it is available in upstream models.

Would it be sensible to include this?

Describe alternatives you've considered

The alternative solution I see would be to join one of the tables like balance_transactions or stg_stripe__fees to invoice_line_items in our core models.

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

No response

Questions

  1. Dates are treated differently for "payout" balance movements vs. other types of balance movements. Why is this the case?

Specifically, whilst other movements use the 'created_at' date we case the 'payout' balance movements to choose the 'available_on' date if available; if not, it's only then we revert to the 'created_at' date.

  1. We'd love to be able to capture monthly opening and closing balances for our Stripe accounts. How can we do that via the Fivetran Stripe connector?

We had a look over the same daily_overview.sql as referenced above and this line stand out:
daily_balance_transactions.daily_net_activity + daily_balance_transactions.total_gross_payout_amount)/100.0 as daily_end_balance
Both the daily_net_activity and total_gross_payout_amount totals look to me like outgoings, so if this is determined as the daily_end_balance what are they subtracted from to begin with?

Or are we saying that we provide this data in the modelled table as the total outgoing balance and, along with the data like total_sales/total_refunds, our clients can then run further models on top of these to understand balances across their accounts?

BUG - Customer Overview Model Should Include No Associate Customer Records

Are you a current Fivetran customer?

Fivetran created bug.

Describe the bug

Currently, the stripe__customer_overview model is joining the transaction into the customer object. However, this results in transactions that are no associated with a customer to be included in the model. This can be confusing for customers as the totals for this model will not tie out to the other models if they have transactions not associated with customers. As mentioned in this dbt Slack thread, this is something that is confusing and should be updated.

Expected behavior

All transactions (even the ones not associated with a customer) should be included in the stripe__customer_overview model. For those that are not associated, we should include them in the "No Associated Customer Records" record.

FEATURE - Add More Context to the `using_invoice_line_sub_filter` variable

Are you a Fivetran customer?

Fivetran created FR

Is your feature request related to a problem? Please describe.

The using_invoice_line_sub_filter can be somewhat confusing to understand for a first time user of this package. As highlighted by a customer within dbt Slack we should add more context within our README to help users understand why this is included and when to leverage the variable.

Describe the solution you'd like

The README has more context as to what the variable is and why it is included, and also when to use it. The slack thread linked above adds some good info that we should add.

Describe alternatives you've considered

The current README state.

BUG - Docs are out of date

Are you a current Fivetran customer?

The docs seem to only include the dbt_stripe_source model contents. Next time we push an update to this package we need to update the docs as well.

[Question] Custom metadata column don't use alias feature

Is there an existing issue for this?

  • I have searched the existing issues

Describe the issue

Following #65 I am trying to add a column from the metadata which already exists in the table.

we have currency in the metadata that we want to extract.
Adding it to the var:

vars:
  stripe__invoice_metadata: ['amounts', 'currency']

Results an issue:

15:45:04  Database Error in model stg_stripe__invoice (models/stg_stripe__invoice.sql)
15:45:04    column name "currency" is duplicated
15:45:04    compiled Code at target/run/stripe_source/models/stg_stripe__invoice.sql

So I was trying to add the alias like in the doc:

vars:
  stripe__invoice_metadata:
    - name: amounts
    - name: currency
      alias: metadata_currency

and it fails with:

08:43:00  Database Error in model stripe__invoice_details (models/stripe__invoice_details.sql)
08:43:00    syntax error at or near "{"
08:43:00    compiled Code at target/run/stripe/models/stripe__invoice_details.sql
08:43:00

I guess that I'm not utilizing the alias feature in the code:

    {% if var('stripe__invoice_metadata',[]) %}
      {% for metadata in var('stripe__invoice_metadata') %}
          ,invoice.{{ metadata }} as invoice_{{ metadata }}
      {% endfor %}
    {% endif %}

Would love for some guidelines

Relevant error log or model output

No response

Expected behavior

currency from the metadata appears in the final invoice table.

dbt Project configurations

As described in #65

Package versions

As described in #65

What database are you using dbt with?

redshift

dbt Version

As described in #65

Additional Context

No response

Are you willing to open a PR to help address this issue?

  • Yes.
  • Yes, but I will need assistance and will schedule time during our office hours for guidance
  • No.

update required dbt version to allow v0.19.0

dbt v0.19.0 was released on Jan 27th but this package has the below line in it's dbt_project.yml

require-dbt-version: [">=0.18.0", "<0.19.0"]

Be great if this could be updated to allow use of latest version of dbt.

The Stripe source package would also need to be updated.

[Feature] Be able to leverage package to create MRR reports

Is there an existing feature request for this?

  • I have searched the existing issues

Describe the Feature

Update daily overview model, or a more fitting model, to account for subscription-based transactions in order to build MRR reports on top of our package.

We need the invoice table in order to connect to the subscription table, which the daily overview model currently doesn't pull from. The closest model that would feed into an MRR report I'd say is the invoice_line_item_details model.

It seems that the daily overview model amounts come from the balance transaction table. The way subscription data would be brought in would be: balance transaction > charge > invoice > subscription. The most downstream models where some of them exist together is in the balance transactions and subscription details . But there isn't a model that ties all of those source tables together.

Describe alternatives you've considered

No response

Are you interested in contributing this feature?

  • Yes.
  • Yes, but I will need assistance and will schedule time during your office hours for guidance.
  • No.

Anything else?

No response

[Investigation] Possible fanout in `int_stripe__account_daily` when using connected accounts

What to investigate

This was discovered from an investigation from error query exceeded resource limits in int_stripe__account_daily.

Upon review, this join does not join on some sort of account_id or connected_account_id. For typical cases where only one account is in use, this is no issue, however if a user is using connected accounts, this would cause a fanout since the same balance_transaction would be repeated for every account. Also, this fanout could be what is causing resource issues.

Because of internal data limitations, there is uncertainty on how to correctly address this. Ideally we want to review data from a user with connected accounts. (If that's you and would like to help us, please let us know in this thread!)

Possible Solution

For model int_stripe__account_daily, in my initial investigation I thought to update the CTE daily_account_balance_transactions with a filter like:

...
    from date_spine
    left join balance_transaction
        on cast(balance_transaction.date as date) = date_spine.date_day
        and balance_transaction.source_relation = date_spine.source_relation
        and balance_transaction.connected_account_id = 
            case when balance_transaction.connected_account_id is not null
                then date_spine.account_id
                else null end -- necessary for cases where an account is not a connected account. We don't want to erroneously filter transactions out.
    group by 1,2,3

However the issue is still that we don't have appropriate data to test if this is accurate. Just posting here, so it isn't lost.

Zendesk reference

balance_transaction: "{{ ref('stg_zendesk__balance_transaction) }}"
card: "{{ ref('stg_zendesk__card) }}"
charge: "{{ ref('stg_zendesk__charge) }}"
customer: "{{ ref('stg_zendesk__customer) }}"
fee: "{{ ref('stg_zendesk__fee) }}"
invoice: "{{ ref('stg_zendesk__invoice) }}"
invoice_line_item: "{{ ref('stg_zendesk__invoice_line_item) }}"
payment_intent: "{{ ref('stg_zendesk__payment_intent) }}"
payment_method_card: "{{ ref('stg_zendesk__payment_method_card) }}"
payment_method: "{{ ref('stg_zendesk__payment_method) }}"
payout: "{{ ref('stg_zendesk__payout) }}"
plan: "{{ ref('stg_zendesk__plan) }}"
refund: "{{ ref('stg_zendesk__refund) }}"
subscription: "{{ ref('stg_zendesk__subscription) }}"

Could this be correct referencing zendesk inside dbt_stripe repo?

BUG - subscription_id should be leveraged from Invoice, not Invoice_Lines

Are you a current Fivetran customer?

Fivetran created Bug

Describe the bug

A customer noted in a dbt Slack thread that the subscription_id we leverage within the stripe__subscription_details model is not completely accurate and we should instead use the subscription_id within the Invoice table. After looking through the Connector Release Notes it is clear that the subscription_id has been added to the Invoice table and should be leveraged here instead of the Invoice_Line table.

When the subscription_id from the Invoice_Line table is used, there leaves room for empty aggregates in the final models. This update will resolve that. Additionally, the subscription_id is not included in the staging model for Invoice. So an update to the source package will be needed as well.

Expected behavior

There are no empty aggregates when a customer runs the package and inspects the final stripe__subscription_details model.

BUG - `most_recent_sale_date` using wrong aggregation

Are you a current Fivetran customer?

Fivetran created Bug

Describe the bug

The calculation for most_recent_sale_date is currently using a min aggregation. However, it should instead be max.

min(case when type in ('charge', 'payment')
then {{ date_timezone('created_at') }}
else null
end) as most_recent_sale_date

Expected behavior

The most_recent_sale_date should be the max date.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.