84 lines
No EOL
2.4 KiB
Markdown
84 lines
No EOL
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. |