配布資料 62Keihi 要件定義 — 金額計算

status: active / 金額計算の仕様。

ここは金銭ロジックの規律——成分別 assertion と、拙速禁止——を扱うための中核になります。決済事業者を使わずに、題材プロジェクトの金銭規律をそのまま再現できるように設計しました。

合計だけを検証するテストでは、成分同士の誤差の相殺を見逃します。そこを体験してもらうための仕様です。

1. 申請合計

申請合計 = Σ 明細金額。ヘッダの合計はサーバ側で明細から都度導出し、クライアントから受け取らない（改竄防止・導出値の直接編集不可)
明細金額は 1〜999,999 円の整数（0円明細は不可）

2. 費目別上限ルール

費目	上限	超過時の挙動
交通費	1明細 50,000円	超過はエラー（提出不可）
会議費	1明細 10,000円	超過は警告付きで提出可・承認画面に超過バッジ表示
消耗品費	1明細 30,000円	超過はエラー
出張費	1明細 200,000円	超過は警告付きで提出可
通信費	1明細 20,000円	超過はエラー

「エラー」と「警告」の2種類があるのは意図的——全状態の洗い出し（エラー/警告/正常 × 提出/承認の組合せ）を単体テスト演習の題材にするため
上限値はマスタ（DB）で管理し、文書とコードに値を重複記載しない（正本は DB。→ 事例 #07 の教訓を構造で回避）

3. 月次締め集計（経理)

締め対象: 対象月に支払済みになった申請（承認済みはまだ含めない——集計基準の明確化）
集計軸: 部門別 × 費目別の合計、および申請件数
月の境界は JST（Asia/Tokyo）の暦月とし、timestamptz 列に対して境界を明示的に指定する（→ 事例 #09 を講義で対比）

4. テスト要求（成分別 assertion の義務）

金額に関わるテストは合計値だけの assert を禁止し、成分別に検証する:

NG: expect(total).toBe(15000)
OK: expect(交通費小計).toBe(8000)
    expect(会議費小計).toBe(7000)
    expect(total).toBe(15000)      // 合計は最後に整合確認として
    expect(警告件数).toBe(1)        // 会議費上限超過の警告

理由: 合計だけの検証は成分同士の誤差相殺を見逃す（題材プロジェクトの返金3成分で確立された規律の移植。→ catalog/03 test-generator）。

5. 変更時の統制（この文書のメタルール）

この文書の数値・計算式を変更する実装は、変更前に影響箇所を実測（該当テスト・画面・集計の全経路列挙）してから着手してください（→ 事例 #12）。「上限を1つ変えるだけ」が何箇所に波及するかを体験させる演習ポイントでもある。