Distribusi bahan bangunan terlihat sederhana dari luar: beli dari pabrik, jual ke toko material. Kenyataannya, satu transaksi bisa melibatkan surat jalan pabrik, armada sendiri atau ekspedisi sewaan, uang jalan supir, biaya palet, biaya bongkar, dan faktur pajak yang harus cocok dengan Coretax DJP.
Artikel ini membedah bagaimana Odoo Enterprise dipakai untuk menata semua itu di sebuah distributor bahan bangunan multi-cabang di wilayah Banten dan Jawa Barat. Fokusnya tiga hal: arsitektur ERP, modul yang dipakai, dan cara implementasinya dijalankan.
Profil Bisnis: Dari Satu Distributor Menjadi Grup Usaha
Perusahaan dalam studi kasus ini adalah distributor bahan bangunan yang melayani toko material, kontraktor, dan proyek. Produknya beragam: semen, hebel (bata ringan), asbes gelombang, papan, paku dan kawat, PVC, pipa dan fitting, sekrup dan baut, hingga ban truk. Operasinya tersebar di beberapa cabang komersial di Banten dan Jawa Barat, ditambah Head Office dan unit Logistik, dengan dua cabang baru yang sedang dibuka.
Pada pertengahan 2026, struktur organisasinya berubah. Sebuah perusahaan induk (Holding) dibentuk di atas perusahaan distribusi, dan sebuah anak usaha manufaktur baru ikut bernaung di bawahnya. Anak usaha ini berbeda karakter: ia memproduksi mortar/semen instan, berdiri sebagai satu entitas tanpa cabang, dan punya rekening bank serta fungsi keuangan sendiri.
Perubahan ini langsung menjadi kebutuhan sistem. Manajemen Holding harus bisa melihat seluruh grup sekaligus, sementara pengguna tertentu cukup melihat satu cabang saja.
Tantangan Bisnis yang Harus Dijawab ERP
Hampir semua kerumitan bisnis ini berasal dari satu fakta: barang yang sama bisa sampai ke pelanggan lewat jalur yang sangat berbeda. Berikut tantangan utamanya.
Area | Kondisi di lapangan |
|---|---|
Jenis penjualan | Barang Langsung (dropship dari pabrik), Barang Stok (dari gudang cabang), serta jasa trucking, bongkar, dan palet |
Pola pengiriman | Franco Distributor/Ekspedisi (wajib isi ongkir atau uang jalan supir), Franco Pabrik, Loco Customer, dan Loco Beli untuk pembelian |
Surat jalan | SJ pabrik, SJ manual untuk barang langsung, dan SJ untuk barang stok, lengkap dengan nomor kendaraan, ekspedisi, supir, palet, dan biaya bongkar |
Pajak | Transaksi PPN dan non-PPN berjalan berdampingan dan harus dilaporkan terpisah |
Harga & termin | Harga jual berbeda per pelanggan dan lokasi kirim; termin pembayaran bervariasi per jenis barang |
Pembelian | Satu tagihan pabrik bisa mencakup banyak surat jalan; pembayaran lewat deposit atau tempo |
Retur | Retur penjualan dan retur pembelian berjalan sendiri-sendiri; pabrik bisa menolak retur |
Satuan barang | Hebel dijual per kubik tetapi dihitung per pcs: 1 kubik hebel 10 cm = 83 pcs, hebel 7,5 cm = 111 pcs |
Logistik | Perawatan armada (servis, ban, oli) dan kas kecil logistik di tiap cabang |
Pertanyaan klien pun sangat praktis: bisakah laba rugi dilihat per cabang, apakah neraca bisa dipisah PPN dan non-PPN, dan bagaimana menghitung komisi sales yang terikat target serta pelunasan piutang.
Arsitektur ERP: Holding, Perusahaan, dan Cabang
Jawaban atas struktur grup ini adalah arsitektur multi-company di Odoo: Holding sebagai induk, perusahaan distribusi dan anak usaha manufaktur sebagai perusahaan anak, dan cabang distribusi dikelola dengan Branch Feature.
Setiap cabang distribusi punya gudangnya sendiri, sedangkan anak usaha manufaktur cukup satu gudang. Laba rugi per cabang diambil dari Branch Feature, bukan dari Analytic Account, sehingga laporan per cabang tetap rapi tanpa input tambahan dari pengguna.
Bagan akun memakai satu baseline bersama. Akun dengan kode yang sama otomatis dijumlahkan saat Holding melihat laporan konsolidasi, sementara akun khusus anak usaha manufaktur muncul sebagai baris tambahan. Staf akuntansi yang menangani kedua perusahaan cukup memakai satu user dengan akses ke keduanya.
Modul Odoo yang Dipakai
Implementasi memakai enam modul standar Odoo 19 Enterprise, lalu menutup celahnya dengan delapan modul kustom.
Modul | Peran dalam bisnis |
|---|---|
Sales | Sales Order, pricelist per pelanggan dan lokasi, termin pembayaran, pemisahan Barang Langsung dan Barang Stok |
Purchase | Pembelian barang stok dari HO, pembelian barang langsung dari cabang, serta pembelian non-dagang seperti ban, oli, dan sparepart |
Inventory | Gudang per cabang, dropship, konversi satuan hebel, retur, dan valuasi persediaan |
Accounting | Jurnal, kas logistik dan kas finance, e-Faktur Coretax, laporan per cabang dan konsolidasi |
Fleet | Biaya kepemilikan armada: servis rutin dan non-rutin, ban, oli, pajak kendaraan |
Manufacturing | Produksi mortar di anak usaha manufaktur: BoM, Quality Control, Shop Floor |
Modul kustom yang dikembangkan:
- Migrasi data dari sistem lama
- Ongkir dan biaya pengiriman berbasis Fleet
- Reimbursement
- Surat Jalan dengan data kendaraan, supir, ekspedisi, palet, dan bongkar
- Transfer antar cabang
- Laba rugi per cabang
- Pelaporan PPN dan non-PPN
- Komisi sales
Transfer antar cabang adalah contoh mengapa kustomisasi tidak terhindarkan. Alur standar berbasis PO antar perusahaan akan memunculkan utang dagang fiktif dan PPN Masukan yang tidak semestinya, sehingga perlu alur tersendiri.
Dropshipping: Menjual Barang yang Tidak Pernah Masuk Gudang
Salah satu jalur penjualan utama adalah Barang Langsung: pelanggan memesan ke cabang, cabang memesan ke pabrik, lalu pabrik mengirim langsung ke lokasi pelanggan. Di Odoo, alur ini dijalankan dengan rute Dropship sehingga satu Sales Order otomatis melahirkan Purchase Order ke pabrik.
[embed: node/531905d9-83e2]
Beberapa aturan membuat alur ini rapi di sisi akuntansi dan operasional:
- Nomor SJ pabrik sebagai benang merah. Nomor surat jalan pabrik dipakai sama di dokumen pembelian dan invoice penjualan, sehingga satu pengiriman bisa ditelusuri dari dua sisi.
- Pola pengiriman tercatat di Sales Order. Franco Pabrik dan Loco Customer tidak menimbulkan uang jalan, sedangkan Franco Distributor/Ekspedisi wajib diisi ongkir atau uang jalan supir.
- Margin dropship terlihat terpisah. Pendapatan dan HPP Barang Langsung masuk ke akun tersendiri, berbeda dari Barang Stok, dan jurnal baru terbentuk saat tagihan dan invoice dikonfirmasi.
- Satuan disesuaikan sebelum penerimaan. Untuk hebel yang dikirim bertahap, satuan di Sales Order dan Purchase Order dikoreksi dari kubik ke pcs sebelum penerimaan virtual divalidasi.
- Retur ditangani dua sisi. Retur ke pabrik tidak otomatis mengubah Sales Order, dan pabrik bisa menolaknya, jadi retur penjualan dan retur pembelian diproses sebagai transaksi terpisah.
Fleet: Armada Sendiri dan Biaya Logistik
Distributor ini mengirim dengan armada sendiri dan ekspedisi sewaan, sehingga biaya logistik harus dibagi dua: biaya memiliki kendaraan dan biaya setiap pengiriman. Keduanya dicatat di tempat yang berbeda agar tidak tercampur.
Jenis biaya | Contoh | Dicatat di |
|---|---|---|
Kepemilikan kendaraan | Servis rutin dan non-rutin, ganti ban, ganti oli, sparepart, pajak kendaraan | Modul Fleet, per kendaraan |
Per pengiriman | Uang jalan supir, sewa ekspedisi, palet, biaya bongkar | Field kustom di Sales Order dan surat jalan, ditandai Analytic Plan Cabang dan Pengiriman |
Realisasi kas | Pengeluaran uang jalan dan biaya lapangan | Jurnal Kas Logistik di tiap cabang |
Dengan pemisahan ini, manajemen bisa menjawab dua pertanyaan berbeda. Berapa biaya sebuah truk per bulan dijawab oleh Fleet, sedangkan berapa margin bersih sebuah Sales Order setelah ongkir dijawab oleh analytic Pengiriman.
Surat jalan juga menyimpan data operasional: nomor kendaraan, nama ekspedisi, nama supir, dan jumlah palet. Sparepart dan ban dibeli lewat Purchase sebagai barang non-dagang dan dinilai dengan FIFO, sehingga biaya per unit tetap bisa dilacak.
Kapasitas armada pun dijadikan referensi perencanaan muat. Untuk hebel, truk kecil (LT) memuat 6 sampai 8 palet atau sekitar 10,8 sampai 14,4 kubik, sementara tronton memuat 18 palet atau sekitar 48,6 kubik untuk hebel 7,5 cm.
Keputusan Desain Akuntansi dan Pajak
ERP yang baik ditentukan oleh keputusan desain di awal, bukan oleh banyaknya fitur. Ini keputusan kunci yang dikunci di proyek ini.
- Valuasi Perpetual at Invoicing. Jurnal persediaan baru terbentuk saat vendor bill atau invoice dikonfirmasi, bukan saat barang diterima atau dikirim. Ini cocok dengan pola dropship, di mana barang tidak pernah singgah di gudang.
- Metode biaya campuran. AVCO untuk bahan bangunan, FIFO untuk sparepart dan ban yang lebih mudah dilacak per unit.
- Pemisahan akun, bukan pemisahan CoA. Barang Langsung dan Barang Stok memakai akun pendapatan dan HPP yang berbeda dalam satu bagan akun yang sama, sehingga margin keduanya bisa dibandingkan.
- Pajak dipilih manual saat invoice. Pajak tidak menempel di produk atau Sales Order, karena barang yang sama bisa dijual dengan atau tanpa PPN.
- Laporan PPN/non-PPN lewat filter pajak. Tidak ada akun ganda dengan akhiran PPN atau NPPN; pemisahan dilakukan lewat filter pajak di laporan.
- Coretax DJP. Instance memakai modul e-Faktur Coretax versi baru. Kode satuan DJP diatur per satuan, termasuk Meter Kubik (UM.0034) untuk hebel.
- Biaya logistik lewat Analytic. Dua Analytic Plan, Cabang dan Pengiriman, mencatat biaya per Sales Order atau surat jalan, sementara Fleet hanya mencatat biaya kepemilikan kendaraan.
Satu catatan penting dari pengujian: di Odoo 19, retur pembelian tidak otomatis mengalir ke Sales Order terkait. Jika pabrik menolak retur, kerugian ditanggung distributor, dan skenario ini sengaja dijadikan kasus uji utama.
Pendekatan Implementasi
Implementasi berjalan dalam lima fase yang berurutan, masing-masing dengan keluaran yang jelas.
- Discovery dan analisis. Pemetaan proses penjualan, pembelian, logistik, dan pajak, lalu gap analysis terhadap fitur standar Odoo.
- Konfigurasi sistem. Struktur perusahaan dan cabang, gudang, bagan akun, jurnal, hak akses, serta satuan barang.
- Migrasi data. Pelanggan, pemasok, produk, saldo awal, dan stok dari sistem lama melalui impor Excel.
- Pelatihan dan UAT. Pengguna kunci menjalankan skenario bisnis nyata di sistem sebelum go-live.
- Go-live dan pendampingan. Peluncuran ke produksi dan masa hypercare.
Beberapa praktik membuat proyek ini lebih terkendali:
- Satu sumber kebenaran. Seluruh data konfigurasi dikelola dalam satu master workbook Excel berisi lebih dari 30 sheet, dari CoA sampai referensi kapasitas truk.
- UAT berbasis skenario. Dokumen uji berisi 19 skenario yang meniru alur bisnis nyata, termasuk dropship, retur ditolak pabrik, dan biaya logistik.
- UAT semi-otomatis. Langkah pengujian di browser dijalankan dengan bantuan AI agent yang menavigasi Odoo, mengambil screenshot, dan memperbarui status uji.
- Infrastruktur cloud. Sistem berjalan di Infinys Cloud dengan PostgreSQL sebagai basis data.
Pelajaran untuk Bisnis Distribusi Lain
Pengalaman di proyek ini menunjukkan bahwa ERP untuk distribusi bahan bangunan bukan soal memasang modul, tetapi soal memodelkan cara barang dan uang benar-benar bergerak.
- Rancang struktur perusahaan untuk masa depan. Holding dan anak usaha baru jauh lebih mudah ditambahkan jika arsitektur multi-company disiapkan sejak awal.
- Bedakan jalur barang di akuntansi. Dropship dan barang stok punya margin dan risiko yang berbeda; pisahkan di level akun, bukan di level sistem.
- Biaya logistik adalah biaya penjualan. Uang jalan, sewa ekspedisi, palet, dan bongkar harus tercatat per pengiriman agar margin per Sales Order terlihat jujur.
- Siapkan pajak dari hari pertama. Coretax, kode satuan DJP, dan pemisahan PPN/non-PPN sulit ditambal setelah go-live.
- Uji dengan skenario nyata. Kasus pinggiran seperti retur yang ditolak pabrik justru paling sering menimbulkan selisih.
Jika bisnis Anda punya pola serupa, seperti banyak cabang, dropship dari pabrik, dan armada sendiri, Odoo ERP dapat menjadi fondasi yang kuat. Tim InfinysCloud siap membantu memetakan kebutuhan Anda. Untuk lebih detil mengenai hal ini bisa email kami ke sales@isi.co.id