Konfigurasi ERP Penjualan & Distribusi

Lecture Note Pertemuan ke-7

(Unit 10: Goods Issue Posting)

Capaian mata kuliah

1. Mahasiswa mampu memahami dan menjelaskan pengaturan customizing untuk organizational structure di
penjualan dan distribusi.
2. Mahasiswa mampu memahami dan menjelaskan pengaturan customizing untuk mengelola transaksi dan
dokumen di penjualan dan distribusi.
3. Mahasiswa mampu memahami dan menjelaskan penyesuaian sistem dengan pengaturan customizing untuk
memenuhi kebutuhan spesifik di penjualan dan distribusi.

Tim Teaching
1. Catherine, S.Kom., M.MSI.

References
1. SAP AG, SCM610 – mySAP Supply Chain Management. SAP AG, 2003.
2. SAP AG, TSCM60 – Order Fulfillment I. SAP AG, 2009.

STMIK Mikroskil 2021

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

Unit ini merupakan kesimpulan dari rantai proses pengiriman, yaitu proses posting goods issue, dimana
menjelaskan efek dan transfer data dari Sales and Distribution ke komponen Material Management dan
Financial Accounting, serta memberikan informasi terkait prosedur dan fungsi yang tersedia untuk membatalkan
efek dari posting goods issue dan proses Quality Management untuk outbound delivery. Selain itu, juga
menjelaskan bagaimana menggunakan Bukti Pengiriman (POD).

SLIDE KE-8

PENJELASAN DARI SLIDE KE-8

Goods issue posting pada outbound delivery menyelesaikan kegiatan pengiriman. Goods issue posting
mensyaratkan bahwa semua kegiatan pengiriman yang wajib telah dilakukan. Misalnya, jika bekerja dengan
picking relevance dan kebutuhan konfirmasi, maka langkah-langkah tersebut harus terlebih dahulu diselesaikan.
Goods issue dapat di-post dengan mengubah outbound delivery tunggal, atau menggunakan fungsi pemrosesan
kolektif untuk memilih semua pengiriman dimana goods issue sudah waktunya untuk di-post. Atau, untuk
melakukannya juga dapat menggunakan outbound delivery monitor. Goods issue juga dapat di-post pada saat
transfer order dikonfirmasi.

Pada saat memroses outbound delivery tunggal, tanggal aktual goods issue dapat ditentukan tanpa mengubah
tanggal rencana. Kotak dialog akan muncul dimana tanggal aktual goods issue dapat dimasukkan, kemudian
goods issue akan di-post pada tanggal tersebut. Dokumen goods issue terkait kemudian di-post dengan
menggunakan tanggal aktual goods issue. Jika tidak ada spesifikasi eksplisit yang dibuat pada tanggal goods
issue, maka tanggal saat ini yang digunakan sebagai tanggal goods issue.

Goods issue berlaku untuk keseluruhan outbound delivery. Kesalahan apapun dicatat ketika, misalnya, data
seperti batch atau nomor seri hilang atau ketika picking belum sepenuhnya dilakukan untuk item. Pada kasus
ini, goods issue tidak akan di-post.

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

SLIDE KE-11

PENJELASAN DARI SLIDE KE-11

Setelah goods issue di-post, maka adanya keterbatasan untuk mengubah outbound delivery. Secara khusus,
perubahan pada kuantiti tidak dapat dilakukan lagi. Pada saat pemrosesan di tahapan ini, dokumen pengiriman
harus mencerminkan pengiriman aktual secara fisik.
Efek-efek dari goods issue:
 Memperbarui persediaan berdasarkan kuantiti:
Persediaan gudang dikurangi dengan jumlah pengiriman; dokumen MM dihasilkan.
 Memperbarui akun neraca berdasarkan nilai:
Pembuatan dokumen akuntansi FI yang melakukan posting berbasis nilai di neraca dan akun perubahan
persediaan.
 Persyaratan pengiriman berkurang.
 Memasukkan informasi status dalam outbound delivery.
 Entri otomatis dalam document flow.
 Outbound delivery muncul dalam billing due list (dalam kasus tagihan terkait pengiriman); jika POD
digunakan, maka dokumen tagihan tidak dapat diproses sampai setelah konfirmasi diterima.

Untuk melakukan billing sebelum goods issue dengan menggunakan transaksi "Create billing document",
pengaturan yang sesuai dapat dilakukan dalam copy control di Customizing. Jika menginginkan tagihan dapat
dibuat sebelum mem-post goods issue, maka pilih copy condition 11 ("Header delivery-related w/o GI"), dimana
terletak di copy control untuk penagihan di level header. Akan tetapi, pengiriman hanya akan muncul dalam
indeks penagihan setelah goods issue. Dalam hal ini, tagihan hanya dapat dibuat secara terpisah.

Jika outbound delivery akan diproses berdasarkan delivery due list sebelum goods issue terjadi, maka diperlukan
modifikasi, atau dapat menggunakan User Exit dalam program LV051FLK.

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

SLIDE KE-13

PENJELASAN DARI SLIDE KE-13

Jika terdapat material yang rusak selama proses loading dan goods issue telah di-post tanpa menyesuaikan
jumlah pengiriman, maka delivery note dan tagihan akan berisi kuantiti yang salah. Pada kasus seperti itu, goods
issue dapat dibatalkan. Kasus lainnya dimana goods issue dapat dibatalkan adalah ketika bekerja tanpa
persyaratan konfirmasi untuk picking dan konfirmasi jumlah yang di-pick tidak sengaja dimasukkan setelah
goods issue di-post.

Goods issue dapat dilakukan dalam satu langkah untuk semua pengiriman yang terkandung dalam satu transfer
order (misalnya pengiriman dengan truk) atau dalam picking wave. Setelah pembatalan, pengiriman dapat
diproses dengan cara yang sama seperti pemrosesan sebelum goods issue di-post.

Jika goods issue untuk outbound delivery dibatalkan, maka posting goods issue akan diatur ulang. Sistem akan
menyalin kuantiti dan nilai dari dokumen goods issue asli dan melakukan posting persediaan berdasarkan
kuantiti dan nilai tersebut dengan penanda terbalik +/-.

Jika goods issue dibatalkan, maka akan mempengaruhi keseluruhan outbound delivery. Dokumen pembatalan
yang dibuat pada saat pembatalan akan dimasukkan dalam document flow pada outbound delivery. Setelah
goods issue dibatalkan, status perpindahan barang dari outbound delivery diatur ulang menjadi "Not yet
started", sehingga memungkinkan untuk memroses kembali outbound delivery seperti biasa. Kebutuhan
pengiriman juga dibuat kembali.

Membatalkan goods issue melibatkan dua langkah jika outbound delivery sudah sepenuhnya atau sebagian
ditagih. Dalam hal ini, dokumen billing harus dibatalkan terlebih dahulu. Setelah itu, goods issue dapat
dibatalkan. Untuk setiap movement type dalam MM Inventory Management, movement type reversal harus
didefinisikan dalam Customizing. Tidak diperlukan pengaturan tambahan untuk movement type yang digunakan
untuk mem-posting goods issue dalam sistem standar.

Jika goods issue dibatalkan, maka sistem mencoba untuk membalikkan keseluruhan proses. Namun, pembalikan
lengkap dari dokumen akuntansi asli tidak selalu dimungkinkan. Ini berlaku, misalnya, untuk material dengan

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

harga standar, ketika harga standar telah berubah antara posting asli dan posting pembalikan. Posting akan
sepenuhnya dibalik untuk material dengan price control V. Hasilnya adalah harga baru tidak akan digunakan.

SLIDE KE-16

PENJELASAN DARI SLIDE KE-16

Pada layar pemilihan, satu atau lebih outbound delivery dapat dipilih untuk di-batalkan goods issue-nya. Selain
nomor outbound delivery, shipping point, route, tanggal goods issue, nomor group dari sekumpulan outbound
deliverry, dan nomor pengiriman dapat dimasukkan sebagai kriteria seleksi.

Pada daftar outbound delivery yang dipilih, tanggal selain tanggal saat ini dapat ditentukan untuk setiap
pengiriman, asalkan tanggalnya sebelum tanggal goods issue. Dengan mengklik dua kali pada item di dalam
daftar, maka dapat langsung beralih ke outbound delivery. Sistem akan menghasilkan log untuk pembatalan
dan kesalahan yang mungkin terjadi.

SLIDE KE-18

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

PENJELASAN DARI SLIDE KE-18

SAP R/3 Quality Management (QM) mendukung Sales and Distribution (SD) dengan pengecekan kualitas untuk
goods issue (misalnya, pengecekan pada saat pengemasan barang). Pengaturan dilakukan pada view Quality
Management dari material master jika pengecekan kualitas akan dilakukan pada material tersebut.

Komponen QM mendukung proses pengiriman dengan melakukan pemeriksaan selama proses pengiriman.
Masalah yang signifikan adalah efek dari pengecekan yang belum selesai pada goods issue. Sertifikat yang
disediakan oleh QM yang dapat ditambahkan ke outbound delivery juga penting.

Ketika outbound delivery dibuat di SD, QM secara otomatis membuat lot inspeksi untuk item pengiriman yang
relevan untuk diinspeksi. Lot inspeksi memberitahukan departemen jaminan kualitas bahwa barang tersebut
perlu diinspeksi. Hasil inspeksi dapat disimpan dalam sistem dengan berbagai cara. Jika barang rusak, maka
catatan cacat dapat dimasukkan. Nilai yang diukur atau kode evaluasi akan disimpan sebagai nilai karakteristik.
Jenis dan prosedur yang digunakan oleh inspeksi direncanakan di data master QM. “Usage decision” mewakili
penyelesaian dari inspeksi QM. Di sinilah barang yang diperiksa diterima untuk digunakan lebih lanjut atau
ditolak.

Tergantung pada pelanggan, atau pada pelanggan dan material bersama-sama, log inspeksi dapat menentukan
apakah harus diterima sebelum goods issue dapat di-post. Jika tidak boleh diterima, maka departemen jaminan
kualitas dapat menyerahkan hasil inspeksi setelah goods issue di-post. Pencetakan sertifikat kualitas dapat
dilakukan dari output control outbound delivery pada level item. Fungsi ini terutama digunakan untuk material
yang ditangani dalam batch.

Selain pemeriksaan yang dijelaskan sebelumnya, terdapat juga pemeriksaan lain yang terlibat dalam produksi.
Sertifikat yang dilampirkan juga dapat digunakan untuk mencetak hasil dari pemeriksaan lainnya. Sejak Release
4.0A, bahkan dimungkinkan untuk memasukkan data dari pemeriksaan komponen selain data produk akhir.

Dimungkinkan juga untuk menghasilkan sertifikat tanpa pemeriksaan. Misalnya, dimungkinkan untuk
menghasilkan sertifikat yang hanya berisi data dari kelas-kelas batch.

SLIDE KE-21

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

PENJELASAN DARI SLIDE KE-21

Proof of Delivery/Bukti pengiriman (POD) dikembangkan sebagai fungsi baru pada rilis 4.6A, dimana pada
dasarnya dirancang untuk mendukung proses pembuatan tagihan setelah pelanggan mengkonfirmasi
kedatangan barang. Setelah goods issue di-post memungkinkan ship-to party untuk mengkonfirmasi kuantiti
yang sebenarnya diterima untuk outbound delivery atau menentukan perbedaan dan memberikan alasannya.
Hal ini sangat diperlukan dalam kasus dimana kuantiti pengiriman bervariasi karena sifat dari barang atau
dimana kuantiti pengiriman yang tepat tidak diketahui sebelumnya.

Sebagai hasil menerima konfirmasi dari ship-to party, faktur dapat dibuat untuk jumlah tepat yang terhutang
berdasarkan kuantiti yang sebenarnya telah dikirim ke pelanggan, sehingga tidak diperlukan lagi untuk
membuat memo kredit. Alasan perbedaan yang terjadi dalam praktik, seperti susut, kebocoran, pencurian, sifat-
sifat tertentu dari barang, misalnya, volatilitas, dan kerusakan dalam perjalanan, disimpan dalam sistem dan
dievaluasi. Saat bernegosiasi dengan forwarding agent, vendor, atau pelanggan, evaluasi ini sangat bernilai
karena semua perbedaan dapat dilihat secara tepat.

Setelah menerima barang, ship-to party akan mentransfer bukti pengiriman melalui IDoc ke SAP R/3 Enterprise,
dengan demikian mengkonfirmasi kuantiti untuk keseluruhan pengiriman. Dalam kebanyakan kasus dimana
tidak terjadi perbedaan kuantiti barang, verifikasi dan konfirmasi akan diotomatisasi dengan menggunakan
IDoc. Jika dilaporkan adanya selisih, maka pengiriman tidak dapat secara otomatis dikonfirmasi. Dalam hal ini
akan dilanjutkan dengan pemrosesan secara manual.

Dokumen dapat diproses dengan menggunakan worklist bersamaan dengan POD: “Outbound deliveries for POD”
dan “Subsequent processing for POD”. Sistem membuat dokumen billing berdasarkan jumlah yang benar atau
diverifikasi. Pembuatan dokumen billing menggunakan billing due list akan diblok sampai bukti pengiriman telah
dikonfirmasi.

Bukti pengiriman dirancang khusus untuk pelanggan eksternal untuk mengkonfirmasi pengiriman. Prosedur
dalam kasus outbound delivery yang relevan dengan POD:
 Outbound delivery dibuat dan di-pick, serta goods issue di-post. Jika relevan dengan POD, maka akan
memiliki status POD yang di-set ke "A" (tidak diproses) sebelum konfirmasi diberikan.
 Pelanggan biasanya memberikan POD melalui IDoc; namun, juga dapat dimasukkan secara manual.
Pelanggan melaporkan kuantiti yang diterima untuk outbound delivery bersamaan dengan perbedaan
kuantiti dan alasannya.
 Jika terjadi perbedaan, maka status POD adalah B (dikonfirmasi dengan perbedaan); jika tidak, maka
statusnya adalah C (dikonfirmasi).
 Dalam hal penyimpangan, POD harus dikonfirmasi secara manual; hal ini mengubah status POD ke C
(dikonfirmasi).
 Prosesnya membutuhkan postprocessing secara manual (posting koreksi); posting koreksi secara otomatis
berdasarkan POD tidak dimungkinkan.
 Hanya ketika status POD adalah C maka outbound delivery dapat ditagih.

Tersedia worklist untuk konfirmasi manual dan postprocessing manual, dimana memungkinkan untuk memilih,
mendaftarkan, dan bekerja dengan POD.

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

Sebelum menggunakan fungsi bukti pengiriman, perlu ditentukan delivery item category yang relevan untuk
proses POD. Perlu juga ditentukan alasan untuk penyimpangan, dan di dalam data master pelanggan yang
digunakan untuk proses POD, aktifkan “POD relevant”. Jumlah dan alasan penyimpangan juga dapat dianalisis
(di mana, kapan, dan mengapa penyimpangan terjadi?). Pengaturan berikut harus dibuat di IMG pada menu
Logistics Execution → Shipping → Deliveries → Proof of Delivery:
 Setiap delivery item category harus ditentukan apakah relevan untuk proses POD. SAP merekomendasikan
bahwa semua item category yang termasuk dalam jenis pengiriman harus diidentifikasi relevan dengan POD.
 Tentukan alasan untuk perbedaan.
 Pada sales area data dari pelanggan yang terlibat dalam proses POD, indikator "POD relevant" diatur pada
view "Shipping".

Bukti pengiriman menggunakan IDoc DELVRY3. Jika perbedaan terjadi, maka segmen untuk penerimaan tanda
terima E1EDL53 harus diselesaikan sebagai tambahan pada segmen dari delivery header E1EDL20 dan delivery
item E1EDL24. Pada segmen ini, ship-to party memasukkan alasan perbedaan, ukuran perbedaan dalam unit
pengiriman atau unit kuantiti penyimpanan, dan unit pengukuran yang terkait. Bukti pengiriman diselesaikan
untuk keseluruhan pengiriman. Jika tidak ada perbedaan, maka segmen E1EDL20 dan E1EDL24 harus
diselesaikan.

Untuk item-item batch split, bukti pengiriman hanya diselesaikan untuk item level rendah karena batch yang
relevan diperlukan sebagai informasi di sini. Item batch utama dikonfirmasi tanpa perbedaan.

Demonstration: Proof of Deliverry

1. Setting di Customizing untuk proof of delivery.
IMG: Logistics Execution → Shipping → Deliveries → Proof of Deliverry → Set POD-Relevance Depending on
Delivery Item Category

IMG: Logistics Execution → Shipping → Deliveries → Proof of Deliverry → Define Reasons for Quantity
Differences

[Sistem Informasi – ES]

 Konfigurasi ERP Penjualan & Distribusi
Lecture Note Pertemuan ke-7
(Unit 10: Goods Issue Posting)

2. Mengidentifikasi customer 2146 (Sales Area: 1000/12/00) sebagai POD-relevant.

Logistics → Logistics Execution → Master Data → Partner → Customer → Change → Sales and Distribution

[Sistem Informasi – ES]