銀行エンジニアリング 02：Business EventとPosting Rule

Level 1 基礎：出来事と記帳方法を分ける

「預金に利息を払った」「口座手数料をいただいた」は業務上の出来事（Business Event）です。それを「どの勘定の借方・貸方にいくら書くか」に変換する決まりが記帳ルール（Posting Rule）で、変換して台帳に書く作業を記帳（Posting）と呼びます。

1. 01Business Event（出来事）
2. 02Posting Rule（記帳ルール）
3. 03Journal Entry（仕訳）
4. 04Journal Lines（明細）
5. 05Ledger Account（勘定）
6. 06Balance（残高）

Level 2 銀行業務：利息支払と手数料徴収

顧客ごとの預金勘定は、銀行全体の「預金」の内訳を顧客単位で持つ補助元帳（Sub Ledger）の役割を果たしています。試算表ではこれらを「顧客普通預金（合算）」にまとめて表示しており、これが総勘定元帳（General Ledger）側から見た預金の姿です。

Level 3 システム：MiniBankでの実装（正常時）

• posting.event_types がイベント種別と会計上の transaction_type、手動記帳の可否を持つ
• Posting Rule は v7 からある accounting.rule_definitions / rule_lines に登録する。v8では勘定の指定に「LEDGER:勘定コード」を使えるようにした
• posting.evaluate() がルールと文脈（口座・金額）から明細を作り、ledger.post_journal_entry() が記帳する
• 仕訳には適用したルールのIDが固定され、後でルールが新しい版に変わっても「当時どのルールで記帳したか」が残る
• 記帳のたびに posting.business_events へ1行追加し、イベント⇔仕訳が1対1で結びつく

異常時：ルールが勘定を見つけられない

Level 4 アーキテクチャ：ルールをデータとして持つ理由

記帳ルールをコードではなくデータ（版付き）で持つと、会計方針の変更を「新しい版の登録と有効化」として記録でき、過去の仕訳は当時の版で説明できます。一方で、ルールの誤りはすべての記帳に波及するため、有効化は専用関数（accounting.activate_rule）に限定され、有効化後の明細は変更できません。

どこを確認すればよいか

• 管理画面「会計・Ledger」→ 会計ルール：全ルールと版
• 管理画面「Ledger・Posting」→ 各イベントのトレース：イベント→ルール→仕訳→残高