Purchase Order (Pesanan Pembelian)

1. Overview

Purchase Order (PO) adalah dokumen pemesanan barang dari sebuah toko ke supplier, dan menjadi acuan untuk Penerimaan Barang (Goods Receipt) serta Penagihan (Bill). Staf membuat PO berisi supplier, kontak supplier, alamat pengiriman toko, termin pembayaran, dan daftar produk beserta qty, harga, diskon, dan pajak. PO ditetapkan penanggung jawabnya (PIC); hanya PIC yang bisa mengajukan, membatalkan, dan menutup PO. PO bisa dicetak sebagai PDF kapan saja.

Hasil yang diharapkan: setiap toko tahu apa yang sedang dipesan dan belum datang, siapa yang bertanggung jawab atas pesanan itu, dan barang yang datang bisa dicocokkan dengan pesanan.

2. Problem

Pembelian di retail kecil dan menengah biasanya berjalan tanpa dokumen pesanan formal. Pesanan disampaikan lewat chat atau telepon, dan pencocokan barang, harga, serta tagihan dilakukan dari ingatan atau catatan pribadi staf. Akibatnya:

• Tidak ada satu tempat untuk melihat apa yang sedang ditunggu dari supplier, per toko.
• Tidak jelas siapa yang bertanggung jawab atas sebuah pesanan.
• Saat barang datang, staf tidak tahu jumlah dan harga yang disepakati; kurang kirim atau kenaikan harga baru ketahuan saat tagihan datang.
• Owner tidak bisa memperkirakan pengeluaran dan jatuh tempo pembayaran karena komitmen pembelian tidak tercatat.

3. Goals & Non-goals

Goals

• PO cepat dibuat sehingga staf mau memakainya. Indikator: staf membuat PO lewat wizard tanpa spreadsheet terpisah.
• Setiap PO punya penanggung jawab yang jelas. Indikator: aksi Ajukan, Batalkan, dan Tutup hanya bisa dilakukan PIC.
• PO menjadi acuan penerimaan barang dan tagihan. Indikator: mayoritas Goods Receipt dan Bill merujuk ke PO.
• Status penerimaan terlihat. Indikator: status PO berubah otomatis mengikuti Goods Receipt yang diajukan.

Non-goals

• Approval bertingkat (cukup PIC yang mengajukan)
• Kirim PO ke supplier via email dari sistem (cukup cetak / unduh PDF)
• Revisi PO setelah Diajukan (batalkan dan buat baru)
• Duplikat PO
• RFQ / perbandingan penawaran supplier, blanket PO, multi-currency
• Lampiran file pada PO

4. User Scenarios

5. User Flow

Penjelasan tiap langkah pada diagram:

1. Isi wizard — Dari daftar PO, staf klik Tambah Baru. Wizard terdiri dari 3 langkah:

   • Umum: toko terisi otomatis dari toko aktif (read-only); alamat pengiriman terisi otomatis dari alamat pengiriman default toko; tanggal pesanan default hari ini; staf mengisi tanggal estimasi diterima, penanggung jawab (opsional), supplier, kontak supplier, tipe pembayaran, dan catatan. Tanggal jatuh tempo dihitung otomatis dari tipe pembayaran.
   • Produk: staf menambah baris lewat dialog: cari produk berdasarkan nama atau barcode (satu pilihan per kemasan/UoM), isi qty, harga (default harga pokok kemasan; harga beli terakhir ditampilkan sebagai acuan), diskon persen dan nominal (bisa lebih dari satu), dan pajak. Total baris dan grand total dihitung langsung.
   • Tinjauan: ringkasan seluruh isian sebelum disimpan.

   Pratinjau PDF tersedia di setiap langkah.

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 — PO tersimpan dengan status Draf, dan staf diarahkan ke daftar PO. Draf bisa diubah (header dan baris), ditetapkan PIC-nya, atau dihapus.

4. Diajukan — PIC klik Ajukan Pesanan dan mengonfirmasi. PO tidak dapat diubah lagi; tercatat siapa dan kapan mengajukan. PO kini bisa dirujuk oleh Goods Receipt dan Bill.

5. Goods Receipt — Saat barang datang, staf membuat Penerimaan Barang yang merujuk PO ini. Proses penerimaan dijelaskan di PRD Goods Receipt.

6. Semua qty diterima? — Saat GR diajukan, BE membandingkan qty diterima dengan qty pesan tiap baris.

7. Diterima Sebagian — Masih ada sisa qty; GR berikutnya kembali ke langkah 5. Sisa qty per baris terlihat di modul Item Pembelian.

8. Diterima — Semua baris terpenuhi. PO masih bisa dirujuk GR dan Bill.

9. Selesai — PIC klik Tutup Pesanan dan mengonfirmasi. PO ditandai selesai dan tidak dapat diubah lagi.

10. Dibatalkan — PIC klik Batalkan Pesanan pada PO Diajukan dan wajib mengisi alasan.

Alternative paths

Jalur alternatif adalah kejadian di luar alur normal di atas, misalnya pengguna berubah pikiran, supplier tidak memenuhi pesanan, atau data master berubah. Setiap jalur ini harus punya perilaku yang jelas agar FE dan BE tidak menebak:

• Perubahan setelah Diajukan — tidak bisa. Batalkan (selama belum ada GR) lalu buat PO baru.
• PO 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, Batalkan, dan Tutup tampil tetapi nonaktif.
• PO Draf tidak jadi dipakai — hapus (satuan atau massal). Draf tidak dibatalkan, tetapi dihapus.
• Supplier tidak memenuhi sisa pesanan — saat ini PO tetap berstatus Diterima Sebagian; belum ada aksi tutup atau batal pada status ini (lihat EC-05).
• Toko tidak aktif — PO hanya bisa dilihat dan dicetak; semua aksi ubah disembunyikan.

6. User Stories

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

US-01 — Membuat PO (P0)

Sebagai staf purchasing, saya ingin membuat PO berisi supplier, alamat pengiriman, termin, dan daftar produk, agar pesanan tercatat sebelum barang datang.

US-02 — Mengubah PO Draf (P0)

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

US-03 — Menetapkan penanggung jawab (P0)

Sebagai kepala toko, saya ingin menetapkan PIC pada PO, agar jelas siapa yang berwenang mengajukan, membatalkan, dan menutup PO.

US-04 — Mengajukan PO (P0)

Sebagai PIC, saya ingin mengajukan PO, agar PO berlaku dan isinya tidak berubah lagi.

US-05 — Membatalkan PO (P0)

Sebagai PIC, saya ingin membatalkan PO yang tidak jadi, agar tidak dianggap pesanan yang ditunggu.

US-06 — Melihat progres penerimaan (P0)

Sebagai staf purchasing, saya ingin status PO berubah mengikuti penerimaan barang, agar tahu apa yang masih ditunggu.

US-07 — Menutup PO (P0)

Sebagai PIC, saya ingin menutup PO yang sudah diterima seluruhnya, agar PO ditandai selesai.

US-08 — Daftar dan pencarian PO (P0)

Sebagai owner, saya ingin melihat dan menyaring PO, agar cepat menemukan pesanan yang belum datang.

US-09 — Menghapus PO Draf (P0)

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

US-10 — Mencetak PO (P1)

Sebagai staf purchasing, saya ingin mencetak atau mengunduh PO sebagai PDF, agar bisa dikirim ke supplier.

US-11 — Riwayat aktivitas (P1)

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

7. Document Structure

Header

Lines

Totals: Total Bruto · Total Diskon · Total Neto · Total Pajak · Grand Total (penjumlahan semua baris), plus jejak dibuat / diajukan / dibatalkan (dengan alasan) / diterima pertama / ditutup 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, PO hanya bisa dilihat dan dicetak.

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 PO, 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 PO milik satu toko dan dibuat pada toko aktif pengguna. Aksi ubah hanya bisa dilakukan saat toko aktif.
• BR-02 Ajukan, Batalkan, dan Tutup hanya boleh dilakukan oleh karyawan yang ditetapkan sebagai PIC PO tersebut, dan memiliki permission aksi terkait. Pembuat PO saja tidak cukup.
• BR-03 Hanya PO Draf yang bisa diubah, ditetapkan PIC-nya, dan dihapus. Setelah Diajukan, isi PO terkunci permanen.
• BR-04 Diskon baris dihitung bertingkat: semua diskon persen diterapkan berurutan terhadap sisa nilai, lalu semua diskon nominal dikurangkan.
• BR-05 Pajak baris dihitung dari nilai setelah diskon (persen), atau berupa nominal tetap. Total baris = neto + pajak; total PO = penjumlahan total baris.
• BR-06 Tanggal jatuh tempo: CBD/COD = tanggal estimasi diterima; EOM = akhir bulan tanggal pesanan; Net N = tanggal pesanan + N hari; Custom = diisi manual (wajib).
• BR-07 Tanggal estimasi diterima tidak boleh sebelum tanggal pesanan.
• BR-08 Qty baris minimal 0,01; harga satuan minimal 1.
• BR-09 Batalkan hanya dari status Diajukan dan wajib menyertakan alasan.
• BR-10 Status Diterima Sebagian dan Diterima ditetapkan otomatis oleh BE berdasarkan GR yang diajukan; tidak bisa diubah manual.
• BR-11 Tutup hanya dari status Diterima.
• BR-12 Goods Receipt dan Bill hanya bisa merujuk PO berstatus Diajukan, Diterima Sebagian, atau Diterima.
• BR-13 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 PO dibuat atau karena dua hal terjadi bersamaan. Perilaku yang diharapkan ditetapkan di sini agar tidak diputuskan sendiri-sendiri saat implementasi.

12. API Contract

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

Lookup yang dipakai form PO

13. Dependencies

PRD terkait

• Goods Receipt — penerimaan barang dari PO, yang mengubah status PO (BR-10) dan toleransi over-receive (EC-06).
• Bill — tagihan yang merujuk PO dan GR (BR-12).
• Item Pembelian (Purchase Order Lines) — tampilan qty dipesan, diterima, dan sisa per baris PO (AC-06.3).

Master data

• Toko — toko aktif, status aktif, alamat pengiriman, dan karyawan (PIC).
• Supplier — data supplier dan kontaknya.
• Produk & Inventaris Produk — kemasan/UoM, barcode, harga pokok, dan harga beli terakhir per toko.

Efek ke modul lain

• PO tidak mengubah stok; stok bertambah saat GR diajukan.
• PO yang Diajukan, Diterima Sebagian, atau Diterima muncul sebagai pilihan di form Goods Receipt dan Bill.
• Setiap perubahan tercatat di log aktivitas (BR-13).