Templat data pemrosesan retur dan pengembalian dana Anda
Templat data pemrosesan retur dan pengembalian dana Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi
Atribut pemrosesan retur dan pengembalian dana
| Nama | Deskripsi | ||
|---|---|---|---|
| ID kasus pengembalian ReturnCaseId | Pengenal unik untuk satu proses pengembalian pelanggan, yang menghubungkan semua aktivitas terkait dari awal hingga selesai. | ||
| Deskripsi ID kasus pengembalian menjadi pengenal utama untuk mengelompokkan semua peristiwa dan aktivitas dalam satu kasus pengembalian. Setiap permintaan pengembalian pelanggan mendapat ID unik agar seluruh proses dapat dilacak dari awal hingga selesai. Dalam process mining, atribut ini menjadi dasar untuk merekonstruksi alur proses. Dengan menghubungkan peristiwa yang berbeda, seperti 'Permintaan pengembalian diajukan', 'Barang diterima', dan 'Pengembalian dana diproses', ke dalam satu rangkaian waktu untuk setiap retur, Anda dapat menganalisis durasi kasus, variasi proses, dan hambatan. Mengapa ini penting Kunci penting untuk melacak pengembalian dari awal hingga selesai. Kunci ini mendukung semua analisis di tingkat kasus, termasuk waktu siklus dan penemuan variasi proses. Sumber data Biasanya berupa nomor dokumen penjualan (VBELN) dari tabel header pesanan retur VBAK, dengan kategori dokumen (VBTYP) yang menunjukkan retur. Contoh 600001896000019060000191 | |||
| Nama aktivitas ActivityName | Nama aktivitas bisnis atau peristiwa tertentu yang terjadi dalam proses pengembalian dan pengembalian dana. | ||
| Deskripsi Atribut ini menjelaskan satu langkah atau tonggak dalam siklus pengembalian. Aktivitas menggambarkan pekerjaan yang dilakukan, seperti 'Pesanan retur disetujui' atau 'Pemeriksaan barang selesai'. Aktivitas ini diperoleh dari perubahan status, pembuatan dokumen, atau tindakan pengguna tertentu yang tercatat di SAP S/4HANA. Menganalisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan peta proses, menemukan jalur proses yang umum maupun jarang, serta menunjukkan aktivitas yang sering diulang dan menandakan pengerjaan ulang atau inefisiensi. Mengapa ini penting Aktivitas menjadi dasar peta proses untuk memvisualisasikan dan menganalisis alur proses, hambatan, serta variasinya. Sumber data Nama aktivitas biasanya ditentukan dari gabungan beberapa data, seperti perubahan status dokumen di tabel VBUK/VBUP, peristiwa pembuatan di tabel header seperti VBAK (dokumen penjualan) dan BKPF (dokumen akuntansi), serta status pergerakan barang di MSEG. Contoh Permintaan pengembalian diajukanBarang diterima di gudangNota kredit dibuatPengembalian dana diproses | |||
| Waktu peristiwa EventTime | Stempel waktu yang menunjukkan secara tepat kapan aktivitas tertentu terjadi. | ||
| Deskripsi Waktu peristiwa mencatat tanggal dan waktu saat peristiwa bisnis direkam di sistem. Stempel waktu ini penting untuk mengurutkan aktivitas secara kronologis dan melakukan semua analisis berbasis waktu. Dalam process mining, atribut ini digunakan untuk menghitung waktu siklus antaraktivitas, mengukur durasi setiap langkah, dan menganalisis kinerja proses dari waktu ke waktu. Data ini menjadi dasar untuk menemukan hambatan, memantau kepatuhan terhadap SLA, dan memahami perubahan proses pengembalian dari waktu ke waktu. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa, menghitung durasi dan waktu siklus, serta menemukan keterlambatan proses. Sumber data Biasanya diambil dari kolom tanggal dan waktu yang terkait dengan pembuatan dokumen atau perubahan status, seperti ERDAT (Tanggal Pembuatan) dan ERZET (Waktu Pembuatan) di tabel VBAK, LIKP, dan BKPF, atau tanggal posting (BUDAT) di dokumen akuntansi. Contoh 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID sistem sumber SourceSystemId | Pengenal sistem sumber tempat data diekstrak. | ||
| Deskripsi Atribut ini menunjukkan sistem pencatatan asal data peristiwa. Untuk proses ini, biasanya berupa ID instans SAP S/4HANA. Di lingkungan dengan beberapa sistem, kolom ini penting untuk melacak asal-usul data, memecahkan masalah, dan memastikan integritas data. Kolom ini membantu membedakan data jika retur diproses di beberapa instans ERP atau terhubung dengan sistem eksternal, seperti sistem manajemen gudang. Mengapa ini penting Memberikan konteks penting tentang asal dan riwayat data, terutama di lingkungan dengan beberapa sistem, sehingga data dapat dilacak dan dipercaya. Sumber data Nilai ini biasanya tetap dan dikonfigurasi saat ekstraksi data. Nilai ini dapat diambil dari informasi administratif sistem SAP, seperti System ID (SID). Contoh S4H_PROD_100S4Q_DEV_200 | |||
| Pembaruan data terakhir LastDataUpdateTimestamp | Stempel waktu yang menunjukkan kapan data untuk peristiwa ini terakhir diperbarui atau diekstrak. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu ekstraksi atau pembaruan data terakhir. Informasi ini menunjukkan seberapa baru data yang dianalisis. Atribut ini membantu Anda memahami kemutakhiran analisis process mining. Pengguna dapat melihat seberapa baru data yang tersedia. Hal ini terutama penting untuk pemantauan operasional dan dashboard yang melacak kasus yang sedang berjalan. Mengapa ini penting Menunjukkan kemutakhiran data, yang penting agar analisis dan dashboard menggunakan informasi terbaru. Sumber data Biasanya, alat ETL atau alur data membuat dan menambahkan stempel waktu ini ke kumpulan data saat ekstraksi. Contoh 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Alasan pengembalian ReturnReason | Alasan yang diberikan pelanggan untuk mengembalikan barang. | ||
| Deskripsi Atribut ini mencatat alasan yang disampaikan pelanggan untuk mengembalikan barang, seperti 'Barang cacat', 'Ukuran salah', atau 'Tidak lagi dibutuhkan'. Biasanya, pelanggan memilih alasan dari daftar kode yang telah ditentukan saat mengajukan pengembalian. Menganalisis alasan pengembalian penting untuk menemukan masalah kualitas produk, memperbaiki deskripsi produk, atau menyempurnakan proses penjualan. Informasi ini memberi gambaran langsung tentang ketidakpuasan pelanggan dan membantu menentukan prioritas perbaikan bisnis untuk menurunkan tingkat pengembalian. Mengapa ini penting Memberi gambaran penting tentang penyebab pengembalian, sehingga akar masalah terkait kualitas produk, kesalahan pemenuhan pesanan, atau perbedaan ekspektasi pelanggan dapat ditemukan. Sumber data Biasanya disimpan di tabel item pesanan penjualan retur (VBAP), pada kolom ABGRU (Alasan penolakan dokumen penjualan). Contoh 001 - Kualitas buruk002 - Rusak dalam pengiriman005 - Barang yang dikirim tidak sesuai | |||
| ID pelanggan CustomerId | Pengenal unik untuk pelanggan yang mengajukan pengembalian. | ||
| Deskripsi Atribut ini menunjukkan pelanggan yang meminta pengembalian. Atribut ini menghubungkan satu kasus proses dengan pihak tertentu dalam data master pelanggan. Menganalisis pengembalian berdasarkan pelanggan membantu menemukan pola, seperti pelanggan dengan tingkat pengembalian yang tidak biasa tingginya, yang mungkin menandakan penipuan atau ketidakpuasan. Anda juga dapat mengelompokkan proses pengembalian berdasarkan jenis, nilai, atau riwayat pelanggan untuk menyesuaikan tingkat layanan. Mengapa ini penting Menghubungkan pengembalian dengan pelanggan tertentu, sehingga perilaku pelanggan dan segmentasi dapat dianalisis serta pelanggan yang sering mengembalikan barang dapat ditemukan. Sumber data Terdapat di kolom nomor pelanggan (KUNNR) pada tabel header pesanan retur (VBAK). Contoh CUST-001234CUST-005678CUST-009012 | |||
| ID produk ProductId | Pengenal unik untuk barang yang dikembalikan. | ||
| Deskripsi Atribut ini menunjukkan material atau produk yang dikembalikan. Atribut ini menghubungkan proses pengembalian dengan barang tertentu di katalog produk. Menganalisis pengembalian berdasarkan produk penting untuk menemukan barang dengan tingkat pengembalian tinggi, yang mungkin menandakan cacat kualitas, deskripsi produk yang kurang jelas, atau masalah produksi. Data ini membantu bisnis mengambil keputusan terkait desain produk, pengelolaan pemasok, dan strategi inventaris. Mengapa ini penting Menghubungkan proses pengembalian dengan produk tertentu, sehingga tingkat pengembalian per barang dapat dianalisis dan masalah kualitas atau deskripsi dapat ditemukan. Sumber data Terdapat di kolom nomor material (MATNR) pada tabel item pesanan retur (VBAP) atau tabel item pengiriman retur (LIPS). Contoh FG-10023HW-45981SW-LICENSE-PREM | |||
| Jumlah pengembalian dana RefundAmount | Nilai akhir pengembalian dana yang diberikan kepada pelanggan. | ||
| Deskripsi Atribut ini menunjukkan jumlah yang benar-benar dikreditkan atau dikembalikan kepada pelanggan setelah proses pengembalian selesai. Nilai ini tercatat di dokumen keuangan, seperti nota kredit. Ini adalah metrik keuangan penting untuk berbagai analisis. Metrik ini diperlukan oleh dashboard 'Analisis selisih jumlah pengembalian dana' untuk membandingkan jumlah yang diminta dengan jumlah yang dibayarkan. Anda juga dapat mengelompokkan retur berdasarkan nilai untuk mengetahui apakah retur bernilai tinggi mengikuti proses yang berbeda atau membutuhkan waktu lebih lama. Mengapa ini penting Melacak dampak keuangan dari pengembalian dan penting untuk menganalisis keakuratan pengembalian dana, menemukan kasus bernilai tinggi, serta memahami biaya keseluruhan. Sumber data Diambil dari kolom nilai bersih (NETWR) pada dokumen nota kredit, yang terdapat di tabel seperti VBRK (Header Dokumen Penagihan) atau BSEG (Segmen Dokumen Akuntansi). Contoh 125.50999.0049.99 | |||
| Nama pengguna UserName | ID pengguna karyawan yang menjalankan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan pengguna atau agen sistem yang bertanggung jawab menyelesaikan tugas, seperti menyetujui retur atau membuat nota kredit. Di SAP, informasi ini biasanya tercatat di kolom yang menyimpan pengguna yang membuat atau mengubah dokumen. Analisis berdasarkan pengguna membantu menemukan individu atau tim berkinerja tinggi, kebutuhan pelatihan, dan pembagian beban kerja. Informasi ini juga penting untuk menyelidiki penyimpangan karena menghubungkan tindakan dalam proses dengan orang tertentu, sehingga mendukung kepatuhan dan audit. Mengapa ini penting Mengaitkan aktivitas proses dengan pengguna tertentu, sehingga kinerja tim, beban kerja, dan kepatuhan dapat dianalisis. Sumber data Informasi ini biasanya ditemukan di tabel header dokumen, seperti ERNAM (Dibuat oleh) di VBAK (Pesanan Penjualan), LIKP (Pengiriman), dan BKPF (Dokumen Akuntansi). Detail pengguna dapat dilengkapi dari tabel master pengguna USR21. Contoh CBROWNASMITHWF_BATCH | |||
| Waktu akhir peristiwa EventEndTime | Stempel waktu yang menandai selesainya suatu aktivitas dan digunakan untuk menghitung durasinya. | ||
| Deskripsi StartTime (EventTime) menandai awal aktivitas, sedangkan EventEndTime menandai akhirnya. Untuk banyak peristiwa yang dibuat sistem, waktu mulai dan selesai sama karena peristiwanya terjadi seketika. Namun, atribut ini penting untuk aktivitas yang memiliki durasi terukur, seperti 'Pemeriksaan barang'. Atribut ini memungkinkan penghitungan langsung waktu pemrosesan aktivitas. Ini penting untuk analisis kinerja karena membantu menemukan langkah tertentu yang paling banyak menyita waktu, bukan hanya jeda di antara langkah. Mengapa ini penting Memungkinkan penghitungan durasi setiap aktivitas secara tepat, sehingga inefisiensi pada langkah proses tertentu dapat ditemukan. Sumber data Nilai ini sering kali diturunkan. Untuk beberapa aktivitas, nilainya mungkin tersedia di kolom terpisah. Namun, biasanya nilai ini menggunakan StartTime aktivitas berikutnya dalam kasus yang sama. Contoh 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Hasil inspeksi barang ItemInspectionOutcome | Hasil pemeriksaan fisik barang yang diretur. | ||
| Deskripsi Atribut ini mencatat hasil inspeksi setelah barang diterima di gudang. Hasil yang umum antara lain 'Diterima', 'Ditolak - Rusak', atau 'Diterima - Dapat dijual kembali'. Data ini memberi konteks penting untuk langkah proses berikutnya. Hasil inspeksi menentukan apakah pengembalian dana diberikan penuh, sebagian, atau tidak diberikan. Analisis hasil ini membantu menemukan penyebab penolakan dan memberi masukan terkait kemasan produk atau mitra pengiriman jika barang sering rusak dalam perjalanan. Mengapa ini penting Menjelaskan dasar keputusan untuk menyetujui atau menolak pengembalian dana, sekaligus memberikan data tentang kondisi barang dan alasan penyesuaian jumlah pengembalian dana. Sumber data Informasi ini mungkin tercatat dalam lot inspeksi di modul manajemen kualitas (QM), atau sebagai status maupun kode alasan pada item baris pengiriman retur (LIPS). Informasi ini juga mungkin tersimpan di kolom khusus. Contoh Diterima - Dapat dijual kembaliDiterima - Perlu diperbaruiDitolak - Kerusakan akibat pelangganDitolak - Barang yang dikembalikan salah | |||
| ID Kebijakan Retur ReturnPolicyId | ID kebijakan retur yang berlaku untuk kasus retur ini. | ||
| Deskripsi Atribut ini menunjukkan kebijakan retur atau kumpulan aturan yang berlaku untuk transaksi. Kebijakan dapat berbeda berdasarkan jenis produk, segmen pelanggan, atau waktu sejak pembelian. Data ini penting untuk 'Ikhtisar Kepatuhan Kebijakan Retur'. Dengan mengaitkan setiap kasus ke kebijakan yang berlaku, sistem dapat memeriksa kepatuhan terhadap aturan secara otomatis, seperti batas waktu retur atau persyaratan kondisi barang, lalu menandai penyimpangan untuk dianalisis. Mengapa ini penting Memungkinkan pemeriksaan kepatuhan terhadap aturan bisnis secara otomatis, sehingga retur diproses secara konsisten sesuai kebijakan. Sumber data Kolom ini biasanya tidak tersedia sebagai kolom standar SAP. Nilainya mungkin perlu ditentukan berdasarkan logika bisnis dan data seperti jenis produk, pelanggan, serta tanggal penjualan. Jika diterapkan, nilainya dapat disimpan di kolom khusus. Contoh STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Jumlah pengembalian dana yang diminta RequestedRefundAmount | Jumlah pengembalian dana yang diminta atau diperkirakan pada awal proses. | ||
| Deskripsi Atribut ini mencatat nilai barang yang dikembalikan berdasarkan permintaan awal. Nilai ini menjadi acuan untuk dibandingkan dengan jumlah akhir yang dikembalikan. Kolom ini diperlukan khusus untuk dashboard 'Analisis selisih jumlah pengembalian dana'. Membandingkan jumlah yang diminta dengan jumlah pengembalian dana sebenarnya membantu menemukan masalah, seperti pengembalian sebagian karena barang rusak, biaya pengisian ulang stok, atau penyesuaian lain. Dengan begitu, keakuratan dan transparansi keuangan tetap terjaga. Mengapa ini penting Menjadi acuan untuk mengukur akurasi pengembalian dana serta membantu menemukan dan menganalisis selisih antara nilai pengembalian dana yang diharapkan dan yang sebenarnya. Sumber data Biasanya diambil dari nilai neto item pada pesanan penjualan retur awal. Nilai ini adalah nilai neto (NETWR) dari item baris terkait di tabel VBAP. Contoh 125.501050.0049.99 | |||
| Kepatuhan SLA pengembalian dana RefundSlaAdherence | Penanda yang menunjukkan apakah pengembalian dana diproses sesuai target Service Level Agreement (SLA). | ||
| Deskripsi Atribut hasil perhitungan ini memeriksa apakah aktivitas 'Pengembalian Dana Diproses' terjadi pada atau sebelum 'Tanggal Target SLA Pengembalian Dana'. Atribut ini menunjukkan secara sederhana apakah setiap kasus memenuhi SLA. Atribut ini menjadi metrik utama untuk dasbor 'Pemantauan Kepatuhan SLA Pengembalian Dana' dan KPI 'Tingkat Kepatuhan SLA Pengembalian Dana'. Atribut ini membantu mengukur kinerja terhadap komitmen kepada pelanggan dan menemukan kasus yang tidak memenuhi harapan, sehingga penyebab keterlambatan dapat dianalisis. Mengapa ini penting Mengukur langsung kinerja terhadap komitmen kepada pelanggan. Karena itu, atribut ini menjadi indikator penting kualitas layanan dan kepuasan pelanggan. Sumber data Dihitung dengan membandingkan EventTime aktivitas 'Pengembalian Dana Diproses' dengan 'RefundSlaTargetDate' untuk setiap kasus. Contoh truefalse | |||
| Kepatuhan terhadap kebijakan pengembalian ReturnPolicyAdherence | Penanda yang menunjukkan apakah kasus retur mematuhi kebijakan retur yang ditetapkan. | ||
| Deskripsi Atribut boolean hasil perhitungan ini menunjukkan apakah retur memenuhi kriteria dalam kebijakan yang berlaku. Logikanya dapat memeriksa, misalnya, apakah retur diajukan dalam batas waktu yang diizinkan atau apakah alasan retur sesuai untuk produk tersebut. Atribut ini mendukung dasbor 'Ikhtisar Kepatuhan Kebijakan Retur'. Atribut ini mengukur tingkat kepatuhan dan memungkinkan Anda menelusuri kasus yang tidak patuh untuk memahami penyebab penyimpangan, sehingga kebijakan dapat diterapkan dengan lebih efektif. Mengapa ini penting Mengukur kepatuhan terhadap aturan bisnis dan membantu menemukan serta mengurangi pelanggaran kebijakan yang dapat mengurangi keuntungan atau menimbulkan pengecualian dalam proses. Sumber data Dihitung berdasarkan aturan bisnis. Contohnya, (Tanggal Pengajuan Retur - Tanggal Pembelian Awal) <= [Jumlah Hari Retur yang Diizinkan]. Perhitungan ini memerlukan Tanggal Pembelian Awal dan aturan kebijakan. Contoh truefalse | |||
| Nomor nota kredit CreditMemoNumber | Pengenal unik untuk dokumen nota kredit yang mengotorisasi pengembalian dana. | ||
| Deskripsi Nota kredit adalah dokumen penagihan yang secara resmi mengkredit akun pelanggan untuk barang yang dikembalikan. Atribut ini berisi nomor unik dokumen keuangan tersebut. Melacak nomor nota kredit penting untuk menganalisis penyelesaian keuangan dalam proses pengembalian. Nomor ini menandai tonggak penting yang sering memicu pembayaran pengembalian dana dan diperlukan untuk rekonsiliasi keuangan serta audit. Mengapa ini penting Menunjukkan transaksi keuangan resmi untuk pengembalian dana. Informasi ini penting untuk melacak tahap akhir proses dan keperluan audit keuangan. Sumber data Ini adalah nomor dokumen penagihan (VBELN) dari tabel header dokumen penagihan (VBRK), dengan kategori dokumen yang menunjukkan nota kredit. Contoh 900003459000034690000347 | |||
| Nomor pengiriman retur ReturnDeliveryNumber | Pengenal unik untuk dokumen pengiriman retur. | ||
| Deskripsi Saat pelanggan mengembalikan barang secara fisik, dokumen pengiriman retur dibuat di SAP untuk mengelola logistik barang masuk. Atribut ini berisi nomor unik dokumen tersebut. ID ini penting untuk melacak perpindahan fisik barang retur. ID ini menghubungkan aspek keuangan dan logistik dalam proses pengembalian, sehingga tahap penerimaan barang dan pemeriksaan dapat dianalisis secara terperinci. Mengapa ini penting Menjadi penghubung penting antara pesanan retur dan penerimaan fisik barang, serta membantu menganalisis logistik dan waktu pemrosesan di gudang. Sumber data Ini adalah nomor dokumen pengiriman (VBELN) dari tabel header pengiriman (LIKP), dengan kategori dokumen yang menunjukkan pengiriman retur. Contoh 840000128400001384000014 | |||
| Organisasi penjualan SalesOrganization | Unit organisasi yang bertanggung jawab atas penjualan awal dan pengembalian. | ||
| Deskripsi Organisasi penjualan adalah elemen penting dalam struktur organisasi SAP yang mewakili unit penanggung jawab penjualan dan distribusi produk serta layanan. Unit ini ditetapkan pada transaksi retur. Atribut ini memungkinkan Anda memfilter dan membandingkan proses pengembalian di berbagai unit bisnis, wilayah, atau divisi. Atribut ini membantu menemukan organisasi penjualan dengan tingkat pengembalian lebih tinggi atau proses penanganan retur yang kurang efisien, sehingga kinerja organisasi dapat dianalisis. Mengapa ini penting Memungkinkan perbandingan kinerja dan tingkat pengembalian di berbagai unit bisnis, wilayah, atau saluran penjualan. Sumber data Terdapat di kolom organisasi penjualan (VKORG) pada tabel header pesanan retur (VBAK). Contoh 10002100US01 | |||
| Otomatis IsAutomated | Penanda yang menunjukkan apakah aktivitas dilakukan oleh sistem atau manusia. | ||
| Deskripsi Atribut boolean ini membedakan aktivitas yang dijalankan otomatis oleh sistem, seperti workflow atau pekerjaan latar belakang, dari aktivitas yang dilakukan pengguna secara manual. Atribut ini penting untuk menghitung KPI 'Tingkat Persetujuan Pengembalian Dana Otomatis' dan menemukan peluang untuk meningkatkan otomatisasi. Dengan menyaring tugas manual, bisnis dapat memusatkan upaya perbaikan proses pada area yang paling diuntungkan dari otomatisasi, baik dari segi kecepatan, biaya, maupun akurasi. Mengapa ini penting Membedakan tugas manual dan otomatis. Informasi ini penting untuk menemukan peluang otomatisasi dan mengukur dampak transformasi digital. Sumber data Nilai ini biasanya ditentukan berdasarkan Nama Pengguna. Misalnya, jika penggunanya 'WF_BATCH' atau ID sistem lainnya, aktivitas akan ditandai sebagai otomatis. Contoh truefalse | |||
| Pengerjaan ulang IsRework | Penanda yang menunjukkan apakah suatu aktivitas dalam kasus merupakan pengulangan aktivitas sebelumnya. | ||
| Deskripsi Atribut boolean hasil perhitungan ini menandai pengerjaan ulang, yaitu saat aktivitas dilakukan lebih dari sekali dalam kasus yang sama. Contohnya, inspeksi barang harus diulang atau nota kredit dibuat, dibatalkan, lalu dibuat kembali. Atribut ini penting untuk dasbor 'Analisis Pengerjaan Ulang Pemrosesan Pengembalian Dana' dan KPI 'Tingkat Pengerjaan Ulang Pengembalian Dana'. Atribut ini membantu mengukur ketidakefisienan proses dengan menyoroti aktivitas yang rentan terhadap kesalahan atau perlu dilakukan berulang kali. Hasilnya menunjukkan area yang memerlukan kontrol atau pelatihan lebih baik. Mengapa ini penting Menandai pekerjaan berulang untuk menunjukkan ketidakefisienan dan kesalahan dalam proses, sehingga perbaikan dapat diarahkan untuk mengurangi pemborosan dan keterlambatan. Sumber data Penanda ini biasanya dihitung oleh alat process mining atau dapat dihitung terlebih dahulu saat transformasi data. Pemeriksaan dilakukan untuk mengetahui apakah nama aktivitas yang sama sudah muncul sebelumnya dalam kasus tersebut. Contoh truefalse | |||
| Petugas pemroses ProcessingAgent | Petugas atau kelompok sumber daya yang bertanggung jawab menangani aktivitas manual. | ||
| Deskripsi Atribut ini menunjukkan orang atau tim yang mengerjakan tugas tertentu. Informasinya dapat lebih spesifik daripada 'Nama Pengguna' karena merujuk pada peran atau tim, terutama di lingkungan layanan bersama. Data ini berguna untuk menganalisis kinerja tiap petugas atau tim melalui dasbor 'Efisiensi Persetujuan Pengembalian Dana'. Data ini membantu memahami pembagian beban kerja, menemukan kebutuhan pelatihan, serta mengenali petugas atau tim berkinerja tinggi yang dapat berbagi praktik terbaik. Mengapa ini penting Memungkinkan analisis kinerja pada tingkat petugas atau tim, sehingga Anda dapat mengelola beban kerja, menemukan kebutuhan pelatihan, dan meningkatkan efisiensi. Sumber data Informasi ini mungkin tersedia melalui fungsi SAP Business Partner jika petugas telah ditetapkan. Informasi tersebut juga dapat ditentukan dari departemen atau peran pengguna dalam struktur organisasi HR. Contoh Dukungan tingkat 1Tim inspeksi gudangDepartemen keuangan - AP | |||
| Status pesanan retur ReturnOrderStatus | Status terkini keseluruhan kasus retur. | ||
| Deskripsi Atribut ini menunjukkan status umum kasus retur pada waktu tertentu, seperti 'Terbuka', 'Sedang diproses', atau 'Ditutup'. Status ini sering kali dirangkum dari pencapaian utama terakhir yang telah selesai. Informasi ini penting untuk 'Dasbor status kasus retur saat ini', yang menampilkan kondisi beban kerja dan pembagian kasus terkini. Manajer dapat melihat jumlah kasus di setiap tahap proses, lalu mengatur sumber daya dan beban kerja dengan lebih baik. Mengapa ini penting Menunjukkan posisi setiap kasus dalam proses. Informasi ini penting bagi dasbor operasional yang memantau beban kerja dan status terkini. Sumber data Ditentukan dari kolom status pada dokumen terkait. Misalnya, dari status header (GBSTK) atau status item (LFSTK) pada dokumen pesanan penjualan (VBUK/VBUP) atau pengiriman terkait. Contoh Menunggu penerimaan barangMenunggu inspeksiMenunggu pengembalian danaDitutup | |||
| Tanggal target SLA pengembalian dana RefundSlaTargetDate | Tanggal batas pemrosesan pengembalian dana untuk kasus retur. | ||
| Deskripsi Atribut ini menetapkan tenggat Service Level Agreement (SLA) untuk memproses pengembalian dana. Tanggal ini biasanya dihitung berdasarkan aturan bisnis, misalnya beberapa hari setelah retur disetujui atau barang diterima. Kolom ini menjadi dasar dasbor 'Pemantauan Kepatuhan SLA Pengembalian Dana' dan KPI terkait. Anda dapat memantau lebih awal kasus yang berisiko melewati tenggat SLA dan menganalisis penyebab keterlambatan. Hasilnya dapat membantu meningkatkan kepuasan pelanggan. Mengapa ini penting Menjadi acuan untuk mengukur kepatuhan SLA, memantau kinerja, memprioritaskan kasus yang tertunda, dan meningkatkan kepuasan pelanggan. Sumber data Kolom ini hampir selalu merupakan hasil perhitungan. Logikanya menggunakan tanggal acuan, misalnya tanggal pembuatan permintaan retur, ditambah durasi yang ditetapkan oleh aturan bisnis. Durasi tersebut dapat bergantung pada faktor seperti jenis pelanggan atau alasan retur. Contoh 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
Aktivitas pemrosesan retur dan pengembalian dana
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Barang diterima di gudang | Peristiwa ini menandai penerimaan fisik barang retur di gudang atau pusat pemrosesan. Peristiwa tercatat secara eksplisit saat Post Goods Receipt (PGR) dijalankan untuk pengiriman retur dan menghasilkan dokumen material. | ||
| Mengapa ini penting Ini adalah tonggak penting yang memulai penghitungan waktu pemeriksaan dan penentuan tindak lanjut. Keterlambatan sebelum tahap ini dipengaruhi pelanggan, sedangkan keterlambatan setelahnya berasal dari proses internal. Sumber data Aktivitas ini tercatat di tabel dokumen material MSEG dan MKPF untuk jenis pergerakan penerimaan barang yang terkait dengan retur. Tanggal posting (MKPF-BUDAT) menunjukkan waktu peristiwa. Pengumpulan data Peristiwa ini menunjukkan posting penerimaan barang untuk pengiriman retur. Jenis peristiwa explicit | |||
| Kasus pengembalian ditutup | Ini adalah aktivitas terakhir yang menandakan proses pengembalian selesai dan tidak ada tindakan lanjutan untuk kasus tersebut. Biasanya, aktivitas ini disimpulkan saat status dokumen pesanan retur di sistem berubah menjadi selesai atau ditutup. | ||
| Mengapa ini penting Peristiwa ini menandai akhir siklus proses dan memungkinkan penghitungan waktu siklus dari awal hingga selesai. Peristiwa ini memastikan kasus telah ditangani sepenuhnya. Sumber data Aktivitas ini disimpulkan saat status keseluruhan pesanan retur di tabel VBAK atau itemnya di VBAP mencapai status 'Selesai' atau 'Ditutup'. Status ini ditentukan oleh konfigurasi manajemen status sistem. Pengumpulan data Aktivitas ini disimpulkan saat status dokumen pesanan retur berubah menjadi 'Selesai'. Jenis peristiwa inferred | |||
| Nota kredit dibuat | Aktivitas ini menandai pembuatan dokumen penagihan resmi yang mengkredit akun pelanggan untuk barang yang dikembalikan. Peristiwa tercatat secara eksplisit saat nota kredit dibuat dari permintaan nota kredit. | ||
| Mengapa ini penting Pembuatan nota kredit merupakan tonggak penting dalam proses keuangan. Tahap ini memastikan jumlah yang akan dikembalikan dan mengizinkan proses pembayaran dimulai. Sumber data Aktivitas ini tercatat saat dokumen penagihan dengan kategori dokumen nota kredit dibuat di tabel VBRK. Dokumen ini ditautkan ke permintaan nota kredit di tabel VBFA. Pengumpulan data Peristiwa tercatat saat dokumen penagihan nota kredit baru disimpan, misalnya melalui transaksi VF01. Jenis peristiwa explicit | |||
| Pemeriksaan barang selesai | Aktivitas ini menandai selesainya penilaian kualitas dan kondisi barang retur. Dalam Advanced Returns Management, tahap ini sering dicatat secara eksplisit, termasuk hasil pemeriksaan dan tindakan selanjutnya, seperti pengembalian dana atau penghapusan barang. | ||
| Mengapa ini penting Durasi dan hasil pemeriksaan berdampak langsung pada waktu pemrosesan pengembalian dana dan pengelolaan inventaris. Aktivitas ini penting untuk menganalisis efisiensi pemeriksaan dan pengerjaan ulang. Sumber data Di SAP Advanced Returns Management (ARM), aktivitas ini dapat tercatat secara eksplisit dari transaksi pemeriksaan. Aktivitas ini juga dapat disimpulkan dari perubahan status item pesanan retur yang menunjukkan hasil pemeriksaan. Pengumpulan data Aktivitas ini tercatat dari log transaksi atau perubahan status yang terkait dengan aktivitas tindak lanjut logistik di ARM. Jenis peristiwa explicit | |||
| Pengembalian dana diproses | Aktivitas ini menandai tahap akhir proses pengembalian dana. Kredit keuangan diselesaikan, yang berarti pembayaran telah dikirim kepada pelanggan. Aktivitas ini disimpulkan dari pembuatan dokumen penyelesaian di modul keuangan yang melunasi kredit terbuka pada akun pelanggan. | ||
| Mengapa ini penting Pada tahap ini, pelanggan benar-benar menerima pembayaran. Waktu dari pengajuan retur hingga tahap ini sangat memengaruhi kepuasan pelanggan dan menjadi ukuran penting untuk memantau kepatuhan terhadap SLA. Sumber data Aktivitas ini disimpulkan dari informasi dokumen penyelesaian di tabel item baris akuntansi keuangan BSEG. Tanggal penyelesaian (BSEG-AUGDT) pada item baris pelanggan yang terkait dengan nota kredit menunjukkan kapan pengembalian dana diproses. Pengumpulan data Aktivitas ini disimpulkan saat kolom tanggal penyelesaian terisi untuk dokumen akuntansi yang terkait dengan nota kredit. Jenis peristiwa inferred | |||
| Permintaan nota kredit dibuat | Setelah pemeriksaan berhasil, aktivitas ini menandai pembuatan permintaan kredit untuk pelanggan. Aktivitas ini tercatat sebagai dokumen penjualan baru berupa permintaan nota kredit yang merujuk pada pesanan retur awal. | ||
| Mengapa ini penting Tahap ini memulai penyelesaian keuangan dalam proses pengembalian. Dengan menganalisis waktu dari pemeriksaan hingga tahap ini, Anda dapat melihat efisiensi serah terima dari bagian logistik ke keuangan. Sumber data Aktivitas ini tercatat saat dokumen penjualan dengan kategori dokumen permintaan nota kredit dibuat di tabel VBAK. Tautan ke retur disimpan di tabel alur dokumen VBFA. Pengumpulan data Peristiwa tercatat saat dokumen permintaan nota kredit baru disimpan. Jenis peristiwa explicit | |||
| Permintaan pengembalian diajukan | Ini adalah awal proses pengembalian, saat pesanan retur resmi dibuat di sistem. SAP S/4HANA mencatat peristiwa ini secara eksplisit saat dokumen penjualan baru dengan jenis pesanan retur disimpan. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya siklus kasus pengembalian secara resmi. Menganalisis waktu dari peristiwa ini hingga kasus ditutup penting untuk mengukur waktu siklus pengembalian secara keseluruhan dan pengalaman pelanggan. Sumber data Peristiwa ini tercatat secara eksplisit saat dokumen penjualan dibuat di tabel VBAK dan kategori dokumen (VBAK-VBTYP) menunjukkan pesanan retur. Waktu pembuatannya tercatat di VBAK-ERDAT. Pengumpulan data Peristiwa tercatat saat pesanan penjualan retur baru disimpan, misalnya melalui transaksi VA01. Jenis peristiwa explicit | |||
| Dokumen akuntansi dibuat | Peristiwa ini terjadi saat nota kredit berhasil diposting ke modul akuntansi keuangan. Entri terkait dibuat di buku besar, sehingga kredit tersebut resmi dari sisi akuntansi. | ||
| Mengapa ini penting Aktivitas ini memastikan kredit telah tercatat di sistem keuangan. Waktu antara pembuatan nota kredit dan posting akuntansi dapat menunjukkan masalah pada antarmuka penagihan dan keuangan. Sumber data Aktivitas ini tercatat saat header dokumen dibuat di tabel akuntansi BKPF dan ditautkan ke nota kredit di VBRK (VBRK-BELNR). Pengumpulan data Peristiwa tercatat saat dokumen penagihan berhasil diposting ke Financial Accounting. Jenis peristiwa explicit | |||
| Dokumen pengiriman retur dibuat | Aktivitas ini menandai pembuatan dokumen pengiriman masuk yang digunakan untuk mengelola penerimaan fisik barang retur. Sistem mencatatnya secara eksplisit saat dokumen pengiriman yang merujuk pada pesanan retur dibuat. | ||
| Mengapa ini penting Tahap ini merupakan tonggak penting dalam logistik. Waktu antara persetujuan retur dan pembuatan dokumen pengiriman menunjukkan seberapa efisien informasi retur disampaikan kepada gudang atau bagian penerimaan. Sumber data Aktivitas ini tercatat saat header pengiriman dibuat di tabel LIKP dan ditautkan ke pesanan retur sebelumnya melalui tabel alur dokumen VBFA. Pengumpulan data Peristiwa tercatat saat dokumen pengiriman retur baru disimpan, misalnya melalui transaksi VL01N. Jenis peristiwa explicit | |||
| Pengembalian ditolak | Barang retur tidak memenuhi kriteria kebijakan pengembalian, sehingga permintaan pengembalian dana atau kredit ditolak. Biasanya, penolakan tercatat melalui status atau kode alasan tertentu pada item pesanan retur setelah pemeriksaan. | ||
| Mengapa ini penting Melacak penolakan membantu menganalisis kepatuhan terhadap kebijakan pengembalian dan menemukan alasan umum penolakan. Ini merupakan jalur pengecualian penting dalam proses. Sumber data Aktivitas ini disimpulkan saat alasan penolakan (VBAP-ABGRU) diisi pada item pesanan retur atau saat status tertentu diberikan selama pemeriksaan di Advanced Returns Management. Pengumpulan data Aktivitas ini disimpulkan saat alasan penolakan atau status khusus 'ditolak' ditetapkan pada item dokumen retur. Jenis peristiwa inferred | |||
| Pesanan penukaran dibuat | Aktivitas ini menunjukkan penyelesaian alternatif: alih-alih menerima pengembalian dana, pelanggan mendapat barang pengganti melalui pesanan penjualan baru. Aktivitas tercatat saat pesanan penjualan baru dibuat dengan merujuk pada retur awal. | ||
| Mengapa ini penting Aktivitas ini membantu membedakan retur untuk pengembalian dana dan retur untuk penukaran. Keduanya memiliki jalur proses dan hasil bagi pelanggan yang berbeda. Informasi ini penting untuk menganalisis variasi proses. Sumber data Aktivitas ini tercatat saat dokumen penjualan baru dibuat di VBAK dan ditautkan ke pesanan retur dalam tabel alur dokumen (VBFA). Pengumpulan data Peristiwa tercatat saat dokumen pesanan penjualan baru untuk barang pengganti disimpan. Jenis peristiwa explicit | |||
| Pesanan retur disetujui | Aktivitas ini menandai persetujuan atau pelepasan resmi pesanan retur agar dapat dilanjutkan ke tahap berikutnya. Biasanya, aktivitas ini disimpulkan dari perubahan status pada header atau item dokumen penjualan yang menunjukkan bahwa blokir telah dilepas. | ||
| Mengapa ini penting Tahap persetujuan dapat menjadi sumber keterlambatan yang signifikan. Dengan melacak aktivitas ini, Anda dapat menemukan hambatan pada tahap otorisasi awal proses pengembalian. Sumber data Aktivitas ini disimpulkan dari tabel manajemen status atau kolom status langsung di tabel VBAK atau VBAP. Perubahan status pelepasan atau penghapusan blokir pengiriman (VBAP-LIFSP) dapat menandakan persetujuan. Pengumpulan data Aktivitas ini disimpulkan dari perubahan kolom status header atau item pesanan retur yang menunjukkan pelepasan atau persetujuan. Jenis peristiwa inferred | |||
Panduan ekstraksi
Langkah
- Periksa prasyarat: Pastikan akun pengguna yang menjalankan ekstraksi memiliki otorisasi yang diperlukan di SAP S/4HANA untuk mengakses Core Data Services (CDS) View yang dibutuhkan. View utama mencakup I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry, dan I_ClearedItem.
- Buka alat kueri: Masuk ke klien SQL atau alat integrasi data pilihan Anda yang sudah terhubung ke basis data SAP S/4HANA. Alatnya dapat berupa SAP Analytics Cloud atau platform ETL pihak ketiga.
- Atur parameter kueri: Sebelum menjalankan kueri SQL yang disediakan, ganti nilai placeholder dengan parameter yang sesuai untuk lingkungan Anda. Atur
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type], serta filter jenis dokumen atau kode perusahaan lainnya. - Jalankan kueri ekstraksi: Salin seluruh kueri SQL, lalu jalankan di alat Anda. Kueri ini menggabungkan hasil dari beberapa pernyataan select untuk mengumpulkan semua aktivitas yang ditentukan ke dalam satu set data.
- Pahami logika kueri: Setiap blok
SELECTdalam strukturUNION ALLmengekstrak satu aktivitas tertentu. Blok tersebut menggabungkan beberapa CDS View untuk mengambil atribut yang dibutuhkan, menetapkan teks tetap sebagaiActivityName, lalu memilih stempel waktu yang sesuai untukEventTime. - Tinjau data mentah: Setelah kueri selesai, periksa hasilnya. Pastikan jumlah baris masuk akal dan kolom utama seperti
ReturnCaseId,ActivityName, danEventTimeterisi sesuai harapan. - Transformasi data: Kueri ini menghasilkan log peristiwa dalam format datar, sehingga biasanya tidak memerlukan perubahan struktur yang berarti. Namun, Anda mungkin perlu menyesuaikan format stempel waktu atau jenis data sesuai kebutuhan sistem tujuan.
- Ekspor log peristiwa: Ekspor hasil kueri sebagai file CSV. Gunakan encoding UTF-8 agar nama pengguna atau deskripsi produk tidak mengalami masalah karakter.
- Unggah ke alat process mining: File CSV siap diunggah ke platform process mining seperti ProcessMind. Petakan kolom file ke kolom yang sesuai di alat, misalnya
ReturnCaseIdke Case ID,ActivityNameke Activity, danEventTimeke Timestamp.
Konfigurasi
- Prasyarat: Pengguna yang menjalankan ekstraksi memerlukan otorisasi untuk melihat objek terkait dokumen penjualan (VBAK), pengiriman (LIKP), penagihan (VBRK), dan akuntansi (BSEG, BKPF). Akses ke CDS View yang mendasarinya juga diperlukan.
- Filter cakupan data: Filter kueri berdasarkan jenis dokumen tertentu untuk memisahkan proses retur. Atur placeholder untuk jenis pesanan retur (misalnya, 'RE'), jenis permintaan nota kredit (misalnya, 'G2'), dan jenis pesanan penggantian (misalnya, 'SO'). Sebaiknya batasi cakupan data dengan memfilter
CompanyCodeatauSalesOrganization. - Filter rentang tanggal: Selalu gunakan filter rentang tanggal untuk mengendalikan kinerja dan volume data. Mulailah dengan data dari 3 hingga 6 bulan terakhir. Kueri menggunakan tanggal pembuatan pesanan retur awal (
I_SalesDocument.CreationDate) sebagai filter utama. - Pertimbangan kinerja: Kueri ini menggabungkan beberapa CDS View berukuran besar dan dapat membebani sumber daya sistem S/4HANA. Jadwalkan ekstraksi di luar jam sibuk untuk mengurangi dampaknya. Untuk set data yang sangat besar, pertimbangkan strategi pemuatan bertahap.
Contoh kueri sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Langkah
- Pastikan tersedia akses baca langsung ke skema SAP HANA yang memuat data penjualan, pengiriman, penagihan, dokumen material, inspeksi, status, dan akuntansi yang relevan. Skema, view, dan nama kolom berbeda-beda di setiap penerapan SAP S/4HANA. Ganti setiap placeholder dalam tanda kurung siku dengan objek dan kolom yang dikonfigurasi di sistem Anda.
- Tentukan cakupan ekstraksi menggunakan [Start date], [End date], [Company Code filter], dan [Return document type filter]. Untuk ekstraksi awal, gunakan rentang 3 hingga 6 bulan. Perpanjang rentang hanya setelah kinerja dan kelengkapan data dipastikan.
- Ambil daftar pesanan retur dari [Your sales document header table] dan [Your sales document item table]. Batasi daftar tersebut pada jenis dokumen pesanan retur yang dikonfigurasi di [Your return order document type configuration]. Gunakan nomor dan nomor item pesanan retur sebagai penghubung utama ke dokumen berikutnya.
- Telusuri alur dokumen dari pesanan retur ke pengiriman retur masuk, permintaan nota kredit, pesanan penggantian, dan nota kredit menggunakan [Your document flow table or view]. Jangan menganggap alur dokumen tersimpan di VBAK atau VBAP. Sesuaikan kolom relasi dengan model alur dokumen yang digunakan sistem.
- Ekstrak peristiwa pembuatan yang tercatat secara eksplisit dari header dan item dokumen terkait. Ambil peristiwa persetujuan, penolakan, inspeksi, penutupan, penerimaan barang, akuntansi, dan kliring dari sumber status, inspeksi, dokumen material, akuntansi, dan kliring yang dikonfigurasi. Catat setiap aktivitas sebagai baris peristiwa terpisah karena ProcessMind tidak menyimpulkan peristiwa.
- Samakan stempel waktu ke jenis stempel waktu basis data dan zona waktu yang konsisten. Gunakan urutan prioritas stempel waktu peristiwa yang telah dikonfigurasi untuk setiap aktivitas. Jika hanya tanggal dan waktu yang tersedia, gabungkan keduanya menggunakan zona waktu sistem yang ditetapkan di [Your system time zone].
- Isi ReturnCaseId untuk setiap peristiwa. Gunakan nomor pesanan retur asal, atau pengenal kasus retur yang dikonfigurasi jika Advanced Returns Management menyimpan kunci kasus terpisah. Kecualikan peristiwa yang tidak dapat dikaitkan dengan kasus retur atau masukkan ke hasil pengecualian untuk ditangani.
- Isi kolom wajib ReturnCaseId, ActivityName, EventTime, SourceSystemId, dan LastDataUpdateTimestamp. Jika tersedia, isi juga kolom yang disarankan, termasuk EventEndTime, UserName, ReturnReason, RefundAmount, ProductId, dan CustomerId. Buat satu baris untuk setiap kejadian aktivitas, jangan gabungkan aktivitas menjadi satu baris kasus.
- Validasi hasil menggunakan pemeriksaan di validationSteps. Pastikan semua 12 nama aktivitas tersedia, urutan stempel waktu dalam setiap kasus masuk akal, dan referensi dokumen cocok dengan tabel sumber.
- Ekspor hasil sebagai CSV UTF-8 atau format tabular lain yang didukung ProcessMind. Pertahankan nama kolom persis seperti yang ditentukan, gunakan satu baris header, simpan stempel waktu dalam format ISO yang tidak ambigu, lalu unggah log peristiwa dengan ReturnCaseId sebagai pengenal kasus dan ActivityName sebagai kolom aktivitas.
Konfigurasi
- Rentang tanggal: Mulailah dengan data dari 3 hingga 6 bulan. Gunakan parameter [Start date] dan [End date]. Sertakan riwayat yang cukup untuk mencakup kasus yang dimulai sebelum periode tersebut tetapi selesai di dalamnya.
- Daftar retur: Filter berdasarkan jenis dokumen pesanan retur yang dikonfigurasi di [Your return order document type configuration]. Jangan menetapkan jenis dokumen secara langsung sebelum memastikannya di sistem tujuan.
- Filter organisasi: Gunakan [Company Code filter], organisasi penjualan, saluran distribusi, divisi, pabrik, atau filter pelanggan hanya jika diperlukan. Pastikan filter tidak mengecualikan dokumen lanjutan lintas perusahaan atau antarperusahaan.
- Objek sumber: Ganti placeholder [Your table name] dan [Your view name] dengan tabel atau CDS View SAP S/4HANA yang telah disetujui. VBAK, VBAP, VBRK, dan VBRP mungkin tersedia di sistem Anda, tetapi pastikan penggunaannya dan ekstensinya sebelum menjalankan kueri.
- Penanganan stempel waktu: Atur kolom stempel waktu sumber dan zona waktu untuk setiap aktivitas. Simpan EventTime dan EventEndTime secara konsisten, sebaiknya dalam UTC atau zona waktu ProcessMind yang disepakati.
- Interpretasi status: Atur nilai status, kode alasan, hasil inspeksi, dan penanda penutupan yang tepat untuk menunjukkan persetujuan, penolakan, penyelesaian inspeksi, dan penutupan kasus di sistem.
- Pengenal sistem sumber: Ganti [Source system identifier] dengan nilai tetap, seperti pengenal sistem SAP yang digunakan platform ekstraksi.
- Stempel waktu penyegaran: Ganti [Extraction timestamp] dengan waktu dimulainya kueri atau waktu pembuatan rekam data sumber. Gunakan nilai yang sama untuk semua baris dalam satu proses ekstraksi, kecuali jika diperlukan stempel waktu penyegaran per baris.
- Kinerja: Batasi daftar awal pesanan retur sebelum menggabungkannya dengan sumber alur dokumen, akuntansi, dokumen material, dan status yang berukuran besar. Gunakan kolom berindeks atau yang mendukung pemangkasan partisi, hindari pemindaian tanpa batas, dan buat hasil perantara hanya jika disetujui administrator basis data.
- Ekstraksi bertahap: Untuk proses berulang, gunakan [Last successful extraction timestamp] dan rentang tumpang tindih yang terkontrol untuk menangkap pembaruan yang terlambat. Hapus duplikat berdasarkan ReturnCaseId, ActivityName, kunci dokumen sumber, dan EventTime.
- Otorisasi dan prasyarat: Dapatkan otorisasi baca untuk semua objek dan kolom sumber yang dikonfigurasi, persetujuan untuk akses langsung ke basis data, serta konfirmasi bahwa komponen SAP dan fungsi Advanced Returns Management yang diperlukan telah aktif jika berlaku.
- Perlindungan data: Batasi kolom pelanggan dan keuangan hanya pada data yang diperlukan, ikuti kontrol privasi organisasi, dan amankan file yang diekspor.
Contoh kueri sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Siap memulai?
Dengan templat ini, Anda mendapat dasar untuk mengekstrak dan menganalisis data pemrosesan retur dan pengembalian dana. Mulai tingkatkan proses Anda hari ini.
Tingkatkan pemrosesan retur dan pengembalian dana di SAP S/4HANA sekarang
Temukan inefisiensi, kurangi waktu siklus hingga 30%, dan tingkatkan kepuasan.
Tidak perlu kartu kredit. Mulai tingkatkan proses Anda hari ini.