概要
月報を修正・削除する機能です。
勤務時間も休憩時間も自由に変更できます。(後述の問題あり)
登録時に入力チェックを行います。有給休暇を取得した日に勤務時間を入力するなど、異常な状態での登録ができないようになっています。
仕様
月報修正の可否について
厚生労働省から資料が出ています。
https://www.mhlw.go.jp/file/06-Seisakujouhou-11200000-Roudoukijunkyoku/0000149439.pdf
本格的な勤怠管理システムを作る場合、自己申告制は避けた方が良さそうです。
当システムの「月報を手動で自由に修正できる」仕様も問題アリという事になります。
下記の文はダメな仕様の例として眺める程度にしてください。
当システムでは自由に手入力できる仕組みにしました。
理由①
自己申告を認めない仕様にする場合、打刻の修正を申請する機能、承認する機能、承認依頼が来ていることを通知する機能 を付ける必要があり、実装が面倒です。
理由②
私の身の回りを基準に考えた場合、現に自己申告制で運用できています。
仮に打刻の修正に申請・承認が必要な方式にした場合、客観的な記録と照らし合わせる手順は無視されて、「承認ボタンを押す手間だけが増えた」という結果になるだろうと予測しました。
理由③
定時に打刻させ、その後残業させるような運用が行われている場合、打刻の修正申請・承認機能を搭載しても効果がありません。月報作成時に簡単に帳尻合わせができる仕組みにしておけば、密かに正確な打刻が行われる可能性が高まります。
当システムでは、自身の打刻データを自由にダウンロードできる機能があります。「打刻データを労働基準監督署に送れる」という点で不正な運用の抑止力になると考えました。
入力項目
| 項目名 | 説明 |
|---|---|
| 開始 | 勤務開始時刻です。自由に入力できます。 |
| 終了 | 勤務終了時刻です。自由に入力できます。 勤務開始時刻以下の値を入力した場合、翌日の時刻として扱います。 当システム全体として、1分未満の労働には対応していません。 30秒だけ労働した場合は、繰り上げて1分労働したものとして入力する必要があります。 |
| 休憩 | 開始～終了の時間帯と、強制休憩の時間帯が重なっている場合、休憩時間として扱います。 |
| 強制休憩 | 「強制休憩」とは、特定の時間帯を自動的に休憩時間として扱う当システム独自の仕組みです。 この仕組みにより、休憩打刻が不要になります。 何かの理由で休憩時間中にも労働した場合、チェックをOFFにして、実際に休憩した時間帯を入力します。 |
| 前日からの継続勤務 | 徹夜して日付変更線を超えて働いた場合にチェックをONにします。 この項目の使い道について 残業代の計算をするとき、たとえ前日からの継続勤務であっても、システム内で設定した日付変更線を超えた後は残業扱いにする必要はありません。 (暦日ではなく日付変更線を境にする→昭和63年1月1日基発1号) (日付変更線を超えたら残業扱いでなくても良い→平成11年3月31日基発168号 ※原文が見当たりませんでした。) しかし、企業の判断で残業扱いにする可能性は有り得ます。 よって、継続勤務かどうかを判定する方法は用意しておいた方が良いだろうと考えました。 前日の勤務終了時刻を見れば自動判定できるのですが、月初日の前日はデータの取得が面倒なので、ユーザーに入力してもらう仕組みにしました |
修正機能の実現方法
月報を新規作成するときは打刻データを元にしています。
月報修正時も同じような構造のデータを元にすれば、ロジックが流用できて便利です。
当システムの場合、月報修正画面で入力された値は一旦「仮打刻」テーブル(打刻データと同じ構造)に保存して、月報修正時は仮打刻テーブルから値を取得するという仕組みにしました。
チケットデータの作り直し
月報を修正したとき、労働時間が変化した場合は代休チケットを作り直します。
同月内で既に代休チケットを消費している場合、代休チケットをユーザーに無断で消滅させます。ユーザーはチケットの作り直しが必要になります。
良い仕様ではないと分かっているのですが、代案が思い浮かびませんでした。発生頻度も少ないはずなので、放置しています。
消滅とは逆のパターンで、月報の修正によって代休発生の条件を満たした場合、代休を自動発生させます。
経緯
当システムでは、長時間残業した場合や休日出勤した場合に代休を自動発生させる機能があります。
月報の修正によって代休発生の前提条件が崩れてしまう場合があるため、月報修正のたびに代休発生条件の再チェック処理を行っています。
代休チケットの作り直しを最小限に抑えるため「労働時間が変化した場合は」という条件を付け加えています。
承認データの引継ぎ
月報を修正したとき、内部的には月報データをDelete→Insertしています。
月報の申請・承認業務は最初からやり直しになるため、承認状態データは破棄します。
一方で、却下時に入力されたコメントは残しておく必要があるため、月報承認コメントデータは月報IDを付け替えて保持しています。