Expense Repository
Component Detail
Description
Data access layer for all expense records in Supabase. Provides CRUD operations for expense claims, queries for attestation queues, and filtered lookups by activity, claimant, status, and organisation. Handles optimistic updates and offline caching.
expense-repository
Summaries
The Expense Repository is the foundational data layer that makes the entire expense reimbursement workflow reliable and auditable. By centralizing all expense record operations — creation, approval, deletion, and status tracking — it ensures that volunteer coordinators and claimants always work from a single consistent source of truth. Offline caching support means volunteers can submit claims even in low-connectivity environments, directly reducing friction and increasing participation rates. This reliability underpins the organization's ability to accurately reimburse volunteers at scale.
The Expense Repository is a medium-complexity data component with no upstream service dependencies, making it an ideal early-sprint deliverable that unblocks all downstream expense features. It must be implemented and tested before the Driver Honorarium Service or any attestation workflow can proceed. Testing priorities include optimistic update conflict resolution, offline cache invalidation, and attestation queue filtering correctness across multiple organizations. A key risk is Supabase query performance under load — index design for claimant, activity, status, and organization filters should be validated with realistic data volumes before release.
The Expense Repository is the Supabase data access layer for all expense entities. It implements full CRUD plus specialized queries: attestation queue retrieval (filtered by organizationId and pending status), claimant history (userId + date range), and activity-scoped lookups. Optimistic updates should use Supabase's real-time subscriptions or local state reconciliation to handle concurrent edits from coordinators. Offline caching requires a local queue (e.g., AsyncStorage or SQLite on mobile) with a sync mechanism that replays queued writes on reconnection.
The getPendingAttestationQueue interface must be paginated or cursor-based to handle large organizations. All mutation interfaces should return the updated record to support optimistic UI patterns.
Responsibilities
- Create expense records linked to activity IDs
- Query expenses by claimant, activity, organisation, and approval status
- Update expense approval status and coordinator comments
- Fetch pending attestation queue filtered by organisation
Interfaces
createExpense(expenseData)
getExpenseByActivity(activityId)
getExpensesByClaimant(userId, from, to)
getPendingAttestationQueue(organizationId)
updateApprovalStatus(expenseId, status, comment)
deleteExpense(expenseId)
getExpenseById(expenseId)
Relationships
Dependents (4)
Components that depend on this component
Used Integrations (1)
External integrations and APIs this component relies on