Receivable Payments (Permintaan Penagihan Piutang)
Tujuan
Menu Receivable Payment menampilkan daftar permintaan penagihan dan form Tambah Permintaan Penagihan Piutang.
Form memperlihatkan pemilihan customer/piutang, nominal yang ditagihkan, serta tabel penagihan. Nama menu dan form tidak
secara sendiri membuktikan penerimaan kas/bank aktual, pembayaran invoice, posting jurnal, atau integrasi Accurate.
Status bukti dan batas kajian
Daftar #!/keuangan/pembayaran_piutang dan form kosong #!/keuangan/pembayaran_piutang/create dibuka read-only pada
SOLOG dev. Tidak ada Filter, Add, Export Excel, field, pencarian piutang, Tagihkan Semua, Add to Table, Back, Save,
atau Detail Data yang digunakan. Identitas, nomor dokumen, branch, tanggal, customer, dan nilai pada gambar final
disamarkan.
Navigasi dan daftar
Finance & Accounting → Receivables → Receivable Payments.
| No. | Elemen | Fungsi UI yang terlihat | Batas kajian |
|---|---|---|---|
| 1 | Filter | Menyaring daftar permintaan penagihan | Tidak ditekan; kriteria tidak diuji |
| 2 | Add | Membuka form Tambah Permintaan Penagihan Piutang | Form kosong dibuka melalui rute aman; tidak disimpan |
| 3 | Export Excel | Mengekspor daftar | Tidak ditekan; format/hak akses belum diuji |
| 4 | Pemilih jumlah data | Opsi 10, 25, 50, 100, dan All | Hanya kontrol tampilan |
| 5 | Pencarian | Mencari daftar | Tidak diisi |
| 6 | Header tabel | Code, Branch, Date, Customer, No. Invoice, Jumlah Ditagihkan, Status, dan aksi | Sebagian header memiliki indikator urut |
| 7 | Baris daftar | Data permintaan penagihan per baris | Semua isi disamarkan; struktur DOM mendeteksi link Detail Data yang tidak dibuka |
| 8 | Pagination | Navigasi Sebelumnya/nomor halaman/Selanjutnya | Tidak digunakan |
Form tambah — data dan pemilihan piutang
| No. | Field/kontrol | Keterangan yang terlihat | Batas kajian |
|---|---|---|---|
| 1 | Branch | Pilihan branch; nilai awal disamarkan | Hak pemilihan branch belum diuji |
| 2 | Tgl Pengajuan* | Tanggal pengajuan | Nilai awal disamarkan |
| 3 | Tgl Diterima Penagih* | Tanggal diterima penagih | Nilai awal disamarkan |
| 4 | Customer* | Pilihan customer | Tidak dipilih |
| 5 | Keterangan kiri | Area catatan pengajuan | Tidak diisi |
| 6 | Daftar Piutang + pencarian | Field piutang dan ikon pencarian | Tidak digunakan |
| 7 | Jumlah Piutang | Nilai piutang yang dipilih | Nilai awal disamarkan; rumus belum diuji |
| 8 | Tagihkan Semua | Checkbox untuk penagihan seluruh nilai | Tidak dicentang |
| 9 | Jumlah Ditagihkan | Nominal yang ditagihkan | Nilai awal disamarkan |
| 10 | Keterangan kanan | Catatan untuk baris penagihan | Tidak diisi |
| 11 | Add to Table | Menambah piutang ke tabel Penagihan | Tidak ditekan; tampil nonaktif pada form kosong |
Form tambah — tabel dan penyimpanan
| No. | Elemen | Keterangan yang terlihat | Batas kajian |
|---|---|---|---|
| 1 | Add to Table | Kontrol yang sama untuk memasukkan detail ke tabel | Tidak ditekan |
| 2 | Header Penagihan | Menandai bagian daftar detail penagihan | Hanya struktur UI |
| 3 | Tabel penagihan | Kolom No. Transaksi, Jumlah Tagihan, Ditagihkan, Sisa Tagihan, Keterangan, dan kolom aksi | Tidak ada baris pada form kosong |
| 4 | Total | Ringkasan total tabel | Nilai ditutup; rumus belum diuji |
| 5 | Back | Kembali ke daftar | Tidak ditekan |
| 6 | Save | Menyimpan permintaan penagihan | Tidak ditekan |
Alur kerja yang direkomendasikan
- Finance/AR memastikan customer, branch, daftar piutang, tanggal pengajuan, serta hak akses telah disahkan.
- Periksa daftar Receivable Payment dan List Piutang untuk mencegah permintaan/penagihan ganda.
- Buat permintaan hanya setelah piutang, bukti invoice, penagih, dan kebijakan penagihan tersedia. Pengisian tidak dilakukan dalam kajian ini.
- Pilih customer dan piutang sesuai bukti. Putuskan apakah Tagihkan Semua dapat digunakan berdasarkan kebijakan OLR; jangan gunakan tanpa memeriksa saldo dan otorisasi.
- Periksa nominal ditagihkan, sisa tagihan, keterangan, dan tabel detail sebelum Save sesuai pemisahan peran.
- Setelah proses resmi berjalan, checker menelusuri status, bukti penagihan/penerimaan, dampak ke 14 - All Receivables, pembayaran, jurnal, dan rekonsiliasi pada system of record yang disahkan.
Variasi dan titik kendali
- Permintaan penagihan vs penerimaan pembayaran: heading menu menyebut Receivable Payment, tetapi form menyebut Permintaan Penagihan Piutang. Perbedaan arti, titik penerimaan kas, dan dampak status/jurnal belum diputuskan.
- Satu atau banyak piutang: Daftar Piutang, Tagihkan Semua, Add to Table, dan tabel detail tersedia. Penerimaan parsial, multi-invoice, kelebihan bayar, deposit, dan penghapusan tidak diuji.
- Tanggal: Tgl Pengajuan dan Tgl Diterima Penagih terlihat; definisi cut-off serta urutan operasional belum diverifikasi.
- Status: kolom Status tersedia pada daftar, tetapi definisi/transisi dan kaitannya dengan bank/cash receipt belum diuji.
- Akun/rekening/pajak: field rekening kas/bank, potongan, pajak, atau attachment tidak tampak pada form yang diperiksa; jangan menganggapnya tersedia atau otomatis terbentuk.
Pengguna dan kewenangan
| Fungsi | Peran yang disarankan | Batasan |
|---|---|---|
| AR/Finance | Menyiapkan dan menelusuri permintaan penagihan | Tidak menyimpan tanpa kewenangan |
| Penagih/Collection | Menerima penugasan dan bukti penagihan sesuai kebijakan | PIC aktual belum diputuskan |
| Billing/Commercial | Menyediakan invoice dan informasi customer | Tidak mengubah saldo tanpa peran AR |
| Cashier/Treasury | Merekonsiliasi penerimaan bila proses terhubung | Hubungan menu dengan penerimaan belum terbukti |
| Finance Manager/Chief Accounting | Menetapkan approval, batas nominal, dan cut-off | PIC aktual belum diputuskan OLR |
| Internal Control | Menguji anti-duplikasi dan bukti penagihan | Akses detail mengikuti kebijakan |
Prasyarat/master data
- Customer, branch, piutang/invoice, termin, user penagih, dan hak akses Finance tersedia serta disahkan.
- Bukti invoice/penagihan, daftar saldo, dan kebijakan penerimaan/cash handling tersedia.
- Peran preparer, checker, approver, serta system of record mengikuti 04 - Matriks PIC dan RACI Proses SOLOG dan 32 - Batas Sistem dan Rekonsiliasi SOLOG Accurate.
Lampiran/keluaran
- Keluaran UI: daftar Receivable Payment, form permintaan penagihan, serta tabel detail penagihan.
- Bukti yang perlu ditetapkan OLR: invoice, bukti penagihan, tanda terima, bukti kas/bank, approval, dan rekonsiliasi.
- Fitur attachment, print, bukti penerimaan, atau jurnal tidak tampak pada halaman/form yang diperiksa.
Hubungan antarmodul
14 - All Receivables · 16 - Receivable Confirm · 10 - Deposit Customer · 24 - Cash Bank Transactions · 27 - Journals · 32 - Batas Sistem dan Rekonsiliasi SOLOG Accurate
Checklist
- Customer, branch, tanggal pengajuan/diterima penagih, dan piutang diperiksa terhadap bukti.
- Permintaan/penagihan ganda dicegah melalui daftar dan register resmi.
- Nominal, sisa tagihan, dan keterangan direview oleh checker sebelum Save.
- Tagihkan Semua dan Add to Table digunakan hanya sesuai wewenang/prosedur.
- Status dan bukti penagihan/penerimaan ditelusuri sebelum melakukan koreksi.
- Rekening/bank, deposit, pajak, jurnal, dan rekonsiliasi SOLOG–Accurate/manual diputuskan dan dicatat di luar asumsi UI.
Gap yang perlu dikonfirmasi
- Kriteria Filter, Export Excel, Detail Data, parameter pencarian Daftar Piutang, dan pagination belum diuji.
- Arti menu/form, status, tanggal, Tagihkan Semua, Add to Table, tabel detail, Total, serta hubungan ke piutang/penerimaan belum diverifikasi.
- Akun kas/bank, attachment, pajak, approval, posting, reversal, audit trail, deposit, overpayment, jurnal, dan Accurate masih memerlukan keputusan OLR.
Referensi
14 - All Receivables · 16 - Receivable Confirm · 10 - Deposit Customer · 24 - Cash Bank Transactions · 27 - Journals · 32 - Batas Sistem dan Rekonsiliasi SOLOG Accurate