Minggu 7 · Pertemuan Teori

06

Purchase
Management

Mengelola Pengadaan dari Permintaan hingga Pembayaran

Sistem Informasi Enterprise — ERP Odoo 19.0
dengan Real UMKM Partner Program

Agenda 120 Menit

#TopikWaktu
1Pre-Test & Diskusi Awal10 min
2Fondasi: LO & Peta Konsep P2P10 min
36.1 — Procure-to-Pay Process Overview15 min
46.2 — Request for Quotation (RFQ)15 min
56.3 — Purchase Order Management15 min
66.4 — Vendor Management10 min
76.5 — Purchase Approval Workflow10 min
86.6 — Purchase Reporting & Analytics10 min
9Studi Kasus BBS + Rangkuman + Preview Lab15 min

🧪 Tebak Sebelum Belajar

Jawab berdasarkan pemahaman saat ini — tanpa mencari referensi. Setelah selesai bab ini, kita akan kembali membandingkan.

Aturan: Diskusikan dengan teman sebangku selama 1 menit per pertanyaan. Tidak ada jawaban yang salah — ini tentang mengaktifkan prior knowledge.

Pre-Test 1–3

Q1: Apa perbedaan antara Request for Quotation (RFQ) dan Purchase Order (PO)?

Q2: Apa itu three-way matching dan dokumen apa saja yang dicocokkan? Mengapa ini penting untuk mencegah kesalahan pembayaran?

Q3: Mengapa UMKM perlu approval workflow untuk pembelian? Kapan tidak perlu?

💬 Diskusikan 1 menit per pertanyaan — catat jawaban Anda

Pre-Test 4–5

Q4: Apa yang terjadi di Odoo jika barang yang diterima hanya setengah dari yang dipesan? Bagaimana sistem mengelola sisa pesanan?

Q5: Apa perbedaan antara Blanket Order dan Purchase Order biasa? Kapan sebaiknya UMKM menggunakan Blanket Order?

💬 Diskusikan 1 menit per pertanyaan — simpan catatan Anda untuk dibandingkan nanti

Tujuan Pembelajaran 1–3

🧠 LO 6.1 — Procure-to-Pay: Menjelaskan dan melacak alur lengkap P2P (RFQ → PO → Receipt → Vendor Bill → Payment) dalam konteks bisnis UMKM

🔧 LO 6.2 — RFQ & PO: Membuat RFQ, membandingkan vendor, dan mengkonfirmasi Purchase Order dengan data yang akurat

🔍 LO 6.3 — Vendor Management: Mengelola vendor pricelists, purchase agreements (blanket orders), dan evaluasi kinerja vendor

Tujuan Pembelajaran 4–6

🔧 LO 6.4 — Three-Way Matching: Memverifikasi konsistensi PO vs Receipt vs Vendor Bill dan menjelaskan implikasi ketidaksesuaian bagi pengendalian internal

💡 LO 6.5 — Approval Workflow: Merancang dan mengkonfigurasi purchase approval workflow berdasarkan struktur organisasi dan kebijakan UMKM

🔍 LO 6.6 — Reporting & Reorder: Menganalisis data pembelian menggunakan purchase reports dan mengkonfigurasi reorder rules untuk pengadaan otomatis

Peta Konsep Procure-to-Pay

Kebutuhan Barang → RFQ (Draft) → RFQ Sent → Purchase Order
Receipt (Inventory) → Vendor Bill (Accounting) → Payment
🛒 Purchase
RFQ, PO, Approval
📦 Inventory
Receipt, Stock Update
💰 Accounting
Vendor Bill, Payment
Trigger: Manual (staf buat RFQ) atau Otomatis (Reorder Rule → RFQ Draft)

Koneksi Antar Bab

Bab 4
Master Data
Vendor & Produk
→
Bab 5
Sales
(Kas Masuk 💰)
→
BAB 6
Purchase
(Kas Keluar 💸)
→
Bab 7
Inventory
& Warehouse

🔗 Dua Sisi Mata Uang: Bab 5 (Sales) mengelola arus kas masuk, Bab 6 (Purchase) mengelola arus kas keluar. Keduanya bermuara di modul Accounting (Bab 8) — Customer Invoice & Vendor Bill bertemu di jurnal yang sama.

6.1
Seksi 6.1

Procure-to-Pay
Process Overview

Siklus Pengadaan: Dari Kebutuhan Barang hingga Pembayaran Lunas

8 Tahap P2P di Odoo

#TahapDokumen / StatusModul
1Identifikasi kebutuhanReorder Rule / ManualPurchase
2Permintaan harga ke vendorRFQ (Sent)Purchase
3Vendor konfirmasi hargaPurchase OrderPurchase
4Barang dikirim vendorReceipt (Waiting)Inventory
5Barang diterima & dicekReceipt (Done)Inventory
6Vendor kirim tagihanVendor Bill (Draft)Accounting
7Verifikasi & postingVendor Bill (Posted)Accounting
8Pembayaran ke vendorPayment (Paid)Accounting

📝 P2P bukan tugas 1 orang — melibatkan: Operasional (identifikasi + terima barang), Manajemen (approve PO), dan Keuangan (verifikasi bill + bayar).

O2C vs P2P + Three-Way Matching

Perbandingan Cermin

AspekO2C (Bab 5)P2P (Bab 6)
ArahKeluar (jual)Masuk (beli)
Dokumen awalQuotation / SORFQ / PO
PergerakanDelivery OrderReceipt
KeuanganCustomer InvoiceVendor Bill
Dampak kasKas masuk (+)Kas keluar (−)

Three-Way Matching

3 dokumen dicocokkan:

① PO (apa & harga yang disepakati)

② Receipt (apa yang diterima)

③ Vendor Bill (apa yang ditagih)

⚠️ Selisih → Odoo auto-flag → Jangan bayar sebelum klarifikasi!

Mini Quiz — Seksi 6.1

Skenario: Staf keuangan UMKM menerima invoice Rp 4.250.000 dari vendor kain. Dokumen yang ada:

  • PO: 300m × Rp 13.800/m = Rp 4.140.000
  • Receipt: 300m (kuantitas sesuai) ✅
  • Vendor Bill: 300m × Rp 14.167/m = Rp 4.250.000

Pertanyaan: Apakah Odoo akan menampilkan peringatan? Apa yang harus dilakukan staf keuangan?

💬 Diskusikan 1 menit — jawaban di slide berikutnya

Jawaban — Quiz 6.1

Ya — Odoo menampilkan peringatan karena harga di Bill (Rp 14.167/m) ≠ harga di PO (Rp 13.800/m). Selisih: Rp 110.000.

Langkah yang benar:

  • Jangan bayar dulu — hubungi vendor untuk klarifikasi selisih
  • PO yang dikonfirmasi = harga kontraktual yang mengikat
  • Minta vendor kirim Credit Note sebesar Rp 110.000 atau terbitkan ulang invoice
💡 Banyak UMKM tetap membayar karena "tidak enak" — padahal meminta koreksi atas selisih harga adalah hal yang wajar dan profesional.
6.2
Seksi 6.2

Request for
Quotation (RFQ)

Memulai Proses Pengadaan dengan Tepat

RFQ Manual & Status Flow

Draft → RFQ Sent → Purchase Order → Done

Field Kunci RFQ

FieldKeterangan
VendorAuto-fill payment terms & lead time
Order DeadlineBatas konfirmasi harga dari vendor
Receipt DateEstimasi barang tiba (dari lead time)
Order LinesProduk, qty, harga, pajak

Navigasi

Purchase → Orders → Purchase Orders → New

Kirim ke vendor → Send by Email → PDF auto-generate → status "RFQ Sent"

⚠️ Kosongkan harga jika ingin vendor yang menentukan — harga terisi bisa diartikan sebagai persetujuan.

Reorder Rules & Multi-Vendor RFQ

🔄 RFQ Otomatis (Reorder Rules)

Stok < minimum → Odoo scheduler → RFQ Draft otomatis dari preferred vendor

RFQ tetap Draft → review manusia tetap perlu sebelum confirm menjadi PO

Contoh BBS: Kain Mori min 150m, max 500m → RFQ 350m auto-generate

📊 Multi-Vendor RFQ

Kirim RFQ produk yang sama ke 2–3 vendor → bandingkan harga → pilih vendor terbaik → cancel sisanya

💡 Rekomendasikan UMKM: bandingkan ≥ 2 vendor untuk pembelian > Rp 5 juta

💡 Tip: Lead time vendor harus akurat — lead time yang terlalu optimis membuat jadwal tidak realistis. Review setiap kuartal berdasarkan data Receipt historis.

Mini Quiz — Seksi 6.2

Pasangkan pernyataan dengan status yang tepat:

A. Belum bersifat mengikat — vendor bisa menolak
B. Komitmen hukum — harga & qty terkunci
C. Baru dibuat, belum dikirim ke vendor
D. Semua Receipt & Bill sudah selesai

Pilihan: RFQ · RFQ Sent · Purchase Order · Done

💬 Pasangkan dalam 1 menit — jawaban di slide berikutnya

Jawaban — Quiz 6.2

PernyataanStatus
A. Belum mengikat — vendor bisa menolakRFQ / RFQ Sent
B. Komitmen hukum — harga & qty terkunciPurchase Order
C. Baru dibuat, belum dikirim ke vendorRFQ (Draft)
D. Semua Receipt & Bill sudah selesaiDone

⚠️ Implikasi kritis: Transisi dari RFQ ke PO terjadi saat tombol Confirm Order diklik — dari titik itu, membatalkan bisa dikenai biaya atau merusak relasi vendor. Konfirmasi harga tertulis sebelum menekan Confirm!

6.3
Seksi 6.3

Purchase Order
Management

Dari Konfirmasi hingga Penerimaan Barang

Konfirmasi PO & Validasi Receipt

Saat PO dikonfirmasi, 4 aksi otomatis:

① Nomor PO permanen (P00001, …)  ② Receipt terbuat di Inventory  ③ Forecasted stock terupdate  ④ Notifikasi vendor

Kolom Order Lines PO

KolomKeterangan
Ordered QtyKuantitas yang dipesan
Received QtyKuantitas yang sudah diterima
Billed QtyKuantitas yang sudah ditagihkan

Proses Validasi Receipt

  1. Buka Receipt dari PO (tombol "Receipt")
  2. Isi kolom Done = qty aktual diterima
  3. Verifikasi: pelanggan, produk, kuantitas
  4. Klik Validate → stok otomatis bertambah

⚠️ Warning: Input kuantitas yang BENAR-BENAR diterima — bukan yang "harusnya datang". Stok yang di-inflate sulit dikoreksi (perlu Return Transfer).

Partial Delivery & Backorder

PO: 400m
→
Receipt 1:
250m ✅
→
Backorder:
150m ⏳
→
Receipt 2:
150m ✅

"Create Backorder"

✅ Receipt baru otomatis untuk sisa qty

✅ Vendor Bill hanya untuk qty diterima

⟶ Gunakan hampir selalu!

"No Backorder"

⚠️ Sisa qty dibatalkan permanen

⚠️ Tidak ada tracking lanjutan

⟶ Hanya jika vendor tidak akan kirim sisa

💡 Tip: Lampirkan foto/scan surat jalan ke Receipt — bukti tak ternilai saat terjadi dispute kuantitas. Di BBS, kebiasaan ini menghemat 3 hari penyelesaian masalah.

Mini Quiz — Seksi 6.3

Mana Billing Policy yang tepat? Rekomendasikan Received Quantities atau Ordered Quantities:

1. Manufaktur batik — sering terima pengiriman parsial
2. Konsultan IT — beli lisensi software tahunan (tanpa barang fisik)
3. Toko retail — beli produk jadi, syarat bayar Net 30 after delivery
4. Distributor — memesan volume besar, dikirim dalam 3–4 batch

💬 Diskusikan 1 menit — jawaban di slide berikutnya

Jawaban — Quiz 6.3

#UMKMRekomendasiAlasan
1Manufaktur batikReceivedPartial delivery → tagih hanya yang sudah benar-benar diterima
2Konsultan ITOrderedTidak ada barang fisik — tagihan berdasarkan kontrak
3Toko retailReceivedBayar setelah delivery (Net 30) = selaras dengan Received
4DistributorReceivedMulti-batch → verifikasi per batch, bill per batch

📝 Aturan praktis: Ordered Quantities cocok untuk Service (jasa, langganan). Untuk semua produk fisik yang bisa partial delivery → pilih Received Quantities (lebih aman).

6.4
Seksi 6.4

Vendor
Management

Pricelist, Agreements, dan Evaluasi Kinerja

Vendor Pricelists & Blanket Orders

Vendor Pricelist (tab Purchase produk)

VendorPrice/mMin. QtyLead Time
CV Sarana BatikRp 14.50050m2 hari
UD Tekstil MakmurRp 13.800200m5 hari
Toko Kain BarokahRp 15.20010m1 hari

Odoo otomatis pilih vendor prioritas yang memenuhi min.qty

Blanket Order

Definisi: Perjanjian jangka menengah — harga terkunci, volume berkomitmen, pengambilan bertahap.

Contoh BBS: 1.200m × Rp 13.800/m, 3 bulan, CV Sarana Batik

Hemat: Rp 700/m × 1.200m = Rp 840.000

💡 Blanket Order = instrumen negosiasi — tukar komitmen volume dengan kepastian harga

Vendor Evaluation Scorecard

VendorHarga (30%)Waktu (30%)Kualitas (25%)Respons (15%)SkorKategori
CV Kimia Warna8892959692,3Preferred
Toko Barokah9585889691,2Preferred
CV Sarana Batik9095859290,9Preferred
UD Tekstil9278808083,5Under Review
Vendor X8550606566,0Exit

4 Kategori: Preferred (≥90) · Approved (75–89) · Under Review (60–74) · Exit (<60)

💡 Review kuartalan — data dari Purchase Analysis. Mengubah "gut feeling" menjadi keputusan berbasis data.

6.5
Seksi 6.5

Purchase Approval
Workflow

Kontrol Otorisasi untuk Setiap Pembelian Signifikan

Konfigurasi & Alur Approval

Konfigurasi

Purchase → Settings → Purchase Order Approval

✅ Aktifkan → set Minimum Amount

Approver = user dengan role Purchase Manager

Threshold BBS: Rp 3.000.000

Di bawah → staf langsung proses

Di atas → Hj. Fatimah harus approve

Alur Kerja

Staf buat RFQ → Confirm Order
↓ nilai > threshold?
Status: Waiting Approval 🔒
↓
✅ Approve → PO Aktif
❌ Refuse → Draft

⚠️ Threshold terlalu rendah → approval fatigue (approver setujui tanpa review). Terlalu tinggi → tidak ada kontrol bermakna. Gunakan persentil 60–70 distribusi PO historis.

Mini Quiz — Seksi 6.5

Benar atau Salah?

1. Jika approval aktif, SEMUA PO tanpa kecuali harus disetujui
2. PO yang ditolak (Refuse) langsung dihapus dari sistem
3. Status "Waiting Approval" berarti PO sudah confirmed dan siap diproses ke Receipt
4. Approval threshold bisa dikonfigurasi di menu Settings

💬 Jawab B/S dalam 1 menit — jawaban di slide berikutnya

Jawaban — Quiz 6.5

#B/SPenjelasan
1SALAHHanya PO di atas threshold yang butuh approval
2SALAHPO kembali ke status Draft — bisa direvisi dan diajukan ulang
3SALAH"Waiting Approval" = PO belum confirmed. Tidak ada Receipt/Bill sampai approved.
4BENARSettings → Purchase → Minimum Order Amount

💡 Miskonsepsi paling umum: mahasiswa mengira "Waiting Approval" = proses sudah berjalan. Kenyataannya: PO frozen total sampai approver bertindak.

6.6
Seksi 6.6

Purchase Reporting
& Analytics

Mengubah Data Pengadaan Menjadi Wawasan Bisnis

3 Laporan Utama Purchase

📊 Purchase Dashboard

5 KPI: Total Spent, Awaiting Approval, Receipts, Bills to Review, Late Orders

Ritual pagi 5 menit/hari

📈 Purchase Analysis

Pivot / Graph / List — Group By: Vendor, Product, Month — Measures: Qty, Total, Avg Cost

Analisis multidimensi

📅 Aged Payable

5 bucket: Not Due, 0–30, 31–60, 61–90, >90 hari — per vendor

💡 Review setiap Senin 5 menit

4 Quick Analysis: ① Vendor terbesar (Graph + Group by Vendor) ② Bahan terlaris (Pivot + Avg Cost) ③ Tren 6 bulan (Line Chart + Month) ④ Gap Ordered vs Received vs Billed (Pivot + 3 measures)

Studi Kasus Batik Berkah Sentosa

🏢 Profil

UMKM manufaktur batik, Yogyakarta

12 karyawan, 400–600 lembar/bulan

Pemilik: Hj. Fatimah Rahayu

😰 Masalah Sebelum Odoo

"20 kontak WhatsApp = manajemen vendor"

Harga berubah tanpa dokumentasi

Bayar tagihan tanpa verifikasi

Stock-out 2–3×/bulan karena reaktif

"Saya bayar karena saya percaya. Tapi kepercayaan bukan pengganti dokumentasi." — Hj. Fatimah

Before vs After

Vendor Terkelola

23 kontak

Tidak terstruktur

Vendor Terkelola

8 aktif

Terdokumentasi + scorecard

Three-Way Matching

Tidak ada

Bayar tanpa verifikasi

Three-Way Matching

Auto-detect

Selisih Rp 100.000 terdeteksi

Blanket Order

Verbal

Janji WA — tidak formal

Blanket Order

Rp 840K

Hemat per siklus kontrak

Utang Dagang

~Rp 15–20 jt

Estimasi kasar

Utang Dagang

Rp 18,3 jt

Aged Payable per vendor

Pelajaran dari BBS

1. Vendor yang banyak ≠ vendor yang dikelola

23 kontak → 8 vendor aktif terdokumentasi. Lebih sedikit vendor yang dikelola baik > banyak kontak tidak terstruktur.

2. Sistem formal tidak mengurangi kepercayaan — mendefinisikannya

Blanket Order formal justru membuat vendor merasa lebih dihargai. Komitmen terdokumentasi > janji verbal.

3. Three-Way Matching = investasi, bukan overhead

Rp 100.000 selisih × 20% dari 30 transaksi/bulan × 12 bulan = potensi kebocoran jutaan/tahun. Sistem bukan biaya — sistem adalah perlindungan.

Peta Integrasi Purchase Module

Bab 5
Sales
Reorder trigger
→
Bab 6
Purchase
RFQ → PO
→
Bab 7
Inventory
Receipt → Stock
Purchase
Vendor Bill
→
Bab 8
Accounting
AP + Payment
Purchase
Raw Materials
→
Bab 9
Manufacturing
BoM Integration

Rangkuman Bab 6

6.1 P2P Overview: 8 tahap, 3 modul. Three-way matching = kontrol internal kritis.

6.2 RFQ: Manual, otomatis (reorder rules), atau multi-vendor. Lead time vendor harus akurat.

6.3 PO Management: Confirm = 4 aksi otomatis. Partial delivery → Create Backorder. Jangan inflate qty Receipt.

6.4 Vendor: Pricelist di tab Purchase produk. Blanket Order = hemat 5–15%. Scorecard → keputusan berbasis data.

6.5 Approval: Threshold dari distribusi PO historis. Terlalu rendah = approval fatigue. Terlalu tinggi = tanpa kontrol.

6.6 Reporting: Dashboard harian, Purchase Analysis multidimensi, Aged Payable tiap Senin.

Di Lab Minggu Ini…

🛒

RFQ → PO

Buat RFQ manual, kirim ke vendor, konfirmasi menjadi PO

📦

Receipt & Backorder

Validasi penerimaan barang termasuk pengiriman parsial

✅

Approval Workflow

Konfigurasi approval threshold dan test alur persetujuan PO

📊

Purchase Reports

Purchase Analysis + Aged Payable untuk data hari ini

⏱ 120 menit · Tim 3–4 orang · Prasyarat: data vendor & produk dari Lab 4

Referensi

📘 van Weele, A. J. (2018). Purchasing and Supply Chain Management (7th ed.). Cengage Learning EMEA.

📘 Monczka, R. M., et al. (2015). Purchasing and Supply Chain Management (6th ed.). Cengage Learning.

📘 CIPS. (2023). Procurement Principles and Management (11th ed.). Chartered Institute of Procurement & Supply.

🌐 Odoo S.A. (2024). Purchase: Overview, RFQ, Purchase Orders, Agreements, Approval, Reporting. Odoo Documentation 19.0.

🇮🇩 Kementerian Koperasi dan UKM. (2023). Statistik UMKM Indonesia 2023.

Terima Kasih

Bab 5 mengelola kas masuk, Bab 6 mengelola kas keluar — keduanya harus seimbang agar kesehatan finansial UMKM terjaga.

Sistem Informasi Enterprise — ERP Odoo 19.0
dengan Real UMKM Partner Program