Fix tenant-safe monthly revenue reporting

[giriss]

Loom Videos

Part 1 - 5 minutes: https://www.loom.com/share/202407d70af847e2a917966c1956ed99
Part 2 - 4 minutes: https://www.loom.com/share/05bbcb4e47f2437e85055fa0d9ebbe14

Sorry my Loom free version only allows up to 5 minutes videos, so I had to do it in 2 parts.

Overview

This PR fixes the revenue dashboard issues reported by Sunset Properties, Ocean Rentals, and the finance team.

The changes focus on three areas:

• Tenant isolation in cached revenue summaries
• Timezone-aware monthly revenue calculations
• Exact decimal handling for financial totals

What changed

Tenant-safe caching

Revenue cache keys now include all relevant report dimensions:

• Tenant
• Property
• Month
• Currency

This prevents properties with the same ID in different tenants from sharing cached revenue data.

Timezone-aware monthly reporting

The dashboard API now accepts a month in YYYY-MM format and calculates revenue using the property’s configured timezone.

The query uses local calendar-month boundaries with a half-open interval:

check_in_date >= start_of_month
check_in_date < start_of_next_month

This ensures reservations near UTC month boundaries are assigned to the correct local reporting month.

For example, Sunset’s reservation at 2024-02-29 23:30 UTC occurs on March 1 in Paris and is therefore included in the March report.

Exact financial totals

Revenue remains a Decimal after database aggregation and is rounded once to cents using ROUND_HALF_UP.

The API returns a fixed-point string such as:

{
  "total_revenue": "2250.00"
}

The frontend displays this value directly instead of applying JavaScript floating-point arithmetic.

Dashboard filters

The dashboard now includes month and currency filters and passes them through the API client to the backend.

The previous client-controlled simulated tenant header has also been removed.

Expected results

For Sunset Properties, prop-001 in March 2024 now reports:

USD 2250.00
4 reservations

Revenue cache entries are isolated by tenant and reporting period, and totals retain consistent decimal precision across the backend and frontend.

Test plan

• Log in as Sunset Properties and verify March 2024 for prop-001 returns 2250.00 with 4 reservations
• Verify the UTC boundary reservation is included in March and excluded from February
• Log in as both clients and confirm shared property IDs do not reuse another tenant’s cached result
• Change the selected month and confirm the dashboard requests and displays the corresponding period
• Confirm revenue is returned and cached as a fixed-point decimal string
• Refresh both client dashboards repeatedly and confirm revenue remains tenant-isolated

Implementation notes

The solution keeps the existing architecture and introduces no additional frontend dependencies. PostgreSQL handles timezone boundaries, while Python Decimal remains the source of truth for financial rounding.

Screenshot: