Implement XledgerExporter: CSV/JSON Payload Serialization
epic-accounting-system-export-engine-task-004 — Extend the XledgerExporter with payload serialization: produce both a Xledger-compatible CSV and a JSON representation of the mapped export records. Use the CSV/JSON File Generator component. Ensure CSV column order and encoding matches Xledger import specification. Include a header row and proper escaping for all string fields. Return the payload wrapper consumed by the caller.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Define a `CsvJsonFileGenerator` utility class (or use it if already defined by the component) that accepts a list of maps and column order config, and produces both `csvBytes` and `jsonString`. The column order must be declared as a `static const List
If in doubt, include it (`0xEF, 0xBB, 0xBF` prepended to `csvBytes`). Do not use the `csv` pub package if it doesn't support all escaping requirements — a hand-rolled RFC 4180 serializer for this use case is 30 lines and far more predictable.
Testing Requirements
Unit tests using `flutter_test`. Required scenarios: (1) 3-record batch produces valid CSV with correct header and 3 data rows; (2) a string field containing a comma is properly quoted in CSV; (3) a string field containing a double-quote is escaped as `""`; (4) amount 150.00 appears as `150.00` not `150` or `1.5E2`; (5) JSON output has correct field names matching Xledger spec; (6) empty mapped records list returns `ValidationError`, not empty file; (7) `exportedClaimIds` in wrapper matches input claim IDs; (8) UTF-8 encoding verified by decoding `csvBytes` with `utf8.decode`. Snapshot test: generate CSV from a fixed 2-record input and assert exact string output matches a stored golden fixture.
The Xledger CSV/JSON import specification may not be available in full detail at implementation time. If the field format, column ordering, encoding requirements, or required fields differ from assumptions, the generated file will be rejected by Xledger on first production use.
Mitigation & Contingency
Mitigation: Obtain the official Xledger import specification document from Blindeforbundet before starting XledgerExporter implementation. Build a dedicated acceptance test that validates a sample export file against all documented constraints.
Contingency: If the spec arrives late, implement a configurable column-mapping layer so that field order and names can be adjusted via configuration without code changes. Ship a file-based export that coordinators can manually verify before connecting to Xledger import.
The atomic claim-marking transaction in Double-Export Guard could fail under high concurrency if two coordinators trigger an export for overlapping date ranges simultaneously, potentially allowing duplicate exports to proceed past the guard.
Mitigation & Contingency
Mitigation: Use a database-level advisory lock or a SELECT FOR UPDATE on the relevant claim rows within the export transaction to serialize concurrent exports per organization. Add an integration test that simulates concurrent export triggers.
Contingency: If locking proves problematic at the database level, implement an application-level distributed lock using a Supabase row in a dedicated export_locks table with an expiry timestamp and automatic cleanup on failure.
HLF's Dynamics portal API endpoint may not be available or documented in time for Phase 1, leaving DynamicsExporter unable to be validated against a real system and potentially shipping with an incorrect field schema.
Mitigation & Contingency
Mitigation: Design DynamicsExporter for file-based export first (CSV/JSON download), with the API push implemented behind a feature flag. Request a Dynamics test environment or sandbox from HLF as early as possible.
Contingency: Ship DynamicsExporter as a file export only for Phase 1. Phase the API push integration into a follow-on task once the Dynamics sandbox is available, using the same AccountingExporter interface with no breaking changes.