PERTALIFE

Ikmal,
untuk ini memang tabel tsb belum kita fungsinya, karena dr semua client kita setau saya gak mau ada pembulatan tsb deh.
karena potensinya khan jd itungan uph lemburnya jd lebih kecil buat karyawan krn pembulatan tsb. Apak client udah pahan dgn dampak ini ke karyawan nya?

Kalau dari infonya sih ini bu, inginnya membaca dari table tersebut

ooh, setau saya ketentuan ini memang belum pernah dijalankan di aplikasi. dan ini berlaku di semua client.
Jadi memang seharusnya soal tabel parameter ini jangan diberikan ke client yaa. Siapa yg info soal tabel ini ya?

Tapi kl skrg mau ini di aktifkan, tolong ini dibuat jadi parameter ya On/Off nya untuk membaca parameter ini supaya fleksibel jg untuk client lain yg ketentuan nya tidak spt ini.

Silahkan di assign ke mbak Yomma aja.
Tks

Dear mba yomma,
Mohon dibantu ya mba yomma.
terima kasih

Ikmal, berarti ini yg salah perhitungan jam lembur & upah lembur pada saat running payroll ya?

Iya mba, karena perhitungannya tidak mengacu ke parameter tersebut mba. Untuk yg parameter itu nanti mau dibuat field baru aja mba untuk ON/OFF nya?

Boleh, buatin di tbl genparam aja ya.

sudah dibuat parameter nya mba di table genparam. Parameter = ACTIVEPHRTMOTROUND

Ikmal, tlg isi sama ovt roundingnya ya

25 menit :
35 menit :
55 menit :
1 jam 10 menit :
1 jam 20 menit :
1 jam 40 menit :
1 jam 50 menit :

Kalau based on yg saat ini di parameter ini analisa saya mba:

25 menit : 25 menit
35 menit : 30 menit
55 menit : 55 menit
1 jam 10 menit : 1 jam
1 jam 20 menit : 1 jam 20 menit
1 jam 40 menit : 1 jam 30 menit
1 jam 50 menit : 1 jam 50 menit

Tapi kalau untuk skema yg disana lagi ditanyakan mas daud untuk konfirmasi

Dear mba Yomma,

Untuk case ini nanti sistem akan membaca berdasarkan value nya saja di table Parameter PHRTMOTROUND, karena field Direction belum memiliki treatment khusus di sisi backend.

Berikut contoh mapping yang sudah dibuat:

0 0 -> untuk case awal

29 0 -> rentang 0–29 menit dihitung menjadi 0

44 30 -> rentang 30–44 menit dihitung menjadi 30 menit

59 45 -> rentang 45–59 menit dihitung menjadi 45 menit

60 60 -> rentang 60 menit ke atas dihitung menjadi 60 menit

Contoh pembacaan waktu:

1 jam 10 menit -> terbaca menjadi 60 menit (1 jam)

1 jam 20 menit -> terbaca menjadi 60 menit (1 jam)

1 jam 40 menit -> terbaca menjadi 90 menit (1 jam 30 menit) karena mengikuti kelipatan di rentang round

1 jam 50 menit -> terbaca menjadi 105 menit (1 jam 45 menit) karena mengikuti kelipatan di rentang round

Ada revisi untuk mappingan di table PHRTMOTROUND ya mba, based on info dari user pertalife, jadinya yg fix akan seperti ini, konsep nya sama membaca value hanya saja nilai2 kelipatan nya yg tadi disesuaikan.

Berikut contoh mapping yang sudah dibuat:

0 0 -> untuk case awal

29 0 -> rentang 0–29 menit dihitung menjadi 0

54-30 -> rentang 30–54 menit dihitung menjadi 30 menit

60-55 -> rentang 55–60 menit dihitung menjadi 60 menit

Contoh pembacaan waktu:

1 jam 10 menit -> terbaca menjadi 60 menit (1 jam)

1 jam 20 menit -> terbaca menjadi 60 menit (1 jam)

1 jam 40 menit -> terbaca menjadi 90 menit (1 jam 30 menit) karena mengikuti kelipatan di rentang round

1 jam 55 menit -> terbaca menjadi 120 menit (2 jam) karena mengikuti kelipatan di rentang round

terima kasih.

Fixing :

Update folder API2/bin : MinovaIS.MinovaES.Business.PY.dll

Dear mba Yomma,

Setelah dilakukan testing menggunakan EmployeeID: 08810916 dengan Payroll Period: 02-2025, misalnya case lembur selama 25 menit (dari StartTime & EndTime), sistem masih menghitung nilai lembur bnya di report payroll result.
Karena seharusnya nilai lembur tersebut 0, berdasarkan parameter yang ada di tabel PHRTMOTROUND (25 menit masih berada dalam rentang value 0 dan belum mencapai batas minimal perhitungan lembur).

Mohon dicek juga untuk skenario lainnya ketika karyawan melakukan lembur beberapa kali dalam satu bulan (misalnya 10 hari kerja), namun durasi lembur setiap harinya di bawah 30 menit terus.
Nah pada kondisi tersebut, setiap lembur harian di bawah 30 menit tidak dihitung sebagai lembur (nilainya jg tetep 0). Jika ada kebutuhan akumulasi, perhitungannya dapat dilakukan berdasarkan Date masing-masing lembur.

terima kasih.