DECISIONLOG re: null converted amounts

CHANGELOG.md

@@ -11,6 +11,8 @@
   - item_id
   - transaction_number
 
+## 📝 Documentation Update 📝
+- [Updated DECISIONLOG](https://github.com/fivetran/dbt_netsuite/blob/main/DECISIONLOG.md#why-converted-transaction-amounts-are-null-if-they-are-non-posting) with our reasoning for why we don't bring in future-facing transactions and leave the `converted_amount` in transaction details empty. ([#115](https://github.com/fivetran/dbt_netsuite/issues/115))
 ## Contributors:
 - [@FrankTub](https://github.com/FrankTub) ([#114](https://github.com/fivetran/dbt_netsuite/issues/114))
 

DECISIONLOG.md

@@ -8,4 +8,12 @@ In the `int_netsuite__transactions_with_converted_amounts` model, account types
 
 ## Creation of 'Other' Account Category for Non Posting and Statistical Account Types
 
-As mentioned above, in the `int_netsuite__transactions_with_converted_amounts`/`int_netsuite2_tran_with_converted_amounts` models, account types are bucketed into broader account _categories_. There is no standard category for `Non Posting` and `Statistical` account types and transactions from these kinds of accounts are excluded from all financial reports. However, they are used for other workflows in Netsuite, so we have bucketed `Non Posting` and `Statistical` account types into a new `Other` account category.
+As mentioned above, in the `int_netsuite__transactions_with_converted_amounts`/`int_netsuite2_tran_with_converted_amounts` models, account types are bucketed into broader account _categories_. There is no standard category for `Non Posting` and `Statistical` account types and transactions from these kinds of accounts are excluded from all financial reports. However, they are used for other workflows in Netsuite, so we have bucketed `Non Posting` and `Statistical` account types into a new `Other` account category.
+
+## Why converted transaction amounts are null if they are non-posting
+
+In our `intermediate` Netsuite models, we translate amounts from posted transactions into their proper `converted_amount` values based on the exchange rates in the reporting and transaction periods. That way, customers will always have accurate `converted_amount` data that can help them validate their financial reporting.
+
+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`.