業務ルールを、例外まで定める

このレッスンの到達目標

金額・日付・状態の条件を具体例で合意する。

音声とインタラクティブ図解で学ぶ音声を再生すると、下のインタラクティブ図解と本文の段落ハイライトが連動して動きます。

BUSINESS STATE MACHINE · AUDIO & INTERACTIVE

販売管理の取引状態マシンと「締め後・例外」の境界シミュレーター

受注→出荷→売上→請求締め→入金の流れで、いつ・どのデータ（受注日／計上日／締め日）が確定し、どこから直接変更が禁止されるかを動かして確かめます。

状態・日付・数量の変化受注確定（受注日 10/12 ／受注 3個）

取引先の優良区分は受注時点のマスターを採用するか、請求時に再評価するかを合意して保持します。

直接変更の可否と監査履歴元伝票の直接変更：条件付き可（出荷前）

試作画面で金額を書き換えられても、業務システムでは「受注日・売上計上日・締め日」と「変更履歴・承認権限」を分けて設計します。

値引きでは対象取引先、適用日、計算単位、端数、税との順序を確認します。受注時と請求時のどちらのマスターを使うか、マスター変更後に既存取引が変わるかも要件です。一般的な慣習を顧客のルールとして採用しません。

取消、返品、部分出荷、締め後訂正の例を使い、どの状態で何を変更できるかを合意します。過去の伝票を直接変えるか、訂正記録を作るかで、請求・会計・監査への影響が違います。業務責任者の判断を記録します。

権限では実行できる人と承認する人を分け、誰がいつ何を変更したかの履歴も定めます。画面からだけでなくAPIやバッチ経由でも必要な制約が守られるかを、後の設計・テストへつなぎます。

未確定の条件は対象外か保留かを明示し、決定者と期限を設定します。限定した条件で先行する場合は、後から変わる可能性と影響を共有します。推測による実装を、合意済み仕様として説明しないでください。

読了記録と習熟度の確認は別です。