EC-CUBEでBtoBの承認フローをどう設計する？多段階承認・権限管理の考え方

この記事でわかること
「一定金額以上は上長の承認を必須にしたい」「発注担当者と承認者を分けたい」「担当→部長→経理と多段階で承認したい」——BtoB-ECでは、こうした承認フローが必要になることがあります。この記事では、承認フローをEC-CUBEでどう設計するかを、承認のパターンの整理から、ロール・履歴・通知の設計まで解説します。ポイントは、ステータスを追加すれば完成するものではなく、業務のどこで承認を挟むかを設計することです。

まず整理：承認フローには複数のパターンがある

「承認フロー」といっても、内容は一つではありません。次のようなパターンがあり、自社がどれに該当するかを整理することが第一歩です。

複数のパターンが組み合わさることもあります。まず、自社の発注・承認プロセスがどうなっているかを整理することが、設計の出発点になります。

承認フロー設計の出発点：「申請・承認・正式発注」をどこで分けるか

承認フローの設計で、最初に決めておきたいのが、「申請」「承認」「正式な発注」を、業務のどのタイミングで分けるかです。ここが、承認フロー設計の核になる部分です。

たとえば、承認の対象が「発注前の申請」なら、承認待ちの段階では、まだEC-CUBE上の正式な受注として扱わない設計も考えられます。逆に、注文を生成したうえで、承認状態を持たせる設計も考えられます。どちらが適しているかは、業務の流れによって変わります。

金額基準の承認一つをとっても、承認対象をどの時点で生成するかによって、設計は変わります。受注ステータスを拡張して管理する方法のほか、申請・承認の状態を別途管理する設計も考えられます。「承認ステータスをいくつか追加すれば完成」ではなく、業務のどこで承認を挟むかを先に決めることが大切です。

ロール（権限）の設計

承認フローでは、誰が申請し、誰が承認するかという、役割（ロール）の設計が必要になります。

• 一般ユーザー（申請者）
• 承認者
• 最終承認者
• 法人管理者

ロールを明確に定義しておかないと、「誰が承認者なのか」が曖昧になり、運用で混乱が生じることがあります。特に、法人顧客が複数のユーザーを持つ場合（発注担当・承認者・管理者など）は、法人ID・部署ID・ロールといった単位で、ユーザー管理を階層化する設計が必要になることがあります。

この場合、法人・部署・ロールをEC側で管理するなら、標準の会員情報だけでは要件を満たさず、データ構造の追加・拡張を検討することになります。一方で、外部の組織マスタ（人事システムなど）を正本にして連携するケースも考えられます。どこで組織・権限を管理するかを、あわせて整理することが大切です。データ構造の考え方は、DB構造・Entity設計の解説もご覧ください。

多段階承認の設計

担当者→部長→経理のような多段階承認では、単純な状態の切り替えだけでは足りないことがあります。次のような要素を、構造として設計することになります。

• 承認の順序の管理
• 承認履歴の管理
• 差し戻しの処理
• 再申請の処理

単純なフラグ（項目）を一つ追加するだけの設計では、後から段階を増やす際に、対応しにくくなることがあります。将来、承認の段階が変わる可能性も想定して設計しておくことが役立ちます。

承認履歴の設計

BtoBでは、「誰が・いつ・どの注文を・承認／却下したか」という履歴が求められることがあります。こうした履歴を、注文データとは別のテーブルで保持する設計にすることで、後から承認の経緯を確認しやすくなります。監査や、社内での確認が必要な場合に、役立つ構造です。

通知の設計

承認フローでは、通知の設計も大切です。承認待ちが放置されると、発注が進まないことがあるため、次のような通知を検討します。

• 承認者へのメール通知
• 管理画面での通知
• 未承認のリマインド

誰に、どのタイミングで通知するかを設計しておくことで、承認の停滞を防ぎやすくなります。

EC-CUBEでの実装の考え方

承認フローは、EC-CUBEの標準機能に含まれているものではありません。実装する場合は、次の切り分けで考えます。

• 標準機能で対応できる範囲（受注ステータスの活用など）
• プラグインを検討する範囲
• 個別開発を検討する範囲（多段階承認・組織階層・履歴管理など）

単純な承認であれば、既存の仕組みを活かせることもありますが、多段階承認や組織階層が関わる場合は、個別の設計・開発を検討することになります。EC-CUBEはオープンソースのため、承認のロジックを業務に合わせて設計できる自由度があります。

SaaSとの違い

SaaS型のECにも、承認機能が用意されていることがあります。標準的な承認フローであれば、SaaS型で対応できることもあります。一方、多段階承認や、業界特有の承認条件、基幹連携を前提とした設計になると、SaaS型では制約が出ることがあります。承認フローの要件によって、適した選択肢が変わります。

承認フロー設計で注意したいこと

• 価格設計と切り離して考える：承認の条件と価格の条件が関わる場合、両方を整理しておかないと、運用で食い違いが生じることがあります。価格設計は複雑価格の設計の記事もご覧ください。
• ロールの定義を曖昧にしない：誰が承認者なのかが不明確だと、運用で混乱が生じることがあります。
• 将来の変更を想定する：1段階の承認から2段階へ、といった変更に対応できる構造にしておくことが役立ちます。

まとめ

EC-CUBEでBtoBの承認フローを設計するには、ロールの設計、承認状態の設計、履歴の管理、通知の設計を、構造として整理することが大切です。そして、その前提として、「申請」「承認」「正式な発注」を業務のどのタイミングで分けるかを決めることが、出発点になります。「承認ステータスを追加すれば完成」ではなく、業務のどこで承認を挟むかを設計することが、承認フローの実装範囲やデータ構造を整理するうえで重要です。

私たちサンクユーは、BtoB-ECの承認フロー設計や、法人向けのユーザー・権限管理、基幹システムとの連携に対応しています。「この承認フローはECで実現できるか整理したい」といった段階から、ご相談いただけます。まずは、現在の発注・承認プロセスをお聞かせください。