The CTEs that project currency rates backwards have a few mistakes that introduce additional dates in the period where we do have actual, factual rates. This PR fixes the errors that cause this.
Added verification estimated started at/date utc.
Ensured continuity for existing reports
I also noticed I missed one propagation of the end date, it's fixed here.
Note: changed the naming from 'start' to 'started' since we already had 'completed' and 'used_link'
Related work items: #17268
This PR includes the logic to handle the completed date of guest journey
Check the schema file to understand the logic implemented. It's an estimation, and in some cases, weird stuff happens on end dates before link usage dates, which effectively breaks the computation. I added a boolean for this
Related work items: #17268
This PR aims to provide a first draft for business KPIs, at this stage **quite minimal**.
It mostly contains a MTD and Monthly display approach. No dimensions are created.
The models created are:
- **int_dates_mtd**: mainly it reads from int_dates to retrieve those days needed for a MTD/monthly display
- **int_core__mtd_booking_metrics**: it contains the booking metrics, ending in a format of date|value|value last year|increment
--> here we could add, in the future, additional metrics from other sources (ex: guest journey, etc)
- **int_core__mtd_aggregated_metrics**: it transforms the data coming from the different mtd intermediate sources to be easily displayed in the dashboard. This is a good candidate for macros :)
- **core__mtd_aggregated_metrics**: copy-paste of the its int_core version, including a bit of model documentation
The dashboard is functional but in another PR. I can show you how it looks like at the moment you are going to check the PR
Related work items: #17214
- Ingest the currency table from the backend into DWH.
- Add the newly created `AccountCurrencyId` into the `User` table.
- Push the data to the intermediate user model while replacing the internal superhog currency ID by the ISO4217 code so it's easily joinable with other stuff.
Now, every money amount related to some user in the SQL server backend can be currency-informed instead of currency-less.
