Data Layer low complexity mobile
0
Dependencies
2
Dependents
1
Entities
0
Integrations

Description

Defines the canonical enum of expense types (kilometers, tolls, parking, public transit), their display metadata (labels, icons, descriptions), reimbursement formula parameters (per-km rate, receipt thresholds), and the full compatibility matrix. Acts as the single source of truth for all expense type data across the feature.

Feature: Expense Type Selection with Mutual Exclusion

expense-type-config

Summaries

The Expense Type Configuration is the authoritative source of all business rules governing how expense types are defined, displayed, and reimbursed within the application. By centralising this configuration, the organisation ensures that policy changes — such as updating the per-kilometre reimbursement rate or adding a new expense category — require a single code change rather than updates scattered across multiple systems. This reduces the risk of inconsistencies between what users see, what is calculated, and what is paid, which directly protects against over- or under-reimbursement errors. It also accelerates future policy rollouts and reduces maintenance cost.

Low complexity component and a foundational dependency for expense-calculation-service and expense-type-repository — it must be delivered first in the feature build sequence. The primary delivery risk is delayed stakeholder confirmation of business values: per-km rates, receipt thresholds, transit zone amounts, and the compatibility matrix must all be signed off by finance and product before this component is finalised. Schedule a requirements lock milestone early. Changes to any value after downstream components have been built will require regression testing of calculation and validation logic.

This component should be treated as a contract document as much as a code artefact — version it carefully and communicate changes to the full team.

Defines the ExpenseType enum (kilometers, tolls, parking, publicTransit) and exposes three typed accessors: getMetadata returns display label, icon asset path, and description string; compatibilityMatrix returns a const Map> used by the rule engine; getFormula returns a typed ReimbursementFormula object consumed by the calculation service. All values should be const to enable tree-shaking and guarantee immutability at compile time. The compatibility matrix must be defined symmetrically — if kilometers excludes publicTransit, publicTransit must exclude kilometers. This is the only component that hardcodes business values; all other components must read from this config.

Write a test that asserts matrix symmetry to prevent accidental asymmetric entries during future edits.

Responsibilities

  • Define ExpenseType enum with all four fixed categories
  • Store display metadata (label, icon, description) per type
  • Store reimbursement formula parameters per type
  • Define the compatibility matrix as a const data structure

Interfaces

ExpenseType (enum: kilometers, tolls, parking, publicTransit)
ExpenseTypeMetadata getMetadata(ExpenseType type)
CompatibilityMatrix get compatibilityMatrix
ReimbursementFormula getFormula(ExpenseType type)

Relationships

Dependents (2)

Components that depend on this component

Related Data Entities (1)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/expense-type-config 6 endpoints
GET /api/v1/expense-type-config List all expense type definitions with metadata, formulas, and compatibility matrix
GET /api/v1/expense-type-config/:id Get full configuration for a specific expense type
POST /api/v1/expense-type-config Create a new expense type definition (admin only)
PUT /api/v1/expense-type-config/:id Update expense type configuration (e.g. rate change, compatibility update)
DELETE /api/v1/expense-type-config/:id Deactivate or remove an expense type definition (admin only)
GET /api/v1/expense-type-config/compatibility-matrix Get the full compatibility matrix across all expense types