Merged PR 2742: Creation of int_core__deal

# Description

Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on.

# Checklist

- [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs?  I didn't see any uses of the previous model int_core__deal_id_master_list.**
- [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: #20822

models/intermediate/core/int_core__deal.sql

@@ -0,0 +1,46 @@
+{{ config(materialized="table", unique_key="id_deal") }}
+with
+    int_core__unified_user as (select * from {{ ref("int_core__unified_user") }}),
+    int_core__country as (select * from {{ ref("int_core__country") }}),
+
+    -- A Deal can have multiple users, which in turn can have different
+    -- billing countries. We assume here that the main billing country
+    -- at deal level is going to be the one that gets repeated the most
+    -- across all users linked to the deal.
+    billing_countries_per_deal as (
+        select
+            id_deal,
+            id_billing_country,
+            row_number() over (
+                partition by id_deal order by count(distinct id_user) desc
+            ) as rn
+        from int_core__unified_user
+        group by 1, 2
+    ),
+    main_billing_country_per_deal as (
+        select
+            bcpd.id_deal,
+            bcpd.id_billing_country as main_id_billing_country_per_deal,
+            c.country_name as main_billing_country_name_per_deal,
+            c.iso_2 as main_billing_country_iso_2_per_deal,
+            c.iso_3 as main_billing_country_iso_3_per_deal
+        from billing_countries_per_deal bcpd 
+        left join int_core__country c 
+            on bcpd.id_billing_country = c.id_country 
+        where bcpd.rn = 1
+    )
+select
+    uu.id_deal,
+    mbcpd.main_id_billing_country_per_deal,
+    mbcpd.main_billing_country_name_per_deal,
+    mbcpd.main_billing_country_iso_2_per_deal,
+    mbcpd.main_billing_country_iso_3_per_deal,
+    count(distinct uu.id_user) as users_with_this_id_deal,
+    count(
+        distinct uu.billing_country_iso_3
+    ) as billing_countries_for_this_id_deal
+from main_billing_country_per_deal mbcpd 
+left join int_core__unified_user uu
+    on uu.id_deal = mbcpd.id_deal
+where mbcpd.id_deal is not null
+group by 1, 2, 3, 4, 5

models/intermediate/core/int_core__deal_id_master_list.sql

@@ -1,4 +0,0 @@
-with int_core__unified_user as (select * from {{ ref("int_core__unified_user") }})
-select id_deal, count(1) as users_with_this_id_deal
-from int_core__unified_user
-group by id_deal

models/intermediate/core/schema.yaml

@@ -2939,4 +2939,58 @@ models:
           plans happened during that month.
         tests:
           - not_null  
-      
+      
+  - name: int_core__deal
+    description:  |
+          This table provides information about the unique entity that identifies a
+          client, which is a Deal.
+          A Deal is a common way to match information between Core, Xero and Hubspot 
+          data sources. It's different from the typical User Host in the sense that
+          a Deal can have multiple User accounts (usually referred to as Platform 
+          accounts). This is because in the past, different Host configurations could
+          only be done if multiple users were created. 
+          It can happen that a Deal has 1 or multiple hosts, as mentioned above. At
+          the same time, not all users that act as hosts have a deal associated. One
+          example is Know Your Guest (KYG) Lite accounts. However, there's also historical
+          cases that for whatever reason there's no Deal associated.
+          
+    columns:
+      - name: id_deal
+        data_type: character varying
+        description: The unique ID for the Deal. One row per id_deal.
+        tests:
+          - not_null
+          - unique
+      - name: main_id_billing_country_per_deal
+        data_type: integer
+        description: |
+          ID of the main country in which the Deal is billed. 
+          It's an estimation since in some cases, a Deal can have
+          different User Hosts and these are not forced to be billed
+          within the same country. However, the volume of these cases
+          is very low, thus we proceed with this estimation. 
+          In some cases it's null. 
+      - name: main_billing_country_name_per_deal
+        data_type: string
+        description: |
+          Name of the main country in which the Deal is billed.
+          In some cases it's null.
+      - name: main_billing_country_iso_2_per_deal
+        data_type: string
+        description: |
+          ISO 3166-1 alpha-2 main country code in which the Deal is billed.
+          In some cases it's null.
+      - name: main_billing_country_iso_3_per_deal
+        data_type: string
+        description: |
+          ISO 3166-1 alpha-3 main country code in which the Deal is billed.
+          In some cases it's null.
+      - name: users_with_this_id_deal
+        data_type: integer
+        description: | 
+          Informative field of how many Users have this same Deal associated.
+      - name: billing_countries_for_this_id_deal
+        data_type: integer
+        description: | 
+          Informative field of how many different billing countries are
+          associated to this Deal based on the user account configuration.