Membangun Aplikasi Web untuk Mengelola Daftar Harga Pemasok & Kontrak

Masalah yang Harus Diselesaikan Aplikasi (dan Untuk Siapa)

Kekacauan harga dan kontrak pemasok biasanya mirip: daftar harga hidup di spreadsheet yang dikirim email, PDF “final_FINAL” ada di drive bersama, dan tidak ada yang yakin mana syarat yang berlaku. Hasilnya bisa diprediksi—harga kedaluwarsa dipakai di pesanan, sengketa yang bisa dihindari, dan perpanjangan yang terlewat.

Masalah bisnis yang harus diperbaiki

Aplikasi web yang baik harus memusatkan sumber kebenaran untuk daftar harga pemasok dan kontrak, serta membuat perubahan dapat ditelusuri ujung-ke-ujung. Ini harus mengurangi:

• Penyalinan manual antar spreadsheet, ERP, dan inbox
• Kesalahan harga akibat versi yang kadaluwarsa
• Perpanjangan dan periode notis yang terlewat
• Waktu yang dihabiskan mencari dokumen atau amandemen yang ditandatangani terakhir

Untuk siapa aplikasi ini

Rancang sistem di sekitar orang yang menyentuh harga dan syarat setiap minggu:

• Procurement: mengimpor daftar harga, merundingkan pembaruan, melacak tanggal efektif
• Finance/AP: memvalidasi harga tagihan, memeriksa mata uang, unit, pajak/biaya
• Legal/Compliance: menyimpan perjanjian yang ditandatangani, amandemen, klausul yang diperlukan
• Approvers (manajemen): meninjau dan menyetujui perubahan harga/syarat
• Admins: mengelola pengguna, peran, data master pemasok, template

Metrik keberhasilan yang menunjukkan aplikasi bekerja

Pilih beberapa target terukur sejak awal:

• Waktu untuk menerbitkan pembaruan harga (mis. dari 2 hari menjadi 2 jam)
• Tingkat kesalahan impor dan jumlah koreksi manual per unggahan
• Rasio pengiriman pengingat perpanjangan (mis. % kontrak yang diberi peringatan sebelum batas notis)
• Tingkat selisih harga (mismatch invoice/PO terkait validitas harga)

Definisi “selesai”: rilis pertama vs iterasi berikut

Untuk rilis pertama, targetkan rekaman pemasok terpusat, impor daftar harga dengan validasi, penyimpanan kontrak dengan tanggal kunci, persetujuan dasar, pencarian, dan jejak audit.

Iterasi berikutnya bisa menambahkan integrasi ERP yang lebih dalam, perpustakaan klausul, pencocokan faktur otomatis, organisasi multi-entitas, dan dashboard pelaporan lanjutan.

Persyaratan dan Pemetaan Alur Kerja

Sebelum Anda membuat sketsa layar atau tabel, petakan apa yang sebenarnya terjadi dari saat pemasok mengirim daftar harga sampai saat seseorang melakukan pemesanan berdasarkan daftar itu. Ini mencegah membangun “repositori dokumen” generik ketika yang Anda butuhkan sebenarnya sistem harga terkontrol.

Pemetaan alur saat ini (as-is)

Mulailah dengan menelusuri contoh nyata bersama procurement, finance, dan legal. Tangkap serah terima dan artefak di setiap langkah:

• Terima daftar harga (email, portal, spreadsheet, EDI) → catat tanggal penerimaan dan sumber
• Tinjau dan negoisasi → rekam pertanyaan, counter-offer, dan perubahan yang disepakati
• Setujui harga dan syarat → identifikasi titik keputusan dan tanda tangan yang diperlukan
• Tandatangani dan simpan dokumen kontrak → tautkan syarat ke daftar harga yang efektif
• Operasikan dan perpanjang → pantau kedaluwarsa, perubahan harga, dan pengecualian

Diagram swimlane sederhana (Supplier → Buyer/Procurement → Legal → Finance → Operations) seringkali cukup.

Identifikasi keputusan kunci dan peran (siapa bisa melakukan apa)

Daftarkan keputusan yang mengubah hasil bisnis dan tetapkan pemilik yang jelas:

• Siapa yang bisa menyetujui daftar harga baru vs amandemen kontrak?
• Siapa yang bisa mengedit field harga (mata uang, unit, MOQ, lead time), dan siapa yang hanya bisa mengajukan permintaan perubahan?
• Siapa yang bisa melihat syarat kontrak sensitif (syarat pembayaran, klausul tanggung jawab), dan siapa yang harus dibatasi?

Catat juga di mana persetujuan berbeda menurut ambang (mis. >5% kenaikan membutuhkan persetujuan finance) sehingga Anda bisa mengkodekan aturan itu nanti.

Definisikan output yang dibutuhkan (apa yang harus diselesaikan orang)

Tuliskan pertanyaan tepat yang harus bisa dijawab aplikasi pada hari pertama:

• "Berapa harga saat ini untuk item X dari pemasok Y, berlaku hari ini?"
• "Kontrak mana yang berakhir dalam 60/90 hari ke depan, dan siapa pemilik perpanjangannya?"
• "Di mana kami punya pengecualian: harga kadaluwarsa masih dipakai, MOQ hilang, ketidaksesuaian mata uang?"

Output ini harus mendorong field data, pencarian, dan laporan—bukan sebaliknya.

Tangkap titik sakit dan kasus tepi sejak dini

Data pengadaan itu berantakan. Dokumentasikan secara eksplisit pengecualian umum:

• Pembaruan parsial (pemasok memperbarui 20 SKU, bukan seluruh katalog)
• Banyak mata uang dan asumsi FX
• MOQ, ukuran kemasan, unit (each vs case), dan pembulatan
• Tanggal efektif yang saling tumpang tindih atau koreksi yang diberi tanggal mundur

Anggap daftar ini sebagai kriteria penerimaan untuk impor dan persetujuan, sehingga sistem mendukung realita daripada memaksakan solusi sementara.

Arsitektur Tingkat Tinggi dan Pemecahan Modul

Arsitektur yang baik untuk daftar harga pemasok dan kontrak lebih sedikit soal pola populer dan lebih banyak soal mengurangi overhead koordinasi sambil menjaga ruang untuk pertumbuhan.

Pendekatan pembangunan: mulai sederhana, berkembang secara terencana

Untuk kebanyakan tim (1–6 engineer) titik awal terbaik adalah modular monolith: satu aplikasi yang dideploy dengan modul dan batasan yang jelas. Anda mendapatkan pengembangan lebih cepat, debugging lebih sederhana, dan lebih sedikit bagian operasional.

Bergerak ke layanan terpisah nanti hanya jika ada alasan jelas—mis. beban impor berat yang butuh skala independen, banyak tim bekerja paralel, atau kebutuhan isolasi ketat. Jalur umum: modular monolith → ekstrak beban import/processing dan document ke worker latar belakang → opsional memecah domain bertrafik tinggi menjadi layanan.

Jika Anda ingin mempercepat prototipe pertama (layar, alur kerja, dan kontrol akses berbasis peran) tanpa mengunci siklus pembangunan panjang, platform vibe-coding seperti Koder.ai dapat membantu menghasilkan baseline React + Go + PostgreSQL dari spesifikasi chat terstruktur, lalu iterasi cepat di impor, persetujuan, dan jejak audit. Untuk tim procurement, itu sering berarti memvalidasi alur kerja dengan pengguna nyata lebih awal—sebelum Anda membangun berlebihan.

Modul inti (set minimum yang tetap dapat dipahami)

Rancang aplikasi di sekitar beberapa domain stabil:

• Suppliers: profil pemasok, kontak, identifier, status
• Catalog (Items/Materials): master item internal dan pemetaan ke kode item pemasok
• Price Lists: header (pemasok, periode berlaku) dan baris (harga, unit, mata uang), plus riwayat impor
• Contracts: rekam kontrak, pemasok terkait, item/kategori yang tercakup, tanggal kunci, dan dokumen terkait
• Approvals & Governance: langkah review, tanda tangan, komentar, dan riwayat keputusan
• Reporting: pencarian, ekspor, tampilan pengeluaran/harga, dan snapshot operasional

Jaga setiap modul bertanggung jawab atas aturan dan akses datanya sendiri. Bahkan di monolith, tegakkan batasan di kode (paket, penamaan, dan API antar modul yang jelas).

Rencanakan integrasi sejak awal (meski tidak dibangun di hari pertama)

Integrasi mengubah aliran data, jadi sediakan titik ekstensi eksplisit:

• SSO (SAML/OIDC) untuk autentikasi dan provisioning pengguna
• ERP/finance systems untuk vendor ID, item master, dan push harga yang disetujui
• Email/calendar untuk pengingat perpanjangan dan notifikasi persetujuan
• Document signing (opsional) untuk menyelesaikan amandemen dan perjanjian baru

Kebutuhan non-fungsional (tetapkan target sebelum rilis)

Tentukan ekspektasi terukur sejak awal:

• Performa: pencarian umum <2 detik; impor diproses secara asinkron dengan visibilitas progres
• Ketersediaan: target uptime jelas dan jadwal maintenance
• Backup & recovery: backup otomatis, latihan restore, dan retensi sesuai kebijakan
• Auditability: riwayat event immutable untuk impor, persetujuan, dan perubahan kontrak, dengan keterlacakan ke pengguna dan cap waktu

Model Data: Entitas, Relasi, dan Versioning

Model data yang bersih adalah apa yang membuat aplikasi pengadaan dapat dipercaya. Ketika pengguna bertanya, “Harga apa yang berlaku pada 3 Maret?” atau “Kontrak mana yang mengatur pembelian itu?”, basis data harus menjawab tanpa tebakan.

Entitas inti (minimum yang akan Anda andalkan)

Mulailah dengan sekumpulan rekam yang terdefinisi baik:

• Supplier: akun vendor (nama, kode pemasok, status, mata uang default, syarat pembayaran)
• Contact: orang di pemasok (banyak per pemasok)
• Item/SKU: apa yang Anda beli (kode item, deskripsi, kategori, unit ukur)
• PriceList: daftar yang disediakan pemasok atau jadwal negosiasi (nama, tanggal efektif, mata uang, sumber file, status)
• PriceLine: baris harga di dalam daftar (item, harga satuan, break/MOQ bila berlaku, flag pajak)
• Contract: perjanjian komersial (nomor kontrak, pemasok, tanggal mulai/akhir, pengaturan perpanjangan, status)
• Term: klausul terstruktur (lead time, garansi, pengiriman, SLA) yang ingin Anda cari/laporkan

Relasi yang menjaga semuanya terhubung

Modelkan relasi untuk mencerminkan cara pembeli bekerja:

• Supplier → Contracts: satu pemasok bisa punya banyak kontrak
• Supplier → PriceLists: satu pemasok bisa menyediakan banyak daftar harga dari waktu ke waktu
• Contract → PriceLists (opsional tapi berguna): tautkan kontrak ke price list yang diaturnya
• Item/SKU → PriceLines: satu item bisa muncul di banyak price line (antar pemasok, mata uang, tanggal efektif)

Jika Anda mendukung banyak lokasi pengiriman atau unit bisnis, pertimbangkan menambahkan konsep Scope (mis. perusahaan, site, region) yang dapat dilampirkan ke kontrak dan daftar harga.

Versioning: jangan timpa history

Hindari mengedit rekam “live” di tempat. Sebagai gantinya:

• Versioning daftar harga: setiap impor membuat versi PriceList baru (atau rekam PriceList baru dengan family identifier). Biarkan versi sebelumnya read-only.
• Amandemen kontrak: simpan setiap amandemen sebagai versi baru dengan tanggal efektif dan dokumen terkait. Tampilan “current” adalah versi terbaru yang disetujui.

Ini membuat pertanyaan audit mudah: Anda bisa merekonstruksi apa yang disetujui kapan, dan apa yang berubah.

Data referensi dan aturan keunikan

Simpan data referensi di tabel terdedikasi untuk menghindari teks bebas yang berantakan:

• Currency, Unit of Measure, Tax Code, dan (jika kirim internasional) Incoterms

Terapkan identifier untuk mencegah duplikat silent:

• Supplier code unik di seluruh sistem
• Item code unik (atau unik per katalog/sumber)
• Contract number unik per pemasok (atau global—pilih dan tegakkan konsisten)

Impor Daftar Harga: Template, Validasi, dan Penanganan Error

Daftar harga biasanya datang dalam spreadsheet yang tidak pernah dibuat untuk mesin. Alur impor yang mulus adalah perbedaan antara “kami akan memakai aplikasi” dan “kami akan terus email Excel.” Tujuannya: membuat unggahan toleran, tetapi data yang disimpan ketat.

Format yang didukung dan template yang dapat diunduh

Dukung CSV dan XLSX sejak hari pertama. CSV bagus untuk ekspor dari ERP dan tool BI; XLSX adalah yang dikirim pemasok.

Sediakan template yang dapat diunduh yang mencerminkan model data Anda (dan mengurangi tebakan). Sertakan:

• Baris pertama dengan nama kolom yang tepat
• Baris contoh yang menunjukkan nilai valid (mata uang, unit, tanggal)
• Sheet “catatan” opsional (untuk XLSX) yang menjelaskan setiap kolom

Versikan template (mis. Template v1, v2) sehingga Anda bisa mengembangkannya tanpa merusak proses yang berjalan.

Aturan pemetaan: kolom wajib vs opsional

Definisikan aturan pemetaan secara eksplisit dan tampilkan di UI saat unggah.

Pendekatan umum:

• Kolom wajib: identifier pemasok, item/SKU, harga, mata uang, unit ukur, tanggal mulai efektif
• Kolom opsional: tanggal akhir efektif, minimum order quantity, lead time, packaging, incoterms, komentar
• Nilai default (per pemasok atau per unggahan): mata uang, unit, tanggal mulai “hari ini”, tanggal akhir kosong

Jika Anda mengizinkan kolom kustom, anggap itu sebagai metadata dan simpan terpisah agar tidak mencemari skema harga inti.

Aturan validasi yang mencegah data buruk

Jalankan validasi sebelum sesuatu dikomit:

• Format numerik: tolak sel harga non-numerik; normalisasi pemisah ribuan; pastikan harga >= 0
• Kode mata uang: validasi terhadap ISO 4217 (mis. USD, EUR)
• Rentang tanggal: start date wajib; end date harus setelah start date; cegah overlap efektif untuk item yang sama jika aturan Anda mengharuskan eksklusivitas
• Baris duplikat: deteksi key identik (mis. supplier + SKU + start date + currency + unit). Putuskan apakah duplikat dianggap error atau "last one wins" (error lebih aman)

Lakukan validasi di tingkat baris (baris ini salah) dan file (unggahan ini konflik dengan rekam yang ada).

Penanganan error: preview, umpan balik per baris, dan reupload

Pengalaman impor yang baik terlihat seperti: Upload → Preview → Fix → Confirm.

Di layar preview:

• Tampilkan tabel dengan sel yang disorot dan pesan jelas (mis. “Kode mata uang tidak valid: US$”)
• Izinkan pengguna mengunduh laporan error (CSV) dengan kolom tambahan “error”
• Sediakan alur perbaiki-dan-reupload yang mempertahankan pilihan pemetaan dari percobaan terakhir

Hindari “gagal seluruh file karena satu baris rusak.” Sebagai gantinya, beri pilihan: impor hanya baris valid atau block sampai semua error diperbaiki, tergantung tata kelola.

Simpan unggahan mentah untuk keterlacakan

Untuk auditabilitas dan reprocessing, simpan:

• File mentah asli (byte persis), dengan checksum dan identitas pengunggah
• Baris terparsing dan hasil validasi (termasuk error)
• Konfigurasi impor (versi template, pemetaan kolom, default)

Ini menciptakan jejak bukti untuk sengketa (“apa yang kita impor dan kapan?”) dan memungkinkan reprocessing ketika aturan validasi berubah.

Rekam Kontrak: Syarat, Dokumen, dan Amandemen

Rekam kontrak harus lebih dari lemari arsip. Ia perlu data terstruktur yang cukup untuk menggerakkan perpanjangan, persetujuan, dan pelaporan—sambil tetap membuat dokumen yang ditandatangani mudah ditemukan.

Syarat inti kontrak (field terstruktur)

Mulailah dengan field yang menjawab pertanyaan procurement setiap minggu:

• Tanggal mulai dan tanggal akhir kontrak
• Tipe perpanjangan (auto-renew, fixed term, evergreen) dan panjang perpanjangan
• Periode notis (mis. “60 hari sebelum end date”) dan siapa yang harus diberi notifikasi
• Syarat pembayaran (Net 30/45/60, diskon pembayaran awal) dan aturan penagihan
• Pemilik kontrak, kontak pemasok, dan pemangku kepentingan internal

Simpan teks bebas untuk kasus tepi, tapi normalisasi apa pun yang akan Anda filter, grup, atau beri alert.

Dokumen, lampiran, dan retensi

Perlakukan dokumen sebagai item kelas-satu yang ditautkan ke kontrak:

• Perjanjian yang ditandatangani (PDF)
• Amandemen/addenda
• Statement of work, rate card, sertifikat asuransi, dokumen kepatuhan

Simpan metadata untuk setiap file: tipe dokumen, tanggal efektif, versi, pengunggah, dan tingkat kerahasiaan. Jika organisasi Anda punya persyaratan retensi, tambahkan field seperti “retention until” dan “legal hold” sehingga aplikasi dapat mencegah penghapusan dan mendukung audit.

Amandemen dan pelacakan klausul

Amandemen tidak boleh menimpa history. Modelkan sebagai perubahan bertanggal yang memperpanjang syarat (tanggal akhir baru), menyesuaikan syarat komersial, atau menambah/membuang scope.

Jika memungkinkan, tangkap klausul kunci sebagai data terstruktur untuk alert dan pelaporan—mis. apakah terminasi untuk convenience diizinkan (Y/N), formula indeksasi, service credits, batas tanggung jawab, dan eksklusivitas.

Satu kontrak, banyak pemasok atau situs

Jika Anda membeli secara sentral tapi beroperasi di banyak lokasi, dukung penautan satu kontrak ke banyak site/unit bisnis, dengan override opsional per site (mis. alamat penagihan, syarat pengiriman). Demikian pula, izinkan satu kontrak mencakup pemasok induk plus anak perusahaan, sambil mempertahankan “pihak yang dikontrakkan” yang jelas untuk kepatuhan.

Alur Persetujuan dan Tata Kelola

Persetujuan adalah tempat daftar harga dan kontrak menjadi dapat dipertanggungjawabkan. Alur kerja yang jelas mengurangi debat “siapa yang menyetujui ini?” dan menciptakan jalur yang dapat diulang dari pengiriman pemasok ke data yang dapat dipakai dan patuh.

Alur status (buat eksplisit)

Gunakan lifecycle sederhana dan terlihat untuk daftar harga dan rekam kontrak:

Draft → Review → Approved → Active → Expired/Terminated

• Draft: dapat diedit oleh pengirim; tidak digunakan dalam pembelian.
• Review: dikunci untuk pengeditan kecuali melalui permintaan perubahan; reviewer memvalidasi kelengkapan dan kesesuaian kebijakan.
• Approved: keputusan tercatat; siap diaktifkan berdasarkan aturan tanggal.
• Active: efektif untuk pemesanan; perubahan memerlukan revisi baru dan persetujuan.
• Expired/Terminated: read-only; disimpan untuk pelaporan dan audit.

Peran dan tanggung jawab

Definisikan tanggung jawab di aplikasi (bukan di tribal knowledge):

• Submitter (Procurement/Supplier manager): mengunggah daftar harga, menyusun syarat kontrak, menanggapi komentar review
• Reviewer (Category/Finance): memeriksa harga, unit, mata uang, dan kesesuaian komersial
• Approver (Budget owner): keputusan akhir untuk dampak komersial
• Legal: reviewer/approver wajib untuk bahasa kontrak, dokumen, dan amandemen
• Admin: mengonfigurasi ambang, aturan routing, dan mengelola izin—sebaiknya tidak menyetujui konten bisnis secara default

Aturan untuk perubahan harga (mencegah cost creep diam-diam)

Tambahkan pemeriksaan berbasis kebijakan yang otomatis memicu langkah persetujuan ekstra:

• Persetujuan ambang: mis. jika ada garis harga naik >5% atau dampak total kategori > $10,000, route ke approver lebih tinggi
• Routing berbasis kategori: kategori strategis (TI, logistik) mungkin selalu memerlukan legal + budget owner
• Penanganan pengecualian: izinkan override hanya dengan alasan wajib dan lampiran

Keputusan siap audit: komentar, alasan, dan bukti

Setiap persetujuan atau penolakan harus menangkap:

• keputusan (approve/reject/request changes)
• kode alasan + penjelasan teks bebas
• cap waktu, aktor, dan revisi yang terkena
• bukti terkait (PDF email, surat pemasok, catatan rapat)

Eskalasi, timeout, dan akuntabilitas

Tetapkan ekspektasi tingkat layanan untuk menghindari persetujuan macet:

• pengingat otomatis pada 24/48 jam
• eskalasi ke approver cadangan setelah timeout tertentu
• visibilitas lewat antrian “My pending approvals” dan laporan overdue

Tata kelola bekerja paling baik ketika dibangun ke alur kerja—bukan ditegakkan setelahnya.

Pengalaman Pengguna: Layar, Pencarian, dan Pelaporan

Aplikasi pengadaan berhasil atau gagal berdasarkan seberapa cepat orang bisa menjawab pertanyaan sederhana: “Berapa harga saat ini?”, “Kontrak mana yang mengatur item ini?”, dan “Apa yang berubah sejak kuartal lalu?” Rancang UI di sekitar alur tersebut, bukan tabel basis data.

Temukan informasi cepat: pencarian dan filter

Sediakan dua titik masuk utama di navigasi atas:

• Pencarian pemasok (nama, tax ID/kode vendor, status, kategori)
• Pencarian item (SKU/part number, deskripsi, pabrikan, unit)

Di halaman hasil, gunakan filter kontrak yang sesuai pekerjaan nyata: tanggal efektif, status kontrak (draft/active/expired), unit bisnis, mata uang, dan “memiliki persetujuan tertunda”. Jaga filter terlihat dan dapat dihapus sebagai chips supaya pengguna non-teknis tidak bingung.

Layar kunci yang harus didesain dulu

Profil pemasok harus menjadi hub: kontrak aktif, daftar harga terbaru, perselisihan/ catatan terbuka, dan panel “aktivitas terbaru”.

Tampilan kontrak harus menjawab “Apa yang boleh kita beli, dengan syarat apa, sampai kapan?” Sertakan syarat kunci (incoterms, syarat pembayaran), dokumen terlampir, dan garis waktu amandemen.

Perbandingan daftar harga adalah tempat pengguna menghabiskan waktu. Tampilkan sekarang vs sebelumnya berdampingan dengan:

• Tanggal efektif (dan harga “masa depan”)
• Delta per item (absolut dan %)
• Sorotan untuk item baru/dihapus

Pelaporan dan ekspor

Laporan harus dapat ditindaklanjuti, bukan dekoratif: “berakhir dalam 60 hari”, “kenaikan harga terbesar”, “item dengan banyak harga aktif”. Tawarkan ekspor satu-klik ke CSV untuk finance dan PDF untuk berbagi/persetujuan, dengan filter yang sama sehingga data yang diekspor sesuai dengan yang dilihat pengguna.

Jaga sederhana dan mudah dimengerti

Gunakan label jelas (“Effective date”, bukan “Validity start”), bantuan inline pada field yang rumit (unit, mata uang), dan empty states yang menjelaskan langkah berikutnya (“Impor daftar harga untuk mulai melacak perubahan”). Checklist onboarding singkat di /help bisa mengurangi waktu pelatihan.

Keamanan, Izin, dan Jejak Audit

Keamanan paling gampang bila dirancang ke dalam alur kerja, bukan ditempelkan kemudian. Untuk aplikasi pengadaan, tujuannya sederhana: orang hanya melihat dan mengubah apa yang menjadi tanggung jawabnya, dan setiap perubahan penting dapat ditelusuri.

Peran dan izin (least privilege)

Mulai dengan model peran kecil yang jelas dan petakan ke aksi, bukan hanya layar:

• Viewer: akses baca-saja ke daftar harga disetujui dan kontrak aktif
• Editor: buat draft, unggah dokumen, siapkan impor, perbaiki error validasi
• Approver: setujui/tolak draft, kunci tanggal efektif, tanda tangan amandemen
• Admin: kelola pengguna, peran, data referensi, dan pengaturan sistem

Izin harus ditegakkan server-side untuk setiap endpoint (izin UI saja tidak cukup). Jika organisasi kompleks, tambahkan aturan scope (mis. per pemasok, unit bisnis, atau region).

Penanganan data sensitif

Putuskan sejak dini apa yang perlu proteksi ekstra:

• File kontrak (PDF, scan): enkripsi saat disimpan, batasi unduhan, dan opsional watermark
• Detail bank: simpan di area terpisah dengan pembatasan lebih ketat; batasi visibilitas ke peran finance sempit
• Visibilitas harga: pertimbangkan menyembunyikan margin atau harga khusus dari audiens luas; dukung tampilan "internal vs vendor-facing" jika perlu

Jejak audit: siapa mengubah apa, dan bagaimana

Tangkap log audit immutable untuk entitas kunci (kontrak, terms, item harga, persetujuan): siapa melakukannya, apa yang berubah (sebelum/ sesudah), kapan, dan sumber (UI/impor/API). Catat nama file impor dan nomor baris sehingga masalah dapat ditelusuri dan diperbaiki.

Autentikasi dan dasar sesi

Pilih satu metode login utama:

• SSO (SAML/OIDC) untuk pengguna enterprise, atau password + MFA untuk tim lebih kecil

Tambahkan kontrol sesi yang masuk akal: access token jangka pendek, cookie aman, timeout tidak aktif, dan meminta ulang autentikasi untuk aksi sensitif (mis. ekspor harga).

Kepatuhan dasar (tanpa berjanji berlebihan)

Targetkan kontrol praktis: least privilege, logging terpusat, backup berkala, dan prosedur restore yang dites. Anggap log audit sebagai rekam bisnis—batasi penghapusan dan definisikan kebijakan retensi.

Aturan Harga: Tanggal Efektif, Mata Uang, dan Unit

Harga jarang "satu angka." Aplikasi perlu aturan jelas agar pembeli, AP, dan pemasok mendapatkan jawaban yang sama: apa harga hari ini untuk item ini?

Penanggalan efektif (start/end, harga masa depan, overlap)

Simpan harga sebagai rekam berbatas waktu dengan start date dan end date opsional. Izinkan baris ber-dated masa depan (mis. kenaikan kuartal depan), dan tentukan apa arti “open-ended” (biasanya: berlaku sampai diganti).

Overlap harus ditangani secara sengaja:

• Tolak overlap secara default saat impor (terbaik untuk tata kelola)
• Izinkan dengan prioritas bila perlu (mis. harga promosi), tapi wajibkan alasan dan persetujuan

Aturan praktis: satu harga dasar aktif per supplier-item-currency-unit pada satu waktu; yang lain harus ditandai eksplisit sebagai override.

Mendefinisikan “harga saat ini”

Ketika banyak kandidat ada, definisikan urutan seleksi, misalnya:

1. Harga yang diatur kontrak (jika kontrak aktif dan item termasuk scope)
2. Override yang disetujui (promo/pengecualian) dalam rentang tanggal
3. Daftar harga pemasok yang disetujui dalam rentang tanggal
4. Fallback atau status “tidak ada harga” (aksi pengguna diperlukan)

Jika proses Anda punya pemasok preferensi, tambahkan prioritas pemasok sebagai field eksplisit yang hanya dipakai ketika ada banyak pemasok valid untuk item sama.

Strategi multi-mata uang

Pilih apakah akan menyimpan:

• Rate FX yang disimpan per rekam harga (terbaik untuk auditability; mereproduksi keputusan historis)
• Konversi FX live (berguna untuk dashboard; tetap simpan mata uang asli)

Banyak tim melakukan keduanya: simpan harga pemasok di mata uang asli, plus nilai yang dikonversi "as-of" untuk pelaporan.

Pembulatan dan konversi unit

Definisikan normalisasi unit (mis. each vs case vs kg) dan simpan faktor konversi yang versioned. Terapkan aturan pembulatan konsisten (desimal mata uang, increment minimum), dan jelaskan kapan pembulatan terjadi: setelah konversi unit, setelah konversi FX, dan/atau pada total baris akhir.

Perpanjangan, Peringatan, dan Dashboard Operasional

Perpanjangan adalah area di mana nilai kontrak dimenangkan atau hilang: periode notis terlewat, auto-renewal diam-diam, dan negosiasi menit terakhir sering menghasilkan syarat yang tidak menguntungkan. Aplikasi Anda harus memperlakukan perpanjangan sebagai proses yang dikelola dengan tanggal jelas, pemilik yang bertanggung jawab, dan antrean operasional yang terlihat.

Garis waktu perpanjangan dan pengingat

Modelkan perpanjangan sebagai serangkaian milestone yang ditautkan ke setiap kontrak (dan opsional ke amandemen spesifik):

• End date (kedaluwarsa)
• Deadline periode notis (tanggal terakhir untuk membatalkan/renegoisasi)
• Awal jendela perpanjangan (kapan sourcing harus dimulai)

Buat pengingat di sekitar milestone ini. Default praktis: cadence 90/60/30 hari sebelum deadline kunci (periode notis biasanya paling kritikal), plus alert “hari-H.”

Saluran notifikasi dan pengiriman

Mulai dengan dua saluran:

• Notifikasi in-app untuk antrean kerja harian
• Email untuk pengingat yang sensitif waktu

Opsional dukung ekspor ICS (per kontrak atau per pengguna) sehingga pemilik bisa subscribe di Outlook/Google Calendar.

Buat notifikasi dapat ditindaklanjuti: sertakan nama kontrak, pemasok, tanggal pasti, dan deep link ke rekam.

Kepemilikan dan eskalasi

Alert harus dikirim ke:

• Contract owner (utama)
• Category owner (sekunder, jika berbeda)
• Backup owner (untuk coverage)

Tambahkan aturan eskalasi: jika primary belum acknowledge dalam X hari, beri tahu backup atau manajer. Lacak timestamp "acknowledged" sehingga alert tidak menjadi noise latar belakang.

Dashboard operasional yang mendorong pekerjaan

Dashboard harus sederhana, dapat difilter, dan aware per peran:

• Kontrak yang akan segera berakhir (per 30/60/90 hari, termasuk deadline notis)
• Kontrak dengan tugas perpanjangan terlambat (belum diakui atau melewati milestone)
• Daftar harga yang menunggu persetujuan (usia, pemilik, pemasok)

Setiap widget harus menaut ke tampilan daftar terfokus dengan pencarian dan ekspor, sehingga dashboard menjadi titik awal tindakan—bukan sekadar pelaporan.

Rencana MVP, Pengujian, dan Checklist Rollout

MVP untuk daftar harga pemasok dan kontrak harus membuktikan satu hal: tim bisa memuat harga dengan aman, menemukan kontrak yang benar cepat, dan mempercayai jejak persetujuan serta audit.

Ruang lingkup MVP (must-haves)

Mulailah dengan workflow tipis end-to-end daripada banyak fitur terpisah:

• Dasar supplier + item master: pemasok, produk/layanan, unit, mata uang
• Impor daftar harga: satu atau dua template (CSV/XLSX), preview, pemetaan field (jika perlu), validasi, dan laporan error
• Rekam kontrak: syarat kunci (tanggal, tipe perpanjangan, pemilik), lampiran, dan penautan ke pemasok serta versi price list relevan
• Persetujuan: satu alur sederhana (Draft → Review → Approved/Rejected) dengan izin berbasis peran dan jejak audit
• Pencarian + pelaporan: pencarian global (pemasok, SKU, ID kontrak), dan satu ekspor “harga disetujui saat ini”

Jika ingin bergerak cepat dengan tim kecil, pertimbangkan menggunakan Koder.ai untuk menghasilkan kerangka awal produk (frontend React, backend Go, PostgreSQL) dan iterasi di "planning mode" bersama pemangku kepentingan procurement/legal. Validasi alur (impor → persetujuan → jejak audit → pengingat perpanjangan), lalu ekspor kode sumber saat siap menguatkan dan memperluas.

Rencana pengujian (apa yang rusak di kehidupan nyata)

Fokuskan pengujian pada area di mana kesalahan berbiaya tinggi:

• Tes validasi impor: kolom wajib hilang, mata uang/unit tidak valid, baris duplikat, overlap tanggal, harga negatif, desimal campur
• Tes izin: siapa yang bisa impor, setujui, edit setelah persetujuan, dan melihat lampiran sensitif
• Tes alur kerja: re-approval on edits, komentar penolakan wajib, entri audit dibuat untuk setiap perubahan status

Rollout dan deployment

Gunakan staging dengan salinan data mirip produksi (disanitasi). Wajibkan checklist: backup aktif, skrip migrasi terlatih, dan rencana rollback (migrasi DB versioned + revert deploy).

Tambahkan monitoring untuk kegagalan impor, query lambat pada pencarian, dan bottleneck persetujuan.

Iterasi setelah peluncuran

Jalankan loop umpan balik 2–4 minggu dengan procurement dan finance: kesalahan unggahan teratas, field kontrak yang hilang, dan layar yang lambat. Kandidat berikutnya: integrasi ERP, portal pemasok untuk unggahan, analitik penghematan dan kepatuhan.

Suggested internal reads: /pricing dan /blog.