稟議の記録を残す：差し戻しの理由と承認の履歴

金額で承認者が変わる稟議の記事で、承認の履歴が残らないと書きました。承認フローと通知メールの記事でも、差し戻しの理由を残せないと書いています。

差し戻しの理由は3本続けて宿題にしてしまいました。片付けます。

作るもの

承認画面に、その発注がここまでどう回ってきたかを出します。

課長が限度額を超えて上長へ回した、という1行が残っています。部長はこれを見てから判断できます。

やることは3つです。

受注に列を足さなかった理由

最初に考えたのは、受注に「差し戻し理由」の列を1つ足すことでした。それなら前回と同じやり方で済みます。

やめました。稟議は1回では終わらないからです。

課長が上長へ回して、部長が承認する。この会社なら2行。金額帯を4つに分けている会社なら、もっと増えます。何回起きるか決まっていないものを、受注の列には書けません。

記録用のテーブルを1つ作りました。持たせたのはこれだけです。

app/Customize/Entity に置いたエンティティは、本体の拡張とは違って新しいテーブルとして扱われます。 リポジトリも自分で書きます。とはいえ本体のリポジトリと同じ書き方で済むので、特別なことはありません。

名前を二重に持っている

承認者への参照とは別に、名前を文字列で控えています。

冗長に見えますが、理由があります。担当者アカウントは管理者が削除できます。削除といっても実際にはステータスを退会にしてメールアドレスを解放するだけですが、会員そのものが消える運用もありえます。

参照だけ持っていると、承認者が消えた瞬間に記録が「誰か分からない承認」になります。稟議の記録としては困る。記録した時点の名前を控えておけば、あとから読めます。

会計や監査の記録では珍しくない持ち方です。参照は「いまの状態」を、控えた値は「そのときの事実」を表します。

差し戻しには理由を必須にする

差し戻しのボタンの上に、理由の入力欄を置きました。空のまま押すと差し戻せません。

理由のない差し戻しは、担当者にとって何の情報にもなりません。次に何をすればいいのか分からない。入力させるほうが親切です。

入力された理由は2箇所に流れます。記録のテーブルと、担当者に届く結果メールです。

メールのテンプレートは前回作ったものに理由の欄を足しただけです。テンプレートはマスタに登録してあるので、文面は管理画面から直せます。

経緯の出し方

承認画面で受注を並べるとき、それぞれの記録も一緒に引いています。受注の一覧を回しながら1件ずつ問い合わせる形なので、承認待ちが大量にあると問い合わせの回数が増えます。

承認待ちは多くても数十件なので、そのままにしました。 気になるなら受注IDをまとめて渡して一度に引き、受注ごとに振り分ければ済みます。件数が増えてから直せば十分だと判断しました。

割り切ったところ

管理画面から見られません。 記録が見えるのはマイページの承認画面だけです。店舗側は「承認待ちだった受注が新規受付になった」ことしか分かりません。追えるようにするなら受注編集の画面に差し込むか、受注のメモ欄へ書き出すことになります。

承認した受注の記録は、承認後に見えなくなります。 承認画面は承認待ちのものだけを並べるので、確定した受注の経緯はどこにも出ません。記録は残っているので、担当者の注文履歴の詳細に出す手はあります。

差し戻した理由を担当者が読み返せません。 メールには載りますが、サイト上では見えません。同じく履歴の詳細に出すのが素直です。

理由の長さを制限していません。 テキスト型なので、いくらでも書けます。運用に乗せるなら上限を決めてください。

記録を後から直せません。 書き間違えても消せない作りです。稟議の記録としてはそのほうが正しいと思いますが、テスト中に困ることはあります。

EC-CUBE 4.2 / 4.3 での違い

新しいテーブルを1つ作るだけなので、本体のバージョンによる違いはほとんどありません。変わるのはいつもどおり、エンティティのマッピングをアノテーションで書くか属性で書くかです。

app/Customize/Entity に置いたエンティティが独立したテーブルとして扱われる仕組みも、4.2 から同じです。変更点の全体はEC-CUBE 4.4 でプラグインが動かなくなる変更点にまとめています。

会員グループ管理を入れている場合

稟議の記録は会員グループを見ていません。誰が操作したかを残すだけなので、会員グループ管理プラグインの有無で挙動は変わりません。

B2B サイト全体でどこまでが標準・プラグインで、どこからが作るものになるのかは、B2Bサイト全体の線引きにまとめました。