
Advance Shipping Notice (ASN): Informasi Pengiriman Sebelum Barang Tiba di Gudang
Barang yang dikirim menuju warehouse, distribution center, pabrik, atau fasilitas customer sering kali tidak bisa datang begitu saja. Penerima dapat membutuhkan nomor pesanan, jenis dan jumlah barang, jumlah pallet atau koli, perkiraan waktu kedatangan, data kendaraan, hingga appointment sebelum truk diperbolehkan masuk ke area receiving. Semakin besar dan kompleks pengirimannya, semakin penting informasi tersebut tersedia sebelum kendaraan tiba.
Bagi pengirim, data itu membantu memastikan barang yang diberangkatkan sesuai dengan pesanan dan informasi yang telah diberikan kepada penerima. Bagi transporter seperti MUAT Cargo, sebagian informasi yang sama diperlukan untuk menilai kebutuhan kendaraan, jadwal pickup, akses lokasi, karakter muatan, serta kebutuhan bongkar-muat. Sementara bagi warehouse, informasi tersebut dapat digunakan untuk menyiapkan loading dock, tenaga kerja, forklift atau alat handling, ruang pemeriksaan, dan proses receiving.
Salah satu mekanisme yang digunakan untuk memberikan informasi tersebut adalah Advance Shipping Notice atau ASN. ASN membuat proses inbound tidak baru dimulai ketika pintu truk dibuka, tetapi sejak barang masih dalam perjalanan atau bahkan sebelum kendaraan meninggalkan lokasi pengirim.
Apa Itu Advance Shipping Notice?
Advance Shipping Notice (ASN) adalah pemberitahuan mengenai shipment yang dikirim kepada pihak penerima sebelum barang tiba. Informasinya menggambarkan apa yang benar-benar sedang atau akan dikirim, bukan hanya apa yang sebelumnya dipesan.
Istilahnya dapat berbeda antarperusahaan dan sistem. Anda dapat menemukan istilah Advance Ship Notice, Advance Shipment Notice, Advanced Shipping Notice, atau Advanced Shipping Notification. SAP, misalnya, menggunakan istilah Advanced Shipping Notification, sementara Oracle menggunakan Advance Shipment Notice. Pada standar X12, fungsi ini erat dengan 856 Ship Notice/Manifest.
Menurut X12 856 Ship Notice/Manifest, informasi shipment dapat mencakup isi pengiriman, referensi order, deskripsi produk, karakteristik fisik, jenis kemasan, marking, carrier, hingga konfigurasi barang di dalam alat transportasi. Artinya, ASN tidak hanya memberi tahu bahwa “barang sudah dikirim”, tetapi dapat menjelaskan struktur shipment dengan detail yang cukup untuk membantu pihak penerima mempersiapkan receiving.
Mengapa Informasi Sebelum Barang Tiba Penting?
Bayangkan gudang baru mengetahui saat kendaraan datang bahwa muatannya terdiri dari 18 pallet, beberapa jenis SKU, dan satu unit mesin yang membutuhkan forklift. Dock mungkin tersedia, tetapi alat handling sedang dipakai untuk pekerjaan lain. Receiving area belum mempunyai cukup ruang dan petugas masih harus mencari nomor purchase order yang sesuai.
Kendaraan akhirnya menunggu meskipun perjalanan transportasinya sendiri tidak terlambat.
Itulah mengapa aktivitas inbound idealnya dimulai sebelum kendaraan berada di depan gudang. Dalam alur operasional gudang MUAT Cargo, pre-receiving ditempatkan sebelum receiving. Informasi seperti pemasok atau pengirim, nomor pesanan, jenis dan jumlah barang, jumlah pallet atau koli, ETA, jenis kendaraan, alat bantu, karakter handling, serta dokumen dapat digunakan untuk menyiapkan area bongkar, tenaga kerja, alat handling, dan ruang pemeriksaan.
ASN membuat kebutuhan tersebut lebih terstruktur. Gudang tidak hanya mengetahui bahwa sebuah kendaraan akan datang, tetapi dapat memahami apa yang ada di dalam shipment dan bagaimana penerimaan perlu dipersiapkan.
Informasi Apa yang Biasanya Ada dalam ASN?
Tidak ada satu format ASN yang wajib digunakan oleh semua perusahaan. Field yang dibutuhkan dapat berbeda menurut industri, buyer, supplier, sistem ERP/WMS, jenis barang, dan kesepakatan trading partner.
Namun, data ASN umumnya berpusat pada identitas shipment, order, barang, kemasan, dan transportasi.
| Kelompok data | Contoh informasi | Kegunaan saat receiving |
|---|---|---|
| Identitas ASN | Nomor ASN, tanggal ASN | Menjadi referensi shipment |
| Purchase/order reference | PO, inbound order, delivery reference | Menghubungkan shipment dengan pesanan |
| Pengirim dan penerima | Supplier, ship-from, ship-to | Memastikan asal dan tujuan |
| Barang | SKU, item number, deskripsi | Mengetahui barang yang akan datang |
| Quantity | Jumlah dan unit of measure | Membandingkan shipped vs ordered |
| Packaging | Pallet, karton, peti, koli | Menilai kebutuhan handling |
| Packing structure | Item pada pallet/karton tertentu | Mempermudah identifikasi fisik |
| Berat dan dimensi | Berat total atau per unit, ukuran | Menilai ruang dan alat |
| Waktu | Shipping date, ETA | Menyiapkan jadwal penerimaan |
| Transportasi | Carrier, kendaraan, shipment reference | Menghubungkan shipment dengan kedatangan fisik |
| Traceability | Batch, lot, serial, label logistics | Digunakan jika jenis barang memerlukannya |
| Handling information | Instruksi atau karakter khusus | Menyiapkan pemeriksaan dan penanganan |
Dokumentasi Microsoft Dynamics 365 yang diperbarui pada 2026 juga menjelaskan bahwa ASN dapat menggambarkan item dan packaging sehingga pekerja gudang mengetahui apa yang akan datang dan dapat mencocokkannya dengan purchase order atau inbound shipment order yang telah dibuat sebelumnya.
Jumlah field bukan ukuran kualitas ASN. ASN dengan puluhan kolom tetapi quantity dan packing structure salah tetap akan menyulitkan receiving. Data yang paling penting adalah data yang akurat, sesuai shipment aktual, dan cukup untuk menjalankan proses penerimaan.
ASN Bukan Purchase Order, Packing List, atau Goods Receipt
Salah satu kesalahan yang mudah terjadi adalah menganggap semua dokumen tersebut memberikan informasi yang sama. Sebenarnya, masing-masing menjawab pertanyaan yang berbeda.
| Informasi | Pertanyaan utama |
|---|---|
| Purchase Order | Apa yang dipesan buyer? |
| ASN | Apa yang diberitahukan sedang dikirim? |
| Packing List | Bagaimana barang dalam shipment dikemas? |
| Dokumen transportasi | Barang apa yang dibawa dalam perjalanan? |
| Actual Receipt/Goods Receipt | Apa yang benar-benar diterima gudang? |
Misalnya buyer memesan 1.500 unit. Saat shipment pertama disiapkan, supplier ternyata baru dapat mengirim 1.440 unit. ASN seharusnya menggambarkan 1.440 unit yang benar-benar diberangkatkan, bukan otomatis menyalin quantity 1.500 dari purchase order.
Ketika truk tiba, gudang kemudian menghitung hanya 1.438 unit secara fisik.
Ordered: 1.500 unit
Advised/shipped: 1.440 unit
Received: 1.438 unit
Framework ordered → advised → received ini bukan nama standar ASN tertentu, tetapi merupakan cara praktis untuk memahami tiga kondisi berbeda yang perlu dijaga agar tidak tercampur.
Bagaimana Alur ASN dari Supplier sampai Receiving?
1. Order atau Inbound Requirement Sudah Diketahui
Pada banyak proses, ASN perlu terhubung dengan order atau inbound reference tertentu. Microsoft Dynamics 365, misalnya, mensyaratkan purchase order atau inbound shipment order telah terdaftar sebelum inbound ASN diproses dalam skenario warehouse management yang didokumentasikan.
2. Supplier Menyiapkan Shipment Aktual
ASN idealnya dibuat dari kondisi shipment yang benar-benar siap diberangkatkan. Setelah picking dan packing selesai, pengirim seharusnya mengetahui SKU apa yang dikirim, quantity aktual, jumlah karton atau pallet, packing structure, berat, serta informasi lain yang dibutuhkan penerima.
Jika PO menyebut 20 pallet tetapi yang siap berangkat hanya 18, ASN perlu menggambarkan 18 pallet yang benar-benar masuk shipment.
3. Informasi Shipment Dikirim kepada Penerima
ASN dapat dikirim melalui mekanisme yang disepakati antara supplier dan buyer. Dalam lingkungan enterprise, formatnya dapat berupa EDI, XML, API, atau integrasi platform supply chain.
X12 mempunyai transaction set 856 Ship Notice/Manifest, sedangkan ekosistem GS1 mengenal DESADV atau Despatch Advice. GS1 menjelaskan pada Global Trace Check List bahwa DESADV digunakan untuk mengirim informasi trade item kepada trading partner sebelum physical delivery.
Operasi yang belum menggunakan integrasi tersebut tetap dapat menerapkan prinsip pre-arrival information, tetapi tidak semua spreadsheet atau email otomatis harus disebut sebagai implementasi EDI ASN. Penting membedakan konsep bisnis ASN dengan standar teknis yang digunakan untuk mengirimkannya.
4. Buyer atau Warehouse Memvalidasi ASN
Data ASN kemudian dicocokkan dengan order atau inbound requirement. Beberapa exception yang dapat ditemukan sebelum barang tiba antara lain nomor PO tidak ditemukan, SKU tidak dikenal, quantity melebihi order, tujuan tidak sesuai, packing information tidak lengkap, atau reference shipment duplikat.
Semakin awal kesalahan tersebut diketahui, semakin besar peluang menyelesaikannya sebelum kendaraan sudah berada di loading dock.
5. Warehouse Menyiapkan Receiving
Setelah shipment dapat dikenali, gudang dapat menggunakan informasi tersebut untuk mempersiapkan proses fisik. Jumlah pallet membantu memperkirakan ruang receiving. Berat dan bentuk barang membantu menentukan alat handling. ETA dan kendaraan membantu mengatur slot. Karakter barang dapat memengaruhi area pemeriksaan atau penempatan sementara.
Karena itu ASN mempunyai hubungan erat dengan dock scheduling. ASN membantu menjawab apa yang akan tiba, sedangkan dock scheduling membantu menjawab kapan kendaraan sebaiknya dilayani dan resource apa yang harus tersedia.
6. Kendaraan Tiba dan Shipment Dicocokkan
ASN tidak menggantikan pemeriksaan fisik. Ketika kendaraan datang, petugas tetap perlu mencocokkan dokumen, identitas shipment, jumlah pallet atau koli, kondisi kemasan, SKU, quantity, dan data lain sesuai prosedur gudang.
Pemberitahuan supplier menunjukkan apa yang seharusnya berada dalam shipment. Receiving membuktikan apa yang benar-benar sampai.
7. Actual Receipt Dicatat
Setelah pemeriksaan selesai, gudang mencatat quantity dan kondisi aktual. Jika hasil fisik berbeda dari ASN, perbedaan tersebut harus dicatat dan diselesaikan melalui prosedur discrepancy yang berlaku. Actual receipt tidak seharusnya diubah hanya agar angka pada sistem terlihat sama dengan ASN.
Dari ASN ke Eksekusi Pengiriman: Di Mana MUAT Cargo Terlibat?
ASN pada dasarnya terjadi antara pihak yang mengirim informasi shipment dan pihak yang menerima barang. Namun shipment fisik tetap perlu bergerak dari origin menuju warehouse, distribution center, pabrik, toko, atau lokasi lainnya.
Di titik inilah data pre-arrival bertemu dengan kebutuhan transportasi.
Dalam layanan trucking FTL MUAT Cargo, proses perencanaan dimulai dari data muatan seperti jenis barang, berat, dimensi setelah packing, origin, destination, rencana pickup, foto barang, kondisi akses lokasi, serta kebutuhan bongkar-muat. Data tersebut digunakan untuk memeriksa kebutuhan ruang, jenis kendaraan, rute, akses, dan penanganan.
Sementara pada layanan sewa gudang MUAT Cargo di Tangerang, customer diminta memberikan jenis, jumlah, berat, dimensi, foto, durasi, dan rencana barang masuk. MUAT kemudian memeriksa kapasitas, penempatan, akses, bongkar-muat, dan pola pengeluaran sebelum jadwal masuk dikonfirmasi.
| Data shipment/pre-arrival | Relevansi untuk koordinasi pengiriman |
|---|---|
| Jenis barang | Membantu memahami karakter muatan |
| Jumlah koli atau pallet | Memberi gambaran bentuk shipment |
| Berat | Memengaruhi kebutuhan kendaraan dan handling |
| Dimensi setelah packing | Membantu menilai ruang kendaraan |
| Origin dan destination | Menjadi dasar perencanaan pengiriman |
| Rencana pickup | Menentukan kesiapan origin |
| ETA/appointment receiving | Perlu diperhitungkan dalam perjalanan |
| Akses lokasi | Memengaruhi kecocokan kendaraan |
| Fasilitas bongkar | Menentukan kebutuhan koordinasi tambahan |
| Handling khusus | Perlu diinformasikan sebelum eksekusi |
| PO/ASN/reference | Membantu pengirim dan penerima mengenali shipment |
Tabel tersebut tidak berarti seluruh field ASN otomatis masuk ke sistem MUAT. Ini adalah pemetaan antara informasi pre-arrival yang dimiliki pengirim/penerima dengan data operasional yang memang relevan dalam perencanaan transportasi dan warehousing.
Jika perusahaan menggunakan EDI 856, DESADV, API, atau integrasi langsung ASN ke WMS, kebutuhan teknis tersebut perlu dikonfirmasi tersendiri. Saat ini tidak ada dasar publik yang cukup untuk menyatakan bahwa MUAT Cargo memiliki native EDI 856, DESADV, atau integrasi ASN otomatis dengan WMS customer.
Contoh: MUAT Mengirim Barang ke Distribution Center yang Meminta ASN
Sebagai ilustrasi, sebuah distributor akan mengirim 10 pallet sparepart dari supplier menuju distribution center. Penerima mewajibkan ASN dan appointment receiving sebelum kendaraan datang.
Supplier bertanggung jawab memastikan PO, SKU, quantity, packing structure, dan ASN yang dikirim kepada distribution center sesuai dengan shipment aktual. Untuk menyiapkan transportasi bersama MUAT Cargo, distributor juga memberikan berat, dimensi, jumlah pallet, lokasi pickup, destination, jadwal, akses, serta kebutuhan bongkar-muat.
PO awal terdiri dari 1.500 unit, tetapi setelah picking selesai hanya 1.440 unit yang siap diberangkatkan. ASN kemudian dibuat berdasarkan 1.440 unit tersebut.
Dari sisi penerima, ASN memberi gambaran bahwa akan datang 10 pallet dengan item dan quantity tertentu sehingga receiving dapat menyiapkan slot, area, dan resource yang diperlukan.
Dari sisi transportasi, MUAT menggunakan informasi fisik muatan dan kondisi lokasi untuk menilai kebutuhan kendaraan dan pelaksanaan pickup. Jika distribution center menetapkan appointment receiving pada waktu tertentu, jadwal tersebut perlu ikut diperhitungkan dalam koordinasi pengiriman.
Saat kendaraan tiba, petugas gudang menemukan quantity aktual hanya 1.438 unit dan salah satu pallet memiliki wrapping yang rusak. Receiving mencatat kondisi yang benar-benar ditemukan, bukan mengubahnya agar sama dengan ASN.
| Tahap | Quantity |
|---|---|
| Purchase Order | 1.500 unit |
| ASN | 1.440 unit |
| Actual receipt | 1.438 unit |
| Discrepancy ASN vs receipt | 2 unit |
Contoh ini bersifat ilustratif, bukan customer case MUAT. Tujuannya menunjukkan bahwa ASN, transportasi, dan receiving mempunyai tanggung jawab berbeda tetapi perlu menggunakan referensi shipment yang konsisten.
Apa yang Harus Dilakukan jika Barang Tidak Sesuai ASN?
ASN yang baik tidak membuat discrepancy mustahil terjadi. Justru ASN memberi baseline sehingga discrepancy dapat diketahui dan ditelusuri.
| Temuan saat receiving | Tindakan yang dapat dipertimbangkan |
|---|---|
| Quantity lebih sedikit | Catat actual receipt dan shortage |
| Quantity berlebih | Pisahkan atau konfirmasi sebelum diterima |
| SKU berbeda | Hold item yang tidak sesuai |
| Packing rusak | Dokumentasikan kondisi dan lakukan pemeriksaan |
| Pallet/label tidak sesuai | Periksa packing structure dan reference |
| ASN tidak ditemukan | Cari order/shipment reference dan lakukan exception handling |
| ASN duplikat | Validasi reference sebelum membuat receipt baru |
| Kendaraan datang di luar appointment | Koordinasikan ulang sesuai kapasitas dock |
| Barang membutuhkan handling berbeda | Tahan proses sampai resource dinyatakan sesuai |
X12 sendiri menggambarkan 856 Ship Notice/Manifest sebagai penghubung antara order dan delivery process. Pada X12 Supply Chain Transaction Flow, akurasi informasi shipment menjadi bagian penting agar proses berikutnya dapat berjalan dengan data yang benar.
Hubungan ASN dengan WMS dan TMS
ASN sering berkaitan dengan Warehouse Management System karena informasinya tersedia sebelum receiving terjadi.
WMS dapat menggunakan ASN untuk membuat atau memperkaya expected receipt, inbound load, packing structure, pallet/license plate, serta pekerjaan receiving sesuai desain sistem. Microsoft Dynamics 365, misalnya, mempunyai inbound ASN entities yang memuat shipment, packing structure, cases, item, quantity, dan license plate.
TMS berada di sisi yang berbeda. Fokusnya lebih dekat dengan transportasi: kendaraan, carrier, route, pickup, delivery, atau shipment execution. Pada operasi yang sudah terintegrasi, informasi dari order, ASN, WMS, dan TMS dapat saling terhubung.
SAP saat ini bahkan menampilkan hubungan antara inbound ASN/delivery, shipment, freight unit, tracking timeline, dan transportation route melalui Monitor Inbound ASNs. Ini memperlihatkan bagaimana ASN modern tidak berhenti pada receiving document, tetapi dapat menjadi bagian dari visibility antara warehouse dan transport operation.
Untuk memahami batas fungsi kedua sistem tersebut, MUAT juga membahas perbedaan WMS dan TMS.
EDI 856 dan GS1 DESADV: Apakah Sama dengan ASN?
Tidak semua ASN menggunakan format teknis yang sama.
X12 856 Ship Notice/Manifest
Dalam ekosistem X12, 856 Ship Notice/Manifest digunakan untuk mengomunikasikan informasi shipment dan konfigurasi barang. Struktur tersebut dapat membawa detail mulai dari shipment sampai packaging dan item.
GS1 DESADV
Dalam GS1, DESADV atau Despatch Advice digunakan untuk memberikan informasi trade item kepada trading partner sebelum physical delivery. Microsoft Dynamics 365 pada dokumentasi 2026 juga menggunakan terminologi despatch advice sebagai salah satu metode mengimpor inbound ASN melalui Despatch Advice.
Secara business purpose, semuanya berkaitan dengan pemberitahuan shipment sebelum receiving. Namun jangan menganggap X12 856, GS1 DESADV, XML, dan implementasi API perusahaan mempunyai struktur teknis yang identik.
Sebelum integrasi dilakukan, trading partner perlu menyepakati format, identifier, field mandatory, hierarchy shipment–pack–item, timing pesan, mekanisme koreksi, acknowledgment, serta exception handling.
ASN Tetap Relevan pada Warehouse Modern di 2026
ASN bukan konsep lama yang kehilangan relevansi setelah supply chain semakin digital.
Dokumentasi Microsoft untuk inbound ASN masih digunakan pada 2026 dan menempatkan ASN sebagai mekanisme agar warehouse mengetahui vendor delivery, isi shipment, packaging, serta keterkaitannya dengan purchase order atau inbound shipment order. Microsoft Dynamics 365 2026 release wave 1 juga menambahkan kemampuan receiving transfer order berbasis ASN pada warehouse management.
Oracle Cloud SCM 26B juga masih mempunyai Advance Shipment Notice Inbound, yang menjelaskan ASN sebagai pesan dari supplier kepada buyer ketika shipping terjadi agar buyer mendapatkan detail shipment dan dapat mempersiapkan penerimaan.
Perkembangan tersebut menunjukkan bahwa tujuan ASN tetap sama—memberi visibility sebelum receiving—sementara cara informasi tersebut diproses semakin terhubung dengan WMS, order management, transport management, scanning, dan workflow digital.
Checklist Data Sebelum Shipment Menuju Gudang
ASN formal mengikuti persyaratan buyer atau sistem yang digunakan. Namun dari sisi operasional, checklist berikut dapat membantu mencegah informasi penting baru dicari ketika kendaraan sudah tiba.
| Pemeriksaan | Status |
|---|---|
| PO/inbound reference sudah benar | □ |
| Identitas pengirim dan penerima sudah benar | □ |
| SKU/item shipment sudah final | □ |
| Quantity mengikuti barang yang benar-benar dikirim | □ |
| Jumlah pallet/karton/koli sudah diperiksa | □ |
| Packing structure tersedia jika diperlukan | □ |
| Berat dan dimensi sudah tersedia | □ |
| Shipment/carrier/vehicle reference sudah benar | □ |
| ETA atau appointment receiving sudah dikonfirmasi | □ |
| Akses kendaraan sudah diperiksa | □ |
| Forklift, crane, atau alat bantu diinformasikan | □ |
| Karakter barang khusus sudah disampaikan | □ |
| PIC origin dan destination dapat dihubungi | □ |
| Mekanisme koreksi jika ASN berubah sudah jelas | □ |
Untuk shipment yang menggunakan MUAT Cargo, data fisik barang, origin, destination, tanggal pickup, akses, serta kebutuhan bongkar-muat sebaiknya disampaikan sedini mungkin agar kebutuhan armada dan pelaksanaan pengiriman dapat diperiksa berdasarkan kondisi aktual.
KPI Apa yang Bisa Digunakan untuk Menilai ASN?
Keberhasilan ASN jangan diukur hanya dari “pesan berhasil dikirim”. Yang lebih penting adalah apakah informasi tersebut membantu receiving bekerja dengan data yang lebih akurat.
Beberapa KPI yang dapat dipertimbangkan adalah ASN timeliness, yaitu apakah ASN diterima sebelum cut-off yang ditentukan; ASN accuracy, yaitu kesesuaian SKU, quantity, packaging, dan reference dengan shipment aktual; discrepancy rate, yaitu seberapa sering advised quantity berbeda dari received quantity; serta dock-to-stock time, yaitu waktu sejak barang tiba hingga siap ditempatkan atau tersedia sesuai proses gudang.
KPI perlu disesuaikan dengan karakter fasilitas. Warehouse dengan beberapa shipment per hari tentu tidak dapat dibandingkan langsung dengan distribution center yang menerima banyak kendaraan, pallet, dan supplier.
Yang perlu dicari adalah apakah informasi sebelum kedatangan benar-benar mengurangi ketidakpastian dan exception pada receiving.
ASN yang Baik Harus Bisa Dipakai, Bukan Hanya Dikirim
Mengirim ASN tidak otomatis membuat receiving efisien. Jika quantity ASN dibuat sebelum actual packing selesai, pallet count tidak sesuai kondisi fisik, nomor order salah, ETA tidak diperbarui, atau informasi handling tidak tersedia, gudang tetap harus mencari ulang informasi ketika kendaraan datang.
Kualitas proses berada pada konsistensi antara:
order yang disepakati → shipment yang disiapkan → ASN yang dikirim → barang yang benar-benar datang → actual receipt yang dicatat.
Semakin konsisten rangkaian tersebut, semakin mudah procurement, supplier, transporter, dan warehouse mengetahui di titik mana sebuah discrepancy muncul.
Pengiriman Menuju Gudang dengan Persyaratan Receiving? Siapkan Datanya Sejak Awal
Advance Shipping Notice membantu proses inbound dimulai sebelum barang menyentuh loading dock. Dengan mengetahui shipment, SKU, quantity, packing, reference order, jadwal, serta informasi transportasi sebelumnya, warehouse mempunyai waktu untuk mempersiapkan receiving dan membandingkan barang aktual dengan informasi yang sudah diterima.
Bagi perusahaan yang menggunakan jasa transportasi, informasi tersebut juga tidak seharusnya berhenti di sistem procurement atau WMS. Berat, dimensi, jumlah pallet atau koli, origin, destination, appointment, akses lokasi, dan kebutuhan alat handling dapat memengaruhi bagaimana shipment dilaksanakan di lapangan.
Jika pengiriman Anda menuju warehouse, distribution center, pabrik, atau lokasi dengan appointment dan prosedur receiving tertentu, siapkan data barang dan persyaratan penerima sejak perencanaan. MUAT Cargo dapat membantu memeriksa kebutuhan transportasi, kendaraan, akses, jadwal, warehousing, dan handling berdasarkan kondisi muatan serta kebutuhan operasional yang tersedia.
FAQ Advance Shipping Notice
Apa kepanjangan ASN dalam warehouse?
ASN umumnya merujuk pada Advance Shipping Notice, Advance Shipment Notice, atau Advanced Shipping Notification tergantung terminologi sistem yang digunakan. Intinya adalah pemberitahuan shipment kepada penerima sebelum barang tiba.
Apakah ASN sama dengan packing list?
Tidak. Packing list menjelaskan isi dan struktur kemasan shipment. ASN merupakan pemberitahuan pre-arrival yang dapat menggunakan informasi dari packing list, tetapi keduanya tidak otomatis merupakan dokumen yang sama.
Apakah ASN harus menggunakan EDI 856?
Tidak. EDI 856 adalah transaction set X12 yang banyak digunakan untuk Ship Notice/Manifest, tetapi ASN dapat diimplementasikan melalui standar atau format lain sesuai kesepakatan trading partner, termasuk GS1 DESADV dan mekanisme integrasi lainnya.
Kapan ASN sebaiknya dikirim?
ASN harus tersedia cukup awal agar penerima dapat memproses informasinya sebelum receiving. Cut-off spesifik mengikuti ketentuan buyer, warehouse, atau trading partner karena tidak ada satu waktu universal untuk seluruh shipment.
Apakah ASN berarti barang sudah diterima?
Tidak. ASN menggambarkan shipment yang diberitahukan akan atau telah dikirim. Barang baru dianggap diterima setelah proses fisik receiving dan pencatatan actual receipt dilakukan.
Bagaimana jika quantity fisik berbeda dari ASN?
Gudang perlu mencatat quantity aktual dan discrepancy yang ditemukan, kemudian menjalankan prosedur konfirmasi, hold, atau exception handling yang berlaku. Actual receipt tidak seharusnya dipaksakan agar sama dengan ASN.
Apakah MUAT Cargo menangani pengiriman dengan persyaratan ASN?
MUAT Cargo dapat menangani kebutuhan transportasi dan warehousing berdasarkan data barang, origin, destination, akses, jadwal, serta kebutuhan handling yang dikonfirmasi. Jika penerima mensyaratkan ASN atau appointment sebelum kendaraan datang, informasikan persyaratan tersebut sejak perencanaan. Untuk kebutuhan integrasi teknis seperti EDI 856, DESADV, API, atau koneksi langsung ke WMS, kapabilitasnya perlu dikonfirmasi secara khusus terlebih dahulu.