# Description
This PR creates a proper Booking Source in `int_core__bookings` table. This mostly refers to ensure that whenever we do data requests tickets on this regards we have a proper logic in place (as last time we had issues because of this). Logic follows Gus recommendation on applying:
```
case
when upper(coalesce(bsrc.booking_source, 'UNKNOWN')) = 'UNKNOWN'
then b.raw_booking_source
else bsrc.booking_source
end
```
where b. is Booking table and bsrc. is Booking Source table.
Things to note:
* A new `stg_core__booking_source` table is created, full-refreshed from the backend (less than 10 records)
* I added a unique test for `stg_core__booking` that was not in there. I don't document the rest of the model though.
* I remove the previous `id_booking_source` as it wasn't used and the logic in place should be far more accurate.
* I do NOT remove the existing `verification_request_booking_source`. I don't remember what's this but I see this is in use specially on Guest Insights (CSAT) and the legacy Truvi reporting (Bookings, PMS, etc.). Not the scope of this ticket to change it.
* I don't do further propagation, but potentially, this could be extended to New Dash Booking Summary as this source is being shown in the dashboard itself.
# 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: #30415
# Description
Change in model `int_core__accommodation_to_product_bundle` to remove effective dates and use original start and end date.
Updated downstream models as well
# 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.
data alert fix
Related work items: #30948
# Description
This PR bumps the `latest_version` value of `int_core__check_in_cover_users` from `1` to `2`, effectively moving the project to the new logic of CIH users.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] 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: #30165
# Description
Now that the Guest Products have been activated, we need to update the project var `guest_products_feature_flag_activation_timestamp` so that the logic based on it throughout the project starts acting properly.
This PR updates the value of the var with the timestamp that Lawrence from the Guest Squad has shared with us.
# 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.
- [ ] 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: #30165
# Description
Model `int_core__vr_check_in_cover` is producing invalid SQL because of a typo: a Jinja `if` block gets created with whitespace trimming, so the output gets concatenated to the previous code without whitespace and the resulting SQL is crap.
This PR changes the if block so it doesn't trim whitespace, hence producing valid SQL and the indended query.
# 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.
- [ ] 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: #30165
# Description
This PR directly removes test accounts, and not just flag them, from:
* `int_core__unified_user`, which means is also propagated to `int_core__user_host`.
It does so by creating a new, extremely simple model named: `int_core__user_test_account`
Then, `int_core__user_host` is inner joined with a small explanation comment on:
* `int_core__accommodation`
* `int_core__unique_accommodation_to_user`
* `int_core__bookings`
* `int_core__verification_requests`
* `int_core__payments`
Effectively removing test accounts.
Lastly, any existence and usage of the column `is_test_account` has been removed -> mostly on New Dash-related models.
# Checklist
**As discussed in the daily, I'll be playing around in prod with this PR**
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] 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: #27319
# Description
Applies the new dedicated source of truth of "is this account fake" based on Claims. This removes the previous logic.
In terms of differences, not much because:
1. New logic applied in the backend is pretty much the same as we had with a few improvements
2. This exclusion is only applied for New Dash. I checked the number of test accounts in New Dash and these are 2, the same ones in the new logic and for the old (currently in production). So no real impact.
Impact will come at the moment to start handling exclusions for KPIs, but this will done later on dedicated PRs to assess impacts properly.
# 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: #27319
# Description
Added unique test for `id_deal` and `id_contact` for `xero_contacts` models.
This should all work after the run
# 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.
id_deal unique test
Related work items: #30809
# Description
This PR adds a new version to `int_core__check_in_cover_users`. The new version respectes the public interface of V1, but changes the strategy to determine which users get included in the list. Instead of relying on their account configuration (v1), v2 simply looks at whether they had any VR created offering CIH in the past 30 days.
This approach changes the semantic of the model, but we deem the new one reasonable.
The motivation behind this change is to ensure this models (1) keeps working after the activation of the Guest Products FF and (2) stays simple. Trying to follow a strategy where we look at both old and new configs was deemed very complex and didn't add much value.
# 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: #30165
# Description
It doesn't look like the multi-user cases per deal are going to be fixed any time soon.
Also, this test was only covering it for newly onboarded deals, while we have more cases for migrated deals that this test was not covering.
# Checklist
- [X] dbt compiles
Related work items: #30479
# Description
Adds a field that helps categorize whether we owe money to an account or they owe money to Truvi.
Outstanding Resolutions or Outstanding Invoices
The idea is to include this field as a filter in the Invoicing & Crediting report to help Finance and Resolutions in the payment and approval process.
# 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.
Outstanding Payments
Related work items: #30204
# Description
This PR moves the categorisation of Bookings with Incidents from the flagging specific model to Booking Summary, effectively keeping this at Booking ID level.
This also handles the direct dependency with the flagging categorisation model.
I also improved the documentation and test coverage on the Booking Summary as it's becoming more and more central to many areas.
# 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: #30676
# Description
This PR prepares the existing `int_core__vr_check_in_cover` model for the activation of the Guest Products feature flag.
It creates a second logic path which identifies VRs that have CIH in them ~~through product bundles~~ through looking at `stg_core__verification_request_to_guest_product `, and unions it with the old stuff.
The new CTE only gets called after the FF gets activated. This is defined in a var that we will need to adjust depending on when do we really activate the FF.
Note that these items are still pending:
- update the var to the right value once Lawrence pulls the trigger.
- clarify what the hell happens with CIH being "pushed" or not to ALL old dash hosts. This PR currently assumes this will NOT happen. If it will happen, we will need to change things.
# 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: #30165
# Description
This PR does the following:
* Moves `core/int_core__booking_summary` to `cross/int_core__booking_summary`
* Renames the model `cross/int_core__booking_summary` to `cross/int_booking_summary`
* Same for schema entry. In the new schema, I just added in the description how to retrieve exclusively New Dash Bookings for usability purposes.
Then, it adapts any dependency on `int_core__booking_summary` to `int_booking_summary`
No additional changes - inclusion of Resolution Incidents data will come later in a different PR.
# 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: #30676
# Description
Reporting version of Stay Disrupt Conversion Funnel. It's just a copy from the intermediate model.
# 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: #30277
# Description
Adds the month equivalent for creation, check in and check out dates for Booking Summary, for reporting purposes
# 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: #30609
# Description
Pulls up the date var in `int_core__guest_product_payments_v2` into the global project (will soon be used in other models).
The name was also changed to something more descriptive for the purpose it will follow in the global project.
# 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: #30165
# Description
First version of Stay Disrupt conversion funnel. It's a simple monthly compute of:
Active accounts -> Accounts that offered SD in GJ started in month -> Accounts that have had payments paid of SD in month
Total Guest Journeys Started -> GJ that offered SD in month-> Payments paid of SD in month
Some details:
* It also includes CIH, and data starts on 1st Jan 2025. This is to create report. This needs to be changed once the report is created.
* Note that Accounts that offered SD in GJ started in month and GJ that offered SD in month is equal to 0 as no data flows through the new flow. The rest has data.
* I consider all users, not only New Dash, knowing that I don't know if someone knows which users will have a certain Guest Product enabled.
Model is "agnostic" to the GP if we want, though the name still aims to be only for SD.
# 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. **View to start with**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #30277
