TCO Pilot AI: Menghitung Biaya per Kasus yang Diterima Baca Selengkapnya →
Sistem ERP & Enterprise Software

ASN Penerimaan Barang: Integrasi ERP dan Penanganan Selisih

Oleh Anggit Restu Pinuntun • October 12, 2026
Ilustrasi konseptual receiving gudang dengan karton, scanner, dokumen, dan barang di area pemeriksaan terpisah

Truk sudah tiba, tetapi gudang belum memiliki daftar barang yang dapat dipercaya. Procurement memegang purchase order, pemasok mengirim surat jalan, dan operator menerima jumlah fisik yang berbeda. Jika seluruh informasi langsung dianggap sebagai penerimaan final, selisih kecil dapat terbawa ke stok dan pemeriksaan invoice.

ASN penerimaan barang integrasi ERP perlu dirancang sebagai alur membandingkan kiriman yang direncanakan dengan barang yang benar-benar diterima. Panduan ini membantu warehouse manager, procurement, finance, serta PIC integrasi menyepakati data, status, dan penyelesaian selisih.

Apa Peran ASN dalam Receiving?

Advance Shipping Notice atau ASN memberi informasi kiriman sebelum barang tiba. GS1 Logistic Label Guideline membahas Despatch Advice/ASN yang diproses oleh sistem penerima sebelum kedatangan, serta Receiving Advice untuk menyampaikan hasil penerimaan. ASN bukan bukti otomatis bahwa barang sudah diterima lengkap dan layak digunakan.

Pisahkan empat fakta: yang dipesan, yang diberitahukan akan dikirim, yang tiba secara fisik, dan yang diterima setelah pemeriksaan. Masing-masing dapat berbeda karena pengiriman parsial, kerusakan, substitusi, atau koreksi dokumen. Menggabungkannya menjadi satu angka membuat tim kehilangan dasar penanganan selisih.

Artikel ini membahas kontrak data dan proses receiving. Untuk gambaran lintas fungsi, gunakan panduan digitalisasi rantai pasok. Untuk kontrol pesan hilang dan ganda, lihat rekonsiliasi integrasi ERP.

Susun Kontrak Data Bersama Pemasok

Mulai dari identitas pemasok, nomor ASN, versi dokumen, referensi PO dan barisnya, tujuan gudang, perkiraan kedatangan, kode barang, jumlah, serta satuan. Tambahkan lot, identitas unit logistik, atau serial hanya bila proses membutuhkan dan pemasok dapat menyediakannya.

Jelaskan kode barang siapa yang digunakan. SKU pemasok perlu dipetakan ke kode internal melalui aturan yang disetujui. Pemetaan berdasarkan nama mirip saja berisiko memasukkan barang salah. Satuan karton, pak, dan unit juga perlu konversi yang terkunci agar jumlah dapat dibandingkan.

Tentukan field wajib, format tanggal, zona waktu, toleransi, dan cara menolak dokumen tidak lengkap. Kontrak harus menjelaskan pembatalan serta koreksi ASN. Dokumen versi baru perlu dapat dibedakan dari kiriman kedua, supaya revisi tidak menggandakan rencana penerimaan.

Rancang Status yang Mengikuti Kejadian Fisik

ASN Diterima dan Divalidasi

Sistem memeriksa identitas, referensi PO, baris, satuan, dan tujuan. Dokumen yang lolos dapat menjadi rencana kerja receiving. Dokumen yang tidak cocok masuk antrean pemeriksaan, bukan langsung membentuk saldo stok tersedia.

Barang Tiba dan Diperiksa

Operator mencatat jumlah aktual, kondisi kemasan, label, dan temuan sesuai prosedur. Barang rusak atau menunggu quality dipisahkan statusnya. Kedatangan kendaraan tidak otomatis menutup semua baris ASN.

Penerimaan Dikonfirmasi

Petugas berwenang mengesahkan jumlah diterima, ditolak, atau ditahan. Hasil ini menjadi dasar transaksi berikutnya sesuai desain ERP. Pastikan finance menerima informasi yang membedakan barang di dock dari barang yang telah diterima secara sah.

Skenario Ilustratif: Kiriman Parsial dengan Selisih Satuan

Bayangkan PO meminta 100 unit. ASN memberitahukan 10 karton dengan isi yang dinyatakan pemasok. Di dock, hanya sembilan karton tiba dan satu karton mengalami kerusakan. Contoh ini ilustratif, bukan catatan implementasi Layana.ID.

Operator tidak cukup memilih “selesai”. Tim perlu mengonfirmasi konversi karton ke unit, jumlah yang diperiksa, jumlah layak diterima, dan sisa yang masih ditunggu. Jika isi karton tidak sesuai master yang disepakati, dokumen harus masuk pemeriksaan procurement.

Transaksi berikutnya harus menjaga perbedaan antara kekurangan kiriman dan penolakan barang. Keduanya dapat memerlukan tindakan berbeda: jadwal pengiriman susulan, klaim, retur, atau penyesuaian dokumen. Sistem sebaiknya mempertahankan alasan dan PIC, bukan hanya selisih total.

Atur Pengecualian dan Persetujuan Manusia

Tentukan siapa yang boleh menerima kelebihan jumlah, menyetujui substitusi, mengubah satuan, atau menutup sisa PO. Kebijakan dapat berbeda menurut kategori barang, nilai transaksi, dan kontrak. Jangan menaruh seluruh keputusan pada operator receiving hanya karena ia berada di depan layar.

Otomasi dapat memeriksa field, mencocokkan referensi, mengelompokkan selisih, dan menyiapkan receiving advice. Keputusan menerima barang di luar syarat pembelian membutuhkan kewenangan bisnis. Jejak persetujuan perlu memuat nilai sebelum-sesudah, alasan, pelaku, serta transaksi terkait.

Antrean selisih harus memiliki owner, batas tindak lanjut yang disepakati, dan status penyelesaian. Notifikasi terkirim tidak membuktikan selisih sudah ditangani. Tampilkan exception yang masih terbuka agar gudang dan procurement tidak saling menganggap pihak lain telah menyelesaikannya.

Integrasi Harus Tahan Revisi dan Kiriman Ulang

Gunakan identitas pesan dan identitas dokumen yang jelas. Nomor ASN dan versi dokumen membantu membedakan revisi, sedangkan identitas pesan membantu mendeteksi pengiriman ulang. Desain idempotency berdasarkan transaksi bisnis agar retry tidak membuat penerimaan baru.

Periksa juga pesan yang datang terlambat. Receiving mungkin telah dilakukan melalui jalur manual ketika koneksi terputus. ASN yang baru tiba setelahnya perlu direkonsiliasi dengan transaksi aktual, bukan memicu pencatatan kedua. Simpan jalur pemulihan dan bukti keterkaitan kedua catatan.

Jika pihak pemasok belum mempunyai API, pilot dapat memakai file terstruktur dengan validasi dan kontrol versi. Pilihan transport mengikuti kesiapan mitra. Membangun API lebih dulu tidak menyelesaikan ketidakjelasan satuan, kode barang, atau persetujuan selisih.

Pilot pada Satu Pemasok dan Satu Gudang

Pilih pemasok dengan variasi kiriman yang cukup mewakili operasi. Susun kasus normal, parsial, kelebihan, kerusakan, PO tidak ditemukan, satuan salah, revisi ASN, pembatalan, duplikasi pesan, dan penerimaan manual saat integrasi terputus.

Warehouse menyetujui bukti fisik; procurement menyetujui hubungan PO dan pengecualian; finance memeriksa dampak terhadap dokumen lanjutan. PIC integrasi membuktikan jumlah serta status di sistem sumber dan tujuan. Akhiri pilot dengan satu latihan pemulihan pesan tanpa membuat stok ganda.

KPI Receiving yang Layak Dibandingkan

  • Proporsi kiriman dengan ASN valid sebelum barang tiba.
  • Waktu dari kedatangan sampai penerimaan yang disahkan, dipisahkan menurut jenis kiriman.
  • Jumlah exception yang masih terbuka dan usia antreannya.
  • Selisih jumlah ASN, fisik, serta jumlah diterima setelah quality.
  • Jumlah duplikasi transaksi dan koreksi akibat salah kode atau satuan.

Gunakan baseline yang sebanding. Receiving lebih cepat belum membuktikan perbaikan bila pemeriksaan kualitas dilewati. Target dan toleransi perlu berasal dari kebutuhan operasi, bukan janji efisiensi universal.

FAQ ASN dan Integrasi ERP

Apakah ASN Dapat Menggantikan Pemeriksaan Fisik?

Tidak. ASN menjelaskan kiriman yang diberitahukan. Kondisi, jumlah, dan penerimaan aktual tetap perlu dibuktikan melalui proses gudang.

Haruskah Semua Pemasok Menggunakan Format Sama?

Perusahaan perlu model data internal yang konsisten. Format sumber dapat berbeda jika pemetaan, validasi, versi, dan tanggung jawabnya jelas.

Petakan Receiving Sebelum Mengotomasi

Siapkan contoh PO, ASN, surat jalan, bukti receiving, daftar satuan, dan jenis selisih paling sering. Tandai siapa yang mengambil keputusan pada setiap exception serta sistem mana yang menjadi sumber status final.

Lihat layanan sistem integrator Layana.ID, lalu diskusikan alur ASN dan penerimaan barang untuk menentukan kontrak data serta ruang lingkup pilot yang sesuai.

Referensi

GS1 Logistic Label Guideline dan GS1 Logistics Interoperability menjadi rujukan pembedaan Despatch Advice dan Receiving Advice. Sumber ditulis tanpa tautan keluar. Alur, contoh, checklist, dan KPI merupakan analisis editorial; tidak ada klaim volume pencarian, hasil proyek, atau persentase penghematan.

Bagikan Artikel Ini:

Teks dan Tautan berhasil disalin!