書き出した数字は、そのまま使える数字ではない
勤怠システムは予定を超えた時間をすべて残業として数えますが、会社が支払うのは承認を通った分だけ、というのが普通です。誰かが 1 行ずつ差を拾い、痕跡を残し、翌月また同じことをします。
勤怠の月次締め：3 日がかりの書き出しと催促から、定時実行 1 回へ
勤怠で難しいのは、表を書き出すことではありません。難しいのは定義です。システムが残業と見なす範囲は会社のそれと違い、給与計算期間は暦月と一致しません。このラインが実際にどう回るかを書きます。
01
引き受ける前、どこで詰まっていたか
月をまたぐ給与計算期間は、2 回の書き出しと手作業の結合を意味する
期間が暦月でない瞬間——たとえば 26 日から翌月 25 日——書き出しは 2 回になり、つなぎ合わせる必要が出ます。つなぎ方を誤れば、残業も欠勤もすべて狂います。しかも気づきにくい形で。
例外の通知は手間がかかり、いちばん間違えやすい
遅刻、打刻漏れ、労働時間の不足は、正しい部門責任者に届かなければなりません。手作業だと、ある部門を落とすか、全社の一覧を全責任者に送るかのどちらかになります。後者のほうが悪い。
02
引き受けたあと、どう回るか
給与計算期間に合わせて取得し、月をまたぐ場合は自動で分割・再結合
期間の境界は設定であり、暦月に固定されません。月をまたぐ期間は 2 回に分けて取得し、人ごとに再結合します。今月は書き出しが 2 回必要だと、誰かが覚えておく必要はありません。
残業は承認済みのみ、休暇は御社の区分に合わせる
残業の列に入るのは承認済みの時間だけで、休暇の区分はツールの既定ではなく、御社がすでに使っている名称に対応付けます。
すでに使っている表と同じ形の月次サマリー
列名と並び順は既存のテンプレートに従います。給与計算をする人が、まず整形し直すことなくそのまま使えます。
例外はルールで格付けし、各責任者には自部門だけを届ける
ルールは設定できます——遅刻が何回連続したら、打刻漏れが何件、何時を超えたら。責任者は設定に固定せずディレクトリから解決するので、異動は翌月には反映されます。
スケジュールで動く
日次のリマインド、月曜のまとめ、月末の定型実行が、それぞれのタイミングで動きます。誰かがカレンダーを見張る必要はありません。
03
どこで必ず人を待つか
- 全社の一覧は、どの部門責任者に届く前にも人事の確認を通ります
- 変更した定義は次の実行から効きます。バージョン更新も再インストールも要りません
- 外部への送信は、必ず人の承認を待ちます
どう受け入れるか
- 数人をサンプルにして、出力をシステムの生記録と 1 行ずつ突き合わせる
- すでに手作業で終えた月を再実行する。結果はその版と一致するはずです
- サマリーは手作業の列修正なしで、そのまま給与計算に流し込める
04
定義はどこから来るか
06
よくある質問
勤怠データはどこへ行きますか？
取得と計算は、デスクトップ版が入っている PC 上で実行されます。ネットワークに出るのは選んだモデルの呼び出しだけで、出るのはタスクの説明文であり、名簿ではありません。法人導入では、その呼び出しを自社ゲートウェイ経由にできます。
残業のルールが特殊ですが、対応できますか？
ルールはコードではなく設定です。承認済みのみ、段階的な換算、休日の割増といった一般的な形はパラメータで表現します。本当に特殊な計算式は、導入時に一度すり合わせ、以降は毎月それを使います。
各責任者に自部門だけを届けられますか？
それが既定です。配信は部門ごとに分け、責任者はディレクトリから取ります。全社の一覧は人事にだけ届きます。
月中に定義が変わったら？
次の実行から効きます。再インストールも、リリース待ちもありません。