見積承認のシステム化｜金額条件・差し戻し・版管理の決め方

見積承認をシステム化するとき、金額の大小だけで承認経路を作るのは不十分です。先に決めるべきなのは、何を変更したら承認を取り直すのか、そして顧客に提出してよい版はどれかです。金額に加えて値引き率や担当・部門などを分岐条件にし、差し戻し後の修正担当と再申請先まで一続きで定義します。

承認済みの見積をそのまま修正できると、承認者が見た内容と顧客が受け取る内容がずれます。承認状態と版を別々に記録し、「承認が完了し、変更できない版」だけを提出できる設計にすると、このずれを防げます。変更時に改訂版を作り、どの項目で再承認を求めるかは、自社の規程に合わせて決めます。

製品仕様は2026年9月21日に確認しました。以下の承認分岐表と版管理は、自社向けに検討する設計例であり、各製品に共通する標準機能ではありません。

見積承認の分岐は金額・値引き・版で決める

承認経路には、金額以外の条件も使えます。ふくろう販売の承認機能オプションでは、見積を含む伝票について、伝票種類別・担当者別に承認金額範囲と承認者を設定できます。同製品固有の仕様として、承認なし・承認レベル1・承認レベル2の3段階、承認者は2名までです。

楽楽販売の承認フロー機能は、多段階承認に加え、見積金額・値引き率・申請者の所属部署などによる自動分岐を案内しています。金額が小さくても値引きが大きい見積はあり得るため、金額条件を満たさないことと、追加承認が不要であることは同じではありません。

架空条件による承認分岐表

以下は設計方法を具体化するための架空例であり、実在企業の規程、顧客事例、導入実績ではありません。一次承認者を所属部署の承認担当とし、税抜見積総額が100万円以上、または定価合計に対する値引き率が10%以上なら営業部長承認を追加します。値引き率は「（定価合計－税抜見積総額）÷定価合計×100」で判定します。

この架空例では、承認済み版の金額、値引き率、担当、部門のいずれを変えても新しい改訂版にし、一次承認から取り直します。実務では、再承認を必須にする変更項目を自社の規程とリスクに合わせて定義する必要があります。変更を禁止する項目、変更後の条件で承認経路を再判定する項目、承認を引き継げる項目に分けると、実装時の曖昧さを減らせます。

差し戻しは「誰に戻り、どこから再開するか」まで決める

差し戻し通知だけが届いても、見積が申請中のままなのか、誰が直すのか、修正後にどの承認者へ送るのかが曖昧では処理が止まります。コメントと通知に、状態、担当、遷移のルールを結び付ける必要があります。

kintoneの申請ワークフロー設定例は、申請中のレコードを承認・却下・差し戻しへ分岐させ、差し戻し後は作成者が再申請して申請中へ戻す流れを示しています。これは見積専用ではない汎用例です。ふくろう販売でも、権限を持つ申請データを承認・差し戻しできます。この機能は標準版向けオプションに限られます。

差し戻し時には、少なくとも次の項目を一つのルールとして持たせます。

• 差し戻し後の状態
• 修正できる担当者
• 差し戻し理由の記録先
• 修正後の再申請先
• 差し戻し前の承認結果を引き継ぐか

再申請を先頭からやり直すなら、その条件も明記します。Dynamics 365 Finance & Operationsの承認操作では、変更要求を受けた文書が起票者へ戻り、変更後または元の版を再提出すると、承認プロセスの先頭へ送られます。これは見積専用ではないワークフローの一般動作です。後述のDynamics 365 Salesの見積改版とは別製品・別機能として参照します。

承認状態と顧客提出版を一致させる

承認履歴が残っていても、承認後に同じ見積を上書きできるなら、その履歴がどの内容への判断だったのか分からなくなります。再見積もりで守るべきなのは、最新版であることより、承認済みの内容と提出内容が一致していることです。

Microsoft Dynamics 365 Salesの見積ステージでは、新規見積はDraft、revision ID 0で始まり、顧客へ送る前にActiveへすると読み取り専用になります。改版時はrevision IDが1増え、新しいDraft見積が作られます。公式資料は、Active時に読み取り専用にする目的を、自社側と顧客側の版を一致させるためと説明しています。

ただし、Dynamics 365 SalesのActiveは「承認済み」を意味しません。この公式例から確認できるのは、顧客と共有する版を読み取り専用にし、改版を別のDraftとして識別する動作までです。承認状態の管理、再申請、提出許可との連動は、この動作とは分けて要件化する必要があります。

自社向けの設計案では、見積IDとは別に版IDを持たせ、承認状態と「現在提出してよい版」を分けます。この例では、改版を起票した時点で旧版の新規提出を止め、新版の承認完了後に提出許可を新版へ移します。差し戻し中も旧版へ戻しません。過去に送った旧版の内容・宛先・提出日時は履歴として保持します。これは自社向けの運用案であり、Dynamics 365 Salesの標準承認機能ではありません。

楽楽販売には、承認済み見積書を発行し顧客へメール送信できる機能があります。ただし、Dynamics 365 Salesの改版と同じ動作を備えるとまでは読み取れません。製品を選ぶ際は、発行できることに加え、どの承認済み版から発行したかを特定できるか確認します。

Excel台帳から承認と版管理を移す場合は、画面を作る前に現行の列、更新者、提出ファイルの置き場を整理します。Excel業務をシステム化する進め方も、移行範囲を決める際の手掛かりになります。

架空見積の版別受入テスト

分岐表は、境界の前後と改版後の提出制御まで動かして初めて確かめられます。次のテストも設計説明用の架空例であり、実在する顧客の見積や導入実績ではありません。

定価合計は税抜100万円で固定します。V1の税抜見積総額は92万円なので、値引き額は8万円、値引き率は (1,000,000－920,000)÷1,000,000×100＝8.0% です。V2は税抜89万円で、値引き額11万円、値引き率は (1,000,000－890,000)÷1,000,000×100＝11.0% です。金額は同じ明細範囲・同じ税抜基準で比較します。この架空例では値引き率の表示だけを小数第1位に丸め、承認条件は丸める前の値で判定します。定価合計がゼロまたは未入力なら値引き率を計算できないため、申請を確認待ちにします。

境界そのものも別に試します。いずれも定価合計は税抜100万円です。

V1とV2はともに総額100万円未満ですが、値引き率は架空の境界値10%をまたぎます。ここでV2に営業部長承認が追加されなければ、金額条件しか動いていません。追加されたとしても、未承認のV2を提出できたり、V1がV2で上書きされたりするなら、承認経路と版管理がつながっていません。

受入条件には、版識別、再申請、提出可否を同じシナリオで含めます。開発範囲を見積もる際は、承認画面に加えて、権限、データ移行、帳票出力、メール送信などの連携範囲を分けて確認します。業務システムの開発費用を左右する要素を先に整理しておくと、承認機能の周辺まで見積範囲に含めるか判断しやすくなります。

導入前に確定する要件

見積承認の要件は、次の順で確定させます。

1. 金額、値引き率、担当、部門など、承認経路を変える条件を列挙する
2. 条件が重なったときの承認順と、同じ承認者への重複回付を決める
3. 差し戻し状態、修正担当者、再申請先を決める
4. 承認済み版を変更できない状態にし、変更時の改訂版作成方法を決める
5. どの変更で承認を取り直すか、承認を引き継げる変更はあるかを決める
6. 改版中の旧版も含め、顧客へ提出できる版を決め、境界値と改版を受入テストにする

見積規程と実際の見積書を並べ、金額、値引き率、担当、部門を変更した場合の再承認条件を分岐表へ書き込みます。そのうえで、承認された内容と提出する版が一致するかを版別テストで確認します。自社の見積規程に合わせて、連携・移行・権限・データ出力をどこまで含めるか整理したい場合は、業務アプリの相談で確認できます。