# Description
Creates a master table for guest products in intermediate. It just gathers information on the name and the latest display name, as well as a couple of additional time fields.
I opted for "latest" rather than "current" because technically Guest Products can be enabled and disabled, and I believe current name would be weird if the product is disabled. Anyway. Next step will be actually creating a master table on guest product configuration, that will handle this disable logic and so on.
# 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: #28513
# Description
After the sync this morning in Core in Airbyte, we have some issues in SH User. This attempts to remove no longer existing fields, namely:
- id_airbnb
- airbnb_url
- platform_comms_recipient
# 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: #28502
# Description
Added booking id to payments model to upgrade payments report
# 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.
Added booking id to payments model
Related work items: #27771
# Description
Changes:
* Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan
* Propagates into booking_service_detail master table. This also computes billable dates.
* Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur.
# 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: #27619
# Description
New Invoice model for S&P
Quite a dense model, it needs to consider some different situations for the different Protection types, verification status and if the user has the `is_protected` flag active for it's bookings.
I leave the documentation for support to better clarify all the possible scenarios and a screenshot of how it is currently looking the model's result.
There are a couple of rename changes on other models, nothing big.
If there are any inquiries let me know.
https://www.notion.so/knowyourguest-superhog/Invoice-Screen-Protect-1610446ff9c980f88de6d6293b4fab03?pvs=4
# 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: #25360
# Description
Changes:
* Creation of a deal-based model that contains when a "deal has appeared in new dash". This is tricky because a Deal can still have multiple users, thus it needs to be attributed to a date. I've chosen the first user appearance for the rest of the metrics.
* Adaptation of dimension deals in KPIs to include a client type, that indicates if the deal is from APIs or not (Platform, i.e., Dashboard).
* Xero metrics by Business Scope. This is the previous "dash source" that I need to change in the previously worked models. I decided to include APIs in the segmentation since in most cases we distinguish old dash from new dash by just "anything that is not in new dash". This is very wrong for invoicing metrics, in which we have APIs. So this actually properly computes a client segmentation by scope.
Note that I'll need to handle the monthly/mtd metrics/agg for these 2 metric models (Resolutions + Invoiced revenue) separately.
# 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: #27356
