Inventaris Konsinyasi di ERP: Miliki Stok yang Bukan Milikmu

Inventaris konsinyasi mematahkan asumsi yang tertanam di sebagian besar modul stok ERP, yaitu bahwa siapa pun yang menguasai barang juga memilikinya. Consignor mengirim stok ke gudang consignee, consignee memajang dan menjualnya, tetapi hak milik hukum tetap berada pada consignor sampai pelanggan akhir benar-benar membeli. Jika model inventaris hanya melacak kuantitas dan lokasi, kamu akan mencatat pendapatan dan harga pokok penjualan pada momen yang salah, dan laporan posisi keuangan akan menunjukkan inventaris yang secara hukum milik pihak lain.

Tulisan ini membahas rancangan konkret untuk stok konsinyasi di ERP kustom: cara memisahkan kepemilikan dari penguasaan pada level model data, cara alur penyelesaian consignor dan akrual komisi seharusnya berjalan, kapan pengakuan pendapatan sebenarnya terpicu menurut aturan gaya IFRS 15 dan ASC 606, serta entri buku besar yang tepat yang harus dihasilkan sebuah penjualan. Pola-pola di sini berasal dari pembangunan modul persetujuan dan inventaris untuk klien manufaktur dan distribusi yang lazim memakai syarat konsinyasi dengan dealer dan mitra ritel.

Kepemilikan vs Penguasaan: Inti Masalah Pemodelan

Setiap entri buku besar stok konvensional menjawab satu pertanyaan: berapa banyak item ada di gudang tertentu. Konsinyasi memaksa pertanyaan kedua yang independen: siapa yang secara hukum memiliki kuantitas itu saat ini. Kedua fakta ini berubah pada peristiwa dan waktu yang berbeda, sehingga tidak bisa disimpan pada penanda yang sama. Implementasi naif yang menambahkan satu boolean seperti is_consignment pada master item akan rusak begitu item yang sama dijual dengan syarat konsinyasi ke satu mitra dan sekaligus dijual langsung ke mitra lain.

• Penguasaan berubah ketika barang berpindah secara fisik antar gudang, dipicu oleh voucher penerimaan barang atau pengeluaran barang.
• Kepemilikan berubah hanya ketika penjualan ke pelanggan akhir dikonfirmasi, atau ketika stok konsinyasi dikembalikan secara formal ke consignor.
• Item yang sama, di gudang yang sama, bisa memiliki unit dengan status kepemilikan berbeda secara bersamaan jika consignee juga menyimpan stok milik sendiri untuk SKU yang identik.

Model Data Dua Buku Besar

Implementasi paling bersih menjaga dua buku besar yang secara logis terpisah namun berbagi tabel dasar yang sama. Buku besar kuantitas menjawab di mana stok secara fisik berada dan berubah pada voucher penerimaan, transfer, serta pengembalian fisik. Buku besar kepemilikan menjawab siapa yang memegang hak milik hukum dan hanya berubah pada voucher penjualan konsinyasi atau voucher transfer kepemilikan formal. Karena kedua buku besar mengacu pada item dan gudang yang sama, kamu selalu bisa menjawab dua pertanyaan yang ditanyakan berbeda oleh manajer gudang dan kontroler keuangan: berapa banyak yang kita punya, dan berapa banyak dari yang kita punya itu benar-benar milik kita.

Siklus Hidup Konsinyasi di ERP

Sebuah pengaturan konsinyasi di sistem melalui empat jenis voucher yang berbeda, masing-masing dengan aturan pencatatannya sendiri dan efeknya sendiri, atau justru sengaja tidak berefek, pada buku besar umum.

1. Perjanjian konsinyasi: sebuah rekaman master mendefinisikan consignor, consignee, pembagian komisi atau margin, frekuensi penyelesaian, dan item mana yang tercakup. Tidak ada pergerakan stok atau buku besar di sini.
2. Penerimaan konsinyasi: barang tiba secara fisik di gudang consignee. Buku besar kuantitas langsung diperbarui. Buku besar kepemilikan tidak berubah, dan yang krusial, tidak ada entri jurnal keuangan yang dicatat, karena belum ada penjualan dan belum ada pendapatan yang diperoleh.
3. Laporan penjualan konsinyasi: consignee melaporkan bahwa unit telah terjual ke pelanggan akhir, biasanya melalui laporan penjualan berkala atau integrasi titik penjualan. Satu peristiwa ini memicu pengurangan kuantitas, perpindahan kepemilikan, dan seluruh rangkaian entri jurnal.
4. Penyelesaian: pada jadwal yang disepakati, consignor menagih atau menghitung bersih kepada consignee untuk nilai barang yang terjual, dikurangi komisi yang disepakati, dan liabilitas yang terakru dari setiap laporan penjualan dihapuskan.

// stock_ledger_entry
{
  id: uuid,
  item_id: uuid,
  warehouse_id: uuid,          // consignee's physical warehouse
  owner_party_id: uuid,        // consignor (legal owner), NOT the warehouse holder
  quantity: decimal,
  valuation_rate: decimal,     // consignor's cost, hidden from consignee
  ownership_flag: 'consignment' | 'owned',
  posting_datetime: timestamp,
  voucher_type: 'consignment_receipt' | 'consignment_sale' | 'consignment_return',
  voucher_id: uuid
}

// Two ledgers move independently:
// 1. Quantity ledger  -> updates on physical receipt/return at consignee warehouse
// 2. Ownership ledger  -> stays with consignor until a sale voucher fires

Penyelesaian Consignor dan Akrual Komisi

Penyelesaian adalah titik di mana kebanyakan modul konsinyasi buatan sendiri berantakan, karena membutuhkan penggabungan banyak peristiwa laporan penjualan kecil menjadi satu utang atau piutang periodik, sambil tetap menjaga jejak audit ke setiap penjualan individual. Mesin penyelesaian harus memperlakukan setiap laporan penjualan yang terkonfirmasi sebagai rekaman tak berubah dan berstempel waktu yang mengakrualkan utang komisi ke consignee dan piutang dari consignee untuk nilai penjualan bruto, lalu mengelompokkan akrual tersebut ke dalam satu proses penyelesaian.

• Setiap proses penyelesaian harus dapat direproduksi hanya dari laporan penjualan yang mendasarinya, sehingga kontroler keuangan selalu bisa menelusuri total penyelesaian kembali ke transaksi individual yang menghasilkannya.
• Tarif komisi harus diberi versi pada perjanjian konsinyasi, bukan ditetapkan tetap per penjualan, karena tarif umumnya berubah di tengah masa perjanjian dan penyelesaian historis harus tetap mencerminkan tarif yang berlaku pada saat penjualan terjadi.
• Laporan penjualan yang disengketakan memerlukan status tahan yang mengecualikannya dari proses penyelesaian saat ini tanpa menghalangi sisa batch, jika tidak satu baris yang disengketakan bisa menghentikan seluruh pembayaran mitra.

Pengakuan Pendapatan: Kapan Entri Jurnal Benar-Benar Terpicu

Menurut IFRS 15 maupun ASC 606, consignor hampir selalu menjadi pihak utama dalam pengaturan ini, karena tetap memegang kendali atas barang, menanggung risiko inventaris, dan biasanya menetapkan atau menyetujui harga jual kembali. Itu berarti consignor mengakui pendapatan dan harga pokok penjualan dalam jumlah bruto pada saat kendali berpindah ke pelanggan akhir, bukan saat barang dikirim ke consignee dan bukan saat kas diterima. Bagian consignee adalah beban komisi, bukan pengurang pendapatan, karena consignor melaporkan secara bruto, bukan neto.

// Fired only when the consignee reports an end-customer sale,
// never at physical receipt of the consigned goods.

function postConsignmentSale(saleReport: ConsignmentSaleReport) {
  const { itemId, qtySold, sellingPrice, commissionRate, costRate } = saleReport

  // 1. Recognize revenue (consignor is principal -> gross reporting)
  journal.post([
    { account: 'AccountsReceivable_Consignee', debit: qtySold * sellingPrice },
    { account: 'SalesRevenue', credit: qtySold * sellingPrice },
  ])

  // 2. Relieve consignment inventory, recognize COGS
  journal.post([
    { account: 'COGS', debit: qtySold * costRate },
    { account: 'ConsignmentInventory', credit: qtySold * costRate },
  ])

  // 3. Accrue the consignee's commission as an expense, net at settlement
  const commission = qtySold * sellingPrice * commissionRate
  journal.post([
    { account: 'CommissionExpense', debit: commission },
    { account: 'AccountsPayable_Consignee', credit: commission },
  ])
}

Mode Kegagalan Umum yang Perlu Diantisipasi Sejak Desain

Sebagian besar kesulitan pada modul inventaris konsinyasi berasal dari beberapa kesalahan berulang yang mudah dihindari jika dirancang sejak awal, bukan ditambal setelah klien mengeluh.

• Memperlakukan konsinyasi sebagai kasus khusus dari penjualan standar, bukan sebagai jenis voucher tersendiri, menghasilkan laporan yang menghitung pendapatan dua kali ketika dasbor penjualan generik menjumlahkan setiap pengiriman, termasuk penerimaan konsinyasi yang sebenarnya belum terjual.
• Menilai stok konsinyasi dengan harga consignee, bukan harga consignor, merusak laporan valuasi inventaris begitu satu item yang sama eksis dalam bentuk konsinyasi maupun milik sendiri di gudang yang sama.
• Melewatkan voucher pengembalian konsinyasi formal dan justru hanya menghapus entri buku besar kuantitas menghancurkan jejak audit yang dibutuhkan kontroler untuk merekonsiliasi stok yang tidak terjual dengan apa yang awalnya dikirim.