承認フローの記事と通知メールの記事で、同じことを2回書きました。承認できるのは管理者1人だけです、と。
実際の稟議はそうなっていません。10万円までは課長、それを超えたら部長。よくある形です。作ります。
作るもの
担当者が発注すると、まず直属の上長に回ります。上長が自分の限度額で足りるなら、そこで確定します。足りなければ、さらに上へ回ります。
画面は EC-CUBE 4.4 の開発環境で、3人のラインを作って動かしたものです。
| 会員 | 上長 | 承認限度額 |
|---|---|---|
| 鈴木（担当者） | 佐藤 | なし（承認できない） |
| 佐藤（課長） | 山田 | 10万円 |
| 山田（部長） | なし | 300万円 |
稟議のラインは、もう持っている
新しい関係を足すか迷いました。「上長」は「会社の管理者」とは別の概念だからです。
足しませんでした。担当者アカウントの記事で作った親子関係を、そのまま稟議のラインとして使います。
あのときは親を1階層しか想定していませんでした。管理者がいて、その下に担当者が並ぶ形です。ただ、関係そのものは「誰が誰の上か」しか表していないので、3階層に伸ばしても意味が壊れません。鈴木の親が佐藤、佐藤の親が山田。これで稟議のラインになります。
会社の概念も変わりません。ラインをいちばん上までたどった人が、その会社の管理者です。
足したのは2つだけ
| 足すもの | どこに | 何のため |
|---|---|---|
| 承認限度額 | 会員 | いくらまで自分の裁量で承認できるか。未設定なら承認できない |
| いま承認を待っている相手 | 受注 | 稟議がどこまで進んだか |
受注ステータスは増やしません。 承認待ちの1つのままです。
ここは迷うところだと思います。「課長承認待ち」「部長承認待ち」とステータスを分ければ、管理画面の一覧で段が見えます。ただ、段を増やすたびにステータスとステートマシンの遷移が増えます。3段なら3つ、金額帯を4つに分けたら4つ。見積依頼の記事で書いたとおり、遷移の名前は在庫やポイントの処理と結びついているので、増やすほど確かめることが増えます。
進み具合は受注が持つ「いま誰の番か」で表せます。 ステータスは1つで足ります。
承認したときに起きること
承認のボタンを押したときの分かれ道は1つです。
- 受注の金額が、押した人の限度額以内なら、そこで確定する。承認者を空にして、受注を新規受付へ進める
- 限度額を超えていたら、その人の上長を新しい承認者にする。ステータスは承認待ちのまま
- 上長がいなければ、承認できない。エラーを出して止める
3つ目は起こりうる状態です。部長の限度額を超える発注が来たら、誰も承認できません。この実装では止めます。 黙って通すより、稟議の設計が足りていないことを画面で知らせたほうがいい。
課長が「上長へ回す」を押すと、部長の画面に現れます。
ボタンの文言も出し分けました。自分で確定できるなら「承認する」、上へ回るだけなら「上長へ回す」。同じ操作でも結果が違うので、押す前に分かるようにしています。
通知は誰に飛ぶか
前回作った通知メールの宛先を変えました。前は「発注した担当者の親」に固定でしたが、いまの承認者に送るようにしています。
そうすると、上長へ回った時点で次の承認者にも通知が飛びます。稟議が自分のところに来たことが分かる。
上の受信箱がそのまま稟議の記録になっています。課長に2件届き、うち1件が部長へ上がり、担当者に結果が2件返っている。
1階層を前提にしていた場所が壊れる
ここが今回いちばん手を入れたところです。前回までの実装は、親子が1階層しかない前提で書いてありました。
| 前回の書き方 | 多段だとどうなるか |
|---|---|
| 承認できるのは「親を持たない会員」 | 課長は親を持つので承認できない |
| 会社の全員＝「自分の直下の子」 | 部長から見て孫にあたる担当者が漏れる |
| ナビに承認待ちを出すのは「管理者」 | 課長に承認タブが出ない |
直し方はそれぞれこうしました。
- 承認できるのは「部下がいる会員」。親の有無ではなく、子の有無で見る
- 会社の全員は、いちばん上までたどってから、そこを起点に下へ全部たどる
- ナビの条件も「部下がいる」に合わせる
とくに2つ目です。 会社単位の注文履歴は、管理者が直下の子の受注を見る作りでした。3階層になると、部長の直下は課長だけなので、担当者の発注が履歴から消えます。階層をまたいで集めるように直しました。
たどる処理には回数の上限を入れてあります。データの持ち方の都合で親子が輪になっていたら、上限がないと止まりません。
割り切ったところ
承認の履歴が残りません。 持っているのは「いま誰の番か」だけです。この続きは稟議の記録を残すに書きました。
差し戻すと最初からです。 途中の誰かが差し戻すと、その受注は注文取消しになります。「課長まで戻す」はできません。
限度額は金額だけで決まります。 商品や取引先で承認者を変える運用には届きません。判定を書いている場所は1つなので、条件を足すこと自体は難しくありません。
代理承認がありません。 課長が不在でも、誰も代わりに承認できません。実際の稟議では代理が要ります。上長を一時的に差し替える仕組みが要るところです。
限度額の設定画面がありません。 いまは直接データを入れています。運用に乗せるなら管理画面の会員編集に項目を足すことになります。
会員グループ管理を入れている場合
稟議のラインは会員グループを見ていません。親子関係だけで決まります。
ただし承認の対象になる範囲は、会員グループ管理プラグインを入れているかどうかで変わります。担当者アカウントの記事で書いたとおり、管理者かどうかの判定にグループを絡めていれば、卸売の会員だけが稟議の対象になります。一般消費者の注文は今までどおり通ります。
B2B サイト全体でどこまでが標準・プラグインで、どこからが作るものになるのかは、B2Bサイト全体の線引きにまとめました。