Perbedaan PR dan PO terletak pada tujuan serta pihak yang dituju. Purchase requisition atau PR menyampaikan kebutuhan pembelian di dalam perusahaan. Purchase order atau PO menyatakan pesanan kepada pemasok berdasarkan kebutuhan dan ketentuan yang telah disetujui. PR yang lolos persetujuan belum membuktikan bahwa PO sudah diterbitkan atau dikirim.
Bagi pemohon unit, purchasing, dan pengelola ERP, pembedaan ini menentukan siapa harus bertindak berikutnya. Jika kedua dokumen diperlakukan sama, perusahaan dapat memesan dua kali, kehilangan sisa permintaan, atau membayar barang yang acuan pesanannya belum jelas.
PR Menjelaskan Kebutuhan, PO Menetapkan Pesanan
PR membantu perusahaan memeriksa alasan pembelian, spesifikasi, jumlah, satuan, lokasi, tanggal kebutuhan, dan pemilik anggaran. SAP mendefinisikan purchase requisition sebagai permintaan kepada fungsi purchasing untuk menyediakan material atau jasa dalam jumlah dan waktu tertentu. Permintaan tersebut dapat memerlukan klarifikasi sebelum layak diteruskan.
PO memuat acuan pemesanan kepada pemasok: item atau jasa, kuantitas, harga dan mata uang, jadwal, tujuan pengiriman, serta ketentuan yang disepakati. SAP Learning menjelaskan bahwa PR yang disetujui dapat menghasilkan satu atau lebih PO. Hubungan ini berguna sebagai konsep, tetapi konfigurasi dan alur persetujuan sistem perusahaan dapat berbeda.
- Arah komunikasi: PR terutama internal; PO ditujukan kepada pemasok yang dipilih.
- Pertanyaan utama: PR menjawab apa yang dibutuhkan dan mengapa; PO menjawab apa yang dipesan kepada siapa serta dengan ketentuan apa.
- Persetujuan: persetujuan kebutuhan dan persetujuan komitmen pembelian dapat berada pada jalur berbeda.
- Bukti lanjutan: PR ditelusuri ke pesanan; PO ditelusuri ke penerimaan, perubahan, dan tagihan.
Jangan menjadikan perbandingan ini sebagai kesimpulan hukum universal tentang daya ikat sebuah dokumen. Ketentuan komersial dan kontrak perlu ditinjau pemilik kewenangan sesuai praktik perusahaan.
Contoh PR Yang Dapat Diproses Purchasing
Berikut contoh ilustratif: maintenance memerlukan 100 seal untuk pekerjaan terjadwal. PR mencatat kode item jika tersedia, material atau spesifikasi yang disahkan, jumlah 100 buah, mesin tujuan, lokasi penerimaan, tanggal kebutuhan, serta pusat biaya. Jika alternatif material dilarang, tulis batas tersebut secara eksplisit.
Keterangan “seal seperti biasa, segera” memindahkan pekerjaan penafsiran ke purchasing. Lampiran foto dapat membantu identifikasi, tetapi tidak otomatis menggantikan ukuran, spesifikasi, dan persetujuan teknis. Pemohon atau engineering tetap bertanggung jawab atas kebutuhan yang diajukan.
Untuk jasa, gunakan uraian hasil pekerjaan, periode, lokasi, dan kriteria penerimaan. Satuan “satu paket” masih terlalu lemah jika tidak ada batas pekerjaan. Purchasing membutuhkan dasar untuk membandingkan penawaran dan menyusun pesanan yang dapat diperiksa saat serah terima.
Satu PR Tidak Selalu Menjadi Satu PO
Misalkan PR 100 seal dipenuhi melalui PO A sebanyak 60 dan PO B sebanyak 40. ERP perlu menjaga alokasi kedua PO ke baris PR yang sama. Jumlah yang sudah dialokasikan adalah 100, sehingga sistem tidak boleh menampilkan seluruh permintaan sebagai kebutuhan baru ketika staf lain membuka daftar PR.
Jika PO A baru berupa draf, perusahaan perlu menentukan apakah 60 sudah dianggap dialokasikan sementara. Jika draf dibatalkan, alokasi harus dilepas tanpa menghapus histori. Aturan ini merupakan rancangan proses yang perlu disepakati, bukan kemampuan otomatis yang dapat diasumsikan dimiliki semua ERP.
Hal sebaliknya juga mungkin: kebutuhan beberapa unit digabung ke satu PO. Pertahankan referensi pemohon dan alokasi biaya per baris. Penggabungan untuk pembelian tidak boleh menghilangkan informasi siapa yang akan menerima atau menanggung biayanya.
Bedakan Status PR Dan Status PO
Status PR dapat mencakup draf, menunggu klarifikasi, diajukan, disetujui, dialokasikan sebagian, dan ditutup. Status PO perlu menjelaskan tahap pemesanan, persetujuan, pengiriman kepada pemasok, serta penyelesaian jumlah. Jangan mengandalkan satu label “selesai” untuk semua objek.
PR selesai diproses purchasing tidak sama dengan barang diterima. PO disetujui internal juga belum tentu telah diterima pemasok. Tambahkan bukti waktu dan pihak yang menjalankan langkah terkait agar unit pemohon tidak harus menebak dari warna status.
Lihat konteks keseluruhannya dalam alur procure-to-pay dari kebutuhan hingga pembayaran. Pembedaan dokumen menjadi berguna ketika pembaca dapat menelusuri pekerjaan berikutnya, bukan hanya menghafal singkatan.
Alur Persetujuan Yang Perlu Disepakati
Mulai dari kewenangan yang sudah berlaku: siapa menyetujui kebutuhan, siapa menilai spesifikasi, siapa memeriksa anggaran, dan siapa melepas PO. Nominal, kategori, unit kerja, atau risiko dapat menentukan jalur berbeda. Jangan mengisi batas otorisasi dari contoh internet tanpa keputusan manajemen.
Perubahan setelah persetujuan juga memerlukan aturan. Pergantian jumlah, item, harga, pemasok, atau lokasi dapat mengubah risiko transaksi. Sistem perlu menunjukkan perbedaan terhadap versi yang pernah disetujui dan menentukan apakah persetujuan ulang dibutuhkan.
- Pisahkan pembuat permintaan dan pemberi persetujuan sesuai kebijakan perusahaan.
- Catat alasan penolakan atau pengembalian agar pemohon bisa memperbaiki field yang tepat.
- Tentukan pengganti pejabat yang tidak tersedia tanpa membagikan akun.
- Simpan versi dokumen yang menjadi dasar keputusan dan pesanan.
Kesalahan Saat Memindahkan PR Dan PO Ke ERP
Kesalahan pertama adalah menganggap nomor dokumen cukup untuk menghubungkan transaksi. Satu PR dapat memiliki banyak item, sehingga hubungan per baris diperlukan. Kedua, satuan “box” pada PR dan “buah” pada PO memerlukan konversi yang disetujui. Ketiga, integrasi yang mengulang kiriman dapat membuat PO baru jika tidak mengenali identitas operasi yang sama.
Uji skenario staf menekan submit dua kali, PR dipenuhi sebagian, PO dibatalkan, dan spesifikasi berubah setelah penawaran. Periksa apakah jumlah terbuka, histori, serta akses antarunit tetap benar. Lulus membuat dokumen pada kondisi normal belum cukup untuk menyatakan proses siap dipakai.
Pertanyaan Yang Sering Muncul
Apakah PR Harus Memiliki Harga Final?
Tidak selalu. PR dapat membawa perkiraan atau batas anggaran sesuai SOP. Bedakan estimasi tersebut dari harga yang akhirnya disetujui dalam pesanan agar angka sementara tidak menjadi komitmen tanpa pemeriksaan.
Apakah PO Boleh Dibuat Tanpa PR?
Bergantung pada kebijakan dan jenis transaksi. Bila jalur tanpa PR diizinkan, simpan alasan, bukti kebutuhan, dan persetujuannya. Jangan menyembunyikan pengecualian sebagai PR fiktif hanya untuk melewati validasi sistem.
Sesudah PO dan penerimaan tersedia, pelajari cara mencocokkan PO, penerimaan, dan invoice. Hubungan dokumen yang jelas membantu AP membedakan pesanan terbuka dari jumlah yang sudah memiliki dasar tagihan.
Petakan Dokumen Sebelum Menambah Formulir
Siapkan contoh PR, PO, revisi, serta transaksi parsial dari kategori yang boleh ditinjau. Tinjau kebutuhan ERP perusahaan, kemudian diskusikan alur PR dan PO bersama Layana.ID untuk menetapkan hubungan dokumen, status, dan pengujian penerimaannya.
Referensi: SAP Help — Purchase Requisition; SAP Learning — Define The Purchase Order Lifecycle. Contoh seal dan rekomendasi kontrol merupakan analisis editorial, bukan kasus pelanggan. Gambar utama merupakan ilustrasi AI.