証憑ルールエンジン設計：経費精算から証憑への変換は一枚のマッピング表だけではない

経費精算書が記録するのは「誰が、何のために、いくら使ったか」であり、証憑が求めるのは「借方・貸方科目、金額、補助核算ディメンション」です。その中間の翻訳は一枚の表では解決できません——同じ費用タイプでも、部門・プロジェクト・インボイス種別が異なれば、出力される科目も異なる。本当に必要なのは、設定可能で、追跡可能で、試算可能なルールエンジンである。

エンジンは書類から4種類の情報を導出する必要があります

4類のうち複雑なルールが必要なのは第1類のみだが、それこそがソリューション全体の成否を決める部分です。

最も犯しやすい設計ミス：条件を固定列として記述すること

多くの実装では、マッチング条件をルール表上の固定列として設計します。1列はdept_id、1列はproject_id、1列はinvoice_type。このようにすると、次のような結果を招きます。マッチング次元を一つ増やすたびに、テーブル構造を変更し、コードを変更し、再リリースする必要がある。

正しい方法は、ルールと条件を2つのテーブルに分け、条件の行数は無制限で、間はAND関係とすることです。

こう設計した後、新しいマッチング次元を追加するにはfieldの列挙に値を追加するだけで、テーブル構造を変更する必要も、リリースする必要もありません。

科目マスタデータは省略できない

科目はルールテーブルにコード文字列を一つ保存するだけではいけません。独立したマスタデータテーブルが必要です。鍵となるのは required_dims このフィールド——これによりシステムは、総勘定元帳に推送されて拒否されるのを待つのではなく、証憑生成段階で次元の完全性検証を完了できます。

優先度 財務に手作業で入力させない

財務担当者が優先度の数値を手作業で記入すると、ほぼ必ず誤りが生じます——すべてのルールの精確さを頭の中で比較する必要があるからです。より信頼できる方法は、システムが条件数に応じて自動計算することです：条件が多いルールほど精確で、優先度が高い。

自動計算を基礎に手動微調整の入口を残し、同条件数だが先後を区別する必要がある特殊な状況に対応します。

包括的ルールがなければならない

マッチングフローは次のとおりです：候補ルールを絞り込み（タイプ一致、有効化済み、伝票日付が有効期間内）→ 各条件がすべて満たされるかを1件ずつ判定 → 複数該当時はpriority昇順で最初の1件を採用 → 該当なしの場合はフォールバックルールを適用。

フォールバックルールは省略できません。これがないと、顧客が費用タイプを1つ追加するだけで証憑生成が失敗し、その時点で経費精算書はすでに承認済みで差し戻しできず、業務が直接行き詰まります。受け皿科目（例：「未分類費用」）により業務を先に流し、財務が事後に調整できます。

試算機能も同様に省略できません

エンジンは試算能力を提供する必要があります。過去の経費精算書を1枚入力すると、完全な導出チェーンを出力します。どのルールに該当したか、なぜ該当したか、最終的にどの科目が生成されるか。

この機能が欠けているため、ルール設定を誤っても証憑生成時にエラーが発生するまで気づけず、調査コストが極めて高く、財務担当者も自ら検証できない。

歴史証憑はルール変更の影響を受けてはなりません

半年後に財務がマッピングルールを調整しても、あなたは依然として「この歴史的証憑が当時なぜこの科目だったのか」を説明できなければならない。これは2つの仕組みに依存する：ルール表のeffective_from / effective_to有効期間、及び証憑仕訳にhit_rule_idルールスナップショットを記録。

証憑生成時は「伝票日付」が属する期間に応じてルールバージョンを選択し、現在時刻によってはなりません。