Expense Type Repository
Component Detail
Description
Manages persistence of expense type selections as part of an expense record in the travel and expense registration flow. Reads and writes the selected expense type set to the local draft store and to Supabase when the expense is submitted. Validates that the stored combination passes mutual exclusion rules before persisting.
expense-type-repository
Summaries
The Expense Type Repository ensures that employee expense selections are never lost during the submission process, protecting against data loss from app backgrounding, network interruptions, or accidental navigation. Draft persistence means employees can start an expense claim, switch tasks, and return without re-entering data — a significant usability improvement that reduces submission abandonment rates. Reliable synchronisation to Supabase on submission provides the finance system with an accurate, validated record of expense types, supporting audit trails and policy compliance reporting. This reliability directly supports employee trust in the tool and reduces support ticket volume.
Low complexity component, but it carries integration dependencies on both local draft storage and the Supabase backend, making it one of the components most exposed to environment-related delays. Confirm Supabase schema and RLS policies for expense type fields before development begins to avoid late-stage blockers. Local draft storage implementation must be agreed upon (Hive, SharedPreferences, or SQLite) early, as this decision affects other draft-related components. Testing must cover offline draft save and restore, online submission, and the edit-flow read-back scenario.
Integration tests against a Supabase staging environment are required. Plan for additional time if Supabase schema changes are needed.
Implements the repository pattern over two storage backends: a local draft store (implementation-agnostic, injected via interface) and Supabase for submitted records. saveDraft serialises the Set
Use async/await throughout with typed exceptions for network and storage failures. The repository must not hold mutable state — each call operates on the provided expenseId. Supabase writes should use upsert semantics to handle re-submissions of draft records cleanly.
Responsibilities
- Persist selected expense types to local draft storage
- Sync confirmed expense type selections to Supabase
- Read back saved expense type selections for edit flows
- Validate persisted combinations against exclusion rules before save
Interfaces
saveDraft(String expenseId, Set<ExpenseType> types) → Future<void>
loadDraft(String expenseId) → Future<Set<ExpenseType>>
submitExpenseTypes(String expenseId, Set<ExpenseType> types) → Future<void>
getExpenseTypes(String expenseId) → Future<Set<ExpenseType>>
Relationships
Related Data Entities (1)
Data entities managed by this component