# Description
Ensures Resolutions Payouts (in amount paid) is timely
# 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.
Same freshness in MTD and YTD/target for Resolutions Payouts
Related work items: #28560
# Description
I noticed this morning that after the name changes some exclusions have been messed up.
I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic.
I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month.
# 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. **Logic is common among YTD and MTD models. At some moment this can be improved**
- [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: #28560
# Description
There's misalignment in the different areas in the business, but even within our own report...
**I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side.
Changes:
* Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary.
* Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost.
* Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD.
Additional Changes:
* Tests are also aligned with new names.
* Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird.
# 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: #28560
# Description
Changes:
* Creates Booking Fees in YTD/MTD
* Creates Booking Fees per Billable Booking in YTD/MTD. This is exposed forward.
* Removes code for Onboarding MRR in YTD/MTD.
Additional fixes:
* Small mistake - Revenue Churn is now considered as NEGATIVE
# 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: #28560
# Description
Main Changes:
* Computes the total booking fees in `int_kpis__metric_daily_invoiced_revenue`
* Propagates within KPIs, including schema and tests
* Propagates within cross in both "by deal" and "by dimension/global"
* Propagates to main kpis tests
Small fix:
* In `int_mtd_vs_previous_year_metrics`, manual formatting because sqlfmt is broken on this 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: #28560
# Description
Main changes:
* Modifies target seeds to include FY2025 and FY2026. This includes now absolute values for equivalent rate metrics. This also includes Booking Fees per Billable Booking, despite this metric is still not computed. This will be done in a separated PR.
* Removes Onboarding MRR as this requirement is no longer needed, and there has not been any target computed for this metric. This is modified to include Revenue Churn as an absolute figure.
Small note. Targets for FY 2025 rely on the actuals from Finance. Up to January 2025 included, these should match with our YTD values, but it's not the case due to small differences in Billable Bookings / Deals; as well as accrued revenue. Accrued revenue is very troublesome specially on Guesty side, since this affects Total Revenue, and this affects also Resolutions Payout Rate, 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: #28560
# Description
Filtered test accounts according to `Account_type` in Cosmos
Unfortunately this doesn't actually filter all test accounts, there are some that are correctly classified and I will have to ask specifically to either remove or classify correctly
# 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.
Filtered test accounts
Related work items: #28239
# Description
Added `id_deal` to edeposit models for Invoice reporting
# 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
- [x] Check if a full-refresh is required after this PR is merged.
Adding id_deal
Related work items: #28239
# Description
Adding `id_deal` to API models in Check in Cover and Screen & Protect
# 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: #28239
# Description
This fixes the duplication error when the same deal has more than one contact. Impact was not massive, it just affected because of the Home to Host account and this has happened during the past week. There were other cases that contained duplicates but these were not invoiced so it didn't affect the total sum.
Changes:
* Contacts now has a boolean field indicating if a deal exists.
* Contacts now has a boolean field indicating if that contact has a deal informed and it's the last updated one. This is opinionated - it could have been done with creation, for instance.
* Sales monthly trends forces the last updated contact to be true.
* Improved robustness by adding tests.
Note that modifying the logic in intermediate on `int_xero__sales_monthly_trends` by changing `id_deal` per `id_contact` would not have worked - we need to do this compute by deal to ensure that any invoicing is reported MoM and YTD.
# 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: #28576
