Transaksi backdated pada modul openbravo payroll sebenarnya tidak perlu terjadi. Namun, jika tidak diakomodir, maka Openbravo payroll tidak mungkin bisa dipakai, terlebih di Indonesia, dimana budaya telat administrasi masih menjadi sesuatu yang lumrah. Bagaimana menjalakan Openbravo payroll dengan transaksi backdated tapi tetap aman?

Tanpa backdated, Openbravo payroll tidak akan jalan. Jadi, apapun vendornya, aplikasi payroll di Indonesia harus bisa memproses transaksi back-dated. Artikel ini membahas bagaimana desain aplikasi payroll yang baik, yaitu tetap bisa back-dated, tapi tetap aman. Sebelum lebih jauh mengenai desain aplikasi payroll nya, kita sebaiknya meluangkan waktu sedikit mengenai apa itu kata-kata back-dated, dan apa itu kata-kata aman?

Back-dated

artinya kita memproses data masa lalu. disebut masa lalu karena effective-date sebuah dokumen, berada di titik sebelum tanggal saat ini, atau effective-date sebuah dokumen berada jauh dibelakang tanggal saat ini. Misalnya, saat ini adalah tanggal 15 Agustus 2016, tetapi proses gaji yang kita sedang eksekusi memiliki effective date 31 Mei 2015.

Aman

artinya, ada 2, yaitu:

  1. performance dari aplikasi payroll itu sendiri tidak dikorbankan.
  2. master data dan data transaksional tidak tumpang tindih

Dua hal diatas, back-dated dan aman, harus ditangani dengan benar sedari awal, jika tidak anda sama saja membuat aplikasi payroll baru dari nol.

contoh kasus 1

  1. dalam aplikasi payroll sudah lumrah kita bisa memasukkan daftar anggota keluarga
  2. bisa saja, sebuah perusahaan, menerapkan insentif yang disebut tunjangan anak, yang memiliki formula sebesar 100 ribu rupiah untuk setiap anak yang menjadi tanggungannya.
  3. misalnya, pada bulan Juni 2015, seorang karyawan bernama Budi, dikaruniai seorang bayi laki laki, dan sejak itu dia menerima tunjangan anak sebesar 100 ribu rupiah setiap bulannnya.
  4. pada bulan April 2017, Budi kembali dikaruniai seorang bayi perempuan, dan sejak itu dia menerima tunjangan anak sebesar 200 ribu rupiah setiap bulannya.
  5. pada bulan Mei 2017, dewan direksi perusahaannya, mengesahkan sebuah surat keputusan (SK) baru yang mengatur besaran tunjangan anak, dari sebelumnya 100 ribu rupiah per anak menjadi 150 ribu rupiah per anak, dan berlaku mulai tanggal 1 Januari 2017.
  6. departemen SDM, pada bulan Mei 2017 segera menghitung selisih gaji bapak Budi, antara gaji dengan SK lama dengan SK baru. pada gaji Budi bulan Januari 2017, seharusnya budi menerima tunjangan anak 150 ribu rupiah (pada Januari 2017 Budi baru punya 1 anak), bukan 300 ribu rupiah (sebab di Master data saat ini, Budi tercatat punya 2 anak).
  7. kejadian nomor 6 menunjukkan perlu desain khusus dalam model data anggota keluarga, sehingga:
    1. back-dated: jika hitung gaji pada bulan Januari 2017 dijalankan ulang, selisih hanya 50 ribu saja, bukan 200 ribu.
    2. aman, dimana supaya tidak berat, dan master data keluarga tidak tumpang tindih, maka sistem tetap menampikan pak Budi punya 2 anak. bukan pak Budi punya 1 anak sejak Juni 2015 dan menjadi 2 anak sejak April 2017.

solusi untuk contoh kasus 1

  1. relasi antara table master karyawan ke tabel anggota keluarga tetap 1 to many.
  2. pada table anggota keluarga, harus ada field valid from dan valid to.

dengan menerapkan 2 hal diatas, maka tetap bisa didapat:

  1. sistem tetap ringan sebab join hanya melibatkan 2 table
  2. jika di proses gaji back-dated, misalnya contoh kasus diatas di proses ulang gaji Januari 2017 pada bulan Mei 2017, maka jumlah anak pak Budi tetap bisa di-query, dan dengan presisi menghasilkan jumlah anak = 1.

contoh kasus 2

  1. dalam aplikasi payroll sudah lumrah kita bisa memasukkan mutasi karyawan, baik itu mutasi promosi, mutasi rotasi, maupun mutasi demosi.
  2. dalam pelaksanaanya, saat memasukkan karyawan yang dimutasi, pasti ada informasi mengenai SK lama (yaitu SK sebelum mutasi), dan SK baru (yaitu SK mutasi karyawan yang bersangkutan).
  3. pada bulan September 2015, bapak Budi dimutasi dari departemen akuntansi ke departemen keuangan, dengan pangkat naik dari golongan 3A menjadi 3B.
  4. bersamaan dengan bapak Budi, bapak Joko mendapat promosi berupa kenaikan pangkat dari 2C menjadi 2D
  5. pada bulan Desember 2015, pak budi Menerima kenaikan jabatan dari Asisten Manajer Keuangan menjadi Manajer Keuangan.
  6. pada bulan Mei 2016, bapak Joko mendapatkan promosi berupa kenaikan jabatan dari pelaksana tugas Manajer Proyek menjadi Manajer Proyek (definitif).
  7. pada bulan Juni 2016, baru diketahui jika bapak SK bapak Budi salah entri, seharusnya pada bulan September 2015, pak Budi tidak naik pangkat.
  8. kejadian pada nomor 6 membuat fenomena chicken and egg, dimana:
    1. jika mutasi karyawan pada bulan September 2015 saya buka approvalnya, maka SK baru yang di-generate pada mutasi karyawan September 2015 akan hilang, padahal SK baru di September 2015 milik pak Joko, dipakai sebagai SK lama di Mei 2016, sehingga mutasi karyawan September 2015, tidak bisa saya reactive. hal yang sama berlaku pada SK pak budi pada September 2015 dipakai sebagai SK lama di mutasi karyawan pada bulan Desember 2015.
    2. untuk menyelesaikan problem pada langkah 7.1 maka mutasi karyawan pada Desember 2015 dan Mei 2016, harus saya lepas approvalnya, dan kemudian dihapus, baru mutasi karyawan pada September 2015 bisa saya lepas approvalnya, karena SK pak joko pada September 2015, sudah tidak link ke mana-mana.
    3. akhirnya, langkah 7.2 harus diulang, mana kala ada SK karyawan lain, di mutasi karyawan Mei 2016, yang link dengan SK di masa-masa mendatang. dan setelah SK september 2015 dibetulkan, SK Mei 2016 harus dibuat ulang, karena sebelumnya sudah dihapus.
    4. alangkah beratnya kegiatan ini mana kalau kesalahan entri SK sudah berlangsung sangat lama.

solusi untuk contoh kasus 2

  1. dibuatkan window baru, dengan isi:
    1. SK mutasi karyawan yang didalamnya terdapat karyawan yang salah input SK
    2. karyawan yang SKnya salah input
    3. field field yang menyimpan informasi SK baru, disini by-default diisi dengan SK baru yang salah tadi, kemudian field yang salah diubah isinya sehingga menjadi benar.
  2. terdapat tombol untuk eksekusi proses dengan alur proses berikut ini:
    1. SK baru pada mutasi karyawan September 2015 diubah sebagaimana isian pada langkah 1.3
    2. SK bulan September 2015 di master karyawan miliki pak Budi diubah sebagaimana isian pada langkah 1.3
    3. SK lama pada mutasi karyawan Desember 2015 diubah sebagaimana isian pada langkah 1.3

dengan menerapkan 2 hal diatas, maka tetap bisa didapat:

  1. tidak ada proses delete foreign-key lalu buat lagi dokumen yang sudah dihapus
  2. isi SK, baik sebagai SK baru di September 2015, riwayat SK september 2015 di master karyawan, dan Sk lama di mutasi Desember 201, semuanya konsisten.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s