docs and moving stuff

models/intermediate/_int_models.yml

@@ -1,23 +0,0 @@
-
-version: 2
-
-models:
-  - name: int_core__deal_id_master_list
-    description: "The distinct list of Deal Ids present in Core, along with the count of Accounts related to it."
-    columns:
-      - name: id_deal
-        description: "The Deal Id."
-        tests:
-          - unique
-          - not_null
-      - name: users_with_this_id_deal
-        description: "The count of Superhog accounts that have this Deal Id assigned."
-  - name: int_core__unified_user
-    description: "Data for all users after merging User and SuperhogUser."
-    columns:
-      - name: id_user
-        description: "The primary key for this table"
-        tests:
-          - unique
-          - not_null
-

models/intermediate/core/int_core__duplicate_bookings.sql

@@ -17,32 +17,8 @@ with
     )
 select
     db.id_booking,
-    db.id_user_guest,
-    db.id_user_host,
-    db.id_integration,
-    db.id_accommodation,
-    db.id_booking_source,
-    db.id_verification_request,
-    db.id_staging_host_booking,
     db.is_duplicate_booking,
-    b.id_booking as is_duplicating_booking_with_id,
-    bs.booking_state,
-    db.check_in_at_utc,
-    db.check_in_date_utc,
-    db.check_out_at_utc,
-    db.check_out_date_utc,
-    db.summary,
-    db.guest_email,
-    db.guest_last_name,
-    db.guest_first_name,
-    db.guest_telephone,
-    db.additional_guests,
-    db.unsubscribe_verification_reminder,
-    db.created_at_utc,
-    db.created_date_utc,
-    db.updated_at_utc,
-    db.updated_date_utc,
-    db.dwh_extracted_at_utc
+    b.id_booking as is_duplicating_booking_with_id
 from stg_core__booking_with_dup_flag db
 left join stg_core__booking_state bs on db.id_booking_state = bs.id_booking_state
 left join

models/intermediate/core/schema.yaml

@@ -0,0 +1,93 @@
+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.

models/reporting/core/schema.yaml

@@ -18,6 +18,9 @@ models:
       - name: id_payment
         data_type: bigint
         description: Superhog id for this Payment.
+        tests:
+          - unique
+          - not_null
 
       - name: is_refundable
         data_type: boolean
@@ -108,3 +111,70 @@ models:
       - name: notes
         data_type: character varying
         description: Free text description on the payment. Typically, contains explanations for integration issues with the payment processor.
+
+  - name: core__bookings
+    description: |
+
+      Bookings that have been processed by the Superhog backend.
+
+      Each record matches one booking.
+
+      All data is coming from the Superhog backend. Some dimensions have been denormalized. 
+      Some pre-aggregations to the booking level have also been performed and added here.
+
+    columns:
+      - name: id_booking
+        data_type: bigint
+        description: The unique, Superhog generated id for this booking.
+        tests:
+          - unique
+          - not_null
+
+      - name: id_user_guest
+        data_type: character varying
+        description: The UUID of the Superhog user playing the guest role in the booking.
+
+      - name: id_user_host
+        data_type: character varying
+        description: The UUID of the Superhog user playing the host role in the booking.
+
+      - name: id_accommodation
+        data_type: bigint
+        description: The ID of the booked listing.
+
+      - name: is_duplicate_booking
+        data_type: boolean
+        description: |
+          A flag that identifies whether the booking is a duplicate.
+
+          A booking is considered a duplicate if there's an older booking with the same user,
+          accomodation and check-in date. If there are two or more bookings with the same user,
+          accomodation and check-in date, the oldest one will have False as a value in this field,
+          and the other ones will have True as a value in this Failed."
+
+          Put simply, if you don't want to receive duplicates, filter this field to True.
+
+      - name: booking_fee_local
+        data_type: numeric
+        description: |
+          The fee that Superhog should charge the host for this booking, measured in local 
+          currency.
+
+          This fee is calculated by finding what was the active price plan for the host user 
+          when the booking fee had to be charged. 
+
+      - 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.