Konfigurasi Kas Bon β
Kas Bon digunakan untuk dana perusahaan yang diajukan sebelum biaya dibayar. Pemohon kemudian mengajukan realisasi berisi pengeluaran aktual serta sisa yang perlu dikembalikan atau kekurangan yang dibayar perusahaan. Alurnya berbeda dari reimbursement atas biaya yang sudah dibayar karyawan.
Gunakan bab ini jika Anda mengelola fitur tersebut. Siapkan posisi, pengguna aktif, izin, kategori biaya, dan field tambahan melalui Setup Awal. Transfer tetap dilakukan melalui channel pembayaran eksternal perusahaan; Reimburse.id menata persetujuan, pencatatan dana, bukti, dan saldo.
Siapkan Modul dengan Urutan yang Tepat β
Formulir dapat disiapkan saat modul belum aktif. Jangan membuka pengajuan sebelum tugas pemohon dan pengelola dana siap. Satu orang dapat menangani beberapa tugas jika perannya memiliki izin yang sesuai.
Pahami Dua Kontrol Perusahaan β
Buka Konfigurasi β Umum & Kontrol β Pengaturan dan cari kontrol Kas Bon.

| Kontrol | Fungsinya |
|---|---|
| Aktifkan modul Kas Bon | Membuka fitur sesuai hak akses pengguna. |
| Terima pengajuan Kas Bon baru | Mengizinkan pengajuan baru jika modul aktif dan ada formulir yang sesuai. |
Biarkan keduanya nonaktif selama persiapan. Untuk menghentikan pengajuan baru sambil menyelesaikan pekerjaan existing, pertahankan modul aktif dan matikan penerimaan pengajuan. Penerimaan tidak dapat aktif saat modul mati. Menonaktifkan modul dapat ditolak jika masih ada dokumen belum selesai, termasuk draf; jangan menonaktifkannya hanya untuk menyembunyikan pekerjaan tertunda.
Aktivasi memeriksa formulir aktif dan melaporkan konfigurasi yang belum lengkap. Baca setiap alasannya, bukan menganggap formulir yang tersimpan pasti siap. Pemeriksaan ini tidak menggantikan verifikasi izin petugas dan kebijakan perusahaan.
Berikan Akses Sesuai Tanggung Jawab β
Buka Konfigurasi β Pengguna & Akses β Peran.
| Tanggung Jawab | Akses yang Perlu Diperiksa |
|---|---|
| Pemohon | Dokumen Kas Bon sendiri dan pembuatan pengajuan melalui formulir yang sesuai. |
| Pemberi persetujuan | Persetujuan pengajuan dan/atau realisasi pada fase yang ditugaskan. |
| Tim pengelola dana | Pemrosesan Kas Bon serta tindakan pencairan, verifikasi pengembalian, pembayaran selisih, atau pembalikan yang diizinkan. |
| Pemeriksa | Daftar/laporan yang sesuai, dengan cakupan seperlunya. |
| Administrator | Pengaturan dan konfigurasi formulir. |
Pemberi persetujuan pengajuan tidak otomatis menjadi pemberi persetujuan realisasi. Menyetujui pengajuan juga tidak memberikan akses mencatat pencairan. Periksa setiap tanggung jawab secara terpisah. HR, administrasi, atau tim lain dapat mengelola dana; izin lebih menentukan daripada nama departemen.
Buat atau Buka Formulir β
Buka Konfigurasi β Form & Field β Form Kas Bon. Klik Tambah, lengkapi informasi awal formulir, lalu simpan; atau gunakan Ubah pada formulir existing.
Formulir baru langsung aktif setelah penyimpanan pertama. Jika perusahaan sudah menerima pengajuan, hentikan sementara penerimaan pada Pengaturan sebelum menyiapkan formulir yang belum lengkap; pekerjaan existing dapat berlanjut selama modul tetap aktif.

Gunakan tindakan perpindahan untuk mengubah urutan menu pengajuan; perpindahan berhasil langsung tersimpan. Gunakan tindakan status aktif untuk menyediakan formulir yang sudah siap. Pengguna tetap memerlukan akses modul/penerimaan dan peran yang sesuai; status aktif saja tidak cukup.
| Tab | Fungsinya |
|---|---|
| Umum | Identitas, penomoran, bukti wajib, kuantitas/harga, dan tenggat realisasi. |
| Akses & Field | Peran pemohon, kategori biaya, dan field tambahan setiap fase/konteks. |
| Approval pengajuan | Aturan saat meminta dana. |
| Approval realisasi | Aturan saat melaporkan pengeluaran aktual. |
| Instruksi | Panduan praktis yang dapat dibuka pengguna. |
| Cetak | Desain terpisah untuk pengajuan dan realisasi. |
Editor menyimpan bagian yang sedang dibuka. Setelah mengubah tab, klik Simpan sebelum melanjutkan; menyimpan satu bagian tidak berarti perubahan belum tersimpan pada semua tab ikut disimpan.
Atur Perilaku Umum dan Penomoran β

Pilih nama dan deskripsi yang mudah dikenali. Periksa kontrol berikut:
| Pengaturan | Artinya |
|---|---|
| Prefix/suffix dokumen, nomor berikutnya, panjang, reset | Penomoran pengajuan dan preview. Token tanggal meliputi {YYYY}, {YY}, dan {MM}. |
| Gunakan jumlah dan harga | Baris biaya realisasi menggunakan kuantitas Γ harga satuan. |
| Lampiran pengajuan wajib | Bukti pendukung diperlukan sebelum pengajuan dikirim untuk persetujuan. |
| Bukti wajib pada setiap detail realisasi | Setiap baris biaya memerlukan bukti sebelum realisasi dikirim. |
| Hari jatuh tempo setelah kegiatan selesai | Hari kalender setelah tanggal akhir kegiatan. Contoh 10 Oktober ditambah tujuh hari menjadi 17 Oktober; nol berarti jatuh tempo pada 10 Oktober. |
| Ikon | Identitas bawaan/unggahan pada menu pengajuan. |
Penomoran mengikuti zona waktu perusahaan, bukan tanggal kegiatan atau jam perangkat. Nomor existing tidak ditulis ulang saat konfigurasi berubah. Tenggat realisasi adalah batas pertanggungjawaban dana, bukan tanggal transfer otomatis.
Pilih Akses, Kategori, dan Field Tambahan β

Role pemohon tertentu membatasi formulir pada peran terpilih. Biarkan kosong untuk semua peran, termasuk yang ditambahkan nanti; pengguna tetap memerlukan izin membuat sendiri.
Expense Type tertentu membatasi kategori biaya realisasi. Label UI ini merujuk pada master kategori biaya yang sama. Biarkan kosong untuk semua kategori aktif, termasuk kategori baru. Ganti atau aktifkan kembali kategori terpilih jika pemeriksaan konfigurasi menyatakan kategori tersebut nonaktif.
| Area Field | Diisi Pengguna |
|---|---|
| Field Tambahan Header Pengajuan | Sekali pada pengajuan, seperti kode proyek atau referensi kegiatan. |
| Field Tambahan Header Realisasi | Sekali untuk realisasi, seperti catatan penyelesaian. |
| Field Tambahan Detail Biaya Realisasi | Pada setiap baris biaya aktual, seperti nama toko atau referensi struk. |
Pilih field aktif dengan jenis, status wajib, dan teks bantuan yang tepat. Urutan pemilihan disimpan terpisah pada setiap area; field terakhir tampil paling bawah. Satu field dapat dipakai pada beberapa area, tetapi nilainya memiliki konteks masing-masing.
Atur Dua Fase Persetujuan β
Approval pengajuan menentukan apakah dana dapat dilanjutkan ke pencairan. Approval realisasi memeriksa biaya aktual setelah dana digunakan. Atur keduanya secara terpisah.


Pada setiap fase, tambahkan aturan bernama. Isi kondisi IF dan tahap THEN, simpan, lalu periksa prioritas/status aktif. Semua kondisi IF pada aturan harus cocok. Aturan aktif diperiksa berdasarkan prioritas dan hanya aturan pertama yang cocok dipilih. IF kosong mencakup semua transaksi pada formulir/fase itu. Editor hanya mengizinkan satu aturan IF kosong yang tersimpan per fase, termasuk aturan nonaktif. Untuk mengubah alur umum tersebut, ubah aturan yang sudah ada; menonaktifkannya tidak membuat aturan kedua dapat ditambahkan. Aturan nonaktif tidak ikut diperiksa.
| Fase | Kondisi yang Berguna |
|---|---|
| Pengajuan | Nominal diminta, posisi, deskripsi, tanggal kegiatan, dan field header pengajuan. |
| Realisasi | Jumlah biaya realisasi, selisih absolut, kategori biaya, dan field header realisasi. |
Selisih absolut adalah besar selisih antara biaya realisasi dan dana bersih yang dicairkan. Bukan berarti βjumlah yang wajib dikembalikan karyawanβ: realisasi lebih besar atau lebih kecil dapat memiliki selisih absolut yang sama.
Untuk tahap THEN, pilih pengguna tertentu, Atasan pemohon (dinamis), atau PIC Posisi (dinamis), serta apakah satu (OR) atau semua (AND) wajib menyetujui. Inilah label pilihan pada Kas Bon: pilihan dinamis pertama memakai cara penentuan Supervisor; pilihan kedua memakai cara penentuan PIC Posisi Teratas pada Pemberi persetujuan di THEN. Tahap berikut mengikuti tahap sebelumnya. Hierarki posisi dan pemeriksaan akses persetujuan sama; tidak ada field PIC tersendiri pada posisi.
Kas Bon menangani pemohon yang dipilih sebagai pemberi persetujuan secara berbeda dari Reimbursement. Pada persetujuan pengajuan maupun realisasi, memilih pemohon secara langsung sebagai pemberi persetujuan merupakan kesalahan konfigurasi. Delegasi dari pihak lain yang akhirnya menunjuk pemohon juga ditolak. Pilih pihak lain yang memenuhi syarat; jangan menganggap pilihan tersebut akan dilewati atau disetujui otomatis. Pilihan dinamis yang tidak menemukan kandidat tersisa merupakan situasi berbeda.
Jika tidak ada aturan cocok, fase persetujuan tersebut selesai otomatis. Pengajuan dapat selesai tanpa pemberi persetujuan, tetapi pencairan tetap perlu dicatat secara terpisah. Realisasi dapat disetujui otomatis, tetapi verifikasi pengembalian atau pembayaran selisih mungkin masih diperlukan. Jangan menganggap persetujuan otomatis sebagai pembayaran otomatis atau pengganti bukti biaya.
Periksa Kedua Alur β

- Simpan aturan fase tersebut dan klik Uji Workflow pada fase yang sama.
- Pilih pemohon yang dituju.
- Untuk pengajuan, isi nominal diminta dan nilai terkait sebagai contoh.
- Untuk realisasi, isi nominal biaya dan Pencairan bersih contoh. Selisih absolut dihitung otomatis.
- Klik Simulasikan, lalu periksa aturan terpilih, kondisi, tahap, delegasi, serta peringatan izin.
- Ulangi untuk nilai batas dan kasus tanpa kecocokan jika kebijakan mengizinkannya.
Simulasi tidak membuat, mengajukan, menyetujui, atau membayar transaksi. Izin persetujuan yang belum tersedia dapat membuat pengguna terpilih tetap Pending, bukan menggantinya diam-diam. Tahap dinamis kosong dapat dilewati; periksa hasil tersebut sebelum menerima pengajuan. Pengajuan realisasi aktual tetap memvalidasi bukti.
Tambahkan Instruksi dan Desain Cetak Opsional β
Pada Instruksi, aktifkan panduan prosedur, tulis arahan singkat, lalu simpan. Misalnya, jelaskan bukti pengajuan dan cara mempertanggungjawabkan dana yang tidak terpakai. Pengguna membuka panduan melalui ikon instruksi dokumen. Halaman yang dibuka kembali memakai instruksi terbaru, termasuk dokumen existing.


Pada Cetak, pilih template pengajuan dan realisasi yang sesuai secara terpisah, atau kosongkan untuk desain bawaan. Kelola template cetak Kas Bon melalui Konfigurasi β Template & Ekspor β Template Cetak Kas Bon. Desain khusus bersifat opsional; tidak menentukan akses persetujuan.
Pahami Dampak Perubahan pada Dokumen Existing β
Menyimpan draf belum membekukan konfigurasi formulir. Pengubahan draf dan pengajuan memakai formulir yang berlaku saat itu, sehingga perubahan administrator dapat memengaruhi draf yang belum diajukan.
Saat pengajuan dikirim untuk persetujuan, Reimburse.id menyimpan salinan konfigurasi, termasuk perilaku terkait, hubungan field, aturan alur, dan informasi template cetak. Mengirim ulang pengajuan yang telah diperbaiki setelah ditolak memperbarui salinan tersebut dari formulir yang berlaku dan membentuk ulang alur persetujuan pengajuan. Periksa persyaratan yang berlaku sebelum mengirim atau mengirim ulang.
Setelah pengajuan disetujui, realisasi memakai salinan konfigurasi dari pengiriman pengajuan terakhir. Perubahan formulir berikutnya tidak mengganti konfigurasi realisasi tersebut hanya karena administrator menyimpan formulir. Simulator memeriksa formulir hari ini, sehingga hasil realisasinya dapat berbeda dari pengajuan yang sudah disetujui.
Instruksi adalah pengecualian penting: isi terbaru ditampilkan saat halaman dibuka kembali. Izin yang berlaku saat ini, status akun, dan delegasi juga perlu diperiksa; salinan konfigurasi bukan pemberian akses permanen.
Checklist Kesiapan Akhir β
- Minimal satu formulir aktif dan pemeriksaan konfigurasinya sudah jelas.
- Peran pemohon dan kategori biaya aktif tersedia.
- Field/bukti wajib serta tenggat sesuai kebijakan perusahaan.
- Aturan pengajuan dan realisasi diperiksa terpisah, termasuk tanpa kecocokan serta nilai batas.
- Setiap pemberi persetujuan memiliki akses fase yang sesuai.
- Tim pengelola dana memiliki tindakan yang diperlukan dan memahami bahwa transfer dilakukan di luar aplikasi.
- Aktifkan modul pada Pengaturan, simpan, lalu izinkan pengajuan baru saat perusahaan siap.
Pemohon kemudian dapat memilih formulir yang sesuai di menu pengajuan. Ikuti proses perusahaan yang disepakati untuk mencatat pencairan, mengirim realisasi, dan menyelesaikan saldo yang tersisa.
Masalah Umum β
| Masalah | Yang Perlu Diperiksa |
|---|---|
| Formulir tidak ada di menu pengajuan | Modul, penerimaan, status aktif, peran pemohon, dan akses membuat. |
| Modul tidak bisa diaktifkan | Baca alasan konfigurasi belum lengkap pada formulir aktif. |
| Modul tidak bisa dinonaktifkan | Dokumen belum selesai mungkin tersisa; hentikan pengajuan baru jika itu yang dibutuhkan. |
| Pengguna terpilih tidak dapat bertindak | Akses fase, akun aktif, delegasi, dan hierarki. |
| Alur realisasi lama berbeda dari preview | Dokumen dapat memakai salinan konfigurasi dari pengajuan awal. |
| Persetujuan otomatis tidak mencairkan dana | Persetujuan dan pencatatan pencairan eksternal adalah tindakan terpisah. |
