# Description
Adding new claim NewDashVersion as an indicator for User Host
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #23457
# Description
Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic.
If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc)
If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash.
The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY**
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Changes claims and logic to consider user is in new dash. Downstream propagation included
Related work items: #23457
# Description
This PR originally started with the intent of modifying the applicable logic for waivers where the host takes the risk (in order to follow the [current state of this specification](https://www.notion.so/knowyourguest-superhog/Guest-Services-Taxes-How-to-calculate-a5ab4c049d61427fafab669dbbffb3a2?pvs=4)).
The verification payments model was quite convoluted already: adding this logic was turning it into an unmanageable ball of hair. So I broke the rules and refactored in the same PR. The end result is that:
- The model implementation has changed quite a bit.
- Behavior for everything but host-takes-risk waivers should remain unchanged.
- Behaviour for host-takes-risk waivers should have changed.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20043
# Description
Sets up warning for KPIs models that will be deprecated, which are:
* 13 in core
* 2 in xero
* 5 in cross
I will keep alive the cross models that handle the final aggregations for Main KPIs for the time being, as well as the newly created Churn model that has a dependency on the monthly by deal to be filled into the mtd flow. I think handling exposure logic for Main KPIs could be a separated migration.
In other words, this is already quite a bit to migrate.
# Checklist
**I just checked that dbt compiles correctly**
- [NA] The edited models and dependants run properly with production data.
- [NA] The edited models are sufficiently documented.
- [NA] The edited models contain PK tests, and I've ran and passed them.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #23268
# Description
Decoms verification payments v1 version, and keeps v2 alive. The PBI of Guest Payments (Biz Overview) was already switched to V2 but the exposures was not reflecting it, so I changed this. Then I dropped all v1 models for verification payments and their entries in schema.
# Checklist
- [X] The edited models and dependants run properly with production data. I did run the upstream dependencies on V2 and I don't see orphans in my dbt docs. However I did not fully run end-to-end all models up to PBI reports since there's other sources involved (Xero, etc).
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #22611
# Description
Moves from intermediate/core to intermediate/cross the following models:
- `int_core__mtd_deal_lifecycle`
- `int_core__mtd_deal_metrics`
to their equivalents:
- `int_mtd_deal_lifecycle`
- `int_mtd_deal_metrics`
This also changes the schema entries, from core to cross, including changing the name of the model in the entry.
This also changes the dependencies, namely in `int_mtd_deal_metrics`, `int_mtd_vs_previous_year_metrics` and `int_monthly_aggregated_metrics_history_by_deal`.
This does NOT aim to alter the logic of the lifecycle in any case; it will be done in a separated PR.
Runs correctly end-to-end. We might need to drop the old models from production manually.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #22689
# Description
Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume:
* if a modification of the amount covered by a protection plan will create a new protection plan id, or not
* if a modification of the price a protection costs will create a new protection plan id, or not
So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover).
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20809
# Description
Adds int_core__product_service_to_price.
This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not.
Currently it's a view since it has 16 records, likely it can be transformed into a table in the future.
The idea will be to create a similar table for protection_plan.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20809
# Description
Quick fix to make lower_limit_migration_date_utc more robust for new dash reporting purposes. I noticed some cases in which users were actually created after the migration date. In these cases, I just keep joined date.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #22331
# Description
This PR adds a new table named `user_product_bundle_contains_services` in intermediate core.
Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained.
For example:
`id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot:
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested*
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20809
# Description
Activates a commented out test for verification payments v2. The test was deactivated because of some master data issues in the backend, but they were fixed after #22148.
# Checklist
- [NA] The edited models and dependants run properly with production data.
- [NA ] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20043
# Description
This PR modifies the V2 of `int_core__verification_payments` to make sure that taxes are not computed for waivers where the host takes the risk (in line with our guest taxes guidelines: https://www.notion.so/knowyourguest-superhog/Guest-Services-Taxes-How-to-calculate-a5ab4c049d61427fafab669dbbffb3a2?pvs=4#323e230365ed496cad6a65b5659895ea).
The PR changes the intermediate column `is_service_subject_to_vat`, making it `false` in the cases where there was no active payaway plan during the month where the payment was generated. This cascades in the main body of the model, because if `is_service_subject_to_vat` is `false`, then the tax amounts get turned into zero.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
add logic
Related work items: #20043
# Description
Update mtd_aggregated_metrics guest payments to be tax-exclusive
# Checklist
- [x] The edited models and dependants run properly with production data.
- [x] The edited models are sufficiently documented.
- [x] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Update mtd_aggregated_metrics guest payments to be tax-exclusive
Related work items: #20045
# Description
This PR propagates tax exclusive check in hero payments for the reporting of Check in Hero.
Additionally, it keeps propagating the amounts with tax inclusiveness in case, at some point, we need them. These are with the new naming convention.
In order not to break anything, the previous amounts are duplicated and aliased in reporting.
Lastly, I spent some time adding some clarifications and documenting payments set to currency and the dependant used for check in hero.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20046
# Description
Fixing logic to ensure priority selection of claims when user satisfies multiple claim conditions.
It adds a new parameter that forcefully prioritises the selection of the date value for a certain claim over the others. If the value is repeated among claims, it will select the earliest date.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20773
# Description
This PR fixes the New Dash migration issue that happened on September 10th 2024. In this migration, users were directly assigned the claim of KygMvp that does not contain a date value. We were using a default hardcode of the first MVP migration, thus in DWH all users have been considered to be migrated late July instead of splitting the first 22 in late July and the ~200 others in September.
The issue lies in the fact that users have configured a ProductBundle and can have Bookings with ProductBundle BEFORE the migration date, which greatly breaks the logic of a migration monitoring.
Changes:
* New migration phase added based on the claim MvpMigratedUser, that Ben created on Friday 13th
* Adaptation of the code in int_core__user_migration to detect if the claim_value (a text field) has a date or not. If so, use that date as long as it's equal or greater than the deployment date, if not use the deployment date. If the claim does not contain a date, use the deployment date (this is the case for the first true 22 migrated users)
I checked that volumes now look correct with this fix.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20773
