Acceptance Criteria

⚙️ General Rules

• Menu dan action yang ditampilkan/aktif harus sesuai dengan role dan permission yang dimiliki

• Data yang ditampilkan harus hanya dalam scope perusahaan sendiri

• Tidak boleh melihat data perusahaan lain (data bocor)

• Setiap new company (registered user) akan di-seed data default: grade, class, job position, job level, organization, satellite office, employee_id, schedule, attendance config

• YANG SUDAH DIPERIKSA TANDAI DENGAN STATUS PASSED/FAILED/SKIPPED/PENDING

⚙️ Platform: Web Admin

📄 Feature: Self-registration ke aplikasi HR

🎯 User Story: Sebagai calon admin Saya ingin daftar sendiri ke aplikasi dengan paket yang saya pilih Sehingga saya dapat menggunakan aplikasi sesuai fitur yang ada di paket

📄 Feature: Login 

🎯 User Story: Sebagai admin Saya ingin login ke web admin Sehingga saya dapat melihat dashboard dan memiliki akses sesuai dengan role yang saya miliki

🎯 User Story: Sebagai employee Saya ingin login ke aplikasi Sehingga saya dapat melihat dashboard dan memiliki akses sesuai dengan role yang saya miliki

📄 Feature: Lupa password

🎯 User Story: Sebagai admin Saya ingin reset password jika lupa sebelum login Sehingga bisa login dari intruksi yang dikirim ke email

📄 Feature: Dashboard

🎯 User Story: Sebagai admin Saya ingin melihat overview perusahaan sendiri di dashboard Sehingga saya bisa mengetahui info pengumuman terbaru, statistik karyawan, karyawan yang cuti, izin, kontrak, kalendar kerja, dsb

📄 Feature: Head Office

🎯 User Story: Sebagai admin Saya ingin update info head office Sehingga info head office bisa digunakan pada fitur lain seperti lokasi pada shift location dan prefix pada employee id

FAILED: is_hq harus terisi ketika create user register sebagai admin dan otomatis membuat compny. employment_info & personal_info juga harus terisi ketika verify user (jika belum terisi)

📄 Feature: Branch Management

🎯 User Story: Sebagai admin Saya ingin manage (crud) data branch yang ada di perusahaan ini Sehingga data dan atribut pada branch bisa digunakan pada fitur lain seperti lokasi pada shift location, sppd pada fitur check in, set branch pada data employee, dsb.

📄 Feature: Satellite Office Management

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data satellite office yang ada di perusahaan ini, sehingga informasi lokasi, geolokasi, dan data terkait lainnya bisa digunakan pada fitur lain seperti:

1. Shift Location: Menentukan lokasi kerja untuk shift.

2. Check-in: Memastikan karyawan melakukan check-in di lokasi yang tepat.

3. Employee Data: Menetapkan satellite office sebagai lokasi kerja karyawan.

4. Business Trip (SPPD): Mengelola check-in untuk perjalanan dinas.

📄 Feature: Setup roles & permissions

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data role dan permission yang ada di perusahaan, sehingga saya bisa mengatur siapa saja karyawan yang memiliki role dan permission tertentu

📄 Feature: Employment status

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data employment status yang ada di perusahaan.

📄 Feature: Grade & class

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data Grade dan Class yang ada di perusahaan, sehingga saya bisa menetapkan level atau tingkatan karyawan dan menggunakan data ini untuk fitur lain

📄 Feature: Job position

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data posisi pekerjaan yang ada di perusahaan, sehingga saya bisa menetapkan jabatan yang relevan untuk setiap karyawan dan menggunakan data ini untuk fitur lain

📄 Feature: Job level

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data level pekerjaan yang ada di perusahaan, sehingga saya bisa menetapkan tingkatan yang relevan untuk setiap posisi dan menggunakan data ini untuk fitur lain, seperti:

1. Employee Data: Menetapkan level pekerjaan pada data setiap karyawan.

2. Compensation & Benefits: Menentukan skala gaji berdasarkan level pekerjaan.

3. Career Path: Memetakan jalur karir karyawan berdasarkan level.

4. Cash Advance: Menentukan limit cash advance by job level

📄 Feature: Holiday

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data hari libur di perusahaan, sehingga:

1. Hari libur bisa diatur sesuai dengan kalender nasional atau kebijakan perusahaan.

2. Karyawan tidak perlu check-in pada hari libur.

3. Jadwal kerja dan laporan kehadiran secara otomatis mencatat hari tersebut sebagai hari libur.

📄 Feature: Work schedule

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data shift dan schedule, sehingga saya bisa menetapkan jam kerja yang fleksibel atau tetap untuk karyawan dan menggunakan data ini untuk fitur lain, seperti:

1. Time Tracking: Mengintegrasikan jadwal kerja dengan sistem absensi.

2. Overtime Calculation: Menghitung lembur berdasarkan jam kerja yang ditentukan.

3. Employee Attendance: Memantau kehadiran karyawan.

📄 Feature: employee_id

🎯 User Story: Sebagai admin Saya ingin dapat mengelola (CRUD) format ID karyawan, sehingga saya bisa menetapkan aturan penomoran yang konsisten dan otomatis untuk setiap karyawan baru yang ditambahkan.

📄 Feature: User/employee 

🎯 User Story: Saya ingin dapat membuat user baru secara manual, melihat daftar user, mengedit, dan menghapus user, sehingga saya bisa mengatur akses pengguna aplikasi sesuai kebutuhan perusahaan.

📄 Feature: Organization

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data organization beserta manager dan anggotanya

📄 Feature: Approval

🎯 User Story: Sebagai admin Saya ingin dapat mengelola (CRUD) alur persetujuan untuk berbagai jenis request, sehingga setiap permohonan dapat disetujui atau ditolak sesuai dengan urutan hierarki yang telah saya tentukan,  sehingga:

1. Saya bisa menetapkan urutan persetujuan yang spesifik untuk setiap jenis permintaan (misalnya, Pengajuan Cuti harus disetujui oleh Supervisor, lalu HR, lalu General Manager).

2. Saya dapat mengubah dan mengatur ulang urutan persetujuan ini jika ada perubahan struktur organisasi.

3. Setiap permohonan dapat disetujui atau ditolak sesuai dengan hierarki yang telah saya tentukan.

Note: 

MAJOR: Harus bisa di reorder

MAJOR cek target , terutama branch

📄 Feature: Announcement

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) pengumuman perusahaan. Tujuannya agar saya bisa membuat, memperbarui, dan menghapus informasi penting yang perlu diketahui oleh seluruh karyawan dan menyampaikannya melalui semua aplikasi yang tersedia.

📄 Feature: Project

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) data proyek beserta atribut-atributnya. Tujuannya agar saya bisa mendefinisikan proyek, mengalokasikan sumber daya, dan melacak aktivitas yang terkait dengan proyek tersebut. Data ini akan terintegrasi dengan fitur lain seperti manajemen lembur dan perjalanan dinas.

📄 Feature: Attendance

🎯 User Story: Sebagai admin, saya ingin dapat mengatur kebijakan dasar absensi perusahaan, seperti menentukan batas waktu pengajuan absensi mundur dan tanggal cut-off untuk laporan bulanan. Tujuannya agar sistem absensi berjalan sesuai aturan yang kami tetapkan, memastikan kedisiplinan dan akurasi data kehadiran.

🎯 User Story: Sebagai admin, saya ingin memantau dan meninjau seluruh data absensi karyawan secara terpusat. Tujuannya agar saya bisa mengevaluasi kedisiplinan, mengidentifikasi anomali (seperti absen atau terlambat), dan mengunduh laporan kehadiran jika diperlukan.

🎯 User Story: Sebagai employee, saya ingin memantau dan melihat ringkasan data kehadiran saya secara real-time di aplikasi mobile, sehingga saya bisa tahu status kehadiran saya setiap hari dan kekurangan jam kerja.

Perhitungan jam mengikuti aturan seperti di Simulasi Attendance:

https://docs.google.com/spreadsheets/d/1Sqsai2HhwARaTnd8jew6wroSvghnDrJ0P4evhgjGa5c/edit?gid=0#gid=0

Note: 

• di attendance log, shift yg muncul harus dari table attendance jika ada (sudah pernah checkin), jika tidak ada, baru dari schedule , data config yg dibutuhkan untuk kalkulasi penentuan flagging, misal late_in , early_in, dsb, simpan juga di table transaksi yaitu attendance, jangan diambil realtime dari schedule/shift. Karena akan ada byk column, ketika query ke table ini, jangan pakai *, pilih column secara manual agar tidak berat

• Tambah config untuk kekurangan jam kerja di bulan itu & cuti yg dipotong

• Cek lagi: You have a shortage of working hours of 8 hours

📄 Feature: Leave Config

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) kebijakan cuti di perusahaan, sehingga:

1. Saya bisa membuat berbagai jenis cuti sesuai kebutuhan perusahaan (misalnya, Cuti Tahunan, Cuti Sakit, Cuti Bersalin).

2. Saya dapat menetapkan aturan dan saldo cuti untuk setiap karyawan atau kelompok karyawan.

3. Saya bisa mendistribusikan saldo cuti secara adil dan transparan.

4. Setiap pengajuan cuti dapat diproses sesuai dengan kebijakan yang telah diatur.

Note: di pengajuan pastikan opsi seperti attachment sesuai config

📄 Feature: Leave Balance

🎯 User Story: Sebagai admin, saya ingin dapat menyesuaikan saldo cuti semua karyawan di perusahaan. Tujuannya agar saya bisa melakukan koreksi, penyesuaian, atau memberikan tambahan cuti secara manual, dengan catatan yang jelas mengenai perubahan yang dilakukan.

📄 Feature: Overtime

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) kebijakan dan aturan lembur di perusahaan, sehingga:

1. Setiap pengajuan lembur dapat diproses sesuai dengan peraturan yang telah ditetapkan.

2. Perhitungan upah lembur berjalan otomatis berdasarkan aturan yang berlaku.

3. Terdapat batasan jam kerja lembur harian dan mingguan.

4. Saya dapat mengatur siapa saja yang berhak mendapatkan upah lembur.

Note: 

• di web user, ketika mengajukan backdate, perlu munculin jam mulai & akhir (contoh di mobile app)

• Durasi max di luar working_day, tidak terambil di fe ketika pengajuan

• Ketika persetukuan di mobile, durasi tidak sesuai

• Overtime user detail rate belum wokking

• Overtime detail di mobile app tidak muncul

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan lembur melalui portal web atau aplikasi mobile. Tujuannya agar saya bisa mendapatkan persetujuan lembur untuk pekerjaan yang sudah atau akan saya lakukan, mendapatkan upah yang sesuai, serta menerima pembaruan status pengajuan di mana saja dan kapan saja.

✅ Positive Acceptance Criteria:

1. Pengajuan Lembur:

1. Pengguna dapat mengakses fitur pengajuan lembur di portal web dan aplikasi mobile.

2. Formulir pengajuan harus konsisten di kedua platform dan meminta semua field yang dibutuhkan (tanggal, jam mulai, jam selesai, alasan, dan, jika perlu, proyek terkait).

3. Pengguna dapat mengajukan lembur untuk tanggal di masa depan atau di masa lalu (sesuai kebijakan backdate yang diatur admin).

4. Setelah pengajuan berhasil, akan muncul notifikasi sukses.

2. Pengelolaan Lampiran:

1. Pengguna dapat mengunggah file pendukung di kedua platform.

3. Pemberitahuan & Status:

1. Pengguna dapat melihat status pengajuan (pending, disetujui, ditolak) di kedua platform.

2. Pengguna menerima notifikasi push (untuk mobile) dan notifikasi di aplikasi ketika pengajuan lemburnya disetujui atau ditolak.

3. Tampilan riwayat pengajuan lembur harus konsisten di web dan mobile.

❌ Negative Acceptance Criteria:

1. Validasi Formulir:

1. Sistem harus mencegah pengajuan jika ada field wajib yang tidak terisi.

2. Sistem harus menolak pengajuan jika jam lembur yang diinputkan melebihi batas yang diatur oleh admin.

3. Sistem harus menolak pengajuan lembur untuk tanggal yang melebihi batas backdate yang diizinkan oleh admin.

2. Unggahan File:

1. Sistem harus menolak unggahan file jika ukurannya melebihi batas yang telah ditentukan (misalnya, 2 MB).

3. Performa & Stabilitas:

1. Aplikasi mobile tidak boleh gagal atau mengalami crash saat pengguna mencoba mengajukan lembur.

4. Notifikasi:

1. Notifikasi tidak boleh terlambat atau tidak terkirim.

5. Manajemen Data:

1. Pengguna tidak bisa mengubah atau menghapus pengajuan yang sudah disetujui atau ditolak.

📄 Feature: Permit

🎯 User Story: Sebagai admin, saya ingin dapat mengelola (CRUD) kebijakan dan aturan izin di perusahaan, sehingga:

1. Setiap pengajuan izin dapat diproses sesuai dengan alur persetujuan yang telah ditetapkan.

2. Karyawan dapat mengajukan izin melalui sistem dengan alasan yang jelas.

3. Saya bisa menentukan jenis-jenis izin apa saja yang tersedia untuk karyawan.

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan izin melalui portal web dan mobile ketika ada keperluan mendesak selama jam kerja. Tujuannya agar saya bisa mendapatkan persetujuan untuk meninggalkan kantor dan memiliki catatan yang jelas mengenai izin yang saya ajukan.

Note: 

• di web user belum bisa resubmit

• izin digunakan, tersimpan hanya untuk yg sudah approved

• Yang diresubmit tidak muncul di approver

• 
  

📄 Feature: Requests

🎯 User Story: Sebagai admin, saya ingin dapat melihat / memonitor semua request dari karyawan di perusahaan saya sesuai peraturan yang berlaku, sehingga:

📄 Feature: Reimbursement

🎯 User Story: Sebagai admin, saya ingin dapat mengatur kebijakan reimbursement di perusahaan saya. Tujuannya agar saya bisa mendefinisikan jenis-jenis pengeluaran yang bisa diajukan, menetapkan batas maksimal, dan memastikan setiap pengajuan diproses sesuai dengan peraturan yang berlaku.

Reimbursement Simulation

https://docs.google.com/spreadsheets/d/1klR_jbiTZk7W7puaVnuxpVQO-Hgrkb9eM1VC5kRflnc 

📄 Feature: Cash Advance

🎯 User Story: Sebagai admin, saya ingin dapat mengatur kebijakan cash advance di perusahaan saya sesuai peraturan yang berlaku.

⚙️ Platform: Mobile & Web User

📄 Feature: Verify Invitation from Admin

🎯 User Story: Sebagai employee Saya ingin dapat memverifikasi alamat email saya melalui undangan yang dikirimkan oleh admin. Tujuannya agar saya bisa mengaktifkan akun saya dan masuk ke aplikasi sebagai pengguna yang sah.

📄 Feature: Lupa password di mobile app

🎯 User Story: Sebagai employee Saya ingin reset password jika lupa sebelum login Sehingga bisa login dari intruksi yang dikirim ke email

📄 Feature: Dashboard

🎯 User Story: Sebagai employee di web dan mobile Saya ingin melihat pengumuman, bisa cekin, melihat kalender kerja, info tim saya, dan info cuti

📄 Feature: Update Profile (Basic Info)

🎯 User Story: Sebagai employee Saya ingin mengedit data pribadi saya dan mengajukan perubahan kepada pihak yang berwenang,sehingga data saya tetap akurat dan valid setelah mendapat persetujuan.

📄 Feature: Update Profile (Education & Experience)

🎯 User Story: Sebagai employee Saya ingin mengajukan pengisian dan perubahan data pendidikan dan pengalaman kerja agar bisa di-approve sama approver.

📄 Feature: Change Password

🎯 User Story: Sebagai employee Saya ingin mengubah password saya Sehingga saya dapat login dengan password baru saya.

✅ Positive Acceptance Criteria:

1. User dapat membuka halaman Change Password di aplikasi.

2. User memasukkan kata sandi lama dengan benar.

3. User memasukkan kata sandi baru sesuai aturan (misalnya minimal 8 karakter, ada huruf & angka).

4. User memasukkan konfirmasi sandi baru yang sama dengan sandi baru.

5. User klik tombol Buat Password Baru.

6. Sistem menampilkan pesan sukses dan password berhasil diperbarui.

7. Setelah logout, user dapat login kembali menggunakan password baru.

❌ Negative Acceptance Criteria:

1. User memasukkan kata sandi lama yang salah

2. User memasukkan kata sandi baru sama dengan kata sandi lama

3. User memasukkan konfirmasi sandi baru yang tidak sama dengan sandi baru.

4. User memasukkan kata sandi baru yang tidak sesuai aturan keamanan (terlalu pendek, hanya angka, dll).

5. User meninggalkan salah satu field kosong (sandi lama, sandi baru, atau konfirmasi).

📄 Feature: Telegram Notification 

🎯 User Story: Sebagai employee Saya ingin menghubungkan akun saya dengan Telegram bot Sehingga saya dapat menerima notifikasi aplikasi langsung di Telegram.

✅ Positive Acceptance Criteria:

1. User dapat membuka halaman Telegram Notification di aplikasi.

2. User klik tombol Buka Telegram Bot, diarahkan ke Telegram bot.

3. Telegram bot muncul dan user klik/ketik /start untuk mulai.

4. User ketik /register email, untuk registrasi email ke bot dengan email yang terdaftar di peoplehub

5. Registrasi berhasil dan user akan menerima kode OTP, baik pada in mail email, atau notifikasi aplikasi

6. User memasukan token otorisasi dan klik tombol verifikasi

7. User berhasil menghubungkan Telegram dengan aplikasi

8. User klik tombol putuskan koneksi untuk memutuskan koneksi

9. User dapat menghubungkan akun telegram nya agar bisa dikirim notifikasi ketika ada event tertentu seperti approval disetujui/ditolak

10. User dapat melepaskan akun telegram agar tidak dikirim notifikasi ke telegram 

❌ Negative Acceptance Criteria:

1. User mengetik perintah selain /register email.

2. User menggunakan email yang tidak terdaftar di PeopleHub saat /register

3. User tidak menerima kode OTP (karena email salah atau jaringan bermasalah).

4. User memasukkan OTP/token yang salah atau expired.

5. User klik Putuskan Koneksi, tetapi sistem gagal melakukan disconnect

📄 Feature: Employee List

🎯 User Story: Sebagai employee Saya ingin melihat info employee lain yang ada di perusahaan saya.

✅ Positive Acceptance Criteria

1. Karyawan dapat mengakses halaman Employee List yang menampilkan daftar semua karyawan.

2. Setiap entri karyawan di dalam daftar harus menampilkan informasi dasar seperti nama, jabatan, dan departemen.

3. Terdapat kolom pencarian yang memungkinkan karyawan untuk mencari rekan kerja berdasarkan kriteria tertentu (misalnya, nama, jabatan, atau departemen).

4. Karyawan dapat mengklik nama atau foto profil karyawan lain untuk melihat detail informasi yang lebih lengkap (misalnya, email, nomor telepon, atau lokasi kantor).

5. Halaman ini harus menampilkan data yang akurat dan terkini sesuai dengan data master karyawan.

❌ Negative Acceptance Criteria

1. Karyawan tidak dapat mengedit atau menghapus data karyawan lain.

2. Data sensitif seperti gaji, informasi pribadi yang bersifat rahasia, atau data performa tidak boleh ditampilkan pada halaman ini.

3. Karyawan yang tidak memiliki akses atau permission tidak bisa melihat daftar ini.

📄 Feature: Org Chart

🎯 User Story: Sebagai employee Saya ingin melihat struktur organisasi di perusahaan saya.

✅ Positive Acceptance Criteria:

1. Karyawan dapat mengakses halaman Org Chart.

2. Tampilan Org Chart harus representatif dan mudah dipahami, idealnya dalam bentuk bagan visual atau pohon hierarki.

3. Bagan harus menampilkan nama karyawan, jabatan, dan hubungan pelaporan (misalnya, siapa yang melapor kepada siapa).

4. Struktur organisasi harus akurat dan terkini sesuai dengan data yang telah ditetapkan di fitur lain (misalnya, Job Position dan Employee List).

❌ Negative Acceptance Criteria:

1. User tidak dapat mengubah atau mengedit struktur organisasi. Tampilan ini hanya bersifat read-only.

2. Data sensitif seperti gaji atau informasi pribadi rahasia tidak boleh ditampilkan di Org Chart.

3. Karyawan hanya dapat melihat struktur yang relevan dengan mereka. Meskipun tidak ada larangan untuk melihat keseluruhan bagan, detail sensitif tetap harus dibatasi.

4. Jika ada data yang tidak terisi (misalnya, seorang karyawan belum memiliki atasan yang ditetapkan), sistem harus menanganinya dengan baik dan tidak menimbulkan error.

📄 Feature: Request (Basic Info)

🎯 User Story: Sebagai employee Saya ingin mengajukan pengisian dan perubahan data pribadi agar bisa di-approve sama approver.

✅ Positive Acceptance Criteria:

❌ Negative Acceptance Criteria:

📄 Feature: Request (Family)

🎯 User Story: Sebagai employee Saya ingin mengajukan pengisian dan perubahan data keluarga agar bisa di-approve sama approver.

📄 Feature: Request (Permit)

Note:

• 
  

2. 
   

📄 Feature: Request (SPPD)

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan perjalanan dinas (SPPD) melalui portal web atau aplikasi mobile. Tujuannya agar saya bisa mengajukan permohonan dengan mudah, memiliki catatan yang jelas tentang status dan riwayatnya, serta selalu mendapatkan pembaruan status pengajuan di mana saja dan kapan saja.

✅ Positive Acceptance Criteria:

1. Pengajuan Perjalanan Dinas:

1. Pengguna dapat mengakses halaman pengajuan perjalanan dinas di portal web dan aplikasi mobile.

2. Formulir pengajuan harus konsisten di kedua platform dan meminta detail wajib seperti tanggal pergi, tanggal kembali, tujuan, dan alasan.

3. Pengguna dapat memilih tanggal di masa depan.

4. Setelah pengajuan dikirim, notifikasi sukses akan muncul dan statusnya berubah menjadi Pending.

2. Pemberitahuan & Status:

1. Pengguna dapat melihat riwayat semua pengajuan perjalanan dinas beserta statusnya (disetujui, ditolak, pending) di kedua platform.

2. Pengguna menerima notifikasi push (untuk mobile) ketika pengajuan disetujui atau ditolak.

3. Tampilan riwayat pengajuan SPPD harus konsisten di web dan mobile.

❌ Negative Acceptance Criteria:

1. Validasi Formulir:

1. Sistem harus mencegah pengajuan perjalanan dinas untuk tanggal di masa lalu atau tanggal yang tidak valid.

2. Sistem harus menolak pengajuan jika ada data wajib yang tidak terisi.

2. Performa & Stabilitas:

1. Aplikasi mobile tidak boleh gagal atau mengalami crash saat pengguna mencoba mengajukan perjalanan dinas.

3. Notifikasi:

1. Notifikasi tidak boleh terlambat atau tidak terkirim.

4. Manajemen Data:

1. Pengguna tidak bisa mengubah atau menghapus pengajuan yang sudah disetujui atau ditolak.

📄 Feature: Request (Time Off)

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan cuti melalui portal web atau aplikasi mobile dan memantau status pengajuan saya. Tujuannya agar saya bisa mengajukan cuti dengan mudah, memiliki informasi yang jelas mengenai sisa saldo cuti, dan mendapatkan pembaruan status pengajuan di mana saja dan kapan saja.

✅ Positive Acceptance Criteria:

1. Pengajuan Cuti:

1. Pengguna dapat mengakses halaman pengajuan cuti di portal web dan aplikasi mobile.

2. Formulir pengajuan harus konsisten di kedua platform dan meminta detail wajib seperti jenis cuti, tanggal mulai, tanggal selesai, dan alasan.

3. Pengguna dapat melihat sisa saldo cuti yang tersedia di kedua platform sebelum mengajukan cuti.

4. Setelah pengajuan dikirim, statusnya berubah menjadi Pending dan muncul dalam daftar riwayat pengajuan.

2. Pemberitahuan & Status:

1. Pengguna dapat melihat riwayat semua pengajuan cuti beserta statusnya (disetujui, ditolak, pending) di kedua platform.

2. Pengguna dapat melihat alur persetujuan untuk pengajuan cutinya.

3. Pengguna menerima notifikasi push (untuk mobile) dan/atau notifikasi di aplikasi ketika pengajuan cutinya disetujui atau ditolak.

4. Tampilan riwayat pengajuan cuti harus konsisten di web dan mobile.

❌ Negative Acceptance Criteria:

1. Validasi Formulir:

1. Sistem harus mencegah pengajuan cuti jika saldo tidak mencukupi.

2. Sistem harus menolak pengajuan cuti untuk tanggal di masa lalu atau tanggal yang tidak diizinkan oleh admin.

3. Pengguna tidak bisa mengajukan cuti untuk jenis cuti yang tidak dialokasikan untuknya.

2. Performa & Stabilitas:

1. Aplikasi mobile tidak boleh gagal atau mengalami crash saat pengguna mencoba mengajukan cuti.

3. Notifikasi:

1. Notifikasi tidak boleh terlambat atau tidak terkirim.

4. Manajemen Data:

1. Pengguna tidak bisa mengubah atau menghapus pengajuan yang sudah disetujui atau ditolak.

📄 Feature: Request (Reimbursement)

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan reimbursement melalui portal web atau aplikasi mobile sesuai dengan kebijakan yang diatur oleh admin. Tujuannya agar saya bisa mendapatkan penggantian biaya dengan mudah dan memantau proses persetujuannya hingga selesai.

2. Acceptance Criteria

✅ Positive Acceptance Criteria:

1. Pengajuan Reimbursement:

1. Pengguna dapat mengakses fitur pengajuan reimbursement di portal web dan aplikasi mobile.

2. Formulir pengajuan harus konsisten di kedua platform dan meminta detail wajib seperti jenis pengeluaran, deskripsi, tanggal, dan jumlah.

3. Pengguna dapat melihat sisa saldo dari setiap jenis reimbursement yang dapat diajukan di kedua platform.

4. Setelah pengajuan dikirim, notifikasi sukses akan muncul dan statusnya berubah menjadi Pending.

2. Manajemen Lampiran:

1. Pengguna dapat mengunggah lampiran sebagai bukti pengeluaran di kedua platform, dengan ukuran file maksimal 2 MB.

3. Pemberitahuan & Status:

1. Sistem harus menampilkan alur persetujuan yang jelas (nama-nama atasan yang akan menyetujui) di kedua platform.

2. Pengguna menerima notifikasi push (untuk mobile) dan/atau notifikasi di aplikasi ketika pengajuan reimbursement-nya disetujui atau ditolak.

3. Tampilan riwayat pengajuan reimbursement harus konsisten di web dan mobile.

❌ Negative Acceptance Criteria:

1. Validasi & Batasan:

1. Sistem harus mencegah pengajuan jika total jumlah yang diajukan melebihi saldo yang tersedia.

2. Sistem harus menolak pengajuan jika ada field wajib yang tidak terisi. 

3. Sistem harus menolak unggahan lampiran jika ukuran file melebihi 2 MB. PASSED

2. Konsistensi & Stabilitas:

1. Aplikasi mobile tidak boleh gagal atau mengalami crash saat pengguna mencoba mengajukan reimbursement.

2. Notifikasi tidak boleh terlambat atau tidak terkirim.

3. Manajemen Data:

1. Pengguna tidak bisa mengajukan reimbursement untuk jenis pengeluaran yang tidak tersedia.

📄 Feature: Request (Cash Advance)

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan cash advance melalui portal web atau aplikasi mobile sesuai kebijakan perusahaan. Tujuannya agar saya bisa mendapatkan uang muka untuk keperluan kerja dan memantau proses persetujuannya dengan mudah, di mana pun dan kapan pun.

✅ Positive Acceptance Criteria:

1. Pengajuan Cash Advance:

1. Pengguna dapat mengakses fitur pengajuan cash advance di portal web dan aplikasi mobile.

2. Formulir pengajuan harus konsisten di kedua platform dan meminta detail wajib seperti Jenis Kegiatan, Tanggal, Keperluan Pengajuan, Tujuan, dan Catatan.

3. Pengguna dapat menambahkan detail pengeluaran (Nama, Deskripsi, Kategori, Jumlah, dan Qty).

4. Pengguna dapat mengunggah lampiran dengan ukuran file maksimal 2 MB.

5. Setelah pengajuan dikirim, notifikasi sukses akan muncul dan statusnya berubah menjadi Pending.

2. Pemberitahuan & Status:

1. Sistem harus menampilkan alur persetujuan yang jelas (nama-nama atasan yang akan menyetujui) di kedua platform.

2. Pengguna menerima notifikasi push (untuk mobile) dan/atau notifikasi di aplikasi ketika pengajuan cash advance-nya disetujui atau ditolak.

3. Tampilan riwayat pengajuan cash advance harus konsisten di web dan mobile.

❌ Negative Acceptance Criteria:

1. Validasi & Batasan:

1. Sistem harus mencegah pengajuan jika ada field wajib yang tidak terisi.

2. Sistem harus menolak pengajuan jika total jumlah yang diajukan melebihi batas yang telah ditentukan oleh admin.

3. Sistem harus menolak unggahan lampiran jika ukuran file melebihi 2 MB.

2. Konsistensi & Stabilitas:

1. Aplikasi mobile tidak boleh gagal atau mengalami crash saat pengguna mencoba mengajukan cash advance.

2. Tampilan harus responsif dan semua elemen formulir harus dapat diakses dengan mudah di layar sentuh.

3. Notifikasi:

1. Notifikasi tidak boleh terlambat atau tidak terkirim.

4. Manajemen Data:

1. Pengguna tidak bisa mengubah atau menghapus pengajuan yang sudah disetujui atau ditolak.

📄 Feature: Request (Attendance)

🎯 User Story: Sebagai employee Saya ingin dapat mengajukan perbaikan absensi dengan mudah melalui aplikasi mobile jika saya lupa check-in atau check-out. Tujuannya agar saya bisa memperbaiki data kehadiran saya kapan saja dan di mana saja, dan riwayat kehadiran saya tetap akurat.

✅ Positive Acceptance Criteria:

1. Pengguna dapat mengakses halaman pengajuan absensi yang terlupa.

2. Formulir pengajuan harus meminta detail wajib, seperti tanggal, jam check-in, jam check-out, dan alasan lupa absensi.

3. Pengguna hanya bisa mengajukan absensi untuk tanggal yang berada dalam batas backdate yang telah diatur oleh admin.

4. Setelah pengajuan dikirim, notifikasi sukses akan muncul.

5. Pengguna dapat melihat status pengajuan (pending, disetujui, ditolak) dalam daftar riwayat.

6. Request date max 1 hari (configurable by admin)
7. Jika user belum cekin di tanggal yg direquest, maka harus cekin & cekout wajib diisi
8. Jika user sudah cekin di tanggal yg direquest, maka yang wajib diisi hanya cekout

❌ Negative Acceptance Criteria:

1. Sistem harus mencegah pengajuan jika tanggal yang dipilih melebihi batas backdate yang telah diatur admin.

2. Sistem harus menolak pengajuan jika ada field wajib yang tidak terisi (misalnya, alasan atau jam).

3. User tidak bisa mengajukan absensi yang tumpang tindih dengan data absensi yang sudah ada atau dengan jenis cuti/izin lainnya.

4. User tidak dapat mengubah atau menghapus pengajuan yang sudah disetujui atau ditolak.

📄 Feature: Request (Change Shift)

🎯 User Story: Sebagai employee Saya ingin mengajukan perubahan shift di masa datang sesuai kebijakan yang diatur oleh admin perusahaan.

✅ Positive Acceptance Criteria:

1. User dapat mengajukan dan memilih shift pengganti.

2. User dapat mengunggah dokumen pendukung untuk shift pengganti dengan maksimal 2MB.

❌ Negative Acceptance Criteria:

1. User mengupload file yang ukurannya tidak semua dengan ketentuan.

2. User tidak dapat memilih tanggal pergantian shift untuk hari yang sudah lewat.

📄 Feature: Notification

🎯 User Story: Sebagai employee saya ingin menerima notifikasi melalui berbagai saluran (di aplikasi, email, FCM, dan Telegram). Tujuannya agar saya tidak ketinggalan informasi penting, seperti status pengajuan saya atau pengumuman perusahaan, di mana pun dan kapan pun.

✅ Positive Acceptance Criteria:

1. Pengguna menerima notifikasi di dalam aplikasi untuk setiap perubahan status pada pengajuan yang ia buat (misalnya, pengajuan cuti disetujui).

2. Pengguna menerima notifikasi melalui email untuk setiap perubahan status pada pengajuan.

3. Pengguna yang mengaktifkan FCM (push notification) di ponselnya menerima notifikasi pop-up saat ada pembaruan penting.

4. Pengguna yang telah mengintegrasikan akun Telegram-nya menerima notifikasi melalui Telegram.

5. Notifikasi harus terkirim secara real-time atau hampir real-time setelah suatu peristiwa terjadi.

6. Isi notifikasi harus jelas dan ringkas, mencakup informasi penting seperti jenis permintaan, status, dan nama approver (jika ada).

❌ Negative Acceptance Criteria:

1. Notifikasi tidak boleh gagal terkirim di salah satu atau semua saluran.

2. Notifikasi tidak boleh terlambat secara signifikan.

3. Notifikasi tidak boleh menampilkan informasi yang salah atau tumpang tindih.

4. Pengguna yang menonaktifkan satu jenis notifikasi (misalnya, email) tidak seharusnya menerima notifikasi melalui saluran tersebut, tetapi tetap menerima di saluran lain yang aktif.

5. Notifikasi tidak boleh terkirim ke pengguna yang salah.

📄 Feature: Auto-update mobile app

🎯 User Story: Sebagai employee Saya ingin aplikasi mobile yang saya gunakan mendapatkan pembaruan secara otomatis jika ada rilis versi terbaru. Tujuannya agar saya selalu menggunakan fitur-fitur terbaru dan perbaikan yang ada tanpa harus repot memperbarui secara manual.

✅ Positive Acceptance Criteria:

1. Ketika ada rilis aplikasi versi terbaru, pengguna yang mengaktifkan fitur pembaruan otomatis di perangkatnya akan mendapatkan pembaruan tanpa perlu tindakan manual.

2. Proses pembaruan harus berjalan di latar belakang (jika diizinkan oleh sistem operasi) dan tidak mengganggu penggunaan aplikasi saat itu.

3. Setelah pembaruan selesai, aplikasi harus berjalan normal dan menampilkan fitur-fitur baru atau perbaikan yang relevan.

4. Pengguna harus dapat melihat informasi versi terbaru di halaman pengaturan aplikasi.

❌ Negative Acceptance Criteria:

1. Aplikasi tidak boleh mengalami crash atau gagal berfungsi selama atau setelah proses pembaruan otomatis.

2. Proses pembaruan tidak boleh menguras baterai atau kuota data pengguna secara berlebihan.

3. Jika pengguna tidak mengaktifkan pembaruan otomatis, aplikasi harus memberikan notifikasi atau pesan yang jelas tentang ketersediaan pembaruan terbaru.

4. Aplikasi tidak boleh secara otomatis memperbarui dirinya jika pengguna hanya terhubung ke jaringan seluler (kecuali diizinkan oleh preferensi pengguna).

⚙️ Platform: Background/Scheduler

📄 Feature: Attendance

🎯 User Story: Sebagai admin Saya ingin sistem secara otomatis men-generate perhitungan kehadiran dan menyimpannya di database. Tujuannya agar data kehadiran dapat diakses dengan cepat dan efisien tanpa membebani server, serta memberikan laporan yang akurat dan up-to-date setiap harinya.

✅ Positive Acceptance Criteria:

1. Proses penjadwalan (scheduler) harus dapat berjalan secara otomatis sesuai jadwal yang telah ditentukan (misalnya, setiap hari pukul 00:00).

2. Sistem harus dapat menghitung data kehadiran untuk setiap karyawan, termasuk status seperti Absen, Terlambat, Cuti, Lembur, Izin, dan lainnya, berdasarkan data check-in/check-out dan kebijakan yang berlaku.

3. Hasil perhitungan harus disimpan dalam tabel terpisah yang dioptimalkan untuk performa.

4. Data yang ditampilkan pada dashboard Attendance Log harus mengambil data dari tabel yang telah digenerate oleh scheduler ini.

5. Jika ada data backdate yang diajukan atau disetujui, scheduler harus dapat memproses ulang data untuk tanggal yang relevan.

❌ Negative Acceptance Criteria:

1. Proses scheduler tidak boleh gagal atau berhenti tanpa adanya notifikasi atau log error.

2. Data yang digenerate oleh scheduler tidak boleh salah atau berbeda dari perhitungan manual.

3. Jika proses perhitungan berjalan, kinerja sistem tidak boleh menurun secara signifikan.

4. Scheduler tidak boleh memproses ulang seluruh data jika hanya ada perubahan pada satu atau dua data karyawan.

5. Jika ada kesalahan dalam proses, sistem harus memiliki mekanisme retry atau pemulihan otomatis.

✅ Positive Acceptance Criteria:

1. Sistem secara otomatis akan melacak batas waktu penyelesaian untuk setiap pengajuan cash advance yang telah disetujui.

2. Sistem akan mengirimkan notifikasi pengingat kepada karyawan yang bersangkutan pada waktu yang telah ditentukan (misalnya, 3 hari sebelum batas waktu).

3. Notifikasi pengingat harus dikirimkan melalui saluran yang telah dikonfigurasi (misalnya, di dalam aplikasi, email, atau FCM).

4. Isi notifikasi harus jelas dan informatif, mencakup nama pengajuan cash advance, tanggal jatuh tempo penyelesaian, dan tautan untuk melakukan settlement.

5. Jika karyawan sudah melakukan settlement, notifikasi pengingat ini tidak boleh lagi dikirimkan.

❌ Negative Acceptance Criteria:

1. Notifikasi pengingat tidak boleh gagal terkirim atau terlambat.

2. Sistem tidak boleh mengirimkan pengingat kepada karyawan yang sudah menyelesaikan cash advance-nya.

3. Notifikasi pengingat tidak boleh menampilkan informasi yang salah mengenai batas waktu atau pengajuan.

4. Sistem tidak boleh berhenti mengirimkan pengingat jika karyawan terus mengabaikan notifikasi sampai batas waktu terlampaui.

📄 Feature: Cash Advance Reminder

🎯 User Story: Sebagai employee Saya ingin menerima pengingat (reminder) jika saya belum melakukan penyelesaian (settlement) untuk cash advance yang saya ajukan, sesuai dengan waktu yang ditentukan oleh sistem. Tujuannya agar saya tidak lupa dan terhindar dari sanksi atau surat peringatan.

⚙️ Non-functional

📄 Feature: Checkin & checkout tps

🎯 User Story: Sebagai user Saya ingin bisa checkin dan checkout dengan cepat meskipun dalam kondisi banyak user berbarengan sehingga proses cekin lancar dan tidak menunggu lama

⚙️ New User/Company Setup Sequence

1. Self-register user (as admin)

2. Verify email

1. Activate user

2. Auto seed per-company default data (once)

3. Login to web admin

4. Setup roles & permissions note: bisa ngga tidak wajib dipilih user?

5. Setup head office note: err Company not found ~ no emp info?

6. Setup branch (opt, tergantung ada/tidak branch)

7. Setup satellite office (opt, tergantung ada/tidak)

8. Setup employment status

9. Setup grade & class

10. Setup job position

11. Setup job level

12. Setup holiday

13. Setup schedule

1. Break

2. Shift

3. Schedule

14. Setup employee_id

15. Insert add user/employee

16. Setup organization

17. Setup approval

18. Setup announcement

19. Setup project

Note: Sangat disarankan untuk setup new company sesuai urutan agar tidak bolak-balik karena memerlukan data di menu sebelumnya