Retur penjualan merusak akurasi stok bila dicatat terlambat atau tanpa status barang. ERP mengatasinya dengan mengaitkan retur ke dokumen penjualan asli, lalu memperbarui stok dan akuntansi otomatis. Angka di sistem pun tetap sama dengan isi gudang.
Retur yang Diam-Diam Menggeser Angka Stok

Bayangkan distributor alat tulis yang menerima 20 dus kertas retur dari pelanggan. Gudang menaruhnya kembali di rak, tetapi admin belum mencatat apa pun. Di sistem, stok tetap kurang 20 dus. Akibatnya, tim sales menolak pesanan baru padahal barangnya tersedia.
Kasus sebaliknya juga terjadi. Barang rusak ikut dicatat sebagai stok layak jual, lalu terkirim ke pelanggan berikutnya. Selisih seperti ini biasanya baru terlihat saat stock opname. Pada saat itu, penelusuran penyebabnya sudah sulit dilakukan.
Alur Retur dalam Sistem ERP Odoo
Pada sistem ERP Odoo, retur dimulai dari delivery order yang sudah selesai. Pengguna memilih fungsi return, lalu mengisi produk, jumlah, dan alasan. Sistem kemudian membuat dokumen penerimaan yang terhubung ke pengiriman awal. Keterkaitan ini memudahkan penelusuran kapan barang keluar, kapan kembali, dan siapa yang memprosesnya.
Kondisi Barang Menentukan Tujuan Stok
Tidak semua barang retur boleh langsung dijual lagi. Perusahaan dapat menentukan lokasi tujuan berdasarkan hasil pemeriksaan di gudang. Tabel berikut merangkum pola yang lazim dipakai.
|
Kondisi Barang |
Lokasi Tujuan |
Dampak ke Stok Tersedia |
Tindak Lanjut |
|
Layak jual |
Gudang utama |
Bertambah |
Credit note atau refund |
|
Perlu perbaikan |
Lokasi karantina |
Tidak bertambah |
Perbaikan, lalu cek ulang |
|
Rusak |
Lokasi scrap |
Tidak bertambah |
Penghapusan persediaan |
Pemisahan lokasi ini mencegah barang bermasalah ikut terhitung sebagai stok tersedia.
Stok, Faktur, dan Akuntansi Harus Seimbang
Retur berdampak pada dua sisi, yaitu fisik dan keuangan. Saat barang kembali, nilai persediaan ikut dikoreksi sesuai metode valuasi yang dipakai. Credit note dibuat dari faktur asal agar piutang pelanggan turun dengan angka yang tepat. Tanpa keterkaitan ini, selisih antara laporan gudang dan laporan keuangan mudah muncul.
Lima Kebiasaan yang Menjaga Retur Tetap Rapi
Beberapa praktik berikut relevan untuk gudang dengan volume retur harian.
- Wajibkan nomor delivery order asal pada setiap retur.
- Sediakan lokasi terpisah untuk karantina dan barang rusak.
- Catat alasan retur lewat pilihan baku, bukan teks bebas.
- Batasi persetujuan retur bernilai besar pada supervisor.
- Cocokkan data retur dengan laporan stok setiap minggu.
Alasan Retur Bisa Jadi Bahan Evaluasi
Data retur yang rapi bukan sekadar urusan stok. Laporan alasan retur menunjukkan produk, pemasok, atau pelanggan yang paling sering bermasalah. Misalnya, retur karena kemasan penyok berulang bisa mengarah ke proses packing. Evaluasi bulanan cukup untuk mulai melihat pola tersebut.
Memilih Pendamping Implementasi yang Tepat
Konfigurasi retur sering bermasalah karena alur gudang tidak dipetakan sejak awal. Vendor ERP yang baik biasanya memulai dengan workshop proses retur, bukan langsung konfigurasi. Perusahaan juga perlu menguji skenario retur sebagian dan retur lintas periode. Ulasan implementasi ERP untuk manajemen retur dan stok dapat dibaca lewat cek di sini sebagai bahan pembanding.
Pertanyaan yang Sering Muncul
- Apakah semua barang retur otomatis menambah stok layak jual? Tidak, hasilnya bergantung pada lokasi tujuan yang dipilih saat retur diproses.
- Apakah retur selalu diselesaikan dengan credit note? Tidak, penyelesaian bisa berupa penggantian barang atau refund sesuai kebijakan perusahaan.
- Bagaimana retur sebagian dicatat di sistem? Pengguna hanya mengisi jumlah yang kembali, sehingga sisa pengiriman tetap tercatat.
Arah Pengelolaan Retur ke Depan
Pengelolaan retur kini bergerak dari pencatatan manual menuju proses yang terhubung penuh dengan stok dan keuangan. Disiplin input data tetap sama pentingnya dengan fitur sistem. Perusahaan yang merapikan retur sejak awal cenderung lebih mudah menjaga akurasi laporan. i2C Studio menjadi salah satu penyedia jasa implementasi ERP berbasis Odoo yang dapat dijadikan referensi dalam memetakan alur retur seperti ini.