Claim Receipt Repository
Component Detail
Description
Persists and retrieves the association between expense claim records and their Supabase Storage receipt paths in the Supabase database. Ensures the claim record reflects current attachment status and storage path, and supports querying claims by attachment state for auditing workflows.
claim-receipt-repository
Summaries
The Claim Receipt Repository safeguards the integrity of expense documentation by ensuring every claim record accurately reflects whether a receipt has been attached and where it is stored. This directly reduces financial risk by enabling audit workflows to surface claims missing required documentation before they are approved for reimbursement. Organizations benefit from reduced fraud exposure, faster audit response times, and compliance confidence. By maintaining a reliable attachment status on every claim, the business can enforce policy consistently and demonstrate due diligence to auditors, reducing the cost of manual reconciliation and potential disputes over reimbursement legitimacy.
This is a low-complexity data layer component with a narrow, well-defined scope limited to receipt path persistence and attachment status queries. Development effort is minimal — primarily CRUD operations against the Supabase database — but it is a foundational dependency for any feature that involves receipt uploads, audit workflows, or claim completeness checks. Testing requires database integration coverage across all five interface methods, including edge cases such as clearing a path that was never set and querying an organization with zero missing receipts. No upstream dependencies exist, so this component can be delivered early and unblocked.
Deployment risk is low provided the expense_claim table schema includes the required storage path and timestamp columns.
The Claim Receipt Repository operates as a thin persistence adapter over the Supabase PostgreSQL client, managing two fields on the expense_claims table: a storage_path column (nullable text pointing to the Supabase Storage object key) and an uploaded_at timestamp. saveReceiptPath() and clearReceiptPath() issue targeted UPDATE statements; getReceiptPath() and getReceiptMetadata() issue SELECT queries scoped to a single claimId. getClaimsWithMissingReceipts(orgId) performs a filtered SELECT WHERE storage_path IS NULL scoped to the organization. Both mobile (via Supabase Flutter SDK) and backend (via Supabase JS/REST) execution contexts are supported, so interface contracts must be consistent across both environments.
No joins or complex aggregations are required, keeping query performance predictable at scale.
Responsibilities
- Save receipt storage path to the claim database record
- Clear receipt path when attachment is removed
- Query claims by receipt attachment status
- Return receipt metadata including path and upload timestamp
Interfaces
saveReceiptPath(claimId, storagePath)
clearReceiptPath(claimId)
getReceiptPath(claimId)
getClaimsWithMissingReceipts(orgId)
getReceiptMetadata(claimId)