Sebagai pemilik UMKM yang masih aktif menjalankan bisnis, saya cukup akrab dengan situasi ketika satu orang harus memegang banyak peran sekaligus. Pagi memikirkan pemasaran, siang menindaklanjuti calon pelanggan, sore menjawab chat, malam baru sempat melihat catatan transaksi dan pekerjaan administrasi yang tertunda.
Selama bisnis masih sederhana, pola seperti ini sering terasa cukup. Masalah biasanya baru terlihat ketika aktivitas mulai bertambah.
Stok dicatat di spreadsheet. Penjualan masuk dari aplikasi kasir atau marketplace. Data pelanggan tertinggal di WhatsApp. Pembelian dari supplier dicatat lagi di tempat lain. Masing-masing sebenarnya bekerja, tetapi informasinya tersebar. Ketika ingin melihat kondisi bisnis secara utuh, kita harus membuka beberapa aplikasi dan mencocokkan datanya satu per satu.
Saya pernah membicarakan masalah ini dengan seorang rekan sesama pelaku UMKM. Ia ingin merapikan operasional bisnisnya menggunakan sistem ERP, tetapi mulai ragu ketika melihat biaya dan kompleksitas beberapa solusi yang tersedia.
Ia kemudian bertanya kepada saya:
“Mas, ada nggak sistem ERP yang lebih murah, atau bahkan bisa kita mulai secara gratis untuk usaha seperti kita?”
Pertanyaan itu cukup lama tinggal di kepala saya.
Selama ini ERP sering terdengar seperti sesuatu yang dekat dengan perusahaan besar: sistem yang kompleks, banyak modul, implementasi panjang, dan membutuhkan anggaran yang tidak kecil. Padahal masalah yang ingin diselesaikan UMKM sering kali jauh lebih sederhana.
Kita hanya ingin stok lebih mudah dipantau. Penjualan tercatat di tempat yang sama. Data pelanggan tidak tercecer. Pembelian dari supplier bisa dilihat kembali. Dan ketika membutuhkan laporan, kita tidak harus memindahkan angka dari satu aplikasi ke aplikasi lainnya.
Dari situ pertanyaannya berubah.
Kalau semua data itu ingin kita hubungkan, apakah harus membeli ERP mahal atau memanggil programmer sejak awal?
Saya tidak langsung menemukan jawabannya.
Dalam bisnis sendiri, saya pernah mencoba berbagai tools, mengubah alur kerja, menemukan bagian yang ternyata terlalu rumit, lalu menyederhanakannya lagi. Ada yang terlihat bagus saat pertama dicoba tetapi tidak cocok digunakan setiap hari. Ada juga solusi sederhana yang justru bertahan karena lebih sesuai dengan cara bisnis berjalan.
Pengalaman itu membuat saya semakin yakin pada satu prinsip: sistem seharusnya mengikuti kebutuhan bisnis, bukan bisnis yang dipaksa mengikuti tools.
Baru setelah masalah dan alurnya cukup jelas, AI menjadi menarik.
Bukan karena AI bisa “membuat ERP dalam lima menit”, tetapi karena sekarang kita memiliki alat yang dapat membantu menyusun kebutuhan, merancang struktur data, membuat tampilan aplikasi, hingga membangun prototype tanpa harus memulai semuanya dari baris kode pertama.
Di artikel ini, saya akan mencoba pendekatan tersebut dari sudut pandang sesama pelaku UMKM. Kita akan melihat apa sebenarnya yang perlu ada dalam ERP sederhana, bagian mana yang bisa dibantu AI dan platform no-code, sampai di mana versi gratis masih masuk akal, serta kapan sebuah prototype sudah tidak cukup lagi untuk digunakan sebagai sistem bisnis.
Tujuannya bukan membangun ERP paling canggih.
Kita mulai dari sesuatu yang lebih realistis: membuat sistem yang cukup sederhana untuk dipahami, cukup terhubung untuk membantu operasional, dan tetap sesuai dengan skala bisnis kita.
Gratis Itu Sampai Mana?
Kata “gratis” perlu dibatasi sejak awal. Target kita adalah membuat prototype ERP UMKM tanpa biaya langganan awal, lalu menguji apakah struktur dan alurnya benar sebelum memutuskan perlu upgrade atau migrasi.
Untuk stack utama, saya menggunakan Softr sebagai lapisan aplikasi dan Airtable sebagai database. Batas Free Plan masing-masing platform tidak sama dan dapat berubah. Karena itu, saya tidak mengunci angka jumlah app user Softr di tutorial ini. Selalu cek paket yang berlaku ketika Anda membangun aplikasi.
Untuk Airtable, dokumentasi resminya saat artikel ini disusun menyebut Free Plan memiliki batas 1.000 records per base dan 1.000 API calls per workspace per bulan. Airtable juga menjelaskan bahwa workspace pertama pada akun baru otomatis memperoleh Team trial selama 14 hari sebelum pengguna memilih tetap di Free Plan atau upgrade. Detail terbaru dapat diperiksa di Airtable Plans Overview.
Jika saat mencoba tutorial Anda melihat fitur yang lebih lengkap dari Free Plan, cek apakah workspace masih berada dalam masa Team trial. Screenshot atau tampilan saat trial bukan bukti bahwa fitur tersebut tersedia permanen pada paket gratis.
Saat pengujian prototype, Airtable menampilkan Team trial 14 hari. Tampilan ini tidak saya gunakan sebagai bukti bahwa seluruh fitur yang terlihat tersedia permanen pada Free Plan.
Softr juga memiliki batas Free Plan sendiri. Angka untuk user, AI credits, database, workflow, dan fitur tertentu dapat berubah. Artinya, “gratis” di sini adalah ruang untuk menguji desain sistem dan alur kerja, bukan janji bahwa ERP akan gratis selamanya ketika data, pengguna, dan kebutuhan bisnis terus bertambah.
Kenapa Softr + Airtable?
Saya memilih kombinasi ini karena perannya mudah dipahami. Airtable menangani data dan relasi antar-record, sedangkan Softr membuat lapisan aplikasi agar owner atau karyawan tidak perlu bekerja langsung di tabel database setiap saat.
Softr saat ini menyediakan AI Co-Builder yang dapat membuat struktur aplikasi, database, halaman, permissions, dan workflow dari deskripsi bahasa biasa. Dokumentasi produknya juga menyebut Airtable sebagai salah satu sumber data yang dapat dihubungkan. Anda bisa melihat kemampuan dasarnya di Softr AI App Builder.
Yang penting, jangan memilih stack hanya karena terlihat mudah saat demo. Saya tetap memakai prinsip yang sama ketika memilih tools: mulai dari masalah, volume data, siapa yang akan memakai, risiko kesalahan, dan kemungkinan pindah platform nanti.
Apakah UMKM Memang Membutuhkan ERP?
Tidak semua UMKM membutuhkan ERP. Kalau transaksi masih sedikit, stok sederhana, dan hanya satu orang yang mengelola semua data, spreadsheet yang rapi bisa lebih efisien.
ERP mulai masuk akal ketika beberapa aktivitas saling bergantung. Pembelian harus menambah stok. Penjualan harus mengurangi stok. Retur perlu kembali ke transaksi asal. Biaya operasional perlu masuk periode yang benar. Owner membutuhkan ringkasan tanpa memberi seluruh data ke karyawan.
Jadi tujuan kita bukan “punya ERP”. Tujuannya adalah mengurangi titik putus antarproses. Ini juga yang membedakan artikel ini dari pembahasan saya tentang implementasi AI dari prompt menjadi sistem kerja. Di sini kita masuk ke aplikasi konkret: database, relasi, stok, transaksi, akses pengguna, finance layer, dan testing.
ERP Minimum yang Akan Kita Bangun
Alur utamanya seperti ini:
Supplier → Pembelian → Detail Pembelian → Produk/Stok → Detail Penjualan → Penjualan → Retur → Biaya Operasional → Aset/Penyusutan → Tax Settings → Dashboard Owner
Struktur tersebut tidak mencoba meniru ERP besar seperti Odoo. Kita membangun prototype yang cukup untuk menguji satu sumber data terintegrasi dan alur operasional dasar UMKM.
Kalau kebutuhan Anda saat ini hanya transaksi dan insight sederhana dari data kasir, arsitektur ini mungkin terlalu besar. Saya sudah membahas pendekatan yang lebih sempit pada artikel tentang aplikasi kasir.
Mulai dari Struktur Data, Bukan Tampilan
Sebelum membuat dashboard, siapkan tabel yang menjadi fondasi sistem:
- Products — SKU, nama produk, kategori, harga jual, HPP saat ini, opening stock, minimum stock, status aktif.
- Suppliers — data pemasok yang diperlukan untuk pembelian.
- Customers — data pelanggan jika memang relevan dengan proses bisnis.
- Purchases — header transaksi pembelian: tanggal, supplier, nomor transaksi, status, total.
- Purchase Items — detail produk, quantity, harga beli, dan subtotal per transaksi pembelian.
- Sales — header transaksi penjualan: tanggal, customer, status, diskon transaksi, ongkir, fee, total.
- Sales Items — detail produk, quantity, harga jual, diskon item, dan HPP Unit Snapshot.
- Returns — transaksi asal, produk, quantity, nilai refund, kondisi barang, dan status restock.
- Operating Expenses — gaji/upah, sewa, listrik, internet, iklan, packaging, software, transportasi, maintenance, dan biaya operasional lain.
- Assets — aset, harga perolehan, nilai residu, masa manfaat bulan, dan simulasi penyusutan.
- Tax Settings — parameter pajak, effective date, official source, last verified, dan status aktif.
- Users / Softr User Access — mapping pengguna dan role.
- Stock Adjustments — penyesuaian stok dengan alasan yang dapat ditelusuri.
- Reporting Periods / Dashboard Summary — opsional jika Anda membutuhkan periode pelaporan yang lebih terstruktur.
Kenapa Sales dan Sales Items Harus Dipisah?
Satu transaksi dapat berisi beberapa produk. Kalau header transaksi dan item dijadikan satu tabel, data seperti tanggal, customer, diskon transaksi, atau biaya pengiriman akan berulang untuk setiap produk.
Pola yang lebih aman adalah memisahkan Sales sebagai header dan Sales Items sebagai detail. Prinsip yang sama dipakai untuk Purchases dan Purchase Items.
Pemisahan ini juga penting untuk HPP. Simpan HPP Unit Snapshot pada Sales Items ketika transaksi selesai. Dengan begitu, margin transaksi lama tidak berubah hanya karena HPP produk diperbarui minggu berikutnya.
Isi Dummy Data Sebelum Menyentuh Data Bisnis Asli
Saya lebih memilih menguji ERP dengan data dummy terlebih dahulu. Buat beberapa produk, satu atau dua supplier, contoh customer, pembelian, penjualan, retur, dan biaya operasional.
Tujuannya bukan membuat database terlihat penuh. Tujuannya adalah menemukan masalah struktur ketika risikonya masih rendah. Misalnya: apakah satu Purchase dapat memiliki banyak Purchase Items? Apakah retur bisa kembali ke Sale dan produk asal? Apakah status Draft tidak ikut mengubah stok?
Data dummy juga membuat kita lebih bebas menghapus dan mengulang skenario tanpa menyentuh data pelanggan, nilai transaksi asli, atau dokumen sensitif.
Master Prompt untuk Membantu Membuat Prototype ERP
Prompt berikut saya susun untuk membantu AI memahami sistem yang ingin dibangun. Anda tidak perlu menerima seluruh hasilnya. Gunakan output AI sebagai draft struktur, lalu periksa tabel, field, relasi, formula, role, dan status transaksi satu per satu.
Kalau Anda belum terbiasa menyusun instruksi yang lengkap, artikel panduan prompt menjelaskan prinsip dasarnya.
Saya adalah pemilik UMKM yang ingin membuat prototype ERP minimum terintegrasi untuk operasional harian. Prioritas saya adalah struktur yang sederhana, mudah diperiksa, dan dapat diuji menggunakan dummy data sebelum memakai data bisnis asli.
TASK
Bantu saya merancang aplikasi ERP UMKM menggunakan Softr sebagai application layer dan Airtable sebagai database utama.
Jangan mulai dari tampilan. Mulai dari data model, relasi, status transaksi, inventory logic, finance logic, role pengguna, dan skenario testing.
DATA ARCHITECTURE
Buat struktur untuk:
1. Products
2. Suppliers
3. Customers
4. Purchases
5. Purchase Items
6. Sales
7. Sales Items
8. Returns
9. Operating Expenses
10. Assets
11. Tax Settings
12. Users / Softr User Access
13. Stock Adjustments
14. Reporting Periods / Dashboard Summary jika benar-benar diperlukan.
Pisahkan header transaksi dan detail transaksi.
Purchases terpisah dari Purchase Items.
Sales terpisah dari Sales Items.
Gunakan linked records agar relasi antar-record dapat ditelusuri.
INVENTORY LOGIC
Gunakan konsep:
Current Stock = Opening Stock
+ Stock In dari Purchase berstatus Received
+ Retur Layak Jual
+ Stock Adjustment
- Stock Out dari Sale berstatus Completed.
Aturan status:
- Purchase Draft tidak menambah stok.
- Purchase Ordered tidak menambah stok sebelum barang diterima.
- Purchase Received menambah stok.
- Purchase Cancelled tidak menambah stok.
- Sale Draft tidak mengurangi stok.
- Sale Completed mengurangi stok.
- Sale Cancelled tidak boleh meninggalkan pengurangan stok.
- Retur Layak Jual dapat menambah stok kembali setelah retur disetujui.
- Retur Rusak dapat mencatat refund tetapi tidak menambah stok tersedia.
SALES & FINANCE LOGIC
Pisahkan Sales dan Sales Items.
Pada Sales Items, simpan HPP Unit Snapshot ketika transaksi selesai agar histori margin transaksi lama tidak berubah ketika HPP produk diperbarui.
Gunakan formula konsep:
Gross Line Sales = Qty × Unit Price
Net Line Sales = Gross Line Sales - Item Discount
HPP Line = Qty × HPP Unit Snapshot
Gross Margin Line = Net Line Sales - HPP Line
Pada level laporan gunakan struktur:
Penjualan Kotor
- Diskon Item
- Diskon Transaksi
- Retur
= Penjualan Bersih
Penjualan Bersih
- HPP
= Laba Kotor
Laba Kotor
- Ongkir yang ditanggung bisnis
- Marketplace/payment fee
- Biaya operasional
- Penyusutan simulasi
= Estimasi Laba Operasional
Gunakan istilah Estimasi Laba Operasional.
Jangan menyebut hasil tersebut sebagai laba bersih final atau laporan akuntansi resmi.
Operating Expenses dapat mencakup contoh seperti:
- gaji/upah;
- sewa;
- listrik;
- internet;
- iklan;
- packaging;
- software;
- transportasi;
- maintenance;
- biaya operasional lain yang relevan dengan bisnis.
RETURNS
Setiap retur harus terhubung ke transaksi dan produk asal.
Pisahkan kondisi retur:
1. Layak Jual
Barang dapat menambah stok kembali setelah retur disetujui.
2. Rusak
Refund dapat dicatat, tetapi barang tidak menambah stok tersedia.
Simpan minimal:
- transaksi asal;
- produk;
- quantity;
- nilai refund;
- kondisi barang;
- status retur;
- keputusan restock.
STOCK ADJUSTMENTS
Gunakan Stock Adjustments untuk koreksi yang bukan berasal dari transaksi pembelian, penjualan, atau retur biasa.
Simpan minimal:
- produk;
- quantity perubahan;
- arah penyesuaian;
- alasan;
- tanggal;
- pengguna yang melakukan penyesuaian.
Jangan mengubah Current Stock secara manual tanpa jejak penyesuaian.
ASSETS & DEPRECIATION
Untuk simulasi manajerial gunakan:
Penyusutan Bulanan = (Harga Perolehan - Nilai Residu) ÷ Masa Manfaat Bulan.
Tandai dengan jelas bahwa perhitungan tersebut adalah simulasi manajerial, BUKAN penyusutan fiskal.
USER ACCESS / RBAC
Buat minimal dua role:
Owner
- dashboard;
- finance;
- assets;
- tax settings;
- seluruh transaksi;
- monitoring sistem.
Karyawan
- hanya halaman operasional yang diperlukan;
- tidak melihat finance yang tidak dibutuhkan;
- tidak melihat tax settings yang tidak dibutuhkan;
- tidak dapat mengubah konfigurasi sensitif tanpa izin.
Hindari delete bebas pada transaksi final.
Gunakan status seperti Cancelled agar audit trail tetap dapat ditelusuri.
TAX ARCHITECTURE & BOUNDARIES
Buat Tax Settings sebagai tempat terpusat untuk menyimpan parameter pajak.
Setiap rule pajak minimal memiliki:
- nama parameter;
- nilai atau formula;
- effective date;
- official source;
- last verified;
- status aktif;
- catatan jika diperlukan.
Jangan hardcode aturan pajak yang sama di banyak formula.
Jangan menyamakan Penjualan Bersih pada dashboard manajerial dengan dasar omzet pajak secara otomatis.
Pisahkan PPN Keluaran dari omzet.
Sebelum menggunakan aturan PPN, periksa status PKP dan jenis transaksi yang berlaku.
Jangan menggeneralisasi satu formula PPN untuk semua transaksi.
Untuk PPh Final UMKM, jangan otomatis menerapkan fasilitas atau threshold yang berlaku untuk Wajib Pajak Orang Pribadi kepada bentuk Wajib Pajak lain.
Jika diperlukan field untuk PPh yang dipungut marketplace, simpan terpisah dari penjualan dan sertakan effective date aturan yang berlaku.
Jika status PKP, aturan, effective date, jenis Wajib Pajak, dasar pengenaan, atau sumber resmi belum tersedia, tulis:
PERLU VERIFIKASI
Jangan mengarang nilai.
AI tidak boleh menentukan kewajiban pajak final.
ERP hanya membantu monitoring dan bukan pengganti Coretax, pelaporan resmi, pemeriksaan dokumen, konsultan pajak, atau profesional lain ketika keputusan membutuhkan penilaian khusus.
DASHBOARD OWNER
Buat dashboard yang tetap berguna pada jalur free-tier tanpa mewajibkan native chart berbayar.
Prioritaskan KPI, summary, list, table, dan filter.
Ringkasan yang dapat digunakan antara lain:
- Penjualan Kotor;
- Penjualan Bersih;
- HPP;
- Laba Kotor;
- Operating Expenses;
- ongkir yang ditanggung bisnis;
- marketplace/payment fee;
- penyusutan simulasi;
- Estimasi Laba Operasional;
- produk dengan stok di bawah minimum;
- transaksi yang belum selesai.
Jangan menjadikan chart sebagai requirement jika paket yang digunakan tidak mendukungnya.
TESTING
Gunakan dummy data terlebih dahulu.
Jalankan minimum end-to-end tests berikut:
1. Purchase Received → stok bertambah.
2. Purchase Draft → stok tidak berubah.
3. Sale Completed → stok berkurang.
4. Sale Draft → stok tidak berkurang.
5. Sale Cancelled → tidak meninggalkan pengurangan stok.
6. Return Layak Jual → stok kembali.
7. Return Rusak → refund dapat tercatat tanpa restock.
8. Diskon → Penjualan Bersih turun sesuai formula.
9. Ongkir yang ditanggung bisnis → Estimasi Laba Operasional turun.
10. Operating Expense → ringkasan periode berubah sesuai data.
11. HPP Unit Snapshot → histori margin lama tidak berubah ketika HPP produk diperbarui.
12. Owner dan Karyawan → akses sesuai role.
13. Tax rule kosong atau belum terverifikasi → tampilkan PERLU VERIFIKASI.
14. Hitungan margin transaksi contoh dapat direkonsiliasi secara manual.
Jika satu pengujian gagal, identifikasi penyebabnya sebelum melanjutkan ke tahap berikutnya.
BOUNDARIES
- Jangan mengarang data bisnis.
- Jangan mengarang harga.
- Jangan mengarang jumlah stok.
- Jangan mengarang tarif atau kewajiban pajak.
- Jangan mengarang status PKP.
- Jangan mengarang kebijakan platform.
- Jangan mengarang hasil pengujian.
- Jangan menganggap seluruh fitur yang terlihat saat trial tersedia permanen pada Free Plan.
- Jangan membuat chart sebagai requirement jika paket gratis tidak mendukungnya.
- Jangan otomatis menghapus transaksi final.
- Jangan memakai data pelanggan asli pada tahap awal testing.
- Jangan membuat keputusan sensitif secara otomatis.
- Jika informasi kurang atau belum terverifikasi, tulis PERLU VERIFIKASI.
- Semua keputusan sensitif tetap diperiksa manusia.
OUTPUT
Berikan hasil dalam urutan berikut:
1. Ringkasan arsitektur ERP minimum.
2. Data model dan relasi antartabel.
3. Field penting setiap tabel.
4. Status transaksi dan efek setiap status terhadap stok.
5. Formula, lookup, dan rollup yang diperlukan.
6. Struktur halaman Softr.
7. Forms dan detail pages yang diperlukan.
8. Role dan permission Owner/Karyawan.
9. Dashboard Owner versi free-tier tanpa mewajibkan chart.
10. Daftar skenario dummy-data testing.
11. Daftar risiko dan asumsi.
12. Daftar item PERLU VERIFIKASI.
13. Langkah implementasi bertahap, dimulai dari bagian paling sederhana dan paling penting untuk operasional.
Pada setiap tahap, jelaskan apa yang perlu saya periksa secara manual sebelum melanjutkan ke tahap berikutnya.
Generate Struktur Awal di Softr, Lalu Periksa Hasilnya
Di Softr, Anda bisa memulai dari AI Co-Builder dan menjelaskan aplikasi yang ingin dibuat. Fokuskan instruksi pada proses: inventory, purchase, sales, returns, expenses, assets, users, dan dashboard owner.
Saya kemudian menguji Master Prompt ini melalui ChatGPT Work yang terhubung ke tools yang saya gunakan. Pada tahap awal, saya sengaja membatasi proses pada struktur database dan dummy data terlebih dahulu. Logika stok, pajak, serta keputusan sensitif tetap harus diperiksa manusia.
Pengujian Master Prompt melalui ChatGPT Work sebelum pembuatan prototype ERP. Build awal dibatasi pada struktur dan dummy data.
Dalam pengujian prototype ini, saya tidak menganggap hasil generator sebagai struktur final. AI dapat mempercepat pembuatan halaman atau tabel awal, tetapi relasi, status transaksi, akses pengguna, dan formula tetap perlu diperiksa manual. Pada tahap ini saya justru mencari kesalahan secepat mungkin sebelum data asli dimasukkan.
Kalau hasilnya terlalu kompleks, sederhanakan. ERP minimum lebih berguna ketika orang yang menjalankan usaha memahami alasan setiap tabel dan setiap status.
Bangun Database Airtable dan Hubungkan Record yang Berkaitan
Di Airtable, buat tabel inti lalu hubungkan record yang memiliki hubungan nyata. Contohnya, satu Purchase terhubung ke satu Supplier dan banyak Purchase Items. Setiap Purchase Item terhubung ke satu Product. Pola serupa berlaku pada Sales dan Sales Items.
Prototype ERP setelah proses build: tabel inti sudah terbentuk dan kemudian saya review kembali sebelum digunakan.
Airtable mendukung linked records antartabel, sehingga relasi bisa ditelusuri tanpa menyalin data yang sama ke banyak tempat. Dokumentasi resminya menjelaskan cara kerja linked records.
Setelah relasi dibuat, gunakan lookup atau rollup hanya untuk nilai yang memang perlu dirangkum. Jangan membuat puluhan formula sebelum alur dasarnya lolos testing.
Stok Harus Mengikuti Status Transaksi
Salah satu sumber kesalahan paling berbahaya adalah menganggap setiap baris pembelian otomatis menambah stok dan setiap baris penjualan otomatis menguranginya. Transaksi bisa masih Draft, batal, belum diterima, atau baru dibuat untuk penawaran.
Logika stok yang kita pakai:
Current Stock = Opening Stock + Stock In dari Purchase Received + Retur Layak Jual + Stock Adjustment - Stock Out dari Sale Completed.
- Purchase Draft → stok tidak berubah.
- Purchase Ordered → stok tidak berubah sampai barang benar-benar diterima.
- Purchase Received → stok bertambah.
- Purchase Cancelled → stok tidak bertambah.
- Sale Draft → stok tidak berkurang.
- Sale Completed → stok berkurang.
- Sale Cancelled → tidak boleh meninggalkan pengurangan stok.
Nama status boleh disesuaikan dengan bisnis Anda, tetapi efeknya harus eksplisit. Status bukan sekadar label tampilan; status menentukan apakah transaksi memengaruhi stok dan laporan.
Retur dan Stock Adjustment Tidak Boleh Dicampur
Retur memiliki transaksi asal. Stock Adjustment biasanya muncul karena koreksi stok fisik, selisih opname, barang rusak yang ditemukan kemudian, atau sebab lain yang perlu dicatat.
Untuk retur, simpan minimal transaksi asal, produk, quantity, nilai refund, kondisi barang, dan keputusan restock.
- Layak Jual → barang dapat masuk kembali ke stok setelah retur disetujui.
- Rusak → refund dapat tetap tercatat, tetapi barang tidak menambah stok tersedia.
Untuk Stock Adjustments, simpan quantity perubahan, arah penyesuaian, alasan, tanggal, dan pengguna yang melakukan perubahan. Hindari mengubah angka Current Stock secara manual tanpa jejak.
Uji Logika dengan Dummy Data Sebelum Membuat Dashboard
Setelah tabel dan relasi selesai, jangan langsung mempercantik aplikasi. Jalankan skenario sederhana dan cek hasilnya satu per satu.
- Buat satu produk dengan opening stock.
- Buat Purchase berstatus Draft. Pastikan stok tidak berubah.
- Ubah transaksi yang sama menjadi Received. Pastikan stok bertambah sesuai Purchase Items.
- Buat Sale Draft. Pastikan stok belum berkurang.
- Ubah menjadi Completed. Pastikan stok berkurang.
- Buat retur layak jual. Pastikan stok kembali.
- Buat retur rusak. Pastikan refund tercatat tetapi stok tidak bertambah.
- Buat Stock Adjustment dan pastikan alasan tercatat.
Kalau satu skenario gagal, berhenti di sana. Jangan menutupi masalah formula dengan dashboard yang terlihat rapi.
Tambahkan Finance Layer Setelah Transaksi Dasar Stabil
Setelah stok dan transaksi lolos pengujian, baru masuk ke finance layer. Tujuannya bukan menggantikan sistem akuntansi, melainkan memberi owner ringkasan operasional yang konsisten.
Pada Sales Items:
- Gross Line Sales = Qty × Unit Price
- Net Line Sales = Gross Line Sales - Item Discount
- HPP Line = Qty × HPP Unit Snapshot
- Gross Margin Line = Net Line Sales - HPP Line
Pada level periode:
Penjualan Kotor - Diskon Item - Diskon Transaksi - Retur = Penjualan Bersih
Penjualan Bersih - HPP = Laba Kotor
Laba Kotor - Ongkir yang Ditanggung Bisnis - Marketplace/Payment Fee - Biaya Operasional - Penyusutan Simulasi = Estimasi Laba Operasional
Saya sengaja menggunakan istilah Estimasi Laba Operasional. Angka ini adalah alat monitoring manajerial dari data yang kita masukkan, bukan klaim laba bersih final atau laporan keuangan resmi.
Operating Expenses
Masukkan biaya yang memang ingin dipantau per periode, misalnya gaji/upah, sewa, listrik, internet, iklan, packaging, software, transportasi, dan maintenance. Kategorinya bisa berbeda untuk setiap usaha.
Aset dan Penyusutan
Untuk simulasi manajerial sederhana, gunakan:
Penyusutan Bulanan = (Harga Perolehan - Nilai Residu) ÷ Masa Manfaat Bulan.
Jangan menyebut hasil ini sebagai penyusutan fiskal. Perlakuan fiskal mengikuti ketentuan perpajakan dan kondisi wajib pajak yang relevan.
Tax Settings: Simpan Aturan sebagai Parameter, Bukan Angka Tersebar
Pajak adalah area yang mudah membuat prototype menjadi berbahaya kalau angka di-hardcode tanpa konteks. Karena itu saya membuat tabel Tax Settings yang menyimpan parameter, effective date, official source, last verified, dan status aktif.
Periksa status PKP lebih dahulu. Untuk transaksi tertentu nonbarang mewah yang mengikuti PMK 131 Tahun 2024, PPN dihitung dengan tarif 12% menggunakan DPP nilai lain sebesar 11/12 dari nilai impor, harga jual, atau penggantian. Mekanisme itu menghasilkan beban efektif 11% pada transaksi yang memang masuk ketentuan tersebut, tetapi tidak boleh digeneralisasi ke seluruh transaksi. Rujukan resminya tersedia di JDIH Kementerian Keuangan — PMK 131/2024.
PPN Keluaran juga sebaiknya dipisahkan dari omzet manajerial. Jangan memasukkan pajak keluaran sebagai penjualan hanya karena nilainya ikut diterima dari pelanggan.
Untuk PPh Final UMKM, PP 20 Tahun 2026 mempertahankan tarif 0,5% untuk wajib pajak tertentu yang memenuhi syarat dan batas peredaran bruto yang berlaku. Fasilitas bagian omzet sampai Rp500 juta setahun yang tidak dikenai PPh Final berlaku untuk Wajib Pajak Orang Pribadi yang memenuhi ketentuan; jangan otomatis menerapkannya ke bentuk wajib pajak lain. Sumber primer dapat diperiksa di JDIH Kementerian Keuangan — PP 20/2026 dan penjelasan DJP tentang PPh Final UMKM 0,5%.
Dasar omzet pajak juga tidak boleh otomatis disamakan dengan kolom “Penjualan Bersih” pada dashboard manajerial. Definisi dan perlakuannya harus mengikuti aturan pajak yang relevan.
Untuk penjualan melalui marketplace, simpan field pemotongan atau pemungutan secara terpisah jika mekanisme tersebut berlaku pada transaksi Anda. Pada saat artikel ini disusun, DJP mengumumkan bahwa pemberlakuan pemungutan PPh Pasal 22 oleh marketplace berdasarkan PMK 37/2025 ditunda sampai 31 Oktober 2026 dan mulai berlaku pada 1 November 2026. Karena itu, effective date dan last verified penting disimpan di Tax Settings. Lihat pengumuman resmi DJP.
ERP ini hanya membantu monitoring. Ia bukan pengganti Coretax, pelaporan resmi, pemeriksaan dokumen, konsultan pajak, atau profesional lain ketika keputusan membutuhkan penilaian khusus.
Hubungkan Softr ke Airtable Setelah Struktur Data Stabil
Ketika base sudah cukup stabil, hubungkan Airtable ke Softr dan bangun halaman berdasarkan kebutuhan pengguna, bukan berdasarkan jumlah tabel.
- Hubungkan sumber data Airtable ke aplikasi Softr.
- Buat halaman operasional untuk transaksi yang benar-benar dipakai.
- Map field dari Airtable ke list, table, detail, dan form yang relevan.
- Uji create/edit record dari Softr menggunakan dummy data.
- Periksa apakah perubahan status menghasilkan efek yang benar di database.
- Baru setelah itu tambahkan ringkasan untuk owner.
Pada Airtable Free Plan, batas API workspace dapat menjadi salah satu titik yang perlu dipantau ketika aplikasi mulai sering membaca atau menulis data. Jangan menunggu sampai sistem dipakai banyak orang untuk memikirkan kapasitas.
Role-Based Access: Owner dan Karyawan Tidak Perlu Melihat Hal yang Sama
Minimal saya membagi akses menjadi dua.
Owner
- Dashboard.
- Finance layer.
- Assets.
- Tax Settings.
- Seluruh transaksi dan monitoring.
Karyawan
- Halaman operasional yang diperlukan untuk pekerjaannya.
- Tidak melihat data finance atau tax yang tidak dibutuhkan.
- Tidak mendapat hak mengubah konfigurasi sistem tanpa alasan.
Softr menyediakan user groups dan visibility/permission sebagai bagian dari pengaturan aplikasi. Namun konfigurasi final harus diuji dengan akun berbeda. Jangan menganggap halaman aman hanya karena menu tidak terlihat.
Untuk transaksi final, saya juga menghindari tombol delete bebas. Lebih aman menggunakan status seperti Cancelled sehingga jejak transaksi masih dapat ditelusuri ketika terjadi selisih.
Forms dan Detail Pages Harus Mengikuti Tugas Pengguna
Karyawan gudang tidak perlu melihat seluruh finance layer hanya untuk menerima barang. Admin penjualan tidak perlu membuka Tax Settings hanya untuk membuat transaksi. Karena itu, form sebaiknya dibuat sesingkat mungkin sesuai tugas.
Contohnya:
- Form Purchase: supplier, tanggal, status, dan detail item.
- Form Sale: customer jika diperlukan, tanggal, item, quantity, harga, diskon, dan status.
- Form Return: transaksi asal, item, quantity, kondisi, refund, keputusan restock.
- Form Expense: tanggal, kategori, deskripsi, nominal, periode.
- Form Stock Adjustment: produk, quantity perubahan, alasan, tanggal, pengguna.
Detail page kemudian dipakai untuk melihat hubungan antar-record: satu pembelian beserta itemnya, satu penjualan beserta detail dan retur terkait, atau satu produk beserta pergerakan stoknya.
End-to-End Test yang Wajib Lolos
Sebelum menyebut prototype “siap dipakai”, jalankan pengujian dari awal sampai akhir. Minimum test yang saya gunakan:
- Purchase Received → stok bertambah.
- Purchase Draft → stok tidak berubah.
- Sale Completed → stok berkurang.
- Sale Draft/Cancelled → tidak mengurangi stok.
- Return layak jual → stok kembali.
- Return rusak → refund dapat tercatat tanpa restock.
- Diskon → Penjualan Bersih turun sesuai logika.
- Ongkir yang ditanggung bisnis → Estimasi Laba Operasional turun.
- Operating Expense → periode dashboard ikut berubah.
- HPP Unit Snapshot → histori margin lama tidak berubah ketika HPP produk diperbarui.
- Owner/Karyawan → akses sesuai role.
- Tax rule kosong → sistem menandai PERLU VERIFIKASI, bukan mengarang angka.
Setelah itu, ambil satu atau dua transaksi contoh dan rekonsiliasi hitungan margin secara manual. Kalau hasil manual dan sistem berbeda, periksa formula sebelum menambah fitur.
Dashboard Free-Tier: Prioritaskan Angka yang Membantu Keputusan
Dashboard tidak harus penuh grafik. Untuk jalur gratis, saya lebih memilih KPI sederhana, summary, list, table, dan filter yang membantu owner melihat kondisi usaha.
Ringkasan yang relevan antara lain:
- Penjualan Kotor periode berjalan.
- Penjualan Bersih.
- HPP.
- Laba Kotor.
- Operating Expenses.
- Ongkir dan marketplace/payment fee yang ditanggung bisnis.
- Penyusutan simulasi.
- Estimasi Laba Operasional.
- Produk dengan stok di bawah minimum.
- Transaksi yang belum selesai.
Saya tidak menjadikan chart sebagai requirement. Dokumentasi Softr saat ini menunjukkan beberapa chart native, seperti Pie Chart dan Scatter Chart, berada pada Professional plan dan di atasnya. Jadi prototype gratis tetap harus berguna tanpa bergantung pada visualisasi berbayar. Contohnya dapat dicek di dokumentasi Pie Chart Softr.
Gunakan Reporting Periods agar Ringkasan Tidak Membingungkan
Dashboard akan sulit dibaca kalau setiap angka memakai periode berbeda. Minimal tentukan start date dan end date untuk laporan bulanan atau periode lain yang memang digunakan bisnis.
Jika filter bawaan sudah cukup, Anda tidak harus membuat tabel Reporting Periods. Tambahkan tabel ini hanya kalau sistem membutuhkan periode yang konsisten untuk banyak ringkasan, closing internal, atau perbandingan antarperiode.
Video Pendamping: Melihat Pola Inventory Softr + Airtable
Untuk melihat contoh alur visual Softr + Airtable, video resmi Softr berikut membahas pembuatan inventory management system, struktur aplikasi, koneksi Airtable, dan role-based permissions. Gunakan sebagai referensi tampilan dan workflow, bukan sebagai pengganti desain data yang sudah kita tetapkan.
Kapan Prototype Gratis Mulai Tidak Cukup?
Upgrade bukan tanda gagal. Justru prototype berguna kalau membantu kita mengetahui batas sistem sebelum mengeluarkan biaya lebih besar.
Mulai evaluasi upgrade atau migrasi ketika:
- jumlah records mendekati batas Airtable;
- API calls tidak lagi cukup untuk pola penggunaan;
- jumlah pengguna atau kebutuhan permission bertambah;
- workflow membutuhkan otomasi dan audit trail yang lebih kuat;
- owner membutuhkan reporting yang lebih kompleks;
- data sudah cukup penting sehingga backup, keamanan, dan kontrol perubahan membutuhkan standar yang lebih tinggi;
- proses akuntansi, pajak, manufaktur, multi-gudang, atau operasional lain sudah melampaui tujuan prototype.
Pada tahap itu Anda dapat mempertimbangkan upgrade plan, memindahkan backend ke Supabase ketika Airtable mulai sempit, atau mengevaluasi alternatif seperti NocoDB/Baserow sesuai kebutuhan. Untuk bisnis yang sudah membutuhkan modul ERP matang, audit, kontrol internal, atau integrasi lebih kompleks, solusi seperti Odoo atau sistem lain yang memang dirancang sebagai ERP penuh perlu dievaluasi terpisah.
Migrasi Lebih Mudah Kalau Struktur Awalnya Tidak Berantakan
Alasan saya memisahkan tabel, menyimpan relasi, menggunakan status, dan menghindari hardcode bukan supaya prototype terlihat teknis. Struktur yang rapi membuat data lebih mudah dipindahkan ketika tools berubah.
Kalau suatu hari Airtable tidak lagi cukup, Products, Sales, Sales Items, Purchases, Purchase Items, Returns, Expenses, Assets, dan Users sudah mempunyai fungsi yang jelas. Anda tidak mulai migrasi dari satu spreadsheet besar yang mencampur semua hal.
AI dapat membantu membuat draft schema atau mapping migrasi, tetapi keputusan seperti field mana yang menjadi source of truth, data mana yang harus dipertahankan, dan siapa yang boleh mengaksesnya tetap perlu diperiksa manusia.
Sistem yang Sederhana Lebih Berguna daripada ERP yang Terlihat Canggih
Setelah mencoba membangun prototype seperti ini, saya justru semakin yakin bahwa bagian tersulit bukan meminta AI membuat aplikasi. Bagian tersulit adalah menentukan kapan stok berubah, data mana yang menjadi sumber utama, bagaimana retur diperlakukan, siapa yang boleh melihat angka tertentu, dan apakah hasil akhirnya bisa direkonsiliasi dengan kejadian bisnis nyata.
Di situlah AI paling berguna untuk UMKM: mempercepat pekerjaan yang sudah kita pahami, membantu menyusun struktur, dan memberi titik awal. Tetapi sistem tetap harus mengikuti proses bisnis, dan manusia tetap memegang keputusan ketika menyangkut transaksi, akses, data sensitif, serta pajak.
Kalau Anda ingin mencoba membangun ERP sederhana seperti ini, sebutkan jenis usaha Anda dan bagian operasional yang paling merepotkan di kolom komentar. Dari situ biasanya lebih mudah menentukan modul mana yang layak dibangun lebih dulu, tanpa membuat sistem terlalu besar sejak awal.
FAQ
Apakah benar UMKM bisa membuat ERP gratis dengan AI?
Bisa untuk tahap prototype, selama kebutuhan masih sesuai batas Free Plan tools yang digunakan. “Gratis” bukan berarti sistem akan gratis selamanya ketika records, pengguna, API usage, workflow, atau kebutuhan bisnis bertambah.
Apakah saya harus bisa coding untuk mengikuti tutorial ini?
Tidak. Softr dan Airtable dapat digunakan dengan pendekatan no-code. Namun Anda tetap perlu memahami alur bisnis, relasi data, status transaksi, akses pengguna, dan cara menguji hasilnya.
Mengapa tutorial ini menggunakan Softr + Airtable?
Airtable dipakai sebagai database yang mudah diperiksa, sedangkan Softr menjadi lapisan aplikasi untuk form, list, detail page, dashboard, dan akses pengguna. Kombinasi ini cocok untuk menguji ERP minimum sebelum memutuskan stack yang lebih besar.
Apakah ERP sederhana ini bisa dipakai untuk stok dan penjualan?
Bisa sebagai prototype operasional jika inventory logic diuji dengan benar. Stok harus mengikuti status transaksi, sehingga Purchase Draft atau Sale Draft tidak mengubah stok sebelum kondisi yang ditentukan terpenuhi.
Apakah sistem ini bisa menghitung pajak otomatis?
Sistem dapat membantu monitoring parameter dan perhitungan yang sudah diverifikasi, tetapi tidak boleh menentukan kewajiban pajak sendiri. Status PKP, dasar pengenaan, effective date, jenis wajib pajak, dan sumber resmi tetap perlu diperiksa.
Apakah prototype ini pengganti Odoo atau ERP profesional?
Tidak. Yang dibangun di sini adalah ERP minimum terintegrasi untuk menguji alur data dan operasional UMKM. Bisnis dengan kebutuhan akuntansi, manufaktur, multi-gudang, audit, compliance, atau integrasi kompleks perlu mengevaluasi ERP yang lebih matang.
Kapan sebaiknya upgrade atau migrasi dari stack gratis?
Evaluasi upgrade atau migrasi ketika records, API calls, pengguna, permissions, workflow, reporting, keamanan, atau kebutuhan audit mulai melampaui batas prototype. Jangan menunggu operasional terganggu baru menyiapkan jalur migrasi.
Bagaimana membatasi akses karyawan ke data sensitif?
Gunakan role dan permission. Owner dapat mengakses dashboard, finance, assets, tax settings, dan monitoring lengkap, sedangkan karyawan hanya mendapat halaman operasional yang diperlukan. Uji dengan akun berbeda untuk memastikan pembatasan benar-benar bekerja.
Apakah sebaiknya langsung memakai data bisnis asli saat testing?
Tidak. Mulai dengan dummy data untuk menguji relasi, formula, status, retur, stok, permission, dan laporan. Masukkan data asli setelah skenario end-to-end lolos dan struktur sudah cukup stabil.
Sumber & Referensi
- Softr — AI App Builder
- Softr — How to Build an App for Free Without Coding in 2026
- Airtable — Plans Overview
- Airtable — Linking Records
- Softr Help Docs — Pie Chart
- JDIH Kementerian Keuangan — PMK 131 Tahun 2024
- JDIH Kementerian Keuangan — PP 20 Tahun 2026
- Direktorat Jenderal Pajak — PPh Final 0,5% bagi UMKM Orang Pribadi
- Direktorat Jenderal Pajak — Penundaan PPh Pasal 22 Marketplace
- Softr — Inventory Management System with Softr + Airtable