Integrasi WMS dengan ERP, Akuntansi, dan Marketplace

untuk Sinkronisasi Expiry Date

 

WMS yang bagus tetapi terisolasi menciptakan masalah baru: data stok dikelola di satu tempat, pesanan masuk di tempat lain, dan angka keuangan di tempat ketiga. Tim akhirnya menyalin data manual, dan selisih muncul. Untuk barang berumur simpan, risikonya lebih besar karena yang disinkronkan bukan hanya jumlah, tetapi juga batch dan tanggal kedaluwarsa. 

Artikel ini membahas apa yang perlu diintegrasikan, bagaimana data expiry mengalir antar sistem, dan jebakan yang perlu dihindari. Ini bagian dari panduan lengkap manajemen expiry date. 

 

Peta Sistem di Sekitar WMS 

Gudang modern jarang berdiri sendiri. Sistem yang umumnya terhubung: 

  • ERP / sistem akuntansi: master produk, pembelian, penjualan, persediaan, dan keuangan. 
  • OMS (Order Management System): pengelolaan pesanan lintas channel. 
  • Marketplace dan toko online: Tokopedia, Shopee, Lazada, TikTok Shop, situs sendiri, dan lainnya. 
  • POS dan sistem toko: untuk bisnis dengan toko fisik. 
  • TMS dan jasa kurir: pengiriman, resi, pelacakan. 
  • Sistem pemasok atau prinsipal: ASN, data batch dan expiry. 
  • Sistem klien (untuk 3PL). 

 

Tidak semua perlu terhubung sejak awal. Prioritaskan integrasi yang paling memengaruhi akurasi stok dan beban kerja manual. 

 

Data Apa yang Mengalir ke Mana 

Dari ERP/akuntansi ke WMS 

  • Master data produk: SKU, nama, kategori, satuan, GTIN, dan atribut pelacakan (batch/expiry). 
  • Pesanan pembelian (PO) untuk persiapan penerimaan. 
  • Pesanan penjualan untuk diproses di gudang. 
  • Master pelanggan dan pemasok, termasuk aturan sisa umur bila disimpan di ERP. 

 

Dari WMS ke ERP/akuntansi 

  • Penerimaan barang (quantity, batch, expiry, nilai). 
  • Pengiriman dan batch/unit yang dikirim. 
  • Penyesuaian stok (selisih opname, rusak, kedaluwarsa, pemusnahan). 
  • Retur dan disposisinya. 
  • Posisi stok untuk rekonsiliasi persediaan. 
  • Data write-off dengan kode alasan, yang menjadi dasar jurnal. Perlakuan akuntansi dan pajak mengikuti ketentuan yang berlaku, konsultasikan dengan akuntan Anda. 

 

Dari WMS ke marketplace/OMS 

  • Ketersediaan stok per SKU (dan per channel bila ada alokasi). 
  • Status pesanan: dikemas, dikirim, resi. 
  • Pembaruan stok secara berkala atau real-time. 

 

Dari marketplace/OMS ke WMS 

  • Pesanan baru lengkap dengan SKU, jumlah, alamat, dan pilihan kurir. 
  • Pembatalan dan perubahan pesanan. 
  • Retur yang diajukan pembeli. 

 

Tantangan Khusus untuk Stok Expiry date

1. Banyak ERP dan marketplace tidak mengenal batch/expiry 

Banyak platform marketplace memperlakukan stok sebagai satu angka per SKU, tanpa informasi batch atau expiry. Artinya, WMS yang harus memastikan batch yang tepat (berdasarkan FEFO dan syarat sisa umur) dialokasikan saat pesanan diproses. Marketplace hanya melihat “tersedia” atau “habis”. 

Implikasi: stok yang dilaporkan ke marketplace sebaiknya hanya stok yang layak jual. Barang karantina, near-expiry yang diblokir untuk channel tertentu, dan barang kedaluwarsa tidak boleh terhitung. Jika dihitung, Anda berisiko menerima pesanan yang tidak bisa dipenuhi dengan batch yang memenuhi syarat. 

 

2. Stok tersedia vs stok layak jual 

Definisikan dengan jelas: 

  • Stok fisik: semua yang ada di gudang. 
  • Stok tersedia: stok fisik dikurangi yang dialokasikan. 
  • Stok layak jual (per channel): stok tersedia yang memenuhi syarat channel (status, sisa umur). 

 

Yang dikirim ke marketplace adalah stok layak jual per channel. Kesalahan definisi ini adalah sumber overselling dan pembatalan pesanan. 

 

3. Alokasi stok antar channel 

Jika satu SKU dijual di beberapa channel dengan syarat sisa umur berbeda, putuskan aturan alokasi: apakah stok dibagi tetap per channel, atau dibagikan dinamis? Batch dengan sisa umur lebih pendek dapat dialokasikan ke channel dengan syarat lebih longgar. 

 

4. Keterlambatan sinkronisasi 

Jeda antara perubahan stok di WMS dan pembaruan di marketplace dapat menyebabkan overselling. Tentukan frekuensi sinkronisasi sesuai volume dan risiko, dan gunakan safety stock (cadangan pengaman) bila perlu. 

 

5. Penamaan dan pemetaan SKU 

SKU di ERP, WMS, dan marketplace sering berbeda. Pemetaan yang tidak tepat menyebabkan stok salah produk. Pastikan ada master data dan tabel pemetaan yang dikelola dengan jelas, dengan GTIN sebagai kunci bila tersedia. 

 

6. Retur dari marketplace 

Retur online membawa jalur data tersendiri. Pastikan ID pesanan asal terhubung dengan batch/unit yang dikirim agar identifikasi saat retur mudah. Lihat Retur Barang dari Pelanggan. 

 

7. Nilai persediaan dan batch di akuntansi 

Beberapa sistem akuntansi menghitung nilai persediaan per SKU, bukan per batch. Jika harga perolehan antar batch berbeda, tentukan metode penilaian yang konsisten (misalnya rata-rata atau FIFO) dan pastikan WMS dan akuntansi sepakat. Hal ini bukan soal pengeluaran fisik FEFO, melainkan penilaian akuntansi. Konsultasikan dengan akuntan Anda. 

 

Pola Integrasi yang Umum 

  • API / webhook (real-time atau mendekati real-time). Sistem saling memanggil ketika terjadi peristiwa. Cepat dan akurat, tetapi memerlukan dokumentasi API dan pengembangan. 
  • Konektor siap pakai. Beberapa WMS memiliki konektor bawaan untuk ERP dan marketplace populer. Lebih cepat diimplementasikan, tetapi terbatas pada fitur konektor. 
  • Middleware / platform integrasi. Layanan pihak ketiga yang menjembatani banyak sistem. Berguna bila banyak sistem terhubung. 
  • Transfer file terjadwal (CSV/SFTP). Sederhana dan kuat untuk sistem lama, tetapi tidak real-time dan rawan kesalahan format. 
  • Input manual atau impor Excel. Hanya sementara; sumber kesalahan dan kelambatan. 
  • Pilihan bergantung pada volume transaksi, kemampuan teknis, dan toleransi terhadap jeda. 

 

Pertanyaan untuk Vendor WMS Tentang Integrasi 

  • Integrasi apa yang sudah tersedia untuk ERP dan marketplace yang kami pakai? 
  • Apakah konektor mendukung data batch dan expiry, atau hanya jumlah? 
  • Bagaimana sistem menghitung dan mengirim stok layak jual per channel? 
  • Seberapa sering sinkronisasi stok berjalan, dan bisa diatur? 
  • Bagaimana kegagalan sinkronisasi ditangani, dan siapa yang diberi tahu? 
  • Apakah API terdokumentasi, dan apakah ada biaya tambahan per integrasi? 
  • Siapa yang membangun dan memelihara integrasi kustom? 
  • Bagaimana perubahan pada API marketplace ditangani? 
  • Bagaimana penyesuaian stok (misalnya pemusnahan kedaluwarsa) dikirim ke ERP? 
  • Apakah ada lingkungan uji (sandbox) untuk menguji sebelum go-live? 

 

Lihat juga Checklist Fitur WMS untuk Manajemen Expiry. 

 

Praktik Terbaik 

  • Tetapkan satu sumber kebenaran untuk setiap jenis data: misalnya master produk di ERP, stok fisik di WMS, pesanan di OMS. 
  • Bersihkan master data sebelum integrasi. Data kotor yang disinkronkan hanya menyebarkan kekacauan lebih cepat. 
  • Mulai dari alur paling kritis (pesanan masuk, stok keluar, penerimaan) lalu tambahkan alur lain. 
  • Uji dengan skenario nyata: pesanan dengan SKU multi-batch, retur, pembatalan, dan stok tipis. 
  • Pantau dan beri peringatan saat sinkronisasi gagal atau tertunda. 
  • Dokumentasikan aturan pemetaan, definisi stok, dan penanggung jawab. 
  • Siapkan prosedur rekonsiliasi berkala antar sistem untuk menangkap selisih lebih awal. 
  • Rencanakan perubahan: marketplace sering memperbarui API dan kebijakan. 

 

Kesimpulan 

Integrasi menentukan apakah investasi WMS memberi hasil penuh. Untuk stok berumur simpan, tantangan utamanya adalah banyak sistem hanya mengenal jumlah, bukan batch dan expiry, sehingga WMS harus menjadi penentu batch mana yang dialokasikan dan stok layak jual per channel yang dilaporkan keluar. Kuncinya: definisi stok yang jelas, pemetaan SKU yang rapi, sinkronisasi yang andal, dan rekonsiliasi rutin. 

Langkah praktis: petakan semua sistem yang menyentuh data stok Anda hari ini dan tandai di mana data disalin manual. Titik-titik itu adalah kandidat integrasi pertama. 

Setelah fondasi teknis jelas, saatnya membahas nilai finansialnya: Cara Menghitung ROI Pengurangan Barang Kedaluwarsa.

Scroll to Top