紙で運用している日報・週報の承認業務を電子化したいという要望はよく頂く相談の１つです。
課題点
その際にご相談頂くポイントは、大きく２つに分類されます。
- 運用：これまでの紙運用から大きく変えると現場が混乱するので、現状の運用をできるだけそのままアプリにしたい
- 費用：全員がアカウントを持っていないため、コスト増とならないようにしたい
今回は、ある程度の自由度を持った承認フローの作成を紹介したいと思います。
最終的には、以下のようなAppsheetが完成します。
お問い合わせ
多少、難易度の高い内容もありますので、もし本内容について自社での構築依頼など、詳細を確認したい場合は、お問い合わせ よりお願い致します！
ご相談内容
今回作成するサンプルとしては、当時頂いたご相談内容を元にしたいと思います。
- これまで通り、承認は、部署内の上位役職者ができるようにしたい
- ただし、役職が１つ上の社員は承認して良いか、それより上の社員が飛び越えて承認は出来ないようにしたい
- また部署ごとの所属人数が異なるため、２～６段階で可変の承認段階が必要
- また、産休などで長期間不在となる場合もあるため、その時はその上の役職の社員が承認出来る必要がある
- 全員がアカウントを持っていないため、コスト増とならないようにしたい
多段承認フォローの基本的な考え方
承認回数を可変に設定できる承認フローをAppSheetで実現するための、設計方針です。まずは要望から必要となる機能を考えます。
- 承認は部署をまたいでは出来ない→部署を判別するために部署マスタが必要
- 承認は役職が上位の者が行う→役職を判別するために役職マスタが必要
- 部署に所属する従業員は、所属する部署と役職をもちマスタで管理する。
- アカウントを持たないユーザも判別できるよう、従業員にはIDとパスワードを持たせ、UserSettingsを使った判定を行う。
- 部署によって承認回数が異なる→部署ごとの承認段階を決めるマスタが必要
- 長期不在に備えた承認者変更が必要→上記の承認段階は固定ではなく可変である必要がある。
テーブル設計としは、以下のテーブルが必要となります。
- マスタ
- 部署
- 役職
- 部署別承認段階
- 従業員
- トランザクション
- 日報
- 日報承認ログ
上記のテーブルを、１つずつ検討していきます。
テーブル設計
マスタ
まずはマスタデータから検討していきます。
１．部署
従業員が配属される部署を管理するマスタです。承認者も部署をまたがって承認することが出来ないよう制御するために必要となります。
| 部署ID | 部署名 |
| B1 | 管理部 |
| B2 | 公共事業部 |
| B3 | 金曜事業部 |
| B4 | 産業事業部 |
２．役職
組織上の役職を管理するマスタです。上位の役職者が、自身の部下の日報を承認できるよう制御するために必要となります。
どちらが上位の役職であるかを判定するために、「承認権限」項目を用いて判定します。
| 役職 | 役職名 | 承認権限 |
| M6 | 代表取締役 | 80 |
| M5 | 本部長 | 70 |
| M4 | 部長 | 60 |
| M3 | 部長代理 | 50 |
| M2 | 課長 | 40 |
| M1 | 課長代理 | 30 |
| T3 | 係長 | 20 |
| T2 | 主任 | 10 |
| T1 | 担当 | 0 |
３．従業員
会社に所属する従業員を管理するマスタです。従業員には所属する「部署」と、職位を表す「役職」をもたせます。
これにより、ログインしたユーザごとに、誰を承認出来るかを判定し、制御することが出来ます。
| 従業員ID | 従業員名 | メールアドレス | パスワード | 部署 | 役職 |
| J001 | Aさん | A@m.com | AAAA | B2 | M6 |
| J002 | Bさん | B@m.com | BBBB | B2 | M5 |
| J003 | Cさん | C@m.com | CCCC | B2 | M4 |
| J004 | Dさん | D@m.com | DDDD | B2 | M3 |
| J005 | Eさん | E@m.com | EEEE | B2 | M2 |
| J006 | Fさん | F@m.com | FFFF | B2 | M1 |
| J007 | Gさん | G@m.com | GGGG | B2 | T4 |
| J008 | Hさん | H@m.com | HHHH | B2 | T3 |
| J009 | Iさん | I@m.com | IIII | B2 | T2 |
| J010 | Jさん | J@m.com | JJJJ | B2 | T1 |
また従業員にはIDとパスワードを持たせ、UserSettingsの機能で簡易ログイン機能を実装します。詳細な実装方法は別の記事をご参考いただければと思います。
４．部署別承認段階
部署ごとに所属人数が異なるため、承認する回数や初回承認者の権限も変えたいとの要望ですので、それを実現するために部署ごとに、承認段階と承認権限をもたせます。
このマスタが今回の肝です。
| 部署ID | 部署名 | 承認段階 | 承認権限 |
| B2 | 公共事業部 | 1 | 10 |
| B2 | 公共事業部 | 2 | 20 |
| B2 | 公共事業部 | 2 | 30 |
| B2 | 公共事業部 | 3 | 40 |
| B2 | 公共事業部 | 4 | 50 |
| B2 | 公共事業部 | 5 | 60 |
| B2 | 公共事業部 | 6 | 70 |
| B3 | 金曜事業部 | 1 | 30 |
| B3 | 金曜事業部 | 2 | 40 |
| B3 | 金曜事業部 | 3 | 50 |
| B3 | 金曜事業部 | 4 | 60 |
トランザクション
各担当者が作成する日報についてです。ポイントは日報の承認ログを残すためのテーブルを用いるところです。
１．日報
日報ですので、いつ・だれが報告したか分かるように、作成者と日付をもうけます。また作業時間の管理のために作業の開始時刻・終了時刻も保持します。
| 日報ID | 作成者 | 日付 | 開始時刻 | 終了時刻 | 報告 |
| 1cfad838 | J010 | 2024/11/24 | 8:50:00 | 17:00:00 | 予定どおり |
| 7b87a0e7 | J010 | 2024/11/24 | 8:50:00 | 17:09:00 | １日遅延 |
| eca702e3 | J008 | 2024/11/24 | 8:50:00 | 20:34:00 | １日前倒し |
２．日報承認ログ
日報の承認ログを残すためのテーブルです。このテーブルを用いて、各日報がどういう状態かを判定します。
まず、「承認区分」をもたせ「承認／非承認」が分かるようにします。合わせて、誰が承認したかを後で追えるように、「承認者」も持たせます。
非承認の際は、なぜ非承認となり、何を修正しないといけないか作成者が分かるように「コメント」を残せるようにします。
また、「部署」「承認段階」を持たせることで、次に承認できる人が誰かを判定できるようにします。
| 日報ID | 日時 | 承認区分 | 承認者 | 部署 | 承認段階 | 権限 | コメント |
| 7b87a0e7 | 11/24/2024 21:09:10 | 承認 | J001 | B2 | |||
| 1cfad838 | 11/24/2024 21:09:16 | 非承認 | J008 | B2 | 1 | 10 | |
| 1cfad838 | 11/24/2024 21:12:21 | 非承認 | J009 | B2 | 1 | 10 | 時刻が不正です。 |
画面
必要最低限の画面構成として、以下の３つを用意します。
| ログイン | 簡易ログイン認証 |
| 日報 | 日報作成のための画面 |
| 日報一覧 | 自分が作成した日報の一覧 |
| 承認待ち一覧 | 部下の承認待ちの日報一覧 |
ログイン画面
メニューのSettingsをクリックすることで、UserSettingsを開きます。
そこにIDとパスワードを入れてユーザ情報を保存します。
設定の詳細は、以下の記事を参考頂ければと思います。
日報
日報の作成画面です。従業員はこの画面から日報を入力します。
日報一覧
日々入力した日報を確認する画面です。
ログインした（UserSettingsで設定した）アカウントの日報だけを表示する必要があるため、スライスを作成します。
日報テーブルに「ログインユーザ日報」のスライスを作成します。
Row filter conditionには、日報の作成者が一致するデータだけを表示するように設定します。
count(
filter("日報",
and(
[_THISROW].[作成者].[従業員ID]=USERSETTINGS("ID"),
[_THISROW].[作成者].[パスワード]=USERSETTINGS("Password"))
)
)>0
これにより、ログインした（UserSettingsで設定した）ごとに表示されるデータ合を出し分けることが可能です。
たとえは「J0080」であれば、
J080のユーザの日報のみが表示されます。
ユーザを「J010」に変えると、
J010のユーザの日報が表示されます。
承認待ち一覧画面
最後に、承認待ち一覧画面です。
ログインユーザに承認（または非承認）をしなければならない日報を表示する画面になります。
承認・非承認ボタンを追加します。このボタンには、部署や役職に応じて、アクションの実行可否を制御する必要があります。
また、承認・非承認ボタンを押すことで「日報承認ログ」に記録を残すようにします。これにより、各日報の承認段階を制御するようにします。
承認ボタン
承認ボタンを押すことで、「日報承認ログ」にデータを追加します。
部署：
any(SELECT(従業員[部署],[従業員ID]=USERSETTINGS("ID")))承認段階
any(
SELECT(部署別承認段階[承認段階],
and(
[承認権限]=any(
SELECT(役職[承認権限],[役職]=
any(
SELECT(従業員[役職],
[従業員ID]=USERSETTINGS("ID")
)
)
)
),
[部署ID]=any(
SELECT(従業員[部署],
[従業員ID]=USERSETTINGS("ID")
)
)
)
)
)権限：
any(
select(
役職[承認権限],
[役職]=any(SELECT(従業員[役職],[従業員ID]=USERSETTINGS("ID")))
)
)Behaviorの「Only if this condition is true」には、承認段階に応じてアクションの表示・非表示が正しく出るように設定できるようにします。
[承認段階]=any(
SELECT(部署別承認段階[承認段階],
and(
[承認権限]=any(
SELECT(役職[承認権限],[役職]=
any(
SELECT(従業員[役職],
[従業員ID]=USERSETTINGS("ID")
)
)
)
),
[部署ID]=any(
SELECT(従業員[部署],
[従業員ID]=USERSETTINGS("ID")
)
)
)
)
)-1非承認ボタン
非承認のアクションは、非承認の理由をコメントできるように「非承認ログ_Form」画面を開くようにします。
画面の表示する「Target」に以下の設定します。
LINKTOFORM(
"日報承認ログ_Form",
"承認区分","非承認",
"日報ID",[日報ID],
"日時",NOW(),
"承認者",USERSETTINGS("ID"),
"部署",any(SELECT(従業員[部署],[従業員ID]=USERSETTINGS("ID"))),
"承認段階",
any(
SELECT(部署別承認段階[承認段階],
and(
[承認権限]=any(
SELECT(役職[承認権限],[役職]=
any(
SELECT(従業員[役職],
[従業員ID]=USERSETTINGS("ID")
)
)
)
),
[部署ID]=any(
SELECT(従業員[部署],
[従業員ID]=USERSETTINGS("ID")
)
)
)
)
),
"権限",any(select(役職[承認権限],[役職]=any(SELECT(従業員[役職],[従業員ID]=USERSETTINGS("ID")))))
)上記の設定を行うことで、「非承認」ボタンをおすと
以下のように承認ログを表示できます。この画面で、コメントを入力することができます。
また承認アクションと同様に、Behaviorの「Only if this condition is true」には、承認段階に応じてアクションの表示・非表示が正しく出るように設定できるようにします。
[承認段階]=any(
SELECT(部署別承認段階[承認段階],
and(
[承認権限]=any(
SELECT(役職[承認権限],[役職]=
any(
SELECT(従業員[役職],
[従業員ID]=USERSETTINGS("ID")
)
)
)
),
[部署ID]=any(
SELECT(従業員[部署],
[従業員ID]=USERSETTINGS("ID")
)
)
)
)
)-1アプリの完成
アプリが完成しました。
- 運用：ある程度の自由度を持った承認フローの作成しましたので、これまでの紙運用にできるだけ近づけ、現場の混乱を低減できるのではと思います。
- 費用：またUserSettingsを利用することで、全員がアカウントを持っていないなくとも利用が出来、コスト低減が出来ると思います。（情報漏洩の観点から社内利用が前提です。）
お問い合わせ
相談やお問合せは、お問い合わせ よりお願い致します！
コメントを残す