Bugfix/cta-and-historical-rate-changes

[fivetran-joemarkiewicz]

PR Overview

This PR will address the following Issue/Feature: #78 #75

This PR will result in the following new package version: v0.11.0

This will be a breaking change as significant updates are being applied to the code which we would like to be reflected in a major update as opposed to a patch.

Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:

• Adjusted our translation rate logic to calculate converted_amount in netsuite__balance_sheet and netsuite2__balance_sheet.
  • The logic is adjusted so we examine the general_rate_type rather than account_category, as is intended by Netsuite definitions.
  • Historical and average rates now convert amounts into the converted_amount_using_transaction_accounting_period. Otherwise, it looks at converted_amount_using_reporting_month.
  • The is_leftside logic is added to make sure debit values are properly assigned as negative converted values if false and positive if true.
• Modified the Cumulative Translation Adjustment calculation within the netsuite2__balance_sheet model to be built upon referencing that the general_rate_type is either historical or average as opposed to checking that the account_category is equity.
  • This update more accurately reflects the behavior of how the Cumulative Translation Adjustment should be calculated. The equity check was not as robust as had an opportunity to generate an incorrect value.

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• [X] dbt compile
• [X] dbt run –full-refresh
• [X] dbt run
• [X] dbt test
• [n/a] dbt run –vars (if applicable)

Before marking this PR as "ready for review" the following have been applied:

• [X] The appropriate issue has been linked and tagged
• [X] You are assigned to the corresponding issue and this PR
• [X] BuildKite integration tests are passing

Detailed Validation

Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":

• [X] You have validated these changes and assure this PR will address the respective Issue/Feature.
• [X] You are reasonably confident these changes will not impact any other components of this package or any dependent packages.
• [X] You have provided details below around the validation steps performed to gain confidence in these changes.

We were able to validate these changes with our internal data and confirmed the totals matched our expected results.

Standard Updates

Please acknowledge that your PR contains the following standard updates:

• Package versioning has been appropriately indexed in the following locations:
  • [X] indexed within dbt_project.yml
  • [X] indexed within integration_tests/dbt_project.yml
• [X] CHANGELOG has individual entries for each respective change in this PR
• [X] README updates have been applied (if applicable)
• [n/a] DECISIONLOG updates have been updated (if applicable)
• [n/a] Appropriate yml documentation has been added (if applicable)

dbt Docs

Please acknowledge that after the above were all completed the below were applied to your branch:

• [X] docs were regenerated (unless this PR does not include any code or yml updates)

If you had to summarize this PR in an emoji, which would it be?

💵

[fivetran-reneeli]

Looks good, just wanted to know your thoughts if it's worth updating the ymls as well. For example, I think a lot was done under the hood for converted_amount and the balance_transactions overall, but I think the definitions still apply so it might be fine. But also could copy some of the notes from the changelog over?

Though future-looking, if the logic were to change again, now you'd have to update the yml again. So it may be best to keep the more high-level definitions that are in place.

[fivetran-joemarkiewicz]

@fivetran-reneeli great call out on if we should update the docs. Truthfully I agree with you that I would prefer not to update the docs to be hyper specific in case we end up making more modifications in the future. The description of the existing models and fields still hold true with these updates, they just are not hyper specific.

[fivetran-reneeli]

@fivetran-reneeli great call out on if we should update the docs. Truthfully I agree with you that I would prefer not to update the docs to be hyper specific in case we end up making more modifications in the future. The description of the existing models and fields still hold true with these updates, they just are not hyper specific.

Sounds good with me, let's keep the docs broad