Salah satu klien saya, sebuah perusahaan rintisan yang baru beberapa bulan berjalan, meminta tambahan fitur di sistem WMS (Warehouse Management System) yang sedang saya kembangkan untuk mereka. Permintaannya sederhana: bisa membuat invoice langsung dari sales order, tanpa harus pindah ke aplikasi lain atau mengetik ulang data di Excel.

Yang menarik justru bukan permintaannya, tapi pertanyaan yang muncul setelahnya: apakah fitur invoice ini sebaiknya dibangun langsung di dalam sistem WMS, atau dipisah ke sistem tersendiri.

Kenapa Pertanyaan Ini Penting

Secara konsep, WMS dan invoice sebenarnya berada di domain yang berbeda. WMS mengurus operasional gudang, mulai dari stok, penerimaan barang masuk, sampai pengiriman. Invoice ada di ranah finance, terkait pencatatan tagihan, jatuh tempo, dan pada akhirnya masuk ke pembukuan.

Kalau bicara sistem enterprise yang sudah besar, biasanya dua hal ini memang dipisah. WMS fokus mengurus gudang, sementara invoice dan pembukuan diserahkan ke sistem akuntansi atau ERP yang terintegrasi lewat API. Tapi klien saya ini masih tahap rintisan, dan belum punya sistem akuntansi sendiri.

Keputusan: Invoice Tetap di WMS, tapi Dibuat Tipis

Kalau saya paksakan invoice dibuat di sistem terpisah sejak awal, klien harus mengelola dua sistem sekaligus, ditambah proses integrasi yang belum tentu mereka butuhkan di tahap ini. Jadi saya putuskan invoice tetap dibangun di dalam WMS, langsung terhubung dengan modul sales order yang sudah ada.

Begitu sales order dibuat, staf tinggal klik untuk melihat invoice-nya. Nomor invoice dibuat otomatis dengan format INV-YYYYMMDD-urutan, misalnya INV-20260822-001. Tanggal jatuh tempo juga dihitung otomatis, bukan diisi manual, jadi tidak ada lagi staf yang lupa atau salah hitung kapan pelanggan harus membayar.

Rincian barang ditampilkan per baris, lengkap dengan keterangan barang, harga per unit, kuantitas, dan total. Invoice bisa langsung dilihat pratinjaunya di dalam sistem, diunduh dalam bentuk PDF, atau langsung dicetak. Semua proses ini terjadi di satu tempat, tanpa perlu membuka aplikasi lain.

Yang saya jaga betul di sini adalah supaya modul invoice ini tetap tipis. Fungsinya hanya menghasilkan dan menampilkan invoice, tidak merambah ke perhitungan pajak, laporan keuangan, atau rekonsiliasi pembayaran. Bagian-bagian itu sengaja tidak disentuh, supaya kalau nanti klien sudah memakai sistem akuntansi sendiri, modul ini tinggal disambungkan lewat integrasi, bukan dibongkar ulang dari awal.

Kenapa Sales Order Tetap Menyatu dengan WMS

Berbeda dengan invoice, sales order memang sebaiknya tetap menyatu dengan WMS, bukan dipisah. Sales order adalah pemicu proses inti WMS itu sendiri, mulai dari reservasi stok, picking, packing, sampai update inventory setelah barang keluar. Kalau sales order dipisah ke sistem lain, WMS jadi tidak tahu kapan harus mengalokasikan stok, dan justru menambah kebutuhan sinkronisasi data yang tidak perlu.

Refleksi: Nilai Sistem Custom Bukan di Kelengkapan Fitur

Dari proyek ini saya belajar satu hal yang sering muncul saat membangun sistem untuk bisnis yang masih berkembang. Nilai dari sistem custom bukan soal selengkap apa fiturnya hari ini, tapi seberapa siap sistem itu menyesuaikan diri saat kebutuhan bisnis berubah. Keputusan arsitektur yang diambil sekarang, sekecil apa pun, akan menentukan seberapa mudah sistem itu tumbuh nanti.

Bagi bisnis yang masih di tahap awal, membangun semua fitur secara terpisah dari hari pertama justru sering jadi beban yang tidak perlu. Yang lebih penting adalah membangun apa yang benar-benar dibutuhkan sekarang, dengan batasan yang jelas, supaya nanti tidak sulit dipisah kalau kebutuhannya berubah.