Panduan Lengkap Implementasi Procurement Workflow: PR, RFQ, PO, GRN

Manajemen pengadaan barang dan jasa merupakan tulang punggung operasional di banyak organisasi, terutama di sektor kesehatan seperti rumah sakit dan klinik. Namun, seringkali proses ini masih dijalankan secara manual, mengakibatkan inefisiensi yang signifikan. Studi menunjukkan bahwa proses pengadaan manual dapat meningkatkan biaya operasional hingga 15-20% dan memperpanjang siklus pengadaan barang rata-rata 30-40% dibandingkan sistem terotomatisasi. Bayangkan, sebuah rumah sakit dengan anggaran pengadaan tahunan Rp 50 miliar bisa kehilangan Rp 7,5 miliar hingga Rp 10 miliar hanya karena inefisiensi proses. Ini belum termasuk risiko kesalahan input, kurangnya transparansi, dan kesulitan dalam pelacakan audit. Dalam konteks yang serba cepat dan membutuhkan akurasi tinggi seperti pelayanan kesehatan, masalah ini menjadi krusial. Sistem yang terintegrasi bukan lagi kemewahan, melainkan kebutuhan mendesak untuk memastikan ketersediaan pasokan medis yang vital, mengelola inventori secara efektif, dan menjaga keberlanjutan finansial. Artikel ini akan memandu Anda, para manajer operasional dan IT, melalui langkah-langkah konkret dalam mengimplementasikan procurement workflow yang modern dan terotomatisasi, mencakup Purchase Requisition (PR), Request for Quotation (RFQ), Purchase Order (PO), hingga Goods Receipt Note (GRN). Kami akan membahas konsep dasar, detail implementasi teknis dengan contoh kode, penanganan error, serta praktik terbaik yang telah teruji.

Konsep Dasar Procurement Workflow: PR, RFQ, PO, GRN

Memahami setiap tahapan dalam procurement workflow adalah kunci untuk membangun sistem yang efektif dan efisien. Keempat tahapan ini—Purchase Requisition (PR), Request for Quotation (RFQ), Purchase Order (PO), dan Goods Receipt Note (GRN)—membentuk siklus pengadaan yang terstruktur, dari identifikasi kebutuhan hingga penerimaan barang.

Purchase Requisition (PR) adalah dokumen internal yang dibuat oleh departemen atau unit kerja untuk meminta pembelian barang atau jasa. Ini adalah langkah pertama dalam siklus pengadaan. Sebagai contoh, di sebuah Rumah Sakit “Medika Jaya”, departemen farmasi mungkin membuat PR untuk 500 strip Paracetamol 500mg dan 200 vial antibiotik Ceftriaxone 1g karena stok menipis. PR ini berisi detail item yang dibutuhkan, kuantitas, tanggal dibutuhkan, dan alasan pembelian. Tujuan utama PR adalah untuk mendapatkan persetujuan internal sebelum proses pengadaan lebih lanjut dilakukan, memastikan bahwa setiap pembelian memiliki justifikasi dan sesuai dengan anggaran yang tersedia.

Request for Quotation (RFQ) adalah dokumen yang dikirimkan kepada beberapa vendor potensial untuk meminta penawaran harga dan kondisi pengiriman untuk barang atau jasa yang dibutuhkan. Setelah PR disetujui, tim pengadaan akan mengidentifikasi vendor yang relevan. Melanjutkan contoh sebelumnya, tim pengadaan RS Medika Jaya akan mengirimkan RFQ ke 3-5 vendor farmasi terdaftar yang memiliki reputasi baik dan memenuhi standar kualitas. RFQ ini akan mencakup spesifikasi item, kuantitas, tanggal pengiriman yang diharapkan, dan syarat pembayaran. Proses RFQ ini sangat penting untuk memastikan transparansi, mendapatkan harga terbaik, dan membandingkan kualitas serta layanan dari berbagai pemasok. Penggunaan RFQ yang terstruktur dapat mengurangi biaya pengadaan rata-rata 8-12%.

Purchase Order (PO) adalah dokumen hukum yang mengikat dan dikirimkan kepada vendor yang terpilih setelah proses RFQ selesai dan penawaran terbaik telah ditentukan. PO berfungsi sebagai konfirmasi resmi atas pembelian. Misalnya, setelah mengevaluasi penawaran, RS Medika Jaya memutuskan untuk memesan Paracetamol dari PT. Pharma Sejahtera dengan harga Rp 5.000 per strip dan Ceftriaxone dari PT. Kimia Farma dengan harga Rp 25.000 per vial, sesuai dengan syarat pembayaran 30 hari net. PO akan mencantumkan nomor PO unik, detail vendor, item yang dipesan, kuantitas, harga unit, total harga, syarat pengiriman, dan tanggal pengiriman yang disepakati. PO adalah instrumen krusial untuk mencegah perselisihan di kemudian hari dan memastikan kedua belah pihak memahami kewajiban masing-masing.

Goods Receipt Note (GRN) adalah dokumen yang dibuat saat barang atau jasa yang dipesan melalui PO diterima oleh organisasi. GRN berfungsi sebagai bukti bahwa barang telah diterima sesuai dengan PO, baik dari segi kuantitas maupun kualitas. Ketika pengiriman Paracetamol dan Ceftriaxone tiba di RS Medika Jaya, staf gudang akan memeriksa setiap item, memverifikasi kuantitas terhadap PO, memeriksa kondisi fisik barang, dan mencatat tanggal penerimaan. Jika ada ketidaksesuaian, seperti kerusakan atau jumlah yang kurang, hal tersebut akan dicatat dalam GRN dan ditindaklanjuti. GRN adalah tahap penting untuk memperbarui inventori, memicu proses pembayaran ke vendor, dan memastikan akurasi data dalam sistem manajemen persediaan. Integrasi keempat tahapan ini dalam satu sistem dapat mempersingkat siklus pengadaan dari rata-rata 14 hari menjadi 5 hari, meningkatkan efisiensi operasional secara drastis.

Detail Implementasi Teknis Sistem Procurement Terotomatisasi

Membangun sistem procurement terotomatisasi yang efektif memerlukan pemilihan arsitektur dan teknologi yang tepat, serta pemahaman mendalam tentang alur data. Untuk organisasi seperti rumah sakit atau klinik yang membutuhkan skalabilitas dan integrasi dengan sistem lain (SIMRS, SIM Klinik, Akuntansi), arsitektur berbasis mikroservis seringkali lebih unggul dibandingkan monolitik, meskipun monolitik bisa menjadi pilihan awal untuk MVP. Namun, untuk sistem yang kompleks, mikroservis memungkinkan pengembangan dan pemeliharaan modul secara independen, seperti modul Procurement, Inventory, dan Finance.

Dalam konteks implementasi teknis, kita dapat menggunakan kombinasi teknologi yang telah terbukti keandalannya. Sebagai backend, Laravel 11.x dengan PHP 8.2+ adalah pilihan yang sangat baik karena framework ini menyediakan ekosistem yang kaya untuk pengembangan API RESTful yang cepat dan aman. Laravel memiliki fitur-fitur seperti ORM Eloquent, sistem validasi yang kuat, dan manajemen otentikasi/otorisasi yang mempermudah pengembangan. Untuk database, PostgreSQL 16 direkomendasikan karena keandalannya, kemampuan menangani data transaksional yang kompleks, serta dukungan untuk fitur-fitur seperti JSONB yang berguna untuk menyimpan data semi-terstruktur. Database ini juga sangat cocok untuk sistem yang membutuhkan integritas data tinggi, seperti data pengadaan dan inventori.

Di sisi frontend, Vue.js 3 atau React 18.x dapat digunakan untuk membangun antarmuka pengguna yang responsif dan interaktif. Kedua framework ini menawarkan performa tinggi dan ekosistem komponen yang luas, memungkinkan pengembangan dashboard yang intuitif untuk setiap tahapan workflow (PR, RFQ, PO, GRN). Komunikasi antara frontend dan backend akan dilakukan melalui RESTful API, memastikan fleksibilitas dan kemampuan integrasi dengan aplikasi lain di masa mendatang, termasuk aplikasi mobile atau sistem eksternal seperti BPJS atau SatuSehat jika diperlukan.

Modul utama dalam sistem ini meliputi: User Management (untuk mengatur peran dan hak akses), Master Data (daftar item, daftar vendor, unit pengukuran), Modul PR (pembuatan, persetujuan, pelacakan PR), Modul RFQ (pembuatan, pengiriman, penerimaan penawaran), Modul PO (pembuatan, persetujuan, pengiriman PO), dan Modul GRN (pencatatan penerimaan barang, pembaruan stok). Setiap modul akan memiliki API endpoint-nya sendiri. Sebagai contoh, alur data akan dimulai ketika seorang pengguna dengan peran 'Requester' membuat PR melalui antarmuka frontend, yang kemudian dikirim ke backend melalui API. Backend akan memvalidasi data dan menyimpannya ke database PostgreSQL. PR tersebut kemudian akan menunggu persetujuan dari 'Approver' (misalnya, Manajer Departemen atau Direktur Operasional). Setelah PR disetujui, tim pengadaan ('Procurement Officer') akan menggunakan sistem untuk menghasilkan RFQ, mengirimkannya kepada vendor melalui email yang terintegrasi, dan menerima penawaran langsung ke dalam sistem. Setelah penawaran dievaluasi dan PO dibuat, sistem akan mengirimkan PO kepada vendor. Terakhir, saat barang diterima, staf gudang akan mencatat GRN, yang secara otomatis akan memperbarui stok di modul Inventory. Implementasi ini harus secara ketat menerapkan Role-Based Access Control (RBAC) untuk memastikan bahwa setiap pengguna hanya dapat mengakses dan melakukan tindakan sesuai dengan peran mereka, serta mencatat setiap aktivitas dalam audit log untuk transparansi dan akuntabilitas, sesuai dengan Permenkes No. 24 Tahun 2022 tentang Rekam Medis Elektronik yang menekankan pentingnya audit trail.

Contoh Kode Implementasi API untuk Procurement Workflow

Untuk memberikan gambaran yang lebih konkret, mari kita lihat beberapa potongan kode yang relevan dalam pengembangan sistem procurement menggunakan Laravel 11.x. Fokus kita adalah pada API untuk mengelola Purchase Requisition (PR), yang merupakan fondasi dari seluruh workflow.

Pertama, kita akan membuat migrasi database untuk tabel purchase_requisitions dan purchase_requisition_items. Ini akan mendefinisikan struktur data yang akan kita gunakan.

<?php declare(strict_types=1); use Illuminate\Database\Migrations\Migration; use Illuminate\\Database\\Schema\\Blueprint; use Illuminate\\Support\\Facades\\Schema; class CreatePurchaseRequisitionsTable extends Migration { public function up(): void { Schema::create('purchase_requisitions', function (Blueprint $table) { $table->id(); $table->string('pr_number')->unique(); $table->foreignId('requested_by_user_id')->constrained('users'); $table->enum('status', ['draft', 'pending_approval', 'approved', 'rejected', 'cancelled', 'completed'])->default('draft'); $table->text('notes')->nullable(); $table->timestamps(); }); Schema::create('purchase_requisition_items', function (Blueprint $table) { $table->id(); $table->foreignId('purchase_requisition_id')->constrained('purchase_requisitions')->onDelete('cascade'); $table->foreignId('item_id')->constrained('items'); // Assuming 'items' table exists $table->decimal('quantity', 10, 2); $table->text('description')->nullable(); $table->timestamps(); }); } public function down(): void { Schema::dropIfExists('purchase_requisition_items'); Schema::dropIfExists('purchase_requisitions'); } }

Migrasi di atas menciptakan dua tabel: purchase_requisitions untuk menyimpan informasi umum PR seperti nomor PR, pemohon, status, dan catatan; serta purchase_requisition_items untuk menyimpan detail item yang diminta dalam setiap PR, termasuk kuantitas dan deskripsi. Relasi onDelete('cascade') memastikan item PR terhapus jika PR induknya dihapus. Tabel users dan items diasumsikan sudah ada.

Selanjutnya, mari kita buat Controller untuk mengelola PR. Controller ini akan menangani permintaan HTTP untuk membuat PR baru.

<?php declare(strict_types=1); namespace App\Http\Controllers\Api; use App\Http\Controllers\Controller; use App\Models\PurchaseRequisition; use App\Models\PurchaseRequisitionItem; use Illuminate\\Http\\JsonResponse; use Illuminate\\Http\\Request; use Illuminate\\Support\\Facades\\DB; use Illuminate\\Support\\Facades\\Auth; class PurchaseRequisitionController extends Controller { public function store(Request $request): JsonResponse { $request->validate([ 'items' => 'required|array|min:1', 'items.*.item_id' => 'required|exists:items,id', 'items.*.quantity' => 'required|numeric|min:0.01', 'items.*.description' => 'nullable|string|max:500', 'notes' => 'nullable|string|max:1000', ]); try { DB::beginTransaction(); $prNumber = 'PR-' . date('Ymd') . '-' . str_pad((string)(PurchaseRequisition::count() + 1), 3, '0', STR_PAD_LEFT); $purchaseRequisition = PurchaseRequisition::create([ 'pr_number' => $prNumber, 'requested_by_user_id' => Auth::id(), 'status' => 'draft', 'notes' => $request->input('notes'), ]); foreach ($request->input('items') as $itemData) { $purchaseRequisition->items()->create([ 'item_id' => $itemData['item_id'], 'quantity' => $itemData['quantity'], 'description' => $itemData['description'] ?? null, ]); } DB::commit(); return response()->json([ 'message' => 'Purchase Requisition created successfully.', 'data' => $purchaseRequisition->load('items') ], 201); } catch (\Exception $e) { DB::rollBack(); return response()->json([ 'message' => 'Failed to create Purchase Requisition.', 'error' => $e->getMessage() ], 500); } } }

Dalam metode store di PurchaseRequisitionController, kita melakukan beberapa hal penting: Pertama, validasi input menggunakan fitur validasi Laravel yang kuat untuk memastikan data yang diterima sesuai dengan harapan. Ini mencakup pemeriksaan bahwa ada setidaknya satu item, ID item valid, dan kuantitas adalah angka positif. Kedua, kita menggunakan transaksi database (DB::beginTransaction() dan DB::commit()) untuk memastikan bahwa pembuatan PR dan item-itemnya adalah operasi atomik; jika terjadi kesalahan di tengah jalan, semua perubahan akan di-rollback. Nomor PR (pr_number) dihasilkan secara sederhana berdasarkan tanggal dan jumlah PR yang ada. Status awal PR adalah 'draft'. Setelah PR dan item-itemnya berhasil disimpan, respons JSON dikirimkan kembali ke klien dengan status HTTP 201 (Created) dan data PR yang baru dibuat, termasuk item-itemnya. Jika terjadi kesalahan, transaksi di-rollback dan pesan error dikirim dengan status HTTP 500 (Internal Server Error). Ini adalah dasar yang kokoh untuk membangun API yang lebih kompleks untuk tahap RFQ, PO, dan GRN.

Contoh Payload, Error Handling, dan Respons API

Dalam pengembangan API untuk sistem procurement, memahami bagaimana data dikirim (payload) dan bagaimana sistem merespons, terutama saat terjadi kesalahan, sangatlah penting. Ini memastikan aplikasi frontend dapat berinteraksi dengan backend secara efisien dan pengguna mendapatkan umpan balik yang jelas.

Misalkan kita memiliki endpoint API untuk membuat Purchase Order (PO). Berikut adalah contoh payload JSON realistis yang akan dikirim oleh aplikasi frontend ke backend:

{