307 lines
21 KiB
Markdown
307 lines
21 KiB
Markdown
|
|
# Data quality assessment: DWH vs. Finance revenue figures
|
|||
|
|
|
|||
|
|
**From 2024-07-22 to 2024-07-24, by Uri**
|
|||
|
|
|
|||
|
|
This page aims to document the differences in Revenue figures observed from Finance point of view vs. DWH point of view. This originates from Suzannah’s request to validate the revenue figures displayed.
|
|||
|
|
|
|||
|
|
# Summary
|
|||
|
|
|
|||
|
|
> Revenue figures are not fully consistent between Data (DWH) side and Finance. Xero-based reporting is generally ok, with some small discrepancies that have minimal impacts and can partially be explained. However, a massive discrepancy on Guest Revenue (Waivers, Deposit Fees, Guest Products) is detected since Data is reporting it with taxes included, while Finance seems to be reporting it without taxes. This generates discrepancies within Data reporting, in the sense that Xero-based reporting/metrics are usually tax exclusive. The issue is communicated on 24th July to all users, waiting for a decision/action on how to proceed next once Pablo & Suzannah are back from holidays.
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
The following sections refer to the investigation carried out by @Oriol (Uri) since July 22nd.
|
|||
|
|
|
|||
|
|
# Finance side
|
|||
|
|
|
|||
|
|
Finance has a file with the different revenue sources, its aggregations and final net revenues. It is divided month by month. After the launch of check-in hero, there’s a new tab since April 2024 to contemplate the Guest Products revenue line, thus information is split in two sheets: from April 2023 to March 2024 and from April 2024 onwards. At the moment of writing this page, the nearest fully completed month was May 2024. The file we’re considering was shared with Uri on 19th July 2024.
|
|||
|
|
|
|||
|
|
On Data team side, please refer to Uri to have access to the file since might not necessarily be of public knowledge, and therefore it won’t be published in this page.
|
|||
|
|
|
|||
|
|
# DWH side
|
|||
|
|
|
|||
|
|
We call “DWH side” anything that is computed in the DWH by the Data team. This means, concretely, the information that is displayed in Business Overview Power Bi application, and other information available in substeps within the DWH. We will further differentiate between “KPIs”, referring to those figures that come from the “Global KPIs view” - meaning `mtd` models vs. what is already shared in the other reports of business overview on Guest Payments, Host Fees and e-deposit. In a nutshell:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
where selected reports in Red were already available before the KPIs, and Green refers to the new data available in the KPIs initiative. Since the KPIs initiative is quite new, we do not discard that there might be inconsistencies between these 2 areas - although, if they exist, they should be minimal.
|
|||
|
|
|
|||
|
|
# First validation - Finance vs. Main KPIs
|
|||
|
|
|
|||
|
|
This first validation was conducted on July 22nd, afternoon. This is important as we’ll see in future steps.
|
|||
|
|
|
|||
|
|
The validation consists of the following steps:
|
|||
|
|
|
|||
|
|
- Retrieve the historical data revenue figures from business KPIs directly from DWH. This data comes from the table `int_mtd_vs_previous_year_metrics` mostly because this one contains more metrics computed than what is displayed at the moment in the reports. See below the query.
|
|||
|
|
- Query here!
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
select
|
|||
|
|
date,
|
|||
|
|
xero_booking_net_fees_in_gbp,
|
|||
|
|
xero_listing_net_fees_in_gbp,
|
|||
|
|
xero_verification_net_fees_in_gbp,
|
|||
|
|
xero_operator_net_fees_in_gbp,
|
|||
|
|
xero_waiver_net_fees_in_gbp,
|
|||
|
|
xero_apis_net_fees_in_gbp,
|
|||
|
|
xero_e_deposit_net_fees_in_gbp,
|
|||
|
|
xero_guesty_net_fees_in_gbp,
|
|||
|
|
xero_host_resolution_amount_paid_in_gbp,
|
|||
|
|
total_guest_revenue_in_gbp,
|
|||
|
|
total_revenue_in_gbp
|
|||
|
|
|
|||
|
|
from intermediate.int_mtd_vs_previous_year_metrics imvpym
|
|||
|
|
where date between '2023-04-30' and '2024-05-31'
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- Export it and copy-paste transposed to the same Excel file as we have from Finance, in a dedicated tab called Data figures (22nd July)
|
|||
|
|
- Make the equivalence of granularities and naming between what is reported from Finance side vs. what we’re reporting on KPIs side from DWH. Find below the equivalence table, to the best of my knowledge.
|
|||
|
|
- Equivalence table
|
|||
|
|
|
|||
|
|
|
|||
|
|
| Common Name | DWH | Finance |
|
|||
|
|
| --- | --- | --- |
|
|||
|
|
| Booking fees | xero_booking_net_fees_in_gbp | Booking fees |
|
|||
|
|
| Listing fees | xero_listing_net_fees_in_gbp | Listing fees |
|
|||
|
|
| Verification fees | xero_verification_net_fees_in_gbp | Verification fees |
|
|||
|
|
| E-deposit fees | xero_e_deposit_net_fees_in_gbp | E-Deposit Fees |
|
|||
|
|
| Guesty | xero_guesty_net_fees_in_gbp | Guesty |
|
|||
|
|
| Damage waivers payments | xero_waiver_net_fees_in_gbp | Damage waiver payments |
|
|||
|
|
| Guest Revenue | total_guest_revenue_in_gbp | Damage Waivers + Deposit Handling + Guest products + Damage waiver payments |
|
|||
|
|
| Operator Revenue | xero_oeprator_net_fees_in_gbp | Booking fees + Listing fees + Verification fees |
|
|||
|
|
| APIs Revenue | xero_apis_net_fees_in_gbp | E-Deposit Fees + Guesty |
|
|||
|
|
| Total Revenue | total_revenue_in_gbp | Damage Waivers + Deposit Handling + Guest products + Damage waiver payments + Booking fees + Listing fees + Verification fees + E-Deposit Fees + Guesty |
|
|||
|
|
- Compute the absolute difference on the figures, Data minus Finance.
|
|||
|
|
- Compute the relative difference on the figures, (Data minus Finance)/Finance %. The result can be seen in the following screenshot
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
**Early conclusions:**
|
|||
|
|
|
|||
|
|
- In May 2024, DWH is not reporting any revenue from Guesty, thus the impact on Guesty value. This also impacts APIs revenue, that only considers e-deposit revenue in May. This also impacts Total Revenue.
|
|||
|
|
- Total Revenue figures are generally higher in DWH side if compared to Finance side, by around ~+5% in 2024.
|
|||
|
|
- The main reason is because Guest Revenue figures are higher than what is reported by Finance, by around ~+15% in 2024. It also seems that the longer in time we go, the greater this discrepancy is.
|
|||
|
|
- A first hypothesis would be the back-fill application of xe.com currency rates, that is automatic for all DWH reporting. This would only impact Guest Revenue, since it’s the only source that is reading from the backend. The rest of metrics would not be impacted by this currency rate. However, the discrepancy is so huge that likely it cannot be the only source of impact.
|
|||
|
|
- In November, December 2023 and January 2024, there’s huge discrepancy in the Verification fees reported. However, these represent a small percentage over the Operator Revenue and therefore Total Revenue
|
|||
|
|
- For the rest of metrics, it looks generally ok, with little to no impact. It seems very sporadic so if we need to check, it will be done with the least priority.
|
|||
|
|
|
|||
|
|
The next sections focus specifically on the first 3 points that are considered as most critical.
|
|||
|
|
|
|||
|
|
## May 2024 - Guesty Revenue
|
|||
|
|
|
|||
|
|
After a short check in the raw data from Xero, it’s clear that there was only one invoice made for Guesty on May 2024 but it has been deleted, without any value assigned into it. The actual May invoice seems to have been done at the end of June.
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
After reporting this subject to Jamie, he acknowledges that what we see in the raw data - and therefore our reporting - is correct. There was some issues on having the reporting on time, thus the Finance number is an estimate for board pack. The real number coincides with what we are going to report on June’s Guesty Revenue from DWH side. Lastly, the DELETED status is probably an error according to Jamie.
|
|||
|
|
|
|||
|
|
This difference is considered as controlled.
|
|||
|
|
|
|||
|
|
## Guest Revenue figures are considerably higher in DWH vs. what we see on Finance
|
|||
|
|
|
|||
|
|
It’s worth stating again that Guest Revenue it’s the only figure that does not come exclusively from Xero. Specifically, for Guest Revenue we’re considering:
|
|||
|
|
|
|||
|
|
- Deposit Fees → Backend
|
|||
|
|
- Checkin Hero Fees → Backend
|
|||
|
|
- Guest Waiver Payments → Backend
|
|||
|
|
- and then we subtract the amount of Waivers paid back to the Host → Xero
|
|||
|
|
|
|||
|
|
It’s worth acknowledging that the line of Damage Waivers Payments is close to no difference since October 2023, so likely the discrepancy comes from how we’re modelising the data coming from the backend or from the backend itself.
|
|||
|
|
|
|||
|
|
We already commented that a partial explanation could be the currency rates integration coming from xe.com, that would have done a complete backfill of revenue figures - thus it could explain a part of the discrepancy. Still, the discrepancy is quite huge for just a day-to-day currency conversion instead of a monthly / hardcoded one.
|
|||
|
|
|
|||
|
|
### DWH 23rd July vs. DWH 22nd July
|
|||
|
|
|
|||
|
|
At this stage, on 23rd July 2024, I conduct a very silly experiment. I’ll re-export the same export that I made yesterday for business KPIs retrieval [Query here!](Data%20quality%20assessment%20DWH%20vs%20Finance%20revenue%20fig%206e3d6b75cdd4463687de899da8aab6fb.md). I will compare this export vs. what I retrieved yesterday, 22nd July 2024, with no additional changes on the query. The main goal is to understand if there’s additional backfill updates on the KPIs that we should be aware of, that potentially could explain these differences. Here’s the result:
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
It’s available in the sheet Data 23rd vs. Data 22nd
|
|||
|
|
|
|||
|
|
In this case we’re seeing absolute differences in GBP. The good news is that for all Xero metrics we have no difference at all. The not so good news is that from one day to another, we lost 100 GBP in April and 79 GBP in May… in mid July 2024.
|
|||
|
|
|
|||
|
|
After debugging this, I discovered that this is because of refunds when the booking is cancelled, which makes tons of sense. See the example below for May 2024 case:
|
|||
|
|
|
|||
|
|
- Query here!
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
select
|
|||
|
|
p.dwh_extracted_at_utc,
|
|||
|
|
p.created_date_utc,
|
|||
|
|
p.paid_date_utc,
|
|||
|
|
p.amount,
|
|||
|
|
p.currency,
|
|||
|
|
p.notes,
|
|||
|
|
ps.payment_status
|
|||
|
|
from
|
|||
|
|
staging.stg_core__payment p
|
|||
|
|
left join staging.stg_core__payment_status ps
|
|||
|
|
on p.id_payment_status = ps.id_payment_status
|
|||
|
|
where date_trunc('month', p.paid_date_utc)::date = '2024-05-01'
|
|||
|
|
order by p.dwh_extracted_at_utc desc
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
The 79 GBP difference can be explained by the first 3 rows, that were extracted between mid afternoon of the 22nd July and the morning on the 23rd. Doing the currency conversion from USD to GBP and adding it up makes it to 79 GBP.
|
|||
|
|
|
|||
|
|
Whenever refunds happen, the status of the payment is no longer PAID, but REFUNDED. Since in KPIs we consider only those that are PAID, it means this is a normal behaviour. Might be interesting to discuss it further in case we want to keep this behaviour (meaning we accept that Revenue figures will likely decrease over time until the booking is over) or if we want to modify it to have more stable yet probably less qualitative data (meaning we do not care about the refunds, or we consider it separately).
|
|||
|
|
|
|||
|
|
Important observation though: the fact that revenue figures in DWH would decrease (a bit) over time, it further enhances the discrepancy that we’re observing between DWH/Finance. Mainly because each day that we full-refresh the history of KPIs, these figures will decrease, and still we are reporting higher Guest Revenue values. Thus, taking a screenshot on the content of the KPIs on the 1st day of a month for the previous month would have even a higher discrepancy vs. Finance.
|
|||
|
|
|
|||
|
|
**Long story short**: good to know, but not what I was looking for, so let’s continue the investigation.
|
|||
|
|
|
|||
|
|
At this stage the easiest is to debug if there’s a specific issue in the computation of the payments coming from the guest, meaning, dividing the guest revenue between Waiver payments, Deposit Fees and Checkin Hero. I’ll take the opportunity and have it already computed at the same level as we have for other Operators revenue metrics.
|
|||
|
|
|
|||
|
|
### Further debugging revenue splits
|
|||
|
|
|
|||
|
|
On 23rd July afternoon, a new deployment has been made available to retrieve the detailed data of guest source of income. So now I proceed to retrieve the data from the DWH with the additional inputs. It’s a modification from the previously shared query, and can be found below:
|
|||
|
|
|
|||
|
|
- Query here!
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
select
|
|||
|
|
date,
|
|||
|
|
xero_booking_net_fees_in_gbp,
|
|||
|
|
xero_listing_net_fees_in_gbp,
|
|||
|
|
xero_verification_net_fees_in_gbp,
|
|||
|
|
xero_operator_net_fees_in_gbp,
|
|||
|
|
xero_waiver_net_fees_in_gbp,
|
|||
|
|
xero_apis_net_fees_in_gbp,
|
|||
|
|
xero_e_deposit_net_fees_in_gbp,
|
|||
|
|
xero_guesty_net_fees_in_gbp,
|
|||
|
|
xero_host_resolution_amount_paid_in_gbp,
|
|||
|
|
total_guest_revenue_in_gbp,
|
|||
|
|
total_revenue_in_gbp,
|
|||
|
|
deposit_fees_in_gbp,
|
|||
|
|
waiver_payments_in_gbp,
|
|||
|
|
checkin_cover_fees_in_gbp,
|
|||
|
|
total_guest_income_in_gbp
|
|||
|
|
|
|||
|
|
from intermediate.int_mtd_vs_previous_year_metrics imvpym
|
|||
|
|
where date between '2023-04-30' and '2024-05-31'
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
|
|||
|
|
I mainly added:
|
|||
|
|
|
|||
|
|
- `deposit_fees_in_gbp`
|
|||
|
|
- `waiver_payments_in_gbp`
|
|||
|
|
- `checkin_cover_fees_in_gbp`
|
|||
|
|
- and an aggregation of the 3 previous values into `total_guest_income_in_gbp`.
|
|||
|
|
|
|||
|
|
At this stage, it’s worth to differentiate between the metrics:
|
|||
|
|
|
|||
|
|
- `total_guest_revenue_in_gbp = deposit_fees_in_gbp + waiver_payments_in_gbp + checkin_cover_fees_in_gbp + xero_waiver_net_fees_in_gbp` (note that this last one corresponds to the amount paid to the host and it’s negative by nature)
|
|||
|
|
- `total_guest_income_in_gbp = deposit_fees_in_gbp + waiver_payments_in_gbp + checkin_cover_fees_in_gbp`
|
|||
|
|
- `total_guest_payments_in_gbp` = any payment effectuated by guests, without enforcing it should come from deposit fee, waiver or checkin cover.
|
|||
|
|
|
|||
|
|
Thus, the new equivalence table (updated) is as follows:
|
|||
|
|
|
|||
|
|
- Updated equivalence table
|
|||
|
|
|
|||
|
|
|
|||
|
|
| Common Name | DWH | Finance |
|
|||
|
|
| --- | --- | --- |
|
|||
|
|
| Booking fees | xero_booking_net_fees_in_gbp | Booking fees |
|
|||
|
|
| Listing fees | xero_listing_net_fees_in_gbp | Listing fees |
|
|||
|
|
| Verification fees | xero_verification_net_fees_in_gbp | Verification fees |
|
|||
|
|
| E-deposit fees | xero_e_deposit_net_fees_in_gbp | E-Deposit Fees |
|
|||
|
|
| Guesty | xero_guesty_net_fees_in_gbp | Guesty |
|
|||
|
|
| Damage waivers payments | xero_waiver_net_fees_in_gbp | Damage waiver payments |
|
|||
|
|
| Guest Revenue | total_guest_revenue_in_gbp | Damage Waivers + Deposit Handling + Guest products + Damage waiver payments |
|
|||
|
|
| Operator Revenue | xero_oeprator_net_fees_in_gbp | Booking fees + Listing fees + Verification fees |
|
|||
|
|
| APIs Revenue | xero_apis_net_fees_in_gbp | E-Deposit Fees + Guesty |
|
|||
|
|
| Total Revenue | total_revenue_in_gbp | Damage Waivers + Deposit Handling + Guest products + Damage waiver payments + Booking fees + Listing fees + Verification fees + E-Deposit Fees + Guesty |
|
|||
|
|
| Waiver income | waiver_payments_in_gbp | Damage Waivers |
|
|||
|
|
| Checkin hero | checkin_cover_fees_in_gbp | Guest Products |
|
|||
|
|
| Deposit fees | deposit_fees_in_gbp | Deposit Handling |
|
|||
|
|
| Guest Income | total_guest_income_in_gbp | Damage Waivers + Deposit Handling + Guest products |
|
|||
|
|
|
|||
|
|
Note that the only difference between Guest Revenue and Guest Income is that we subtract the waiver amount paid back to hosts in Guest Revenue, while we don’t do it for Guest Income. Afterwards, we do first a comparison of this data vs. the one retrieved this morning.
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
This comparison is available in the sheet Data 23rd AFT vs. Data 23rd
|
|||
|
|
|
|||
|
|
So again we have a source of discrepancy on revenue figures coming from Guest Revenue, though these might be potentially linked to the changes made on DWH. At this stage I don’t spend more time on debugging these cases.
|
|||
|
|
|
|||
|
|
Afterwards, we conduct the same comparison strategy as we did yesterday, mainly, these new figures of Data 23rd AFT vs. Finance export.
|
|||
|
|
|
|||
|
|

|
|||
|
|
|
|||
|
|
It’s not clear why this is impacting all guest revenue sources, even on checkin hero that had only 3 payments on May 2024, and the difference is between 28.43 GBP in all Data reports vs. 26.71 GBP in Finance. A possibility could be that for these metrics we’re comparing figures with vs. without taxes, or that indeed the currency rate being used is clearly different.
|
|||
|
|
|
|||
|
|
### Tax inclusive or tax exclusive?
|
|||
|
|
|
|||
|
|
After doing a quick look around on July 24th, I am not able to determine if Payments table - and generally, any amount coming from Superhog backend (what we call internally in Data as Core) - are tax inclusive or not. A message has been posted to senior devs and product team in case someone knows the answer.
|
|||
|
|
|
|||
|
|
Ben Robinson confirms that Payments table has taxes included, thus being the main reason why Guest-related figures have a discrepancy Data vs. Finance. This means that clearly we have a discrepancy on how we’re measuring monetary amounts between different sources (Xero vs. Backend).
|
|||
|
|
|
|||
|
|
Pending confirmation from Jamie on the source of data used for Guest revenue metrics on Finance side, a communication is sent on #data channel on 24th July 2024, 11 AM, informing the users about the issue and the detailed impacts.
|
|||
|
|
|
|||
|
|
- Message sent here
|
|||
|
|
|
|||
|
|
🔥 Important message regarding **revenue & monetary amounts data quality** on Power BI reports 🔥
|
|||
|
|
|
|||
|
|
After aiming to match revenue figures reported from Data side vs. Finance side, **we have detected a discrepancy being caused by tax inclusiveness / exclusiveness**. In a nutshell, Xero-based figures are being reported without taxes while Superhog backend (SH) figures coming from guest payments are being reported with the associated taxes of each country.
|
|||
|
|
|
|||
|
|
🔴 This is generating **incorrect insights** in the areas/metrics that combine both sources, specifically:
|
|||
|
|
|
|||
|
|
- **Business Overview - Guest Payments report**
|
|||
|
|
- Waivers: total waiver amount charged (tax incl.) vs. amount paid back to hosts (tax. excl). The % Paid to Host is also impacted
|
|||
|
|
- **Business Overview - Main KPIs**
|
|||
|
|
- Total Revenue and derived metrics combine both data from SH (Guest Revenue, coming from guest payments) and Xero (Invoiced Operator Revenue, Invoiced APIs Revenue). Also, keep in mind that by nature the different Revenue sources can be inconsistent between them.
|
|||
|
|
|
|||
|
|
We highly recommend NOT taking any decision based on the data displayed on the abovementioned areas.
|
|||
|
|
|
|||
|
|
**🟡 If you're using other reports, data should be consistent within that report/tab**. In a nutshell, keep in mind the following:
|
|||
|
|
|
|||
|
|
- Business overview: The readme and tabs should specify the source of the data, thus SH = tax incl. and Xero = tax excl. Beyond Waivers, tabs should be consistent.
|
|||
|
|
- Accounting reports: These come from Xero, so all should be tax excl.
|
|||
|
|
- Check-in Hero reports: These come from SH, thus data is tax incl.
|
|||
|
|
|
|||
|
|
**We're** **not expecting to provide a solution for this issue anytime soon** as we need Pablo and Suzannah back from holidays to deep-dive into it.
|
|||
|
|
|
|||
|
|
We'll keep you posted in the following days as we have more news on this subject. Sorry for any inconvenience.
|
|||
|
|
|
|||
|
|
|
|||
|
|
From here, we have 2 possibilities:
|
|||
|
|
|
|||
|
|
- All DWH reporting is set to tax inclusive, except on some dedicated areas.
|
|||
|
|
- Pros: feasible, since Xero-based data allows to select tax incl. or tax excl.
|
|||
|
|
- Cons: it can create inconsistencies in the future that we might not be able to understand because we won’t be able always to compare vs. finance data
|
|||
|
|
- All DWH reporting is set to tax exclusive, except on some dedicated areas
|
|||
|
|
- Pros: consistency will be granted across all data reporting and analysis. At the moment, to the best of my knowledge, no tax incl. use-case is present
|
|||
|
|
- Cons: Likely not feasible to do with the data coming from the backend. Maybe Stripe contains this information (I’d guess this is the source of Finance data anyway), but it will require work on Data engineering / tech team side
|
|||
|
|
|
|||
|
|
For the time being, we will live with this issue until Pablo & Suzannah are back from holidays, as I’m not knowledgeable enough on financial subjects.
|
|||
|
|
|
|||
|
|
## Guest Payments and Guest Income showing very similar values
|
|||
|
|
|
|||
|
|
Guest Payments is a metric displayed in the business KPIs dashboard that is defined as follows:
|
|||
|
|
|
|||
|
|
> Total monetary amount of income paid by guests, converted to GBP. All verification payment types are considered (Waiver, Deposit, Fee, Check-in Cover).
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
It’s worth to reinforce that it’s considering a PAID status. On the other side, for Guest Income computation that was created for the purpose of this investigation is exactly the same definition but we enforce to only consider Waiver, Fee and Check-in Cover - meaning we’re excluding Deposit amounts.
|
|||
|
|
|
|||
|
|
Knowing that the deposits generally have a huge monetary amount linked to it, why is it that there’s a very small difference (or no difference at all) between these 2 metrics?
|
|||
|
|
|
|||
|
|
- Query here!
|
|||
|
|
|
|||
|
|
```sql
|
|||
|
|
select
|
|||
|
|
date_trunc('month',payment_paid_date_utc)::date as first_day_month,
|
|||
|
|
verification_payment_type,
|
|||
|
|
payment_status,
|
|||
|
|
count(1) as total_volume,
|
|||
|
|
count(distinct id_payment) as unique_payments,
|
|||
|
|
sum(amount_in_gbp) as amount_in_gbp
|
|||
|
|
from intermediate.int_core__verification_payments icvp
|
|||
|
|
group by 1,2,3
|
|||
|
|
order by 1 desc, 2 asc, 3 asc
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
|
|||
|
|

|