94 lines
3.5 KiB
YAML
94 lines
3.5 KiB
YAML
|
version: 2
|
||
|
|
|
||
|
|
models:
|
||
|
|
- name: int_core__duplicate_bookings
|
||
|
|
description: |
|
||
|
|
A list of bookings which are considered duplicates of other bookings.
|
||
|
|
|
||
|
|
We currently consider two bookings to be duplicate if they have the same:
|
||
|
|
- Guest user id
|
||
|
|
- Accomodation id
|
||
|
|
- Check-in date
|
||
|
|
|
||
|
|
Bear in mind these bookings do have different booking ids.
|
||
|
|
|
||
|
|
Out of a duplicated tuple of 2 or more bookings:
|
||
|
|
- Our logic will consider the oldest one to be the "original", not duplicate one.
|
||
|
|
- This table will contain only the duplicates, and not the original.
|
||
|
|
columns:
|
||
|
|
- name: id_booking
|
||
|
|
data_type: bigint
|
||
|
|
description: The unique, Superhog generated id for this booking.
|
||
|
|
|
||
|
|
- name: is_duplicate_booking
|
||
|
|
data_type: boolean
|
||
|
|
description: |
|
||
|
|
True if the booking is duplicate.
|
||
|
|
|
||
|
|
If you are thinking that this is redundant, you are right. All
|
||
|
|
records in this table will be true. But we keep this field to
|
||
|
|
make your life easier when joining with other tables.
|
||
|
|
|
||
|
|
- name: is_duplicating_booking_with_id
|
||
|
|
data_type: bigint
|
||
|
|
description: |
|
||
|
|
|
||
|
|
Indicates what's the original booking being duplicated.
|
||
|
|
|
||
|
|
If there is a tuple of duplicate bookings {A, B, C}, where A is the
|
||
|
|
original and the others are the duplicates:
|
||
|
|
- B and C will appear in this table, A will not.
|
||
|
|
- The value of this field for both B and C will be A's id.
|
||
|
|
|
||
|
|
- name: int_core__booking_charge_events
|
||
|
|
description: |
|
||
|
|
|
||
|
|
Booking charge events is a fancy word for saying: a booking happened,
|
||
|
|
the related host had a booking fee set up at the right time, hence we
|
||
|
|
need to charge him.
|
||
|
|
|
||
|
|
The table contains one record per booking and shows the associated
|
||
|
|
booking fee, as well as the point in time in which the charge event was
|
||
|
|
considered.
|
||
|
|
|
||
|
|
Be wary of the booking fees: they don't have an associated currency.
|
||
|
|
Crazy, I know, but we currently don't store that information in the
|
||
|
|
backend.
|
||
|
|
|
||
|
|
As for the charge dates: the exact point in time at which we consider
|
||
|
|
that we should be charging a fee depends on billing details of the host
|
||
|
|
customer. For some bookings, this will be the check-in. For others, its
|
||
|
|
when the guest begins the verification process.
|
||
|
|
|
||
|
|
Not all bookings appear here since we don't charge a fee for all
|
||
|
|
bookings.
|
||
|
|
|
||
|
|
columns:
|
||
|
|
- name: id_booking
|
||
|
|
data_type: bigint
|
||
|
|
description: The unique, Superhog generated id for this booking.
|
||
|
|
|
||
|
|
- name: id_price_plan
|
||
|
|
data_type: bigint
|
||
|
|
description: The id of the price plan that relates to this booking.
|
||
|
|
|
||
|
|
- name: booking_fee_local
|
||
|
|
data_type: numeric
|
||
|
|
description: The fee to apply to the booking, in host currency.
|
||
|
|
|
||
|
|
- name: booking_fee_charge_at_utc
|
||
|
|
data_type: timestamp without time zone
|
||
|
|
description: |
|
||
|
|
The point in time in which the booking should be invoiced.
|
||
|
|
|
||
|
|
This could be the check-in date of the booking or the date in which the guest verification
|
||
|
|
started, depending on the billing settings of the host.
|
||
|
|
|
||
|
|
- name: booking_fee_charge_date_utc
|
||
|
|
data_type: date
|
||
|
|
description: |
|
||
|
|
The date in which the booking should be invoiced.
|
||
|
|
|
||
|
|
This could be the check-in date of the booking or the date in which the guest verification
|
||
|
|
started, depending on the billing settings of the host.
|