Aplikasi timesheet dengan aturan lembur: pengiriman mingguan dan persetujuan

Apa yang harus diselesaikan oleh aplikasi timesheet ini

Aplikasi timesheet dengan aturan lembur sebenarnya bukan hanya soal melacak jam. Ini tentang mencegah kebingungan, mengurangi kesalahan pembayaran, dan memberi semua orang proses yang dapat diprediksi.

Saat timesheet disimpan di spreadsheet atau pesan chat, masalah kecil cepat menumpuk. Orang menggunakan template berbeda, lupa mencatat istirahat, atau mengubah entri kemudian tanpa ada yang menyadari. Manajer menghabiskan waktu mengejar jam yang hilang alih-alih memeriksa apakah minggu itu masuk akal. Menjelang hari payroll, Anda merakit informasi parsial dan berharap itu sesuai dengan ingatan karyawan.

Lembur adalah tempat perselisihan mulai muncul. Jika aturan tidak konsisten (atau tidak ditulis agar mudah diikuti), dua karyawan dengan jadwal yang sama bisa dibayar berbeda. Bahkan saat semua pihak berniat baik, aturan yang tidak jelas menciptakan pekerjaan ulang: perhitungan ulang, edit retroaktif, dan percakapan canggung.

Persetujuan adalah gerbang pengaman sebelum uang bergerak. Langkah persetujuan oleh manajer mengonfirmasi minggu sudah lengkap, kode pekerjaan atau proyek (jika dipakai) masuk akal, dan lembur dapat dibenarkan. Ini juga menciptakan momen jelas “ini final”, sehingga payroll tidak menarik angka dari draf yang masih berjalan.

Pengiriman mingguan sebaiknya menjadi kebiasaan sederhana: semua orang bekerja dalam minggu kerja yang ditentukan (misalnya, Senin–Minggu), mengirimkan sebelum batas waktu yang jelas (misalnya, Senin jam 10:00), dan menerima pengingat sebelum tenggat. Setelah dikirim, edit sebaiknya diblokir atau memerlukan persetujuan ulang, dan status harus jelas (Draft, Submitted, Approved, Rejected).

Persyaratan inti dan batasannya

Aplikasi seperti ini hanya bekerja jika semua orang setuju pada dasar-dasarnya sejak awal: kapan orang mengirim, siapa yang bisa mengubah apa, dan apa yang dihitung sebagai lembur. Jika Anda tidak menetapkan batasan awal, aplikasi berubah menjadi argumen mingguan.

Mulailah dengan ritme pengiriman. Pengiriman mingguan menjaga semuanya sederhana untuk sebagian besar tim: orang dapat memasukkan waktu selama minggu berjalan, lalu mengirim sekali. Batasan kunci adalah apakah Anda mengizinkan edit setelah pengiriman. Aturan umum adalah entri tetap dapat diedit sampai tombol Submit mingguan ditekan.

Aturan lembur harus tak ambigu. Tentukan apakah lembur dipicu oleh batas harian (misalnya, lebih dari 8 jam per hari), batas mingguan (lebih dari 40 jam per minggu), atau keduanya. Jika keduanya berlaku, nyatakan mana yang menang saat keduanya tumpang tindih agar tidak menghitung lembur dua kali.

Persetujuan manajer harus tetap dalam loop yang ketat sehingga cepat digunakan: approve (jam menjadi final), request changes (karyawan mengedit dan mengirim ulang), atau reject (karyawan memperbaiki dan mengirim ulang).

Setelah disetujui, kunci periode tersebut. Penguncian mencegah edit menit-menit terakhir dan menjaga konsistensi payroll. Jika koreksi diperlukan, gunakan aksi “unlock dengan alasan” yang merekam siapa yang membuka kunci dan mengapa.

Ekspor payroll harus berisi hanya jam yang disetujui. Jadikan itu batas keras: apa pun yang belum disetujui tetap keluar dari ekspor, meski terlihat lengkap.

Data yang harus Anda simpan (tanpa membuatnya berbelit)

Tujuannya bukan melacak segala hal. Ini menangkap cukup untuk menghitung jam, menerapkan kebijakan, dan membuktikan siapa yang menyetujui apa.

Mulailah dengan peran. Kebanyakan tim membutuhkan tiga: karyawan yang memasukkan waktu, manajer yang menyetujui, dan payroll (atau admin) yang bisa mengekspor dan menangani pengaturan. Permisi tetap sederhana agar orang tidak terblokir.

Catatan minimum yang perlu disimpan

Pikirkan dalam tiga lapis: orang, timesheet mingguan, dan entri waktu individual.

Simpan data dasar tiap orang (nama, ID karyawan atau email, peran, manajer, dan tim atau cost center). Untuk setiap timesheet, simpan pemilik, tanggal mulai minggu, zona waktu yang digunakan untuk minggu itu, dan status (Draft, Submitted, Approved, Rejected). Untuk setiap entri waktu, tangkap tanggal, jam mulai, jam selesai, menit istirahat, proyek atau tugas, dan catatan singkat.

Anda juga ingin pengaturan kalender seperti hari mulai minggu (Senin atau Minggu) dan zona waktu yang akan dipakai untuk aturan. Jika payroll memerlukannya, tambahkan konteks opsional seperti lokasi atau departemen.

Bidang persetujuan dan audit yang akan berguna

Persetujuan adalah tempat perselisihan terjadi, jadi simpan jejak audit kecil yang membosankan dan jelas:

• Submitted at, submitted by
• Approved at, approved by
• Rejected at, rejected by, rejection reason
• Last edited at, last edited by
• Locked flag (untuk mencegah edit setelah persetujuan)

Contoh: seorang karyawan di Berlin mengirim pada Minggu malam. Jika Anda menyimpan zona waktu yang digunakan untuk minggu itu, Anda menghindari masalah klasik di mana waktu pengiriman terlihat seperti Senin untuk manajer di New York.

Jika Anda hanya menangkap bidang-bidang ini, Anda bisa menjalankan aturan lembur, mengarahkan persetujuan, dan mengekspor total bersih ke payroll tanpa mengubah aplikasi menjadi sistem HR yang kompleks.

Tuliskan aturan lembur dalam bahasa yang sederhana dulu

Tulis kebijakan sebagai kalimat sederhana yang bisa dibaca siapa saja. Jika Anda tidak bisa menjelaskannya dengan jelas, aplikasi akan menimbulkan kejutan di payroll.

Mulailah dengan memilih pemicu: lembur setelah 8 jam per hari, setelah 40 jam per minggu, atau keduanya. Jika menggunakan keduanya, tentukan urutannya. Pilihan umum adalah menghitung lembur harian dulu, lalu menerapkan lembur mingguan hanya pada jam reguler yang tersisa.

Jelaskan dengan tegas waktu apa yang dihitung. Istirahat yang tidak dibayar bisa mengubah semuanya, jadi katakan secara jelas: “Makan siang tidak dibayar dan tidak dihitung sebagai jam kerja.” Jika Anda melakukan pembulatan waktu, tulis juga. Misalnya: “Bulatkan setiap clock-in dan clock-out ke kelipatan 5 menit.” Selama sebulan, pilihan pembulatan kecil bisa berakumulasi.

Kemudian atasi hari khusus. Akhir pekan, hari libur, dan waktu perjalanan sering memiliki aturan pembayaran berbeda. Meski Anda tidak membayar ekstra, Anda tetap perlu pernyataan jelas seperti: “Jam Sabtu diperlakukan sama seperti hari kerja kecuali total jam mingguan melebihi 40.”

Kalimat kebijakan yang bisa Anda salin dan sesuaikan:

• “Lembur adalah setiap jam kerja lebih dari 8 jam per hari.”
• “Lembur mingguan berlaku hanya setelah 40 jam reguler, tidak termasuk jam lembur harian yang sudah dihitung.”
• “Istirahat tidak dibayar dikecualikan; istirahat yang dibayar dihitung.”
• “Jam hari libur dibayar 1.5x dan tidak dihitung untuk lembur mingguan.”
• “Waktu perjalanan antar lokasi kerja dihitung; perjalanan pulang-pergi dari rumah tidak dihitung.”

Setelah kalimat-kalimat ini disepakati, membangun logika menjadi tugas terjemahan daripada debat.

Langkah demi langkah: alur pengiriman mingguan

Alur mingguan bekerja terbaik ketika semua orang tahu apa yang dihitung sebagai “minggu ini,” dan kapan harus dikirim. Pilih satu hari mulai minggu (sering Senin) dan batas waktu yang jelas (misalnya, Senin jam 10:00 di zona waktu karyawan). Pengiriman terlambat tetap boleh, tapi harus terlihat.

1) Tetapkan periode minggu dan tenggat

Tentukan sebuah minggu sebagai rentang tanggal tetap dan simpan pada timesheet. Ini menghindari kebingungan saat seseorang membuka aplikasi di tengah minggu atau bepergian. Sertakan field status sejak hari pertama (Draft, Submitted, Approved, Rejected).

2) Bangun layar timesheet karyawan (tambah/edit entri)

Permudah pengeditan entri: tanggal, jam mulai, jam selesai (atau total jam), waktu istirahat, proyek atau kode biaya (jika perlu), dan catatan singkat. Biarkan karyawan menyalin entri kemarin dan mengubahnya. Satu pintasan itu mengurangi beban mingguan secara signifikan.

3) Tampilkan total otomatis (reguler vs lembur)

Saat entri ditambahkan, tampilkan total mingguan di bagian atas: total jam, jam reguler, jam lembur. Pembagian bisa bersifat perkiraan sampai minggu selesai, tetapi harus terupdate secara real time agar karyawan menangkap kesalahan lebih awal.

Jika field yang wajib kosong, tampilkan peringatan jelas alih-alih membiarkan total terlihat “salah”.

4) Submit dan kunci minggu

Submit harus melakukan tiga hal: memvalidasi entri (tidak ada waktu negatif, tidak ada overlap, catatan yang wajib), mengubah status ke Submitted, dan mengunci pengeditan. Jika perubahan diperlukan, rute melalui “Return to Draft” (biasanya dipicu oleh pengembalian manajer atau rejection).

5) Beri tahu manajer dan tampilkan antrean pending

Setelah dikirim, manajer membutuhkan antrean sederhana: nama karyawan, rentang minggu, total jam, isu yang diberi tanda (seperti catatan yang hilang), dan layar review cepat. Ini juga tempat yang tepat untuk notifikasi otomatis saat timesheet berubah menjadi Submitted.

Langkah demi langkah: alur persetujuan manajer

Seorang manajer harus membuka satu layar dan langsung melihat apa yang perlu diperhatikan. Tampilkan antrean singkat minggu yang diserahkan, masing-masing dengan nama karyawan, rentang minggu, total jam, jam lembur (jika ada), dan indikator cepat untuk catatan. Ringkasan itu membantu manajer mendeteksi masalah tanpa mengklik setiap hari.

Saat manajer membuka sebuah minggu, jaga keputusan tetap konsisten:

• Approve: mengunci minggu dan menandainya siap untuk ekspor payroll.
• Send back: mengembalikan ke karyawan dengan komentar yang diwajibkan.
• Reject: digunakan untuk isu kebijakan (kerja hilang, proyek salah, diduga duplikat).
• Delegate: alihkan ke approver cadangan saat manajer sedang tidak ada.

Komentar penting. Wajibkan alasan singkat untuk send-back dan reject, dan simpan bersama catatan sehingga karyawan tahu persis apa yang harus diperbaiki.

Jelaskan apa yang bisa diubah setelah tiap keputusan. Setelah send-back atau reject, karyawan dapat mengedit entri dan catatan, lalu mengirim ulang. Setelah approve, edit sebaiknya diblokir secara default. Jika Anda mengizinkan perubahan, gunakan aksi “reopen week” yang memulai siklus persetujuan baru (dan, jika perlu, persetujuan kedua).

Rencanakan untuk ketidakhadiran. Tetapkan approver cadangan per tim (atau per karyawan) dan izinkan HR atau peran admin untuk menugaskan ulang persetujuan selama liburan.

Simpan jejak audit: siapa yang mengirim, siapa yang menyetujui (atau mendelegasikan), cap waktu, dan log perubahan sederhana (field apa yang berubah dan kapan).

Logika perhitungan lembur dan kasus tepi

Lembur terdengar sederhana sampai minggu berantakan pertama muncul. Anda perlu satu sumber kebenaran untuk matematika, dan itu harus cocok dengan apa yang dilihat karyawan, yang disetujui manajer, dan yang diekspor payroll.

Mulailah dengan memutuskan dari apa Anda menghitung: total harian, total mingguan, atau keduanya. Banyak kebijakan menganggap 8 jam pertama per hari sebagai waktu reguler, lalu apa pun di atasnya dihitung sebagai lembur. Lainnya mengabaikan batas harian dan hanya melihat jam mingguan (misalnya, apa pun di atas 40 jam). Jika kebijakan Anda menggunakan keduanya, definisikan urutannya agar tidak menghitung lembur dua kali. Pendekatan praktis: hitung lembur harian terlebih dahulu, lalu hitung lembur mingguan pada sisa jam reguler.

Kasus tepi yang harus Anda tangani sejak awal

Situasi-situasi ini biasanya merusak total atau menciptakan perselisihan:

• Split shifts: dua entri terpisah dalam satu hari harus digabung menjadi satu total harian.
• Shift semalam: simpan mulai dan selesai sebagai nilai tanggal-waktu penuh, bukan hanya jam.
• Tidak ada jam selesai: blokir pengiriman atau tandai entri tidak lengkap agar tidak memperbesar jam.
• Overlap dan negatif: cegah entri yang tumpang tindih atau selesai sebelum mulai.
• Aturan pembulatan: putuskan apakah membulatkan per entri (misalnya, ke 5 menit) atau hanya pada total harian.

Orang lebih cepat memperbaiki diri ketika mereka bisa melihat rincian jelas. Tampilkan jam reguler, jam lembur, dan istirahat yang tidak dibayar untuk setiap hari, kemudian ringkasan mingguan. Jika sesuatu terlihat salah, sorot entri yang menyebabkan (misalnya: “Tumpang tindih dengan 14:00–16:00”).

Jaga agar perhitungan konsisten di mana pun. Gunakan ulang logika lembur yang sama untuk layar karyawan, tampilan manajer, laporan, dan ekspor payroll.

Ekspor jam yang disetujui untuk payroll

Tim payroll jarang membutuhkan semua yang dilacak aplikasi. Mereka membutuhkan file yang dapat diprediksi dengan nama kolom yang tepat yang diharapkan sistem mereka, dikirim sesuai jadwal. Putuskan ini sejak awal agar Anda tidak berulang kali bolak-balik setiap minggu.

Mulailah dengan menyepakati format ekspor. CSV umum karena sebagian besar sistem payroll dapat mengimpornya, tetapi kunci sebenarnya adalah daftar field dan nama kolom. Jika payroll mengatakan kolom harus disebut EmployeeID, cocokkan itu persis.

File ekspor praktis biasanya berisi employee ID (bukan hanya nama), tanggal akhir minggu (atau tanggal mulai plus akhir minggu), jam reguler dan jam lembur di kolom terpisah, cost center atau kode proyek (jika Anda mengalokasikan tenaga kerja), serta cap waktu persetujuan dan ID approver. Perhatikan bahwa EmployeeID yang ditulis dengan backticks di sini harus dipertahankan sesuai kebutuhan sistem Anda.

Hanya ekspor minggu yang benar-benar disetujui. Perlakukan persetujuan sebagai gerbang: tanpa persetujuan, tidak ada ekspor.

Koreksi sering membuat tim terjebak. Pendekatan bersih adalah menghindari mengedit record yang sudah diekspor secara langsung. Sebagai gantinya, buat entri penyesuaian yang dapat diimpor payroll sebagai delta. Misalnya, jika Minggu ke-42 diekspor dengan 5.0 jam lembur tetapi seharusnya 4.0, buat baris penyesuaian untuk -1.0 jam lembur yang terkait dengan minggu dan karyawan asal.

Simpan ekspor sebagai batch sehingga payroll bisa menjalankan ulang dengan aman. Beri setiap batch ID ekspor, tanggal dan waktu pembuatan, dan filter yang dipakai (misalnya, “Approved weeks ending 2026-01-18”). Jika payroll mengimpor batch yang sama dua kali, ID ekspor membantu mendeteksi duplikasi.

Kesalahan umum dan jebakan yang harus dihindari

Aplikasi ini biasanya gagal karena alasan sederhana: status “final” yang tidak jelas, batas waktu yang tidak jelas, dan ekspor yang tidak cocok dengan apa yang diharapkan payroll.

Jebakan pertama adalah membiarkan orang mengedit waktu setelah minggu disetujui. Kedengarannya fleksibel, tetapi merusak kepercayaan pada angka. Perlakukan Approved sebagai terkunci. Jika seseorang benar-benar perlu mengubah, minta permintaan koreksi yang membuka kembali minggu dan meninggalkan jejak audit tentang apa yang diubah dan mengapa.

Perubahan aturan lembur tengah periode adalah sumber sengketa yang umum lainnya. Jika kebijakan berubah pada Rabu, dokumentasikan tanggal efektif dan versi yang digunakan untuk setiap minggu. Jika tidak, dua orang bisa punya jam identik dan hasil lembur berbeda. Bahkan catatan sederhana seperti “Policy v2 effective Jan 15” yang dilampirkan pada minggu bisa mencegah perdebatan.

Keputusan zona waktu dapat diam-diam merusak total. Pilih satu aturan dan patuhi: gunakan zona waktu lokal karyawan, atau zona waktu payroll perusahaan. Jika Anda tidak melakukan apa pun, shift larut malam bisa bergeser ke hari yang salah dan mengubah total harian serta lembur.

Persetujuan tanpa komentar membuang waktu. Saat manajer menolak atau mengembalikan minggu, wajibkan alasan singkat agar karyawan tahu apa yang harus diperbaiki.

Beberapa aturan yang layak ditegakkan:

• Kunci minggu yang dikirim kecuali manajer mengembalikannya.
• Pertahankan minggu yang disetujui terkunci kecuali melalui alur koreksi yang tercatat.
• Versi kebijakan lembur dan simpan tanggal efektifnya.
• Tentukan satu aturan zona waktu dan tampilkan di timesheet.
• Ekspor hanya minggu yang sepenuhnya disetujui (bukan Submitted, bukan persetujuan parsial).

Daftar periksa cepat sebelum peluncuran

Sebelum siapa pun mulai mencatat waktu, sepakati pengaturan yang menentukan apakah proses terasa adil dan dapat diprediksi.

Kunci pengaturan kalender: hari mulai minggu (Senin vs Minggu) dan cutoff pengiriman (misalnya, “kirim sebelum Senin jam 10:00 untuk minggu sebelumnya”). Tuliskan itu dan ulangi di UI agar orang tidak menebak.

Tulis kebijakan lembur dalam kalimat sederhana, lalu uji dengan beberapa contoh nyata. Jangan hanya menguji satu minggu “normal”. Coba 3 sampai 5 skenario termasuk shift larut, istirahat makan yang terlewat, dan split shift.

Simpan pemeriksaan peluncuran praktis:

• Hari mulai minggu dan cutoff pengiriman sudah diatur dan dikomunikasikan.
• Aturan lembur ditulis dan diuji dengan 3 sampai 5 contoh.
• Manajer dapat melihat total dan catatan karyawan sebelum menyetujui.
• Ekspor payroll hanya mencakup data yang disetujui dan bisa direproduksi.

Perhatikan khusus penguncian. Submit harus menghentikan edit kecuali manajer mengembalikan. Approved harus nyaris tak berubah kecuali alur koreksi yang tercatat. Jika tidak, payroll menjadi target yang bergerak.

Buat ekspor payroll membosankan. Harus menghasilkan angka yang sama untuk periode yang sama, dan hanya termasuk jam yang disetujui. Jika menjalankan ulang ekspor bulan lalu mengubah hasil, hentikan peluncuran dan perbaiki dulu.

Contoh skenario yang realistis

Sebuah tim gudang membayar lembur untuk apa pun di atas 40 jam dalam minggu Senin sampai Minggu, dan hanya jam yang disetujui yang dapat dibayarkan. Setiap pekerja mengirim sekali seminggu, dan manajer harus menyetujui sebelum Senin siang.

Jordan bekerja shift pagi. Sampai Jumat, Jordan mencatat 38 jam. Pada Sabtu, Jordan lembur untuk pengiriman mendesak dan mencatat 6 jam lagi. Minggu malam, Jordan meninjau minggu, menambahkan catatan singkat pada entri Sabtu, dan mengirimkan timesheet dengan total 44 jam.

Senin pagi, manajer memeriksa pengiriman. Aplikasi menunjukkan pembagian sederhana: 40 jam reguler dan 4 jam lembur. Manajer melihat entri Sabtu dibuat setelah shift selesai dan meminta detail. Jordan menyadari waktu mulai keliru 30 menit dan perlu memperbaikinya.

Karena timesheet sudah dikirim, koreksi melewati alur pengiriman ulang: manajer menolak timesheet dengan alasan (“Perbaiki waktu mulai Sabtu, lalu kirim ulang”). Jordan mengedit entri Sabtu, mengirim ulang, dan lembur dihitung ulang menjadi 3.5 jam.

Saat manajer menyetujui, payroll mendapat ekspor bersih untuk minggu itu: ID karyawan dan nama, tanggal mulai dan akhir minggu, jam reguler dan jam lembur yang disetujui, opsi cost center atau lokasi (Warehouse A), plus cap waktu persetujuan dan nama approver.

Setelah peluncuran, tim melacak beberapa metrik sederhana: pengiriman terlambat (setelah Minggu), tingkat penolakan (seberapa sering manajer mengembalikan timesheet), dan rata-rata waktu dari submit ke approval. Jika angka-angka itu naik, biasanya menunjukkan aturan yang tidak jelas atau pengingat yang hilang.

Langkah berikutnya dan rencana rollout sederhana

Perlakukan versi pertama sebagai uji terbatas, bukan perubahan seluruh perusahaan. Pilih satu tim pilot dengan campuran jam reguler dan lembur yang normal, dan mulai dengan satu kebijakan lembur jelas. Ini menjaga umpan balik fokus dan membuktikan alur kerja ujung-ke-ujung.

Jalankan pilot selama 2 sampai 4 siklus mingguan. Itu cukup pengiriman nyata untuk melihat di mana orang ragu, di mana manajer kesulitan, dan apakah ekspor payroll cocok dengan yang diharapkan finance.

Rencana rollout yang praktis:

• Pilotkan dengan satu tim dan satu kebijakan lembur (lewati kasus khusus pada minggu pertama).
• Kumpulkan lima pertanyaan paling umum dan perbaiki layar atau label yang menyebabkannya.
• Kunci kepemilikan: siapa yang dapat memperbarui aturan lembur, kode pembayaran, dan pengaturan persetujuan.
• Sepakati jadwal ekspor payroll (misalnya, setiap Senin jam 09:00 setelah penutupan persetujuan).
• Tambahkan satu integrasi hanya ketika ekspor manual benar selama dua periode gaji.

Perubahan teks UI kecil mengurangi banyak tiket dukungan. Buat alur pengiriman singkat, dan tambahkan teks bantuan hanya di tempat orang benar-benar kesulitan.

Tentukan sejak awal siapa yang mengelola pembaruan kebijakan. HR mungkin mengelola definisi lembur, payroll mengelola format ekspor, dan manajer mengelola persetujuan. Buat izin itu eksplisit agar admin yang berniat baik tidak mengubah pengaturan di tengah periode gaji.

Jika Anda ingin membangun ini tanpa koding khusus, AppMaster (appmaster.io) adalah salah satu opsi untuk prototyping dan mengirimkannya dengan model data visual, alur drag-and-drop untuk submit dan persetujuan, serta pembuat UI web/mobile. Mulailah dengan alur minimum, lalu perluas hanya setelah pilot membuktikan logika lembur dan ekspor payroll sesuai proses Anda.