84 lines
2.4 KiB
Markdown
84 lines
2.4 KiB
Markdown
|
# Finance Workflow Change – Host Resolution Payments Handling
|
|||
|
|
|
|||
|
|
## Summary
|
|||
|
|
|
|||
|
|
The Finance team is introducing a structural change in how **Host Resolution Payments** are recorded and processed in our systems. This affects the **source of truth** for these transactions and requires a coordinated update across our **Data Warehouse (DWH)** and **reporting models**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## What’s Changing?
|
|||
|
|
|
|||
|
|
### **Previous Approach:**
|
|||
|
|
|
|||
|
|
- Host resolution payments were handled as **bank transactions**.
|
|||
|
|
- Stored in the `xero.bank_transactions` table.
|
|||
|
|
- Payments categorized using:
|
|||
|
|
- `account_code = 323` → *E-Deposit Resolution - Host Payment*
|
|||
|
|
- `account_code = 316` → *Resolutions - Host Payment*
|
|||
|
|
|
|||
|
|
### **New Approach:**
|
|||
|
|
|
|||
|
|
- Host resolution payments will now be handled as **credit notes** instead.
|
|||
|
|
- Stored in the `xero.credit_notes` table.
|
|||
|
|
- Categorization remains the same:
|
|||
|
|
- `account_code = '323'` → *E-Deposit claims*
|
|||
|
|
- `account_code = '324'` → Check In Hero - Resolutions (Guest) (new as of 23.04 7pm)
|
|||
|
|
- `account_code = '316'` → *All other resolution payments*
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Effective Date
|
|||
|
|
|
|||
|
|
> 🔔 This change applies to all resolution claims made on or after
|
|||
|
|
>
|
|||
|
|
>
|
|||
|
|
> **📆 March 31st, 2025**
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Implementation Plan
|
|||
|
|
|
|||
|
|
### Step 1: Create Unified Resolution Payments Table
|
|||
|
|
|
|||
|
|
A new table will be introduced in the DWH that consolidates **host resolution payments** from both:
|
|||
|
|
|
|||
|
|
- `bank_transactions` (for transactions **before** March 31st, 2025), and
|
|||
|
|
- `credit_notes` (for transactions **from** March 31st, 2025 **onward**).
|
|||
|
|
|
|||
|
|
This ensures continuity in analysis and reporting across the transition.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Step 2: Review & Update Downstream Models
|
|||
|
|
|
|||
|
|
We will **review all DWH models that depend on**:
|
|||
|
|
|
|||
|
|
- `xero.credit_notes`
|
|||
|
|
- `xero.bank_transactions`
|
|||
|
|
|
|||
|
|
…and assess how the change might affect:
|
|||
|
|
|
|||
|
|
- joins
|
|||
|
|
- any possible aggregations that might be affected
|
|||
|
|
|
|||
|
|
[Credit Notes Downstream Analysis](Credit%20Notes%20Downstream%20Analysis%201de0446ff9c980d9a0c1fd9477d7fcb7.md)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### Step 3: Update Reporting
|
|||
|
|
|
|||
|
|
The following reports are expected to require updates:
|
|||
|
|
|
|||
|
|
- **Main KPIs Report**
|
|||
|
|
- **Host Resolutions Report**
|
|||
|
|
|
|||
|
|
More may follow depending on dependencies.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Key Considerations
|
|||
|
|
|
|||
|
|
- Ensure **no double counting** during the transition period (e.g. if one payment is mistakenly captured in both sources).
|
|||
|
|
- Validate that the new credit notes data includes **all fields** currently used in `bank_transactions`.
|
|||
|
|
- Coordinate QA testing with Finance to verify totals match.
|