業務システムの導入ガイド
購買申請をシステム化する｜承認・発注・検収の分担
購買申請をシステム化するときは、承認後の発注、納品、検収までを一つの案件としてつなぎます。そのうえで、誰が発注し、納品された物を誰が検収するかを分け、「申請済み」「承認済み」「発注済み」「納品済み」「検収済み」を別の状態として設計します。
申請が承認されていても、まだ取引先へ発注していないことはあります。物が届いていても、数量や品質の確認が済んだとは限りません。ひとつの「処理済み」へ集約すると、この違いを記録から判定できなくなります。
承認後に数量が変わっても、承認時、発注時、納品時、検収時の数量は、それぞれの記録として残します。変更後の数量だけに置き換えると、何を根拠に発注・検収したかを追えなくなるためです。
製品仕様は、2026年9月27日に各社の公開情報で確認しました。以下の責任表とテストケースは、実在の顧客事例や自社実績ではない架空の設計例です。
購買申請のシステム化は状態を分けるところから始める
住友電工情報システムの製品では、購入依頼、発注、入荷、検収ごとに独立した承認ワークフローを設定できます（電子承認ワークフロー）。依頼部門と購買部門の双方に入荷・検収入力を用意し、購買部門には購入依頼の受付や発注入力も用意しています（購入依頼から検収までの一連の購買業務をサポート）。
この実装例から、購買申請の状態を次のように分ける設計が候補になります。
| 状態 | 状態になる条件 | 最低限残す記録 | まだ完了していないこと |
|---|---|---|---|
| 申請済み | 申請者が品目・数量・希望日・目的を登録した | 申請者、申請日時、申請内容 | 承認、発注、納品、検収 |
| 承認済み | 承認者が必要性・予算・承認時点の数量を判断した | 承認者、承認日時、承認対象の数量 | 対外発注、納品、検収 |
| 発注済み | 発注担当が承認済み内容を基に対外発注した | 発注担当、発注日時、発注番号、発注数量 | 納品、検収 |
| 一部納品・納品済み | 明細ごとの受領を記録し、未納分があれば一部納品、全明細の納品残がゼロなら納品済み | 受領担当、受領日時、受領数量、納品残 | 現物・数量・品質の検収 |
| 一部検収・検収済み | 明細ごとの検収を記録し、納品残と未検収分が全明細でゼロになれば検収済み | 検収担当、検収日時、今回・累計の検収数量、結果 | 不合格や返品があれば別途対応 |
各状態の記録は、後の処理へ進んでも保持します。承認済みは発注の根拠として残り、発注済みは納品と検収の照合先として残ります。
承認された稟議データを発注書へ自動転記し、申請から発注、その後の納品・支払までを扱う製品実装例も確認できます。さらに、納品数量に応じた支払管理とともに、納品残数や検品日を発注関連データとして管理する例があります（ラクス「仕入・納品管理」）。申請から発注へデータを引き継ぐことと、納品と検収を別に記録することは、同じ購買案件を途切れさせずに管理するための組み合わせです。
四者の責任を決める判断表
状態だけを増やしても、更新する人が決まっていなければ運用は止まります。架空の条件例として、申請者・承認者・発注担当・検収担当の責任を次のように分けます。
| 判断・操作 | 申請者 | 承認者 | 発注担当 | 検収担当 |
|---|---|---|---|---|
| 品目・数量・希望日・目的の登録 | 実行し、内容に責任を持つ | 参照する | 参照する | 必要に応じて参照する |
| 必要性・予算・承認時点の数量の判断 | 判断材料を補足する | 承認・差戻しを実行する | 承認結果を参照する | 承認結果を参照する |
| 取引先への発注と発注番号の記録 | 実行しない | 実行しない | 実行し、発注記録に責任を持つ | 参照する |
| 納品の受領と受領数量の記録 | 納品先で受領した場合は報告する | 参照する | 受領報告を基に納品記録を確定する | 納品記録を参照する |
| 納品された現物・数量・品質の確認 | 必要に応じて参照する | 参照する | 発注記録を提示する | 実行し、検収記録に責任を持つ |
| 承認後の数量変更 | 変更申請を起票できる | 変更後の数量を再判断する | 変更申請中は対象明細の発注操作を保留する | 確定した発注数量と納品数量を基に検収する |
この表なら、「承認できる人」と「取引先へ発注する人」、「物が届いたことを記録する人」と「内容を検収する人」を分けて画面権限と通知先を決められます。自社で実際に判断・操作する担当へ各責任を割り当て、その後に役職名や所属を対応させます。
承認後の数量変更を受け入れられるか
承認済みの数量を直接書き換えれば、画面上は最新値になります。しかし、承認者が何を承認し、発注担当が何を発注したかという根拠まで同時に変わってしまいます。
公開されている製品仕様には、伝票の新規登録に加え、変更・取消時にも承認ワークフローを回し、承認者と承認時点を記録する実装例があります（住友電工情報システム「電子承認ワークフロー」）。この実装を踏まえると、変更時の再承認と履歴保持は採用候補になります。
この設計例では、変更申請中の明細は新たな発注操作を保留し、旧数量での発注も止めます。取引先へすでに出した注文を自動で止める扱いにはせず、発注担当が先方との調整状況を確認します。申請が却下・取り下げになった場合も、発注担当が承認内容と発注履歴を確認してから保留を解除します。
開発前の受入条件をテストケースにすると、画面一覧からは読み取れない判定の曖昧さが表れます。数量変更を扱う架空のテストケースは次のとおりです。
| ケース | 操作 | 期待する判定 | 保持する記録 |
|---|---|---|---|
| 承認後・発注前に数量を増減する | 申請者が数量変更を申請する | 承認済み数量を直接上書きせず、再承認が完了するまで対象明細の発注操作を保留する | 変更前後の数量、変更申請者、再承認者、各日時 |
| 発注後に数量を増減する | 発注担当が変更を登録する | 元発注を残し、再承認が完了してから変更発注または取消・再発注を行う | 元の発注番号・数量、変更または取消の記録、新しい承認記録 |
| 一部分だけ納品される | 受領数量を登録する | 発注数量を維持したまま、累計納品数量と残数量を更新する | 発注数量、各納品数量、累計納品数量、残数量 |
| 未検収数量を超えて検収しようとする | 検収担当が今回の検収数量を登録する | 同じ明細の有効な累計検収数量に今回分を足すと累計受領数量を超えるため、登録できない | 対象明細、累計受領数、既検収数、今回の入力値、判定結果 |
| 検収後に数量を訂正する | 検収担当が訂正を申請する | 元の検収記録を消さず、取消または訂正の履歴を残す | 元記録、取消・訂正内容、実行者、実行日時 |
検収の上限は、受領した累計数量から、すでに検収した有効な累計数量を引いて求めます。取消済みの記録を有効数量に含めず、今回の入力後の累計で判定します。
架空の例として、同じ品目の発注明細で、発注数量12個、累計受領10個、うち検収済み8個とします。返品・不合格・発注変更・検収取消はない条件です。
| 確認すること | 計算・操作 | 判定 |
|---|---|---|
| 未納分 | 12 − 10 = 2個 | 一部納品のまま |
| 追加で検収できる数 | 10 − 8 = 2個 | 今回の検収上限は2個 |
| 今回5個を入力 | 8 + 5 = 13個 | 受領10個を超えるため拒否し、検収済み8個を維持 |
| 今回2個を入力 | 8 + 2 = 10個 | 受領分の検収は完了。ただし未納2個が残るため、発注明細全体は一部検収 |
「今回5個は受領10個より少ない」だけでは合格にしません。すでに検収した8個を含めて照合します。返品や不合格がある業務では、その数量と処置を別に持ち、発注残や未検収分へどう戻すかを決めてから完了条件へ加えます。
要件定義で確認する順番
既存の申請書や表計算ファイルがある場合も、その項目を画面へ写す前に、申請後の発注・納品・検収までを整理します。Excel管理から業務システムへ移行する進め方も踏まえ、各工程で必要な判断から要件を組み立てます。
- 申請、承認、発注、納品、検収を実行している担当を特定する
- 各状態へ進む条件と、戻す条件を決める
- 状態ごとに担当者、実行日時、対象数量を残す
- 承認後・発注後・検収後の変更ルールをテストケースにする
- 通知、権限、外部連携、データ出力の必要範囲を決める
この順番で整理すると、必要な画面と権限に加え、契約前に確認すべき開発範囲も具体化します。初期開発と運用保守は個別見積もりになるため、検討時には業務システムの開発費用を考えるポイントと照らし、連携・移行・権限・データ出力の範囲を確認してください。
Cotomuでは、自社業務に合わせたWebアプリを、困っている業務ひとつから設計・開発します。購買申請では、承認画面に加え、発注担当への引継ぎ、納品と検収の分離、各時点の数量履歴までを責任表とテストケースに落とすことが相談の出発点です。業務アプリの相談では、現在の申請書や運用を基に必要な範囲を整理できます。