Sisense Community logo
    • Community Feedback
    • Chapters
    • Events
    • Forums
      • Help and How To
      • Product Feedback Forum
      • Strategy & Use Cases
    • Blogs
    • KB Docs
      • KB Docs
      • Add-Ons & Plug-Ins
      • APIs
      • Best Practices
      • Blox
      • CDT
      • Cloud Managed Service
      • Data Models
      • Data Sources
      • Embedding Analytics
      • How-Tos & FAQs
      • Onboarding
      • PySisense
      • Security
      • Sisense Administration
      • Sisense Intelligence & AI
      • Troubleshooting
      • Widget & Dashboard Scripts
    • Support
    • Learning
      • Sisense Academy: Free Courses and Certifications
      • Official Developer Documentation
      • Official Product Documentation
      • Official Sisense Youtube Channel
      • Sisense Compose SDK Playground
      • Official Sisense Discord
    • Use Case Gallery
    Discussions
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
    •                    
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
    Discussions
    • TagsChevronRightIcon
    conversion
      • How-Tos & FAQsChevronRightIcon

      User Parameters Use Case - Automatic Currency Conversion

                                                               

      User Parameters Use Case - Automatic Currency Conversion This article explains one of the example use cases of User Parameters laid out in  User Parameters - What They Are and What They're For (Example Use Cases) . In addition to connection settings, User  Parameters can also be used in table queries in live models to provide tailored data to end users.  One of the most common uses of this type of parameter is for customizing a formula to achieve an automatic localization, e.g. currency conversion. The idea is to use a parameter to associate each user group to their respective currency, then use the parameter to customize the table query and convert the default currency to users' local currencies.  Depending on your requirements, you can use parameters to store a static exchange rate, or the currency code to allow for dynamic currency conversion. Let's walk through an example of each type of currency conversion. a. Static Conversion For simple static conversion, the values of the parameter should represent the exchange rates of the default currency to users' local currencies. When creating the parameter, be sure to select Custom Live Queries  in the Applicable Areas field, and Number in the Field Type field. Here is how the exchange rate parameter should be defined: Once you've created the user parameter, the next step is to assign a value for each group (or individual user, if needed). Here is an example of user groups and value assignment for the exchange rate parameter, assuming the default currency is US Dollar (USD): Now that the parameter values have been assigned to groups, the final step is to create/modify your table query(ies). Let's take a table called FactPayments in an insurance company's data model as an example. This is the original query of the table: SELECT<br/>     P.CLAIM_KEY<br/>     , P.POLICY_KEY<br/>     , P.PAYMENT_DT_TIME<br/><span>     , CONVERT_TIMEZONE('UTC', '{{TIMEZONE}}', PAYMENT_DT_TIME) AS PAYMENT_DT_TIME_LOCAL<br/>     , DATE_TRUNC('DAY', PAYMENT_DT_TIME_LOCAL) AS PAYMENT_DT_LOCAL</span><br/>     , P.PAIDAMOUNT<br/>     , P.STATUS<br/>     , PO.CUSTOMERID<br/>FROM "INSURANCE_CLAIMS"."PAYMENTS" P<br/>JOIN "INSURANCE_CLAIMS"."POLICIES" PO<br/>ON P."POLICY_KEY" = PO."POLICY_KEY" In this example, the amount of funds paid to customers for their insurance claim is stored in USD in a column called PAIDAMOUNT. To convert the payment amount to users' local currencies, multiply the PAIDAMOUNT column by the value of the user parameter.  To add a parameter to a query, type two curly brackets, then select the parameter from the dropdown menu.  Here is what the conversion formula should look like: <font color="#000000">PAIDAMOUNT * {{EXCHANGE_RATE}}</font> Here is the full, updated query of the FactPayments table: <span>SELECT<br/>     P.CLAIM_KEY<br/>     , P.POLICY_KEY<br/>     , P.PAYMENT_DT_TIME<br/>     , CONVERT_TIMEZONE('UTC', '{{TIMEZONE}}', PAYMENT_DT_TIME) AS PAYMENT_DT_TIME_LOCAL<br/>     , DATE_TRUNC('DAY', PAYMENT_DT_TIME_LOCAL) AS PAYMENT_DT_LOCAL<br/>     , P.PAIDAMOUNT<br/><font color="#993300"><strong>     , {{EXCHANGE_RATE}} AS EXCHANGE_RATE</strong></font><br/><font color="#993300"><strong>     , P.PAIDAMOUNT * {{</strong></font><font color="#993300"><strong>EXCHANGE_RATE</strong></font><font color="#993300"><strong>}} AS PAIDAMOUNT_LOCAL</strong></font><br/>     , P.STATUS<br/>     , PO.CUSTOMERID<br/>FROM "INSURANCE_CLAIMS"."PAYMENTS" P<br/>JOIN "INSURANCE_CLAIMS"."POLICIES" PO<br/>ON P.POLICY_KEY = PO.POLICY_KEY</span> Save the query and repeat the same step for all other tables that require currency conversion. Once completed, republish the model and revisit your dashboard. For this example, here is how the data originally looks with payment amount in USD: Here is how it looks for users in the Japan user group, for which the payment amount is converted with a static exchange rate of 151.7: b. Dynamic Conversion For a more complex conversion where historical exchange rate fluctuations need to be taken into account, a history table of currency exchange rates is required. This data is typically readily available within your organization or can be collected from public sources, such as the IMF . Here's an example of a historical exchange rate table (one date per currency): The values of the parameter should  reflect the IDs of users' local currencies as referenced in the exchange rates history table. In this example, they should correspond to the values in the CURRENCY_CODE field in the history table above. Note that  whitespace is not currently supported in parameter values. Therefore, using the full currency names as values, such as "Japanese Yen," will not be accepted. Here is how the currency code parameter should be defined: Here is an example of user groups and value assignment for the currency code parameter: In the context of the FactPayments table example, to convert the payment amount to users' local currencies using the exchange rate effective on the payment date, add a join in the query with the historical exchange rate table. The join conditions should be set on the currency code and date fields, where the currency code from the history table matches the value of the user parameter. Here is how the join should look like: JOIN "INSURANCE_CLAIMS"."EXCHANGE_RATE" X<br/>ON X.CURRENCY_CODE = '{{CURRENCY_CODE}}'<br/>AND PAYMENT_DT_LOCAL = X.DATE Here is the full, updated query of the FactPayments table: SELECT<br/><span>     </span>P.CLAIM_KEY<br/><span>     </span>, P.POLICY_KEY<br/><span>     </span>, P.PAYMENT_DT_TIME<br/><span>     </span>, CONVERT_TIMEZONE('UTC', '{{TIMEZONE}}', PAYMENT_DT_TIME) AS PAYMENT_DT_TIME_LOCAL<br/><span>     </span>, DATE_TRUNC('DAY', PAYMENT_DT_TIME_LOCAL) AS PAYMENT_DT_LOCAL<br/><span>     </span>, P.PAIDAMOUNT<br/><font color="#993300"><strong>     , X.EXCHANGE_RATE AS EXCHANGE_RATE</strong></font><br/><font color="#993300"><strong>     , P.PAIDAMOUNT * X.EXCHANGE_RATE AS PAIDAMOUNT_LOCAL</strong></font><br/><font color="#993300"><strong>     , '{{CURRENCY_CODE}}' AS CURRENCY_CODE</strong></font><br/><span>     </span>, P.STATUS<br/><span>     </span>, PO.CUSTOMERID<br/>FROM "INSURANCE_CLAIMS"."PAYMENTS" P<br/>JOIN "INSURANCE_CLAIMS"."POLICIES" PO<br/>ON P.POLICY_KEY = PO.POLICY_KEY<br/><font color="#993300"><strong>JOIN "INSURANCE_CLAIMS"."EXCHANGE_RATE" X</strong></font><br/><font color="#993300"><strong>ON X.CURRENCY_CODE = '{{CURRENCY_CODE}}'</strong></font><br/><font color="#993300"><strong>AND PAYMENT_DT_LOCAL = X.DATE</strong></font> Save the query and repeat the same step for all other tables that require currency conversion. Here is how the data originally looks with payment amount in USD: Here is how it looks for users in the Japan user group, for which the payment amount is converted using the USD-JPY exchange rate  applicable on the payment date:

      Tri Anthony
      Tri AnthonyPosted 2 years ago
      0
               
      • How-Tos & FAQsChevronRightIcon

      User Parameters Use Case - Automatic Time Zone Conversion

                                                                       

      User Parameters Use Case - Automatic Time Zone Conversion This article explains one of the example use cases of User Parameters laid out in  User Parameters - What They Are and What They're For (Example Use Cases) . In addition to connection settings, User  Parameters can also be used in table queries in live models to provide tailored data to end users.  One of the most common uses of this type of parameter is for customizing a formula to achieve an automatic localization, e.g. time zone conversion. The idea is to use a parameter to associate each user group to their respective time zone name or UTC offset, then use the parameter to customize the table query and convert the default time zone to users' local time zones. Let's walk through an example of an automatic time zone conversion on a Snowflake live model.  The first step is to create the user parameter. When creating parameters for a query, be sure to select Custom Live Queries  in the Applicable Areas field. Once you've created the user parameter, the next step is to assign a value for each group (or individual user, if needed). For this use case, the value should represent the time zones of the users, either the standardized name or the UTC offset, depending on the database that you use. Snowflake, in particular, has a pre-built time zone conversion function called CONVERT_TIMEZONE  that accepts  IANA standardized time zone names as inputs. This function greatly simplifies the conversion formula because it automatically takes into account daylight saving time/summer time. Below is an example of user groups and value assignment for the time zone parameter. Now that the parameter values have been assigned to groups, the final step is to create/modify your table query(ies). Let's take a table called FactPayments in an insurance company's data model as an example. This is the original query of the table: SELECT<br/>     P.CLAIM_KEY<br/>     , P.POLICY_KEY<br/>     , P.PAYMENT_DT_TIME<br/>     , P.PAIDAMOUNT<br/>     , P.STATUS<br/>     , PO.CUSTOMERID<br/>FROM "INSURANCE_CLAIMS"."PAYMENTS" P<br/>JOIN "INSURANCE_CLAIMS"."POLICIES" PO<br/>ON P."POLICY_KEY" = PO."POLICY_KEY" In this example, payment dates and timestamps are stored in UTC in the PAYMENT_DT_TIME column. To convert the timestamps to users' local timezones, add a new calculated column utilizing Snowflake's CONVERT_TIMEZONE function and the user parameter. To add a parameter to a query, type two curly brackets, then select the parameter from the dropdown menu. Here is how the conversion formula should look like: CONVERT_TIMEZONE(UTC , {{TIMEZONE}}, PAYMENT_DT_TIME) Here is the full, updated query of the FactPayments table: SELECT<br/>     P.CLAIM_KEY<br/>     , P.POLICY_KEY<br/>     , P.PAYMENT_DT_TIME<br/><font color="#993300">     <strong>, CONVERT_TIMEZONE('UTC', '{{TIMEZONE}}', P.PAYMENT_DT_TIME) AS PAYMENT_DT_TIME_LOCAL //Date with timestamp<br/>     , DATE_TRUNC('DAY', PAYMENT_DT_TIME_LOCAL) AS PAYMENT_DT_LOCAL //Date without timestamp</strong></font><br/>     , P.PAIDAMOUNT<br/>     , P.STATUS<br/>     , PO.CUSTOMERID<br/>FROM "INSURANCE_CLAIMS"."PAYMENTS" P<br/>JOIN "INSURANCE_CLAIMS"."POLICIES" PO<br/>ON P.POLICY_KEY = PO.POLICY_KEY Save the query and repeat the same step for all other tables that require time zone conversion. Once completed, republish the model and revisit your dashboard.  For this example, here is how the data originally looks with dates in UTC time zone: Here is how it looks for users in the U.S. Eastern time zone: Note : if your database does not have a pre-built time zone conversion function, you can use UTC offsets as the values of the parameter. For example, for Eastern Standard Time (UTC-5), the value for the parameter should be -5. You can then add the offset to the timestamp in the query using the date manipulation function that your database supports (DATEADD for SQL Server, Snowflake, and Amazon Redshift, DATE_ADD for MySQL, + INTERVAL for PostgreSQL and Oracle ). The limitation of this approach is that it doesn't automatically  account for  daylight saving time.  Therefore, you will need to build logic in the query to handle this aspect (e.g., get the daylight saving period for each time zone, then use a CASE statement to check if each date falls within that period).

      Tri Anthony
      Tri AnthonyPosted 2 years ago
      0