data-dwh-dbt-project/models/intermediate/cross/int_booking_summary.sql

177 lines
5.7 KiB
MySQL
Raw Normal View History

{{ config(materialized="table", unique_key=["id_booking"]) }}
with
int_core__booking_to_service as (
select * from {{ ref("int_core__booking_to_service") }}
),
int_core__booking_service_detail as (
select * from {{ ref("int_core__booking_service_detail") }}
)
select
bts.id_booking,
bts.id_verification_request,
bts.id_accommodation,
bts.id_user_product_bundle,
bts.id_deal,
bts.id_user_host,
bts.id_user_guest,
bts.booking_status,
bts.program_name,
bts.booking_created_at_utc,
bts.booking_created_date_utc,
bts.booking_updated_at_utc,
bts.booking_updated_date_utc,
bts.booking_check_in_at_utc,
bts.booking_check_in_date_utc,
bts.booking_check_out_at_utc,
bts.booking_check_out_date_utc,
bts.booking_number_of_nights,
bts.host_currency_code,
bts.is_user_in_new_dash,
bts.new_dash_version,
bts.user_in_new_dash_since_timestamp_at_utc,
sum(bsd.service_total_price_in_gbp) as booking_total_price_in_gbp,
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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
2024-11-26 10:14:37 +00:00
min(bsd.service_first_chargeable_date_utc) as service_first_chargeable_date_utc,
max(bsd.service_last_chargeable_date_utc) as service_last_chargeable_date_utc,
min(bsd.service_first_billable_date_utc) as service_first_billable_date_utc,
max(bsd.service_last_billable_date_utc) as service_last_billable_date_utc,
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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
2024-11-26 10:14:37 +00:00
min(bsd.service_detail_created_at_utc) as service_first_created_at_utc,
max(bsd.service_detail_created_at_utc) as service_last_created_at_utc,
max(bsd.service_detail_updated_at_utc) as service_last_updated_at_utc,
count(distinct bsd.id_booking_service_detail) as number_of_applied_services,
count(
distinct case
when bsd.is_paid_service then bsd.id_booking_service_detail else null
end
) as number_of_applied_paid_services,
count(
distinct case
when bsd.is_upgraded_service then bsd.id_booking_service_detail else null
end
) as number_of_applied_upgraded_services,
count(
distinct case
when bsd.is_billable_service then bsd.id_booking_service_detail else null
end
) as number_of_applied_billable_services,
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # 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
2024-11-22 13:50:30 +00:00
case
when
sum(bsd.service_total_price_in_gbp) > 0
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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
2024-11-26 10:14:37 +00:00
and min(bsd.service_first_chargeable_date_utc) is not null
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # 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
2024-11-22 13:50:30 +00:00
then true
else false
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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
2024-11-26 10:14:37 +00:00
end as is_booking_chargeable,
case
when
sum(
case
when bsd.is_billable_service
then bsd.service_total_price_in_gbp
else 0
end
)
> 0
and min(bsd.service_first_billable_date_utc) is not null
then true
else false
end as is_booking_billable,
case
when sum(case when bsd.is_missing_currency_code then 1 else 0 end) > 0
then true
else false
end as is_missing_currency_code_in_service_detail,
case
when sum(case when bsd.is_booking_cancelled then 1 else 0 end) > 0
then true
else false
end as is_booking_cancelled,
2025-02-19 16:37:40 +01:00
case
when bts.id_verification_request is null then false else true
end as has_verification_request,
case
when sum(case when bsd.is_paid_service then 1 else 0 end) > 0
then true
else false
end as has_paid_services,
case
when sum(case when bsd.is_upgraded_service then 1 else 0 end) > 0
then true
else false
end as has_upgraded_services,
case
when sum(case when bsd.is_billable_service then 1 else 0 end) > 0
then true
else false
end as has_billable_services,
case
when
sum(case when bsd.service_business_type = 'SCREENING' then 1 else 0 end) > 0
then true
else false
end as has_screening_service_business_type,
2025-04-08 12:09:08 +02:00
case
when
sum(
case
when
bsd.service_business_type = 'SCREENING'
and bsd.service_name <> {{ var("default_service") }}
then 1
else 0
end
)
> 0
then true
else false
end as has_upgraded_screening_service_business_type,
case
when
sum(
case
when bsd.service_business_type = 'DEPOSIT_MANAGEMENT' then 1 else 0
end
)
> 0
then true
else false
end as has_deposit_management_service_business_type,
case
when
sum(case when bsd.service_business_type = 'PROTECTION' then 1 else 0 end)
> 0
then true
else false
end as has_protection_service_business_type,
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # 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
2024-11-22 13:50:30 +00:00
bts.is_missing_id_deal,
case
when bts.host_currency_code is null then true else false
end as is_missing_host_currency_code
from int_core__booking_to_service bts
inner join
int_core__booking_service_detail bsd
on bts.id_booking_service_detail = bsd.id_booking_service_detail
group by
bts.id_booking,
bts.id_verification_request,
bts.id_accommodation,
bts.id_user_product_bundle,
bts.id_deal,
bts.id_user_host,
bts.id_user_guest,
bts.booking_status,
bts.program_name,
bts.booking_created_at_utc,
bts.booking_created_date_utc,
bts.booking_updated_at_utc,
bts.booking_updated_date_utc,
bts.booking_check_in_at_utc,
bts.booking_check_in_date_utc,
bts.booking_check_out_at_utc,
bts.booking_check_out_date_utc,
bts.booking_number_of_nights,
bts.host_currency_code,
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # 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
2024-11-22 13:50:30 +00:00
bts.is_missing_id_deal,
bts.is_user_in_new_dash,
bts.new_dash_version,
bts.user_in_new_dash_since_timestamp_at_utc