# Description
Minor Changes:
* Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry.
* Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry.
* Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry.
Main Changes:
* New fields and re-order existing ones on `int_core__booking_to_service`.
* Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table.
New Model:
* First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation.
* This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side.
* This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected.
# 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
Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version.
Changes:
* Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models.
* Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f).
* Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking)
# 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
- [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh**
Related work items: #20809
# Description
Removes Address Validation within DWH.
Note that I keep the 2 reporting fields, nullified. These should be removed after the removal of these fields in PBI.
# Checklist
- [X] 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: #23976
# Description
Removes other_sharing_platform_url field that will disappear from the backend in the release going out next week.
Apparently there's a dependency with a PBI report that uses core__unified_user table, so I just nullified the reporting field. The report is called users_dashboard, which AFAIK is not published anywhere. I wonder if this is one of the it-should-not-exist report. Waiting for tomorrow confirmation with Pablo.
Important note: Since this removes fields from staging, which is incremental, we need to trigger a full-refresh for this table. Otherwise execution will fail.
# Checklist
- [X] 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
- [X] Check if a full-refresh is required after this PR is merged. **Yes, please refer to my previous comment.**
Related work items: #23974
# Description
Modelises 2 new tables into staging:
* BookingView
* BookingViewToService
Ideally, we need the contents of BookingToService. This does not exist, so we will need to modelise it in intermediate. Current relationship is that 1) we know services applied to a booking view id (BookingViewToService ) 2) we know booking view id how it relates to booking (BookingView) 3) we can retrieve booking info as usual (Booking, etc)
# 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: #23996
# Description
Changes data type of dates and timestamps of relevant fields in stg_hubspot__deals
# 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.
- [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: #22689
# Description
This PR aims to remove custom pricing/protection fields for New Pricing.
After discussing with Clay, custom pricing/protected amounts are not allowed in New Pricing. This user-specific changes might be applied in the form of discounts, but these are not defined/implemented yet.
There were some fields created in the New Pricing tables that were considering the custom possibility, and Gus confirm that these will come as Null. So I prefer to delete them now, have clean code, and if in X months dev team wants to remove these, we should be good.
# 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.
- [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: #20809
# Description
Creation on stg_hubspot__form_submissions 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.
- [ ] 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.
Stg Hubspot form_submissions
# Description
Creation on stg_hubspot__contacts 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.
- [ ] 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.
staging Hubspot contacts
# Description
This PR creates 3 new models in staging:
- `stg_core__protection_plan`: main information of a protection plan. Here I denormalise the info coming from Protection, meaning, Protection is not a standalone model.
- `stg_core__protection_plan_to_price`: How much does a protection service cost? It's very similar to the model product_service_to_price.
- `stg_core__protection_plan_cover`: How much does a protection service protects, i.e., covers? I took the liberty of modifying the original name since it was confusing to me. Let me know if you'd like to modify the name.
# 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
This PR integrates into staging the following Core tables, regarding New Pricing:
- ProductService
- ProductServiceToPrice
- AppliedProductService (IT HAS BEEN REMOVED)
Models are also documented in staging. Tables contain data already but not necessarily records for New Dash, since still we have not had any paid service applied into a booking / V2 has not been launched yet.
New Dash modelisation for V2 will follow once these tables exist in staging, in order to be able to report 1) revenue and 2) services selected.
# 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. **N/A, few records so not a big deal. Might need to change in the future.**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #20809
# 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
