Cetak biru aplikasi permintaan pengadaan untuk persetujuan dan PO

Apa yang perlu diperbaiki oleh aplikasi permintaan pengadaan internal

Thread email dan spreadsheet gagal dengan cara yang sama dan bisa diprediksi. Permintaan terkubur. File terpecah menjadi versi "final_v7". Persetujuan terjadi di chat samping tanpa jejak. Saat seseorang bertanya, "Apakah kita boleh membeli ini?" jawaban tergantung siapa yang sedang online dan lembar mana yang mereka percaya.

Aplikasi permintaan harus membuat status jelas pada setiap saat. Anda harus bisa membuka sebuah request dan langsung melihat siapa yang mengajukannya, apa yang ingin dibeli, perkiraan biaya, dan apa langkah berikutnya. Aplikasi juga harus memiliki riwayat yang bersih: siapa yang menyetujui atau menolak, kapan mereka melakukannya, dan apa yang berubah setelahnya.

Setidaknya, setiap request harus menjawab pertanyaan-pertanyaan ini tanpa harus menggali:

• Siapa yang memegang langkah berikutnya?
• Apa yang tertunda (persetujuan, pengecekan anggaran, kutipan vendor, pembuatan PO)?
• Apa yang telah disetujui (jumlah, vendor, ruang lingkup), dan apakah itu berubah?
• Kapan dibutuhkan, dan mengapa?
• Apa jejak audit sehingga finance bisa mempercayainya?

Ruang lingkup adalah tempat banyak tim membangun fitur berlebihan. Tentukan sejak awal apakah Anda hanya menangani dari request sampai purchase order, atau juga langkah selanjutnya seperti pencocokan invoice dan penerimaan barang. Request sampai PO biasanya milestone pertama terbaik: memaksa persetujuan dan pengecekan anggaran yang rapi, namun menjaga proyek tetap terjangkau.

Jaga versi pertama tetap sederhana. Mulai dengan satu tim, satu jalur persetujuan, dan definisi "selesai" yang jelas. Contohnya, permintaan IT di bawah $1.000 mungkin hanya perlu persetujuan manajer, sementara pembelian lebih besar diarahkan ke finance.

Jika Anda ingin membangunnya cepat tanpa menulis kode, AppMaster adalah opsi praktis. Anda bisa memodelkan data request, menyiapkan langkah persetujuan, dan menghasilkan aplikasi web dan mobile siap produksi dari blueprint yang sama.

Pengguna, peran, dan aturan akses

Aplikasi permintaan pengadaan hidup atau mati oleh izin. Jika orang yang salah bisa mengubah request setelah persetujuan, atau tim tidak bisa melihat apa yang mereka butuhkan, proses menjadi lambat dan berisiko.

Mulai dengan memberi nama peran yang jelas. Jabatan berbeda-beda antar perusahaan, tetapi sebagian besar aplikasi butuh tanggung jawab stabil: requesters (membuat request dan menjawab pertanyaan), managers (mengonfirmasi kebutuhan dan waktu), procurement (memvalidasi vendor dan membuat PO), finance (mengonfirmasi anggaran dan kebijakan), dan satu atau lebih approver (otoritas tanda tangan). Beberapa alur juga menyertakan kontak vendor dengan akses terbatas untuk detail eksternal bersama.

Lalu definisikan apa yang bisa dilakukan setiap peran pada tiap tahap. Satu aturan mencegah banyak perselisihan: setelah request diserahkan, requester hanya boleh mengedit klarifikasi (catatan, lampiran, detail pengiriman). Harga, vendor, kuantitas, mata uang, dan cost center harus dianggap sebagai field kunci yang memerlukan perubahan resmi dan re-approval.

Aturan visibilitas harus sama jelasnya. Requesters harus melihat permintaan mereka sendiri dan statusnya. Managers harus melihat permintaan dari laporan langsung mereka. Procurement dan finance biasanya membutuhkan visibilitas lintas departemen. Kontak vendor tidak boleh melihat catatan internal, data anggaran, atau vendor lain.

Delegasi penting karena persetujuan tidak boleh berhenti saat seseorang tidak ada. Dukung delegasi terencana (liburan) dan backup darurat (sakit). Delegasi harus meneruskan hak persetujuan, tetapi bukan kemampuan untuk menulis ulang request.

Permintaan lintas-departemen umum (misalnya IT membeli perangkat lunak untuk Marketing). Pisahkan "tim pemohon" dari "pemilik cost center." Arahkan persetujuan ke pemilik cost center, dan tampilkan kedua pihak di record sehingga jelas siapa yang meminta dan siapa yang membayar.

Di AppMaster, Anda bisa memodelkan peran, kepemilikan record, dan tindakan berbasis tahap dalam data model dan business processes, sehingga aturan yang sama berlaku di layar web dan mobile.

Model data: entitas inti dan field

Aplikasi permintaan pengadaan yang baik dimulai dengan model data yang bersih. Jika tabel Anda jelas, persetujuan, pengecekan anggaran, dan purchase order menjadi lebih mudah untuk diautomasi dan dilaporkan.

Entitas inti yang perlu disertakan

Sebagian besar tim menangani mayoritas kasus dengan sejumlah entitas kecil:

• Requests: satu record per permintaan pengadaan (header).
• RequestItems: garis item, kuantitas, dan perkiraan harga satuan.
• Vendors: data master pemasok yang digunakan ulang di request dan PO.
• Budgets: ketersediaan anggaran menurut cost center, proyek, departemen, atau periode.
• PurchaseOrders: order formal yang dibuat dari request yang disetujui.
• Approvals: setiap langkah persetujuan, keputusan, dan komentar.

Field yang berguna nanti

Untuk Requests, sertakan field yang membantu routing dan mengurangi bolak-balik: requester, departemen, cost center, tanggal kebutuhan, justifikasi bisnis, dan lampiran (kutipan, spesifikasi, screenshot). Referensi vendor yang disukai sederhana membantu, bahkan jika pemilihan vendor diselesaikan kemudian.

Status bekerja paling baik ketika eksplisit dan didukung oleh timestamp. Simpan satu field status pada Requests (Draft, Submitted, Approved, Rejected, Ordered, Closed), dan simpan tanggal kunci seperti submitted_at, approved_at, rejected_at, ordered_at, dan closed_at. Ini membuat pelaporan (cycle time, aging, bottleneck) mudah tanpa menebak dari log.

Untuk PurchaseOrders, pisahkan header PO (nomor, vendor, ship-to, bill-to, syarat pembayaran) dari line items PO, dan tautkan kembali ke request asli dan itemnya. Jejak keterlacakan itu penting saat harga berubah.

Desain jejak audit

Approvals adalah jejak audit Anda, tetapi biasanya Anda memerlukan lebih dari sekadar "disetujui/ditolak." Simpan siapa yang bertindak, kapan, apa keputusan mereka, dan mengapa.

Pendekatan ringan adalah tabel Activity/Audit yang merekam actor_user_id, entity_type, entity_id, action, old_value, new_value, dan created_at. Di AppMaster, ini bisa dimapping dengan rapi di Data Designer dan diisi otomatis dari business processes sehingga setiap perubahan terlacak.

Rekaman vendor dan pelacakan komunikasi

Aplikasi permintaan pengadaan hanya bekerja jika semua orang menggunakan fakta vendor yang sama. Perlakukan tabel vendor sebagai sumber kebenaran tunggal, bukan sesuatu yang diketik ulang di setiap request. Saat detail vendor berada di satu tempat, persetujuan bergerak lebih cepat dan finance melihat lebih sedikit kejutan.

Mulailah dengan record vendor yang memuat dasar yang sering digunakan: nama legal, nama tampilan, tax ID (jika digunakan), mata uang default, alamat penagihan, dan syarat pembayaran. Simpan email utama accounts payable, dan izinkan beberapa kontak agar orang yang tepat digunakan untuk kutipan vs invoice.

Tambahkan status vendor sehingga aplikasi bisa memblokir pembelian berisiko secara konsisten: Active (bisa dipilih), Pending review (diizinkan, tapi diarahkan ke validasi tambahan), dan Blocked (tidak bisa digunakan tanpa review).

Pelacakan komunikasi mencegah masalah "siapa yang terakhir mengirim email?". Buat entitas Communication (atau VendorInteraction) yang ditautkan ke Vendor dan, bila memungkinkan, ke Request, Quote, atau Purchase Order tertentu. Setiap record harus menangkap channel (email, telpon, meeting), arah (keluar/masuk), timestamp, pemilik, dan ringkasan singkat. Jika Anda mengumpulkan kutipan, simpan sebagai record terstruktur (jumlah, mata uang, tanggal berlaku) dan lampirkan file bila perlu.

Beberapa aturan biasanya menjaga data vendor tetap bersih tanpa memperlambat orang:

• Pilih Vendor dari daftar, bukan teks bebas.
• Kunci syarat pembayaran setelah pembuatan PO kecuali ada persetujuan yang diperlukan.
• Auto-route vendor dengan status Pending review ke procurement.
• Untuk pembelian bernilai tinggi, minta setidaknya satu interaksi yang tercatat dan timeline kutipan yang terlihat.

Jika Anda membangun ini di AppMaster, Anda bisa memodelkan Vendor, VendorContact, dan VendorCommunication di Data Designer dan menampilkan timeline pada layar request dan PO sehingga riwayat penuh hanya dengan satu klik.

Pengecekan anggaran: bagaimana memvalidasi pengeluaran sebelum persetujuan

Pengecekan anggaran menjawab pertanyaan sederhana: apakah kita memiliki cukup dana yang disetujui untuk permintaan ini saat ini? Putuskan sejak awal apakah perusahaan memperlakukan anggaran sebagai penghalang keras (tidak bisa lanjut) atau sebagai peringatan (bisa lanjut, tetapi butuh persetujuan ekstra). Pilihan itu mengubah seluruh pengalaman untuk pemohon dan penyetuju.

Anggaran bisa berasal dari tempat berbeda, jadi buat sumbernya eksplisit. Opsi umum adalah anggaran tahunan departemen, anggaran proyek, atau batas bulanan untuk cost center. Jika permintaan bisa dibagi ke beberapa sumber, tangkap jumlah terpisah per sumber agar pelaporan tetap rapi.

Untuk menghindari kejutan, hitung perkiraan pengeluaran dengan cara yang sama seperti yang akan dipakai finance nanti. Aplikasi request hanya berguna jika semua pihak melihat angka yang sama sebelum persetujuan.

Checklist perhitungan sederhana yang dipakai banyak tim mencakup total garis item (qty x harga satuan), diskon, pajak, ongkos kirim dan penanganan, serta konversi mata uang (simpan rate dan tanggal rate). Kemudian bandingkan perkiraan pengeluaran dengan anggaran yang tersedia (anggaran dikurangi jumlah yang sudah terikat). Jika Anda melacak komitmen, sertakan request yang tertunda dan PO terbuka, bukan hanya invoice yang sudah dibayar.

Saat anggaran tidak mencukupi, jangan paksa requester menebak. Pilih satu jalur dan encode dalam workflow: arahkan ke pemilik anggaran untuk menetapkan sumber, izinkan override sekali dengan persetujuan finance, kembalikan request dengan tugas "detail anggaran", atau auto-reject kategori yang selalu membutuhkan anggaran.

Contoh: sebuah tim meminta paket laptop baru. Aplikasi menghitung biaya item plus pajak dan ongkos kirim, mengonversinya ke mata uang departemen, dan menandai bahwa hanya $900 tersedia terhadap permintaan $1.150. Jika Anda memperlakukan ini sebagai peringatan, permintaan masih bisa diteruskan ke manajer, tetapi persetujuan finance menjadi wajib.

Di AppMaster, Anda bisa memodelkan sumber anggaran di Data Designer dan menjalankan pengecekan sebagai langkah Business Process sebelum keputusan persetujuan pertama.

Alur persetujuan dan aturan routing

Persetujuan adalah tempat aplikasi request menyelamatkan waktu atau berubah menjadi relay inbox yang lambat. Jaga jalur default sederhana, lalu tambahkan aturan hanya ketika mereka mencegah risiko nyata.

Mulai dengan mendefinisikan apa yang dilindungi oleh setiap persetujuan. Set umum adalah persetujuan manajer (kebutuhan dan prioritas), persetujuan finance (anggaran dan akuntansi), dan persetujuan procurement (vendor dan metode pembelian). Tambahkan keamanan dan legal hanya ketika kategori atau vendor tertentu membutuhkannya.

Aturan routing harus dapat diprediksi. Orang harus bisa menebak apa yang terjadi selanjutnya sebelum menekan Submit. Faktor routing tipikal adalah ambang jumlah, routing berdasarkan kategori (software ke security, kontrak ke legal), level risiko vendor, aturan departemen atau cost center, dan tipe pembelian (CapEx vs OpEx, subscription vs one-time).

Gunakan persetujuan berurutan ketika urutan penting. Misalnya, finance mungkin memblokir request yang kehilangan cost center, jadi lebih baik menangkap itu sebelum procurement menghabiskan waktu menegosiasikan. Gunakan persetujuan paralel ketika tim bisa meninjau secara independen, seperti security dan legal meninjau pembelian SaaS standar sementara finance memeriksa anggaran.

Rencanakan loop rework yang rapi. Ketika approver mengembalikan request, requester harus menambahkan detail yang hilang dan menyerahkan kembali tanpa kehilangan riwayat. Simpan log persetujuan dengan timestamp, komentar, dan versi field kunci seperti jumlah, vendor, dan kategori.

Contoh: SaaS senilai $12.000 diarahkan ke manager dan finance terlebih dahulu. Setelah keduanya menyetujui, security dan procurement berjalan paralel. Jika security menandai data processing detail yang hilang, itu dikembalikan ke requester, lalu kembali ke langkah yang sama dengan jejak audit tetap utuh.

Jika Anda membangun ini di AppMaster, modelkan state alur kerja dan transisinya sebagai Business Process sehingga routing tetap terlihat dan mudah disesuaikan ketika kebijakan berkembang.

Langkah demi langkah: dari request ke purchase order

Alur yang baik menjaga request terus bergerak tanpa membiarkan detail mengambang. Tangkap informasi yang cukup di awal, lalu freeze apa yang penting begitu review dimulai.

Urutan praktis bagi sebagian besar tim terlihat seperti ini:

• Draft the request: Tambahkan line items, kuantitas, harga target, vendor yang disukai (atau vendor TBD), alasan bisnis, cost center, dan tanggal kebutuhan. Lampirkan kutipan atau konteks agar penyetuju tidak perlu mengejar.
• Submit and lock key fields: Saat requester menekan Submit, kunci vendor, mata uang, cost center, dan estimasi total. Biarkan area komentar pendek tetap bisa diedit agar reviewer bisa bertanya tanpa mengubah record.
• Run budget checks and route approvals: Validasi pengeluaran sebelum orang menyetujuinya. Jika request melebihi ambang, kehilangan kutipan, atau terkait kategori terbatas, arahkan ke grup yang tepat. Jika anggaran tidak cukup, kembalikan permintaan dengan alasan spesifik.
• Create the PO after final approval: Hasilkan PO dari request yang disetujui dan salin line items yang disetujui. PO menjadi sumber kebenaran untuk angka yang ditujukan ke vendor.
• Send the PO and track confirmation: Catat kapan PO dikirim, pengakuan vendor, tanggal pengiriman, dan setiap pengiriman parsial. Jika vendor mengusulkan perubahan, tangkap sebagai revisi.

Contoh: tim support meminta 10 headset baru. Mereka melampirkan kutipan, memilih kategori IT Supplies, dan submit. Aplikasi memeriksa anggaran IT, mengarahkan ke team lead (di bawah $1.000) lalu finance (di atas $500). Setelah disetujui, PO dibuat dan dikirim, dan pembeli mencatat konfirmasi serta tanggal pengiriman.

Di alat no-code seperti AppMaster, ini biasanya menjadi beberapa layar (Draft, Review, PO) ditambah Business Process yang mengunci field, menjalankan logika anggaran, dan membuat record PO secara otomatis.

Purchase orders: penomoran, line items, dan kontrol perubahan

Purchase order (PO) hanya berguna jika konsisten, dapat dilacak, dan sulit diubah secara tidak sengaja. Dalam alur Anda, PO harus menjadi record stabil yang bisa dipercaya vendor dan finance.

Penomoran PO: kapan harus menghasilkan nomor

Hasilkan nomor PO saat PO resmi diterbitkan ke vendor, bukan saat seseorang mulai menyusunnya. Draft dihapus, dimulai ulang, dan digabung; itulah cara celah dan duplikasi terjadi.

Untuk menghindari duplikasi, simpan nomor PO berikutnya di satu tempat terkontrol dan tetapkan dengan langkah atomik (satu aksi yang berhasil sepenuhnya atau gagal). Jika Anda butuh nomor yang ramah manusia, tambahkan prefix seperti entitas legal atau tahun, tetapi biarkan counter unik sebagai bagian yang tidak pernah terulang.

Struktur PO: header, lines, dan total

Pisahkan PO menjadi header dan line items. Header menyimpan konteks; lines menyimpan apa yang dibeli.

Jaga header fokus: vendor dan kontak, ship-to dan bill-to, mata uang, syarat pembayaran, tanggal pengiriman yang diharapkan, status (Draft, Issued, Acknowledged, Closed), dan referensi kutipan.

Line items harus cukup ketat untuk pencocokan invoice nanti: deskripsi, kuantitas, unit, harga satuan, pajak, diskon, dan cost center atau kode anggaran. Total harus dihitung, bukan diketik.

Kontrol perubahan: revisi vs batal dan terbitkan ulang

Putuskan sejak awal kapan revisi diperbolehkan. Perubahan kecil seperti tanggal pengiriman atau catatan bisa menjadi versi revisi (mis. PO-1042 v2) dengan tautan "menggantikan v1" yang jelas. Perubahan besar seperti vendor, mata uang, atau perubahan material pada total biasanya pantas untuk "batal dan terbitkan ulang" agar tidak ada yang mengirim berdasarkan dokumen yang salah.

Contoh: request disetujui untuk 10 laptop, tetapi kutipan vendor berubah dari pengiriman 2 minggu menjadi 8 minggu. Buat revisi dengan tanggal pengiriman yang diperbarui dan simpan detail kutipan asli agar PO selalu sesuai dengan yang disepakati.

Jika Anda membangun ini di AppMaster, modelkan header PO, line items, dan versi PO sebagai entitas terpisah sehingga revisi tetap bersih dan dapat diaudit.

Notifikasi dan alur komunikasi vendor

Notifikasi menentukan apakah alur kerja pengadaan internal terasa mulus atau berubah menjadi pencarian thread. Perlakukan pesan sebagai bagian dari proses dan kaitkan dengan perubahan status atau tindakan berikutnya yang jelas.

Mulai dengan set kecil update internal agar orang tidak mengabaikannya: approved/rejected, pengecekan anggaran gagal atau butuh klarifikasi, PO dibuat dan siap dikirim, persetujuan tertunda atau tanggal pengiriman lewat, dan PO berubah atau dibatalkan.

Setiap notifikasi harus bisa dibaca dalam 10 detik. Gunakan template konsisten dengan judul request, total jumlah, status saat ini, dan tepatnya apa yang penerima harus lakukan berikutnya. Untuk approver, sertakan alasan singkat pengeluaran dan line items paling penting.

Komunikasi vendor juga harus terstruktur. Vendor umumnya butuh PO dikirim, PO diubah, pembatalan, dan pertanyaan pengiriman. Simpan setiap pesan keluar dan masuk di thread vendor untuk PO atau request tersebut. Lacak hasil dengan field sederhana seperti status (draft, sent, delivered, failed), vendor_response (none, replied, bounced), follow_up_needed (yes/no), dan follow_up_date.

Contoh: request laptop disetujui, PO dikirim, dan vendor membalas bahwa model tersebut backordered. Aplikasi mencatat balasan, mengatur follow_up_needed ke yes, dan memberi tahu requester untuk memilih alternatif. Di AppMaster, Anda bisa menghubungkan perubahan status ke langkah email/SMS/Telegram dan menyimpan outcome pesan bersama PO.

Kesalahan umum dan jebakan yang harus dihindari

Risiko terbesar bukan fitur yang hilang. Risiko itu membangun aturan yang salah dan mengajari perusahaan untuk mengakali aturan tersebut.

Satu kegagalan umum adalah mengubah request menjadi labirin status. Jika orang tidak bisa membedakan "Pending validation" vs "Under review", mereka berhenti mengupdate dan data menjadi berisik. Jaga status terkait dengan tindakan dan pemilik yang jelas. Setiap status harus menjawab satu pertanyaan: "Apa yang terjadi selanjutnya, dan siapa yang melakukannya?"

Jebakan lain adalah persetujuan tanpa pemilik atau tenggat waktu. Request tersangkut saat approver cuti atau peran tidak jelas ("Finance" bukan nama orang). Tambahkan cakupan cadangan dan ekspektasi waktu sederhana, meski informal.

Kesalahan yang paling sering menyebabkan rework:

• Terlalu banyak status dan pengecualian yang hanya dipahami pembuatnya
• Persetujuan ditugaskan ke grup tanpa fallback ketika seseorang tidak tersedia
• Mengedit harga, kuantitas, atau vendor setelah persetujuan tanpa memaksa re-approval
• Pengecekan anggaran yang tidak sesuai cara finance melacak pengeluaran (periode, cost center, komitmen vs aktual)
• Override manual tanpa alasan tercatat dan tanpa jejak audit

Perubahan setelah persetujuan perlu perhatian khusus karena perubahan kecil "tanpa bahaya" sering mengubah risiko. Jika seseorang mendapatkan persetujuan untuk 10 laptop seharga $900 masing-masing, lalu mengubah item menjadi model yang lebih mahal atau menambah kuantitas, Anda bisa berakhir dengan persetujuan yang tidak mencerminkan apa yang dibeli.

Juga, jangan perlakukan validasi anggaran sebagai field ya/tidak tunggal. Finance biasanya peduli tentang bagaimana pengeluaran dilaporkan: departemen, proyek, akun GL, dan jendela waktu. Jika aplikasi Anda memeriksa anggaran bulanan tetapi finance melaporkan kuartalan, "anggaran tersedia" Anda akan selalu terlihat salah.

Jika Anda membangun ini di AppMaster, kunci field kunci setelah persetujuan dan catat setiap pengecualian sebagai event (siapa, kapan, apa yang berubah, dan mengapa). Jejak audit itulah yang menyelamatkan Anda saat sengketa dan audit.

Daftar periksa cepat, skenario contoh, dan langkah berikutnya

Sebelum peluncuran, tuliskan hal-hal dasar. Sebagian besar "kekacauan persetujuan" terjadi karena satu aturan kecil atau field wajib hilang.

Daftar periksa peluncuran sederhana:

• Peran dan izin (requester, approver, finance, procurement, admin)
• Aturan persetujuan (jumlah, departemen, kategori, lokasi)
• Status dan kepemilikan (Draft, Submitted, Needs info, Approved, PO created, Closed)
• Field wajib (vendor, cost center, tanggal pengiriman, alasan bisnis)
• Lampiran wajib (kutipan, kontrak, security review, lembar spesifikasi)

Setelah aturan itu ada, tambahkan validasi cepat yang berjalan sebelum request bisa maju: pemilihan vendor (atau jalur vendor-baru yang jelas), cakupan anggaran untuk periode yang benar, bukti harga, detail pengiriman/penagihan lengkap, dan alasan bisnis nyata.

Skenario contoh: team lead mengajukan request laptop untuk karyawan baru yang mulai minggu depan. Mereka memilih vendor yang disukai, melampirkan kutipan, dan menandai cost center yang tepat. Manajer menyetujui karena sesuai rencana perekrutan. Finance menyetujui setelah pengecekan anggaran lulus. Procurement membuat PO, mengirimkannya ke vendor, dan mencatat konfirmasi vendor serta tanggal pengiriman yang diharapkan di record yang sama sehingga requester bisa melacak progres tanpa email tambahan.

Langkah berikutnya: prototipe model data dan aturan alur kerja Anda, lalu uji dengan tim pilot kecil dan satu atau dua kategori pembelian. Di AppMaster, Anda bisa membangun tabel di Data Designer dan memetakan logika routing di Business Process Editor. Jalankan pilot singkat, tinjau titik di mana request tersangkut, perketat field wajib, lalu gulirkan lebih luas. Jika Anda ingin melihat bagaimana pendekatan ini diterjemahkan ke pembangunan aplikasi nyata, AppMaster (appmaster.io) dirancang untuk membuat alat internal penuh dengan logika persetujuan, API, dan antarmuka web serta native mobile dari model yang sama.