dbt_netsuite v0.13.0 release #117
Conversation
Adding entity key to enable downstream processing
Added some of the transaction line booleans to allow downstream filtering
…ounts DECISIONLOG re: null converted amounts
Feature/performance improvements
Feature/performance improvements
DECISIONLOG.md
Outdated
| For the sake of financial fidelity, we decided not to convert amounts that are non-posting because the exchange rates are subject to change. While that can provide additional value for customers looking to do financial forecasting, we do not want to create confusion by bringing in converted transactions that have amounts that are variable to change, and disrupt existing financial reporting processes. | ||
|
|
||
| For customers interested in creating future-facing `converted_amount` values, our recommendation would be to materialize the `intermediate` tables to grab the exchange rate data in your internal warehouse, then leverage the `transaction_amount` in these particular cases to produce the future `converted_amounts`. |
There was a problem hiding this comment.
"our recommendation would be to materialize the
intermediatetables"
Are these currently ephemeral by default and we are suggesting customers materialize them as tables or views? if so, i'd update this wording to be "our recommendation would be to materialize the intermediate models as views or tables (they are currently ephemeral by default)..."
or better yet, it could be good to provide the dbt_project.yml code snippet for how to do so ^
There was a problem hiding this comment.
@fivetran-avinash Could you take a look at Jamie's comment since this is related to your PR?
There was a problem hiding this comment.
Thanks @fivetran-jamie! I agree with your suggestions.
The code snippet they would want to update in the dbt_project.yml would be underneath models, so something like:
For customers interested in creating future-facing
converted_amountvalues, our recommendation would be to materialize theintermediatetables to grab the exchange rate data in your internal warehouse, then leverage thetransaction_amountin these particular cases to produce the futureconverted_amounts. You can update the models section of yourdbt_project.ymlto update the materialization.netsuite2: intermediate: +materialized: [table or view]
Should suffice to add in the DECISIONLOG.
packages.yml
Outdated
| version: [">=0.9.0", "<0.10.0"] | ||
| # - package: fivetran/netsuite_source | ||
| # version: [">=0.10.0", "<0.11.0"] | ||
| - git: https://github.com/fivetran/dbt_netsuite_source.git |
There was a problem hiding this comment.
reminder to update before merging
There was a problem hiding this comment.
Thanks for the review @fivetran-jamie! Please see my updates.
DECISIONLOG.md
Outdated
| For the sake of financial fidelity, we decided not to convert amounts that are non-posting because the exchange rates are subject to change. While that can provide additional value for customers looking to do financial forecasting, we do not want to create confusion by bringing in converted transactions that have amounts that are variable to change, and disrupt existing financial reporting processes. | ||
|
|
||
| For customers interested in creating future-facing `converted_amount` values, our recommendation would be to materialize the `intermediate` tables to grab the exchange rate data in your internal warehouse, then leverage the `transaction_amount` in these particular cases to produce the future `converted_amounts`. |
Co-authored-by: Jamie Rodriguez <[email protected]>
Release branch containing: