Informasi tentang Proses & Logika Approval Layer (Persetujuan Berlapis)

    Last updated on 

    Pendahuluan

    Artikel ini menjelaskan logika alur persetujuan yang digunakan di Staffinc Suite untuk skenario persetujuan multi-layer, seperti permintaan cuti, lembur, dan dispute. Artikel ini menekankan bahwa status suatu permintaan hanya dianggap final ketika telah mencapai dan menerima keputusan dari approver terakhir.

    Approver terakhir memiliki otoritas tertinggi, sehingga dapat mengesampingkan keputusan yang dibuat oleh layer approver sebelumnya.

    Creation of Approval Rule

    Logika Inti & Alur Proses

    1. Struktur Persetujuan Multi-Layer

    • Staffinc Suite memungkinkan pengaturan rantai persetujuan hierarkis, yang disebut Approval Rules, di mana setiap permintaan dapat melewati beberapa level persetujuan (misalnya: Supervisor → Manager → HR) tergantung pada konfigurasi.
    • Default Approvers dapat dikonfigurasi di setiap Approval Rule.Mereka dapat:
      • Melihat semua permintaan di seluruh layer persetujuan.
      • Melakukan tindakan persetujuan tanpa bergantung pada layer tempat permintaan tersebut berada saat ini.
    • Peran ini ditujukan untuk HR Admin atau Operational Supervisor yang membutuhkan visibilitas luas dan kontrol atas alur kerja.

    2. Inisiasi Permintaan

    • Ketika karyawan mengajukan permintaan cuti, lembur, atau dispute, permintaan tersebut akan masuk ke dalam rantai persetujuan yang telah ditentukan dan muncul dengan status Pending Approval di dalam sistem.

    3. Peninjauan Berurutan oleh Setiap Layer

    • Setiap approver dalam rantai persetujuan harus mengambil tindakan—menyetujui atau menolak—sebelum permintaan dapat dilanjutkan ke layer berikutnya.
    • Jika approver menyetujui, permintaan akan diteruskan ke penghubung (connector) berikutnya dalam rantai.
    • Jika approver menolak, permintaan akan langsung difinalisasi sebagai Rejected, terlepas dari apakah persetujuan di layer berikutnya masih menunggu.

    4. Otoritas Approver Terakhir

    • Permintaan hanya dianggap benar-benar final setelah disetujui oleh seluruh layer, termasuk approver terakhir.
    • Approver terakhir memiliki kewenangan penuh dalam pengambilan keputusan, bahkan jika approver sebelumnya telah menyetujui, sehingga dapat membatalkan keputusan tersebut (misalnya menolak meskipun sebelumnya disetujui).

    5. Dampak Finalisasi Setelah Disetujui

    • Cuti: Jika disetujui oleh layer terakhir:
      • Untuk cuti berbayar: saldo cuti akan dikurangi dan status kehadiran diperbarui menjadi “Paid Leave”.
      • Untuk cuti tidak berbayar: tidak ada pengurangan saldo, tetapi status kehadiran diperbarui menjadi “Unpaid Leave”.
    • Lembur:
      Berfungsi dengan cara yang serupa—setelah difinalisasi, durasi lembur yang disetujui akan tercermin dalam data kehadiran dan payroll sesuai ketentuan.
    • Dispute:
      Setelah persetujuan akhir, data kehadiran akan dikoreksi atau diperbarui sesuai dengan hasil penyelesaian dispute.

    Mengapa Hal Ini Penting

    • Memastikan tata kelola yang jelas, dengan setiap keputusan dapat ditelusuri melalui rantai persetujuan.
    • Mencegah finalisasi yang terlalu dini—hanya approver terakhir yang dapat mengonfirmasi hasil akhir permintaan.
    • Memaksimalkan transparansi melalui jejak persetujuan yang terdokumentasi serta kontrol dan akuntabilitas yang tetap terjaga.

    Referensi untuk Informasi Lebih Lanjut

    • Cara Membuat Aturan Persetujuan (Approval Rules) — menjelaskan proses pembuatan Approval Rules.
    • How to Do Approval for Pending Leave Requests — menjelaskan alur persetujuan cuti multi-layer, cara menyetujui atau menolak, serta dampaknya terhadap saldo cuti dan status kehadiran.