Bill (Penagihan)

1. Overview

Bill adalah dokumen tagihan supplier yang dicatat toko berdasarkan barang yang sudah diterima melalui Goods Receipt (GR). Satu Bill berlaku untuk satu supplier dan bisa menggabungkan beberapa GR, baik yang berasal dari Purchase Order (PO) maupun yang dibuat tanpa PO. Baris Bill dibentuk otomatis dari baris GR dengan qty sama dengan qty diterima; staf hanya menyesuaikan harga, diskon, dan pajak per baris, serta diskon dan pajak general untuk seluruh tagihan. Bill ditetapkan penanggung jawabnya (PIC); hanya PIC yang bisa mengajukan Bill. Setelah diajukan, pembayaran ke supplier dicatat di Bill, sekaligus atau bertahap, sampai lunas.

Hasil yang diharapkan: owner tahu berapa utang ke setiap supplier, kapan jatuh temponya, dan berapa yang sudah maupun belum dibayar, sementara toko hanya membayar barang yang benar-benar diterima.

2. Problem

Tagihan supplier di retail kecil dan menengah biasanya dibayar berdasarkan nota supplier tanpa dicocokkan dengan barang yang diterima. Akibatnya:

• Toko ikut membayar barang yang kurang kirim atau ditolak saat penerimaan.
• Harga di nota yang berbeda dari harga yang disepakati di PO tidak terdeteksi.
• Total utang ke supplier dan jatuh temponya tidak terpantau, sehingga pembayaran terlambat atau justru dibayar dua kali.
• Pembayaran bertahap tidak tercatat rapi, sehingga sisa tagihan harus dihitung ulang secara manual.

3. Goals & Non-goals

Goals

• Tagihan hanya untuk barang yang diterima. Indikator: setiap baris Bill berasal dari baris GR, dengan qty sama dengan qty diterima dan tidak bisa diubah.
• Tagihan cepat dibuat. Indikator: harga, diskon, dan pajak baris terisi otomatis dari PO jika GR berasal dari PO.
• Satu tagihan bisa mencakup beberapa pengiriman. Indikator: satu Bill bisa merujuk beberapa GR dari supplier yang sama.
• Sisa utang selalu terpantau. Indikator: total tagihan, total sudah dibayar, dan total belum dibayar tampil di daftar dan detail, dan status berubah otomatis mengikuti pembayaran.

Non-goals

• Pembatalan atau revisi Bill setelah Diajukan (belum ada alur batal; lihat EC-13)
• Cetak / unduh PDF Bill
• Menambah baris di luar GR, menghapus baris, atau mengubah qty
• Pembayaran di muka (down payment) sebelum Bill dibuat
• Nota debit / kredit dan retur ke supplier
• Multi-currency
• Jurnal akuntansi otomatis ke modul Finance

4. User Scenarios

5. User Flow

Penjelasan tiap langkah pada diagram:

1. Isi wizard — Dari daftar Bill, staf klik Tambah Baru. Wizard terdiri dari 3 langkah:
   • Umum:
     • Toko terisi otomatis dari toko aktif (read-only).
     • Staf memilih satu atau lebih Pesanan Pembelian (PO toko aktif berstatus Diajukan, Diterima Sebagian, atau Diterima), dan/atau opsi Tanpa Pesanan Pembelian. Pilihan ini hanya menyaring GR yang bisa dipilih.
     • Setelah itu staf memilih satu atau lebih Penerimaan Barang: GR toko aktif berstatus Diajukan yang merujuk PO terpilih, ditambah GR tanpa PO jika opsi Tanpa Pesanan Pembelian dipilih.
     • Supplier terisi otomatis dan terkunci dari PO pertama yang dipilih (atau dari GR pertama jika tidak ada PO). PO dan GR milik supplier lain tetap tampil tetapi tidak bisa dipilih.
     • Alamat penagihan diambil dari alamat supplier, dengan default alamat penagihan default supplier atau alamat pertamanya.
     • Tanggal penagihan default hari ini. Staf memilih tipe pembayaran, lalu tanggal jatuh tempo dihitung otomatis (BR-13); pada tipe Custom, tanggal jatuh tempo diisi manual.
     • Penanggung jawab default pengguna yang sedang login. Staf juga bisa melampirkan bukti penagihan (mis. foto nota supplier) dan mengisi catatan.
   • Produk: baris dibentuk otomatis 1:1 dari semua baris GR yang dipilih, dan dibentuk ulang setiap kali pilihan GR berubah. Setiap baris menampilkan nomor GR, produk, qty (sama dengan qty diterima, read-only), dan UoM. Jika baris GR tertaut ke baris PO, harga, diskon, dan pajak terisi dari baris PO. Staf mengubah harga, diskon, dan pajak per baris lewat dialog Ubah Produk, serta diskon dan pajak untuk seluruh tagihan lewat Atur Diskon/Pajak General. Kartu perhitungan menampilkan total harga kotor, diskon item, diskon general, total harga bersih, pajak item, pajak general, dan grand total.
   • Tinjauan: ringkasan seluruh isian sebelum disimpan.
2. Data valid? — Validasi per langkah saat klik Selanjutnya, dan validasi BE saat Simpan. Error BE ditampilkan di langkah Tinjauan dan pada field terkait.
3. Draf — Bill tersimpan dengan status Draf, dan staf diarahkan ke daftar Bill. GR yang dirujuk berstatus Selesai sehingga tidak bisa dipilih lagi untuk Bill lain. Draf bisa diubah (informasi umum, harga/diskon/pajak baris, serta diskon/pajak general), ditetapkan PIC-nya, atau dihapus.
4. Diajukan — PIC klik Ajukan Penagihan dan mengonfirmasi. Isi Bill tidak dapat diubah lagi; tercatat siapa dan kapan mengajukan. Tab Pembayaran kini aktif.
5. Catat pembayaran — Di tab Pembayaran, pengguna klik Tambah Pembayaran dan mengisi metode pembayaran, tanggal & waktu pembayaran (default saat ini), jumlah, penanggung jawab pembayaran (default pengguna yang login), bukti pembayaran, dan catatan. Ringkasan di atas daftar menampilkan total tagihan, total sudah dibayar, dan total belum dibayar.
6. Sisa tagihan = 0? — Setelah pembayaran disimpan atau dihapus, BE menghitung ulang total sudah dibayar dan sisa tagihan.
7. Dibayar Sebagian — Masih ada sisa tagihan; pembayaran berikutnya kembali ke langkah 5.
8. Lunas — Sisa tagihan nol. Pembayaran tidak bisa ditambah atau dihapus lagi.

Alternative paths

Jalur alternatif adalah kejadian di luar alur normal di atas, misalnya pengguna berubah pikiran, nota supplier berbeda dari pesanan, atau salah catat pembayaran. Setiap jalur ini harus punya perilaku yang jelas agar FE dan BE tidak menebak:

• Perubahan setelah Diajukan — tidak bisa, dan belum ada alur batal (lihat EC-13).
• Bill belum punya PIC — tombol Ajukan nonaktif untuk semua pengguna. Tetapkan PIC dulu lewat Edit Draf atau aksi tetapkan PIC di daftar.
• Pengguna bukan PIC — tombol Ajukan tampil tetapi nonaktif.
• GR dari supplier berbeda — tidak bisa digabung dalam satu Bill; buat Bill terpisah per supplier.
• Harga di nota berbeda dari PO — ubah harga baris selama Bill masih Draf.
• Salah catat pembayaran — hapus pembayaran tersebut selama Bill belum Lunas, lalu catat ulang.
• Bill Draf tidak jadi dipakai — hapus (satuan atau massal).
• Toko tidak aktif — Bill hanya bisa dilihat; semua aksi ubah dan pembayaran disembunyikan.

6. User Stories

Prioritas: P0 wajib untuk rilis, P1 penting, P2 kalau sempat.

US-01 — Membuat Bill dari GR (P0)

Sebagai staf finance, saya ingin membuat tagihan dari satu atau beberapa GR, agar tagihan supplier sesuai dengan barang yang diterima.

US-02 — Menyesuaikan harga, diskon, dan pajak (P0)

Sebagai staf finance, saya ingin menyesuaikan harga, diskon, dan pajak sesuai nota supplier, agar total tagihan sama dengan yang harus dibayar.

US-03 — Mengubah Bill Draf (P0)

Sebagai staf finance, saya ingin mengubah Bill yang masih Draf, agar kesalahan bisa diperbaiki sebelum diajukan.

US-04 — Menetapkan penanggung jawab (P0)

Sebagai kepala toko, saya ingin menetapkan PIC pada Bill, agar jelas siapa yang berwenang mengajukan tagihan.

US-05 — Mengajukan Bill (P0)

Sebagai PIC, saya ingin mengajukan Bill, agar tagihan berlaku dan pembayaran bisa dicatat.

US-06 — Mencatat pembayaran (P0)

Sebagai owner, saya ingin mencatat pembayaran ke supplier, sekaligus atau bertahap, agar sisa utang selalu diketahui.

US-07 — Menghapus pembayaran (P0)

Sebagai owner, saya ingin menghapus pembayaran yang salah catat, agar sisa tagihan kembali benar.

US-08 — Daftar dan pencarian Bill (P0)

Sebagai owner, saya ingin melihat dan menyaring Bill, agar cepat menemukan tagihan yang belum lunas.

US-09 — Menghapus Bill Draf (P0)

Sebagai staf finance, saya ingin menghapus Draf yang tidak jadi dipakai, agar daftar tetap bersih.

US-10 — Riwayat aktivitas (P1)

Sebagai owner, saya ingin melihat log aktivitas Bill, agar tahu siapa mengubah apa dan kapan.

7. Document Structure

Header

Lines

Payments

Totals: Total Harga Kotor · Total Diskon Item · Total Diskon General · Total Harga Bersih · Total Pajak Item · Total Pajak General · Grand Total, plus Total Sudah Dibayar dan Total Belum Dibayar. API mengembalikan tax_total sebagai gabungan pajak item dan pajak general, sehingga pajak general = tax_total − tax_item. Jejak yang disimpan: dibuat / diajukan oleh siapa dan kapan.

8. Status Lifecycle

9. Permissions & Actions

Permissions

Akses berbasis permission (bukan role tetap). Semua aksi ubah juga mensyaratkan toko aktif; pada toko tidak aktif, Bill hanya bisa dilihat.

Belum ada permission khusus untuk pembayaran; pembayaran memakai permission update. FE menyembunyikan aksi yang tidak diizinkan dan menonaktifkan aksi jika pengguna bukan PIC; BE tetap menolaknya. Keduanya harus konsisten.

Actions by status (✓ tersedia)

10. Business Rules

Aturan bisnis adalah ketentuan yang berlaku di semua layar dan semua aksi pada Bill, siapa pun yang melakukannya. FE memakainya sebagai validasi di form, BE memakainya sebagai sumber kebenaran; jika keduanya berbeda, perilaku BE yang dianggap benar dan FE menyesuaikan.

• BR-01 Bill milik satu toko dan dibuat pada toko aktif pengguna. Aksi ubah hanya bisa dilakukan saat toko aktif.
• BR-02 Ajukan hanya boleh dilakukan oleh karyawan yang ditetapkan sebagai PIC Bill tersebut, dan memiliki permission submit. Pembuat Bill saja tidak cukup.
• BR-03 Hanya Bill Draf yang bisa diubah, ditetapkan PIC-nya, dan dihapus. Setelah Diajukan, isi Bill terkunci; yang masih bisa dilakukan hanya menambah dan menghapus pembayaran.
• BR-04 Satu Bill hanya untuk satu supplier. Semua GR yang dipilih harus berasal dari supplier yang sama, dan supplier tidak bisa diubah setelah Bill dibuat.
• BR-05 Hanya GR toko aktif berstatus Diajukan yang bisa dipilih. Satu GR hanya bisa dirujuk oleh satu Bill; saat Bill dibuat, GR yang dirujuk berstatus Selesai.
• BR-06 Pilihan Pesanan Pembelian hanya menyaring GR: PO toko aktif berstatus Diajukan, Diterima Sebagian, atau Diterima, ditambah opsi Tanpa Pesanan Pembelian untuk GR yang tidak merujuk PO. Keduanya bisa dikombinasikan dalam satu Bill. Daftar PO pada Bill diturunkan dari GR yang dirujuk.
• BR-07 Baris Bill dibentuk 1:1 dari baris GR yang dipilih. Qty sama dengan qty diterima dan tidak bisa diubah; baris tidak bisa ditambah atau dihapus secara manual.
• BR-08 Harga, diskon, dan pajak baris default diambil dari baris PO jika baris GR tertaut ke PO. Harga baris minimal 1.
• BR-09 Perhitungan baris: bruto = qty × harga; semua diskon persen diterapkan berurutan terhadap sisa nilai, lalu semua diskon nominal dikurangkan; pajak dihitung dari nilai setelah diskon (persen) atau berupa nominal tetap; total baris = neto + pajak.
• BR-10 Perhitungan Bill: diskon general diterapkan dengan cara yang sama (persen berurutan, lalu nominal) terhadap jumlah neto semua baris. Pajak general dihitung dari neto setelah diskon general (persen) atau berupa nominal tetap. Grand total = neto setelah diskon general + total pajak baris + pajak general.
• BR-11 Diskon bernilai 0 tidak disimpan.
• BR-12 Alamat penagihan adalah alamat milik supplier, bukan alamat toko. BE menolak alamat yang bukan milik supplier.
• BR-13 Tanggal jatuh tempo dihitung dari tanggal penagihan: CBD/COD = tanggal penagihan; EOM = akhir bulan tanggal penagihan; Net N = tanggal penagihan + N hari; Custom = diisi manual (wajib). Tanggal jatuh tempo hanya dikirim FE untuk tipe Custom; tipe lainnya dihitung BE.
• BR-14 Pembayaran hanya bisa dicatat pada Bill berstatus Diajukan atau Dibayar Sebagian. Metode, tanggal & waktu, jumlah (minimal 1), dan minimal satu penanggung jawab wajib diisi.
• BR-15 Status Dibayar Sebagian dan Lunas ditetapkan otomatis oleh BE: total sudah dibayar lebih dari 0 dan masih ada sisa menjadi Dibayar Sebagian; sisa tagihan 0 menjadi Lunas. Status ini tidak bisa diubah manual.
• BR-16 Bill Lunas terkunci; pembayaran tidak bisa ditambah atau dihapus.
• BR-17 Semua perubahan dan transisi status dicatat di log aktivitas: aksi, pengguna, dan waktu.

11. Edge Cases

Edge case adalah kondisi yang jarang terjadi tetapi pasti muncul di operasional nyata, biasanya karena data berubah setelah Bill dibuat atau karena dua hal terjadi bersamaan. Perilaku yang diharapkan ditetapkan di sini agar tidak diputuskan sendiri-sendiri saat implementasi. Baris bertanda Perlu konfirmasi BE belum terlihat perilakunya dari FE dan perlu disepakati.

12. API Contract

Daftar endpoint per aksi. Detail request dan response ada di Postman (lihat metadata API).

Lookup yang dipakai form Bill

Filter GR pada lookup dikirim sekaligus dalam satu request: status = submitted, ditambah purchase_order_id[] untuk PO yang dipilih dan/atau with_purchase_order = false jika opsi Tanpa Pesanan Pembelian dipilih. Kedua filter terakhir digabung dengan OR.

13. Dependencies

PRD terkait

• Goods Receipt — sumber baris Bill; GR berstatus Selesai saat dirujuk (BR-05).
• Purchase Order — penyaring GR, serta sumber default harga, diskon, dan pajak baris (BR-06, BR-08).

Master data

• Toko — toko aktif, status aktif, dan karyawan (PIC).
• Supplier — supplier yang dikunci dari PO/GR, beserta alamatnya (alamat penagihan).
• Produk & Inventaris Produk — produk dan kemasan yang dibawa dari baris GR.

Efek ke modul lain

• Goods Receipt — GR yang dirujuk menjadi Selesai dan tidak bisa dipilih untuk Bill lain (BR-05).
• Bill tidak mengubah stok; stok sudah bertambah saat GR diajukan.
• Finance — total sudah dibayar dan sisa tagihan menjadi dasar pemantauan utang ke supplier.
• Setiap perubahan tercatat di log aktivitas (BR-17).