Templat Data Order-to-Cash Anda, Penagihan dan Pembuatan Faktur
Templat Data Order-to-Cash Anda, Penagihan dan Pembuatan Faktur
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data untuk SAP S/4HANA
Atribut Order-to-Cash, Penagihan dan Pembuatan Faktur
| Nama | Deskripsi | ||
|---|---|---|---|
| Nomor faktur InvoiceNumber | Pengenal unik dokumen penagihan yang berfungsi sebagai ID kasus utama dalam proses pembuatan faktur. | ||
| Deskripsi Nomor Faktur, yang disebut Nomor Dokumen Penagihan di SAP, mengidentifikasi setiap transaksi penagihan secara unik. Nomor ini menjadi kunci utama yang menghubungkan semua aktivitas terkait, mulai dari pembuatan dan posting faktur hingga penerimaan dan pencocokan pembayaran. Dalam process mining, atribut ini penting untuk menghubungkan kasus. Semua peristiwa dengan Nomor Faktur yang sama dikelompokkan ke dalam satu instans proses. Dengan begitu, Anda dapat menganalisis seluruh siklus penagihan setiap faktur dari awal hingga akhir, melacak waktu siklus, menemukan penyimpangan, dan meninjau perjalanan tiap faktur. Mengapa ini penting Pengenal utama ini menghubungkan semua aktivitas penagihan terkait ke dalam satu kasus sehingga analisis proses dari awal hingga akhir dapat dilakukan. Sumber data Tabel SAP: VBRK, Kolom: VBELN Contoh 900012349000567890009012 | |||
| Nama aktivitas ActivityName | Nama aktivitas bisnis atau peristiwa yang terjadi dalam proses penagihan, seperti 'Faktur dibuat' atau 'Pembayaran diterima'. | ||
| Deskripsi Nama Aktivitas menjelaskan langkah atau tahap tertentu dalam siklus penagihan. Aktivitas ini diturunkan dari berbagai titik data di SAP, seperti kode transaksi, perubahan status dokumen, atau entri log tertentu, untuk membentuk alur proses yang berurutan. Analisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan peta proses, menemukan variasi proses yang umum maupun jarang terjadi, mengidentifikasi hambatan antar langkah, serta mengukur frekuensi aktivitas yang tidak memberi nilai tambah, seperti pengerjaan ulang atau pembatalan. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam proses sehingga Anda dapat memvisualisasikan peta proses dan menganalisis alur, variasi, serta hambatan proses. Sumber data Ditentukan dari berbagai sumber, termasuk kode transaksi (SY-TCODE), status dokumen perubahan (tabel CDHDR/CDPOS), atau log workflow bisnis, misalnya SWW_WI2OBJ. Contoh Faktur dibuatFaktur diposting ke akuntansiPembayaran pelanggan diterimaFaktur dibatalkan | |||
| Waktu peristiwa EventTime | Stempel waktu yang menunjukkan secara tepat kapan suatu aktivitas atau peristiwa terjadi. | ||
| Deskripsi Waktu peristiwa mencatat tanggal dan waktu setiap aktivitas, sehingga menjadi dasar urutan kronologis proses. Stempel waktu ini penting untuk menghitung durasi, waktu siklus, dan waktu tunggu antar langkah dalam proses penagihan. Dalam analisis, Waktu peristiwa digunakan untuk mengurutkan aktivitas, menghitung indikator kinerja utama seperti Days Sales Outstanding dan waktu siklus pembuatan faktur, serta menemukan hambatan terkait waktu. Data ini memberikan gambaran proses yang dinamis, termasuk perubahan kinerja dari waktu ke waktu dan durasi setiap tahap dalam siklus penagihan. Mengapa ini penting Atribut ini memberikan urutan kronologis peristiwa yang diperlukan untuk menghitung semua metrik berbasis waktu, seperti waktu siklus dan durasi. Sumber data Diambil dari berbagai kolom tanggal dan waktu, bergantung pada aktivitasnya. Contohnya, tanggal dan waktu pembuatan (VBRK-ERDAT, VBRK-ERZET), stempel waktu perubahan (CDHDR-UDATE, CDHDR-UTIME), atau tanggal posting (BKPF-BUDAT). Contoh 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Jumlah faktur InvoiceAmount | Total nilai bersih faktur. | ||
| Deskripsi Atribut ini menunjukkan total nilai uang barang atau layanan yang ditagihkan, sebelum pajak. Ini merupakan data keuangan dasar untuk setiap kasus faktur. Jumlah Faktur digunakan dalam berbagai analisis. Anda dapat mengelompokkan proses berdasarkan nilai, misalnya untuk melihat apakah faktur bernilai tinggi diproses dengan cara berbeda atau lebih sering terlambat. Atribut ini juga menjadi dasar pelaporan keuangan dan penghitungan total nilai piutang yang belum dibayar. Mengapa ini penting Atribut ini menunjukkan nilai keuangan setiap faktur sehingga Anda dapat menganalisis berdasarkan nilai, menentukan prioritas penagihan, dan menilai dampak keuangan. Sumber data Tabel SAP: VBRK, Kolom: NETWR Contoh 1500.0025000.50125.75 | |||
| Nama pelanggan CustomerName | Nama pelanggan yang menerima faktur. | ||
| Deskripsi Atribut ini menunjukkan nama resmi pelanggan yang ditagih. Data diambil dari data induk pelanggan pusat di SAP. Analisis proses berdasarkan pelanggan membantu menemukan pola pada akun tertentu. Misalnya, Anda dapat mengetahui pelanggan yang sering terlambat membayar, paling sering mengajukan sengketa, atau mengalami proses penagihan yang paling tidak efisien. Temuan ini membantu Anda mengelola hubungan dengan pelanggan secara terarah dan menyesuaikan strategi penagihan. Mengapa ini penting Atribut ini mendukung analisis berdasarkan pelanggan untuk menemukan pola pembayaran, frekuensi sengketa, dan inefisiensi proses pada akun tertentu. Sumber data Diambil dari tabel data induk pelanggan KNA1 (Kolom: NAME1), yang terhubung melalui ID pembayar di header faktur (VBRK-KUNRG). Contoh Pembangkit Listrik SpringfieldToko Kwik-E-MartCyberdyne Systems | |||
| Nama pengguna UserName | ID pengguna karyawan yang menjalankan aktivitas. | ||
| Deskripsi Atribut ini mencatat ID pengguna SAP yang bertanggung jawab atas suatu peristiwa, seperti membuat faktur, memposting dokumen, atau melunasi pembayaran. Atribut ini menghubungkan langkah proses dengan orang atau tim yang menjalankannya. Analisis berdasarkan Nama Pengguna membantu menemukan karyawan dengan kinerja tinggi, kebutuhan pelatihan, atau ketimpangan beban kerja. Atribut ini juga penting untuk analisis kepatuhan karena menunjukkan siapa yang menjalankan aktivitas penting dan membantu memahami perbedaan cara pengguna menjalankan proses yang sama. Mengapa ini penting Atribut ini menghubungkan aktivitas proses dengan pengguna tertentu sehingga beban kerja, kinerja, dan kepatuhan dapat dianalisis pada tingkat individu atau tim. Sumber data Untuk peristiwa pembuatan, data ini ada di VBRK-ERNAM. Untuk perubahan berikutnya, data dapat ditemukan di tabel riwayat perubahan seperti CDHDR-USERNAME atau di log workflow. Contoh CBURNSHSIMPSONLLEONARD | |||
| Tanggal faktur InvoiceDate | Tanggal resmi saat faktur diterbitkan kepada pelanggan. | ||
| Deskripsi Tanggal Faktur, yang juga disebut tanggal penagihan di SAP, menjadi titik awal berbagai perhitungan keuangan. Tanggal ini digunakan untuk menentukan ketentuan pembayaran, tanggal jatuh tempo, dan umur piutang. Tanggal ini merupakan atribut penting di tingkat kasus untuk analisis keuangan. Tanggal ini menjadi dasar penghitungan KPI Days Sales Outstanding (DSO) dan pembuatan laporan umur faktur yang belum dibayar. Keduanya penting untuk mengelola arus kas dan penagihan. Mengapa ini penting Tanggal ini menjadi acuan utama perhitungan keuangan, termasuk DSO, tanggal jatuh tempo pembayaran, dan analisis umur faktur. Sumber data Tabel SAP: VBRK, Kolom: FKDAT Contoh 2023-03-202023-04-012023-05-18 | |||
| Tanggal jatuh tempo pembayaran PaymentDueDate | Tanggal batas pembayaran faktur oleh pelanggan. | ||
| Deskripsi Tanggal jatuh tempo pembayaran dihitung berdasarkan tanggal faktur dan ketentuan pembayaran yang disepakati. Tanggal ini menjadi batas pembayaran agar faktur tidak terlambat dibayar. Atribut ini penting untuk memantau efektivitas penagihan dan memperkirakan arus kas. Atribut ini digunakan langsung untuk menghitung KPI Tingkat Pembayaran Tepat Waktu dan mengelompokkan faktur dalam laporan umur piutang. Analisis selisih antara tanggal jatuh tempo dan tanggal pembayaran aktual membantu menilai efektivitas berbagai ketentuan pembayaran. Mengapa ini penting Atribut ini menetapkan batas waktu pembayaran pelanggan sehingga penting untuk menghitung tingkat pembayaran tepat waktu dan mengelola piutang usaha. Sumber data Tanggal ini tidak disimpan secara langsung. SAP menghitungnya berdasarkan Tanggal Faktur (VBRK-FKDAT) dan kunci Ketentuan Pembayaran (VBRK-ZTERM) menggunakan fungsi penentuan tanggal standar SAP. Contoh 2023-04-192023-05-012023-06-17 | |||
| Waktu Selesai EndTime | Waktu yang menunjukkan secara tepat kapan suatu aktivitas atau peristiwa selesai. | ||
| Deskripsi Waktu Selesai menandai berakhirnya suatu aktivitas. Dalam process mining, waktu ini sering diperkirakan dari Waktu Mulai aktivitas berikutnya dalam kasus yang sama. Jika sistem mencatat waktu mulai dan selesai, data tersebut juga dapat digunakan secara langsung. Atribut ini diperlukan untuk menghitung Waktu Pemrosesan setiap aktivitas. Kurangi Waktu Mulai dari Waktu Selesai untuk mengetahui durasi setiap langkah. Informasi ini penting untuk menganalisis hambatan, misalnya keterlambatan pada tahap persetujuan faktur. Mengapa ini penting Atribut ini membantu menghitung durasi pemrosesan setiap aktivitas secara tepat, yang menjadi dasar analisis hambatan. Sumber data Atribut ini diturunkan untuk keperluan process mining. Biasanya, nilainya dihitung dari StartTime peristiwa berikutnya dalam urutan kasus. Dalam beberapa situasi, tabel tertentu mungkin mencatat waktu penyelesaian secara langsung. Contoh 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Wilayah Region | Wilayah geografis pelanggan. | ||
| Deskripsi Atribut Wilayah menunjukkan area geografis, seperti negara bagian atau provinsi, yang terkait dengan alamat pelanggan. Data ini biasanya menjadi bagian dari catatan data induk pelanggan. Atribut ini penting untuk dashboard Kinerja Penagihan Regional. Anda dapat membandingkan metrik utama, seperti waktu siklus, tingkat kesalahan, dan DSO, antarwilayah. Perbandingan ini dapat menunjukkan perbedaan pelaksanaan proses, kepatuhan, atau efisiensi di tiap wilayah. Hasilnya dapat menjadi dasar perbaikan terarah dan penerapan praktik terbaik secara konsisten. Mengapa ini penting Atribut ini membantu membandingkan kinerja penagihan antarwilayah, menemukan kesenjangan regional, dan menstandarkan proses. Sumber data Diambil dari tabel data induk pelanggan KNA1 (Kolom: REGIO), yang terhubung melalui ID pembayar di header faktur (VBRK-KUNRG). Contoh CANYTXBA | |||
| Alasan Nota Kredit CreditMemoReason | Kode alasan yang menjelaskan penerbitan nota kredit. | ||
| Deskripsi Jika faktur salah dan perlu dikreditkan, alasan biasanya dicantumkan pada dokumen nota kredit. Dengan begitu, sumber kesalahan penagihan dapat dikelompokkan secara terstruktur. Atribut ini mendukung KPI Tingkat Kesalahan Penagihan. Dengan mengelompokkan dan menganalisis alasan penerbitan nota kredit, perusahaan dapat menemukan jenis kesalahan yang paling sering terjadi, seperti kesalahan harga atau pengembalian produk. Hasil analisis ini membantu memperbaiki proses agar koreksi keuangan dan pengerjaan ulang berkurang. Mengapa ini penting Atribut ini mengelompokkan alasan pemberian kredit, sehingga Anda dapat menemukan sumber kesalahan penagihan yang paling sering terjadi dan meningkatkan kualitas proses. Sumber data Tabel SAP: VBRK, Kolom: AUGRU (Alasan Pesanan). Kolom ini digunakan pada permintaan nota kredit/debit yang kemudian ditagihkan. Contoh 001 - Selisih Harga002 - Kualitas Buruk005 - Pengembalian oleh Pelanggan | |||
| Alasan Sengketa CustomerDisputeReason | Alasan yang disampaikan pelanggan saat menyanggah faktur. | ||
| Deskripsi Saat pelanggan menyanggah faktur, alasan sengketa biasanya dicatat. Penyebabnya bisa berupa kesalahan harga, jumlah barang yang tidak sesuai, atau barang rusak. Informasi ini mungkin tersimpan di modul SAP Dispute Management atau dalam catatan teks. Analisis alasan sengketa menjadi dasar KPI Tingkat Kesalahan Penagihan dan analisis kesalahan terkait. Analisis ini membantu menemukan penyebab utama ketidakakuratan faktur. Perusahaan dapat mengatasi masalah pada proses sebelumnya, meningkatkan kualitas faktur, dan memperbaiki kepuasan pelanggan. Mengapa ini penting Atribut ini menjelaskan alasan faktur disanggah, sehingga Anda dapat mengetahui penyebab utama kesalahan penagihan dan ketidakpuasan pelanggan. Sumber data Jika menggunakan SAP Dispute Management, informasi ini dapat ditemukan di tabel seperti UDM_DISPUTE. Jika tidak, informasi mungkin diambil dari kode alasan pada dokumen terkait atau kolom teks. Contoh Harga Tidak SesuaiJumlah Tidak SesuaiBarang yang Diterima Rusak | |||
| Dibayar Tepat Waktu IsPaidOnTime | Penanda benar/salah yang menunjukkan apakah faktur dibayar pada atau sebelum tanggal jatuh tempo. | ||
| Deskripsi Atribut ini dihitung dengan membandingkan tanggal pembayaran sebenarnya dengan tanggal jatuh tempo yang ditetapkan. Nilainya 'true' jika pembayaran tepat waktu dan 'false' jika terlambat. Penanda ini memudahkan penghitungan dan visualisasi KPI Tingkat Pembayaran Tepat Waktu. Anda dapat memfilter dan mengelompokkan faktur untuk membandingkan ciri-ciri faktur yang terlambat dibayar dengan yang dibayar tepat waktu. Analisis ini dapat mengungkap pola berdasarkan pelanggan, wilayah, atau ketentuan pembayaran yang berkaitan dengan keterlambatan. Mengapa ini penting Atribut ini memudahkan pengukuran kinerja dengan menandai setiap faktur sebagai 'tepat waktu' atau 'terlambat', sehingga mendukung KPI Tingkat Pembayaran Tepat Waktu. Sumber data Kolom ini dihitung dengan membandingkan waktu aktivitas 'Pembayaran Pelanggan Diterima' dengan nilai pada atribut 'PaymentDueDate'. Contoh truefalse | |||
| Jenis Dokumen Penagihan BillingDocumentType | Kode untuk mengelompokkan dokumen penagihan, seperti faktur, nota kredit, atau pembatalan. | ||
| Deskripsi Jenis Dokumen Penagihan adalah kolom penting yang mengelompokkan transaksi dalam proses penagihan. Jenis ini mengatur cara dokumen diproses, termasuk rentang nomor dan aturan pencatatan akuntansinya. Atribut ini memungkinkan Anda memfilter proses untuk menganalisis jenis transaksi tertentu. Misalnya, buat tampilan proses khusus untuk nota kredit guna memahami alasan dan alur koreksi keuangan. Anda juga dapat menganalisis faktur standar secara terpisah dari pembatalan agar proses penagihan utama terlihat lebih jelas. Mengapa ini penting Atribut ini mengelompokkan transaksi, sehingga Anda dapat menganalisis alur dokumen tertentu, seperti faktur standar, nota kredit, atau pembatalan. Sumber data Tabel SAP: VBRK, Kolom: FKART Contoh F2G2S1L2 | |||
| Ketentuan pembayaran PaymentTerms | Kode yang menentukan ketentuan pembayaran, seperti jangka waktu pembayaran. | ||
| Deskripsi Ketentuan Pembayaran adalah syarat yang disepakati dengan pelanggan untuk menentukan kapan faktur harus dibayar. Contohnya, 'Net 30' berarti pembayaran jatuh tempo dalam 30 hari, sedangkan '2/10 Net 30' berarti pelanggan mendapat diskon 2% jika membayar dalam 10 hari, atau harus membayar penuh dalam 30 hari. Analisis berdasarkan ketentuan pembayaran membantu menilai efektivitasnya. Dengan membandingkan ketentuan yang berbeda dengan waktu pembayaran sebenarnya, perusahaan dapat mengetahui ketentuan mana yang paling mendorong pembayaran tepat waktu dan menyesuaikannya untuk memperbaiki arus kas. Mengapa ini penting Atribut ini menjelaskan jadwal pembayaran yang disepakati. Dengan begitu, Anda dapat menganalisis ketentuan mana yang paling efektif mendorong pelanggan membayar tepat waktu. Sumber data Tabel SAP: VBRK, Kolom: ZTERM Contoh Z030Z060ZB60 | |||
| Kode Perusahaan CompanyCode | Unit organisasi tempat transaksi keuangan dicatat. | ||
| Deskripsi Kode Perusahaan adalah entitas organisasi utama di SAP Financials. Kode ini mewakili perusahaan yang berdiri secara hukum dan menjadi dasar penyusunan laporan keuangan. Setiap dokumen penagihan dikaitkan dengan kode perusahaan tertentu. Dalam organisasi yang memiliki beberapa perusahaan, analisis berdasarkan Kode Perusahaan penting untuk membandingkan kinerja proses, metrik keuangan seperti DSO, dan kepatuhan antarentitas hukum. Kode ini juga menjadi filter organisasi tingkat tinggi untuk semua dasbor proses. Mengapa ini penting Atribut ini memungkinkan analisis proses berdasarkan entitas hukum, sehingga Anda dapat membandingkan kinerja dan menggabungkan laporan keuangan di seluruh organisasi. Sumber data Tabel SAP: VBRK, Kolom: BUKRS Contoh 10002000US01 | |||
| Mata uang Currency | Kode mata uang untuk jumlah faktur. | ||
| Deskripsi Atribut ini menunjukkan mata uang yang digunakan untuk menyatakan jumlah faktur, seperti USD, EUR, atau JPY. Informasi ini memberikan konteks yang diperlukan untuk semua nilai uang. Di organisasi global, mata uang penting untuk memastikan analisis dan pelaporan keuangan yang akurat. Atribut ini memungkinkan data keuangan dijumlahkan dengan benar setelah dikonversi ke mata uang pelaporan yang sama, serta membantu membandingkan kinerja penagihan antarwilayah dengan mata uang lokal yang berbeda. Mengapa ini penting Atribut ini memberikan konteks penting untuk semua nilai uang sehingga analisis dan pelaporan keuangan tetap akurat, terutama dalam operasional multinasional. Sumber data Tabel SAP: VBRK, Kolom: WAERK Contoh USDEURGBP | |||
| Nomor Pesanan Penjualan SalesOrderNumber | Nomor identitas pesanan penjualan awal yang menjadi dasar pembuatan faktur. | ||
| Deskripsi Nomor Pesanan Penjualan menghubungkan dokumen penagihan dengan aktivitas penjualan sebelumnya. Satu pesanan penjualan dapat menghasilkan satu atau beberapa faktur. Tautan ini menunjukkan alur dokumen secara lengkap. Atribut ini penting untuk analisis Order-to-Cash dari awal hingga akhir. Atribut ini memperluas analisis ke tahap sebelumnya, sehingga masalah penagihan dapat dikaitkan dengan kemungkinan penyebabnya saat pesanan dibuat atau dipenuhi. Misalnya, atribut ini membantu menghitung total waktu pembuatan faktur sejak pesanan dipenuhi. Mengapa ini penting Atribut ini menghubungkan faktur dengan pesanan penjualan awal, sehingga Anda dapat melihat proses Order-to-Cash secara menyeluruh, bukan hanya tahap penagihan. Sumber data Tabel SAP: VBRP (Data Item Dokumen Penagihan), Kolom: AUBEL Contoh 100001231000045610000789 | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk peristiwa ini terakhir kali diekstrak atau diperbarui. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu terakhir kali data diambil dari sistem sumber. Sebagai kolom metadata, atribut ini penting untuk mengetahui seberapa baru data yang dianalisis. Informasi ini digunakan untuk memeriksa kebaruan analisis dan mengatur jadwal pembaruan data. Dengan begitu, pemangku kepentingan mengetahui seberapa mutakhir data saat mengambil keputusan berdasarkan dashboard dan wawasan process mining. Mengapa ini penting Atribut ini menunjukkan seberapa baru data, hal penting untuk memercayai hasil analisis dan memahami relevansinya dengan kondisi operasional saat ini. Sumber data Stempel waktu ini dibuat dan ditambahkan ke setiap catatan selama proses ekstraksi dan pemuatan data (ETL). Contoh 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Sistem sumber SourceSystem | Menunjukkan sistem sumber tertentu tempat data diambil. | ||
| Deskripsi Atribut ini menunjukkan asal data. Informasi ini berguna terutama jika lingkungan Anda menggunakan beberapa instans SAP atau sistem terintegrasi lainnya. Biasanya, atribut ini mencakup ID sistem dan nomor klien. Dalam analisis, atribut ini membantu membedakan proses dan kinerja antar sistem atau entitas organisasi. Atribut ini juga memastikan asal-usul data dapat dilacak dan memberikan konteks, terutama saat data dari beberapa sumber digabungkan untuk memberikan gambaran proses secara menyeluruh. Mengapa ini penting Atribut ini memberikan konteks penting tentang asal data, memperjelas informasi di lingkungan dengan banyak sistem, dan mendukung tata kelola data. Sumber data Biasanya, nilai statis ini ditentukan saat ekstraksi data dan menggabungkan ID sistem (SY-SYSID) dengan klien (SY-MANDT). Contoh S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Status Pembayaran PaymentStatus | Status pembayaran faktur saat ini, seperti Belum Dibayar, Lunas, atau Terlambat. | ||
| Deskripsi Status Pembayaran menunjukkan posisi faktur dalam proses penagihan. Di SAP, status ini tidak berasal dari satu kolom, tetapi ditentukan dengan memeriksa status pelunasan dokumen akuntansi terkait. Atribut ini penting untuk dasbor Umur Faktur Belum Lunas. Anda dapat mengelompokkan semua faktur yang belum lunas berdasarkan status dan umurnya, sehingga tim penagihan dapat menentukan prioritas. Perubahan status juga dapat digunakan untuk memantau proses penagihan. Mengapa ini penting Atribut ini menunjukkan status penagihan setiap faktur dengan jelas, sehingga tim dapat mengelola piutang dan menentukan prioritas penagihan. Sumber data Ditentukan dengan memeriksa status pelunasan dokumen akuntansi (VBRK-BELNR) di tabel keuangan seperti BSID (pos terbuka) dan BSAD (pos yang telah dilunasi). Contoh Belum DibayarLunasTerlambatDibayar Sebagian | |||
Aktivitas Order-to-Cash, Penagihan dan Pembuatan Faktur
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Faktur dibuat | Aktivitas ini menandai pembuatan dokumen penagihan di sistem. Peristiwa ini tercatat secara eksplisit saat pengguna menjalankan transaksi seperti VF01 atau saat pekerjaan latar belakang membuat faktur, sehingga muncul entri baru di tabel header dokumen penagihan. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam proses penagihan. Analisis waktu dari pemenuhan pesanan hingga aktivitas ini penting untuk mengukur waktu siklus pembuatan faktur dan menemukan keterlambatan di tahap awal proses. Sumber data Tercatat di tabel VBRK SAP S/4HANA (Billing Document: Header Data) saat dokumen dibuat. Tanggal pembuatan (VBRK-ERDAT) dan waktu pembuatan (VBRK-ERZET) digunakan sebagai stempel waktu. Pengumpulan data Peristiwa ini diambil dari stempel waktu pembuatan catatan dokumen penagihan di tabel VBRK. Jenis peristiwa explicit | |||
| Faktur diposting ke akuntansi | Menandai keberhasilan posting dokumen penagihan ke modul akuntansi keuangan. Ini adalah tahap penting saat faktur menjadi piutang resmi dan menghasilkan entri di buku besar. | ||
| Mengapa ini penting Aktivitas ini memastikan faktur menjadi dokumen keuangan yang sah. Waktu antara pembuatan dan posting menjadi indikator kinerja utama untuk menilai efisiensi pemrosesan internal. Sumber data Peristiwa ini tercatat saat dokumen akuntansi terkait dibuat. Dokumen penagihan (VBRK-VBELN) terhubung ke dokumen akuntansi (BKPF-BELNR) melalui VBRK-BELNR, sedangkan tanggal posting tercatat di BKPF-BUDAT. Pengumpulan data Diambil dari tanggal posting (BUDAT) dokumen akuntansi di tabel BKPF yang terhubung ke dokumen penagihan. Jenis peristiwa explicit | |||
| Faktur ditutup | Aktivitas ini menandai status akhir faktur yang telah dibayar lunas. Fungsinya sama dengan 'Pembayaran dialokasikan/dicocokkan' dan menunjukkan bahwa proses untuk faktur ini telah selesai. | ||
| Mengapa ini penting Menjadi peristiwa akhir utama untuk alur proses yang berjalan lancar. Pengukuran total waktu siklus hingga tahap ini memberikan gambaran lengkap tentang siklus penagihan dan pembuatan faktur dari awal hingga akhir. Sumber data Disimpulkan dari status item baris pelanggan di dokumen akuntansi. Item berstatus ditutup atau 'dilunasi' jika kolom tanggal pelunasan (BSEG-AUGDT) dan dokumen pelunasan (BSEG-AUGBL) telah terisi. Pengumpulan data Disimpulkan dari terisinya tanggal pelunasan (AUGDT) di tabel BSEG/ACDOCA untuk item baris faktur. Jenis peristiwa inferred | |||
| Pembayaran dialokasikan/dicocokkan | Menandai saat pembayaran masuk dari pelanggan dicocokkan dan digunakan untuk melunasi item faktur terbuka di buku pembantu piutang. Dari sisi keuangan, aktivitas ini menyelesaikan transaksi. | ||
| Mengapa ini penting Mengukur efisiensi proses pencatatan pembayaran. Keterlambatan pada tahap ini dapat membuat saldo akun pelanggan tidak mencerminkan keadaan sebenarnya dan menambah pekerjaan yang tidak perlu bagi tim penagihan. Sumber data Peristiwa ini diambil dari tanggal pelunasan (BSEG-AUGDT) pada item baris dokumen akuntansi faktur asli. Tanggal ini terisi saat dokumen pelunasan melunasi item tersebut. Pengumpulan data Diambil dari kolom tanggal pelunasan (AUGDT) di tabel BSEG/ACDOCA untuk item baris faktur. Jenis peristiwa explicit | |||
| Pembayaran pelanggan diterima | Aktivitas ini menandai pencatatan pembayaran masuk dari pelanggan ke sistem keuangan. Pada tahap ini, pembayaran mungkin belum dialokasikan ke faktur tertentu, tetapi dana sudah tercatat. | ||
| Mengapa ini penting Ini adalah tahap penting untuk menghitung Days Sales Outstanding (DSO). Tahap ini menandakan kas sudah diterima, meski pencocokan pembayaran masih tertunda. Sumber data Diambil dari tanggal posting (BKPF-BUDAT) dokumen pembayaran pelanggan, yang biasanya bertipe dokumen 'DZ' di tabel BKPF. Pengumpulan data Peristiwa ini didasarkan pada pembuatan dokumen pembayaran di BKPF/BSEG. Jenis peristiwa explicit | |||
| Faktur dibatalkan | Terjadi saat faktur yang sudah dibuat dibatalkan, biasanya dengan membuat dokumen pembatalan terkait. Tindakan ini membalikkan faktur asli beserta dampaknya pada akuntansi. | ||
| Mengapa ini penting Menunjukkan pengerjaan ulang, koreksi, atau kesalahan penagihan. Pembatalan yang sering terjadi mengindikasikan masalah besar di tahap sebelumnya, seperti entri pesanan penjualan atau konfigurasi penagihan. Sumber data Tercatat saat dokumen penagihan pembatalan dibuat, misalnya dengan jenis dokumen 'S1'. Dokumen baru di VBRK ini merujuk ke nomor faktur asli melalui kolom VBRK-SFAKN. Pengumpulan data Peristiwa ini diambil dari tanggal pembuatan dokumen pembatalan di VBRK yang merujuk ke faktur asli. Jenis peristiwa explicit | |||
| Faktur diblokir untuk diposting | Peristiwa ini terjadi saat faktur dibuat, tetapi otomatis diblokir agar tidak diposting ke akuntansi keuangan karena berbagai alasan, seperti pemeriksaan kredit atau data yang tidak konsisten. Status ini disimpulkan dari kolom status posting pada dokumen penagihan. | ||
| Mengapa ini penting Menunjukkan hambatan saat faktur sudah dibuat, tetapi belum langsung diteruskan ke bagian keuangan sehingga seluruh siklus penagihan kas tertunda. Ini menjadi indikator penting masalah kualitas data atau pengelolaan kredit. Sumber data Disimpulkan dari kolom status posting di tabel header dokumen penagihan (VBRK-RFBSK). Status seperti 'A' (Billing document blocked for forwarding to FI) menunjukkan adanya pemblokiran. Pengumpulan data Disimpulkan dengan memeriksa nilai kolom status posting (VBRK-RFBSK) segera setelah faktur dibuat. Jenis peristiwa inferred | |||
| Faktur dikirim ke pelanggan | Aktivitas ini menandai pengiriman faktur kepada pelanggan, misalnya melalui cetak, email, atau EDI. Cara pencatatannya bergantung pada konfigurasi pengelolaan output di SAP. | ||
| Mengapa ini penting Dari sudut pandang pelanggan, inilah awal resmi penghitungan waktu pembayaran. Keterlambatan pengiriman faktur berdampak langsung pada Days Sales Outstanding (DSO) dan arus kas. Sumber data Peristiwa ini dapat dicatat secara eksplisit di tabel kontrol output, seperti NAST untuk metode lama atau padanannya di S/4HANA. Jika tidak tercatat secara eksplisit, waktu peristiwa ini sering disimpulkan sama dengan waktu 'Faktur diposting ke akuntansi'. Pengumpulan data Periksa log pemrosesan di tabel pengelolaan output untuk menemukan stempel waktu yang terkait dengan jenis output faktur. Jenis peristiwa explicit | |||
| Nota kredit dibuat | Aktivitas ini menandai pembuatan nota kredit untuk pelanggan, misalnya untuk mengoreksi tagihan berlebih atau memberikan kredit atas barang yang dikembalikan. Nota kredit sering terhubung ke faktur asli. | ||
| Mengapa ini penting Menunjukkan masalah yang mengakibatkan penyesuaian keuangan setelah penagihan. Analisis nota kredit dapat mengungkap kesalahan harga, masalah produk, atau akar penyebab lain yang mengurangi pendapatan. Sumber data Dibuat secara eksplisit sebagai dokumen penagihan baru di VBRK dengan jenis penagihan khusus nota kredit, misalnya 'G2'. Dokumen ini sering merujuk ke pesanan penjualan atau faktur asli. Pengumpulan data Diambil dari pembuatan dokumen penagihan bertipe nota kredit di VBRK. Jenis peristiwa explicit | |||
| Pengerjaan ulang penagihan teridentifikasi | Peristiwa hasil perhitungan yang mengidentifikasi siklus pengerjaan ulang: faktur dibatalkan, lalu faktur baru dibuat untuk pesanan penjualan yang sama. Ini bukan satu transaksi, melainkan pola dari beberapa peristiwa. | ||
| Mengapa ini penting Mendukung KPI Tingkat Pengerjaan Ulang Penagihan secara langsung dengan menghitung kejadian koreksi. Informasi ini membantu menemukan inefisiensi dan mengukur biaya akibat kualitas proses penagihan yang buruk. Sumber data Pola ini dihitung dengan mencari peristiwa 'Faktur dibatalkan' yang diikuti peristiwa 'Faktur dibuat' baru. Keduanya harus merujuk ke dokumen sumber yang sama, seperti nomor pesanan penjualan. Pengumpulan data Diperoleh dengan mendeteksi urutan 'Faktur dibatalkan' lalu 'Faktur dibuat' untuk referensi pesanan penjualan yang sama. Jenis peristiwa calculated | |||
| Pengingat pembayaran dikirim | Menandai pengiriman pengingat pembayaran atau surat penagihan kepada pelanggan untuk faktur yang telah jatuh tempo. Prosedur penagihan otomatis menghasilkan peristiwa ini secara eksplisit. | ||
| Mengapa ini penting Membantu menganalisis efektivitas proses penagihan. Anda dapat mengetahui apakah pengingat mempercepat pembayaran dan tingkat penagihan mana yang paling berdampak. Sumber data Tercatat di tabel riwayat penagihan (MAHNV, MHND) saat proses penagihan (Transaksi F150) dijalankan untuk item terbuka pada faktur. Pengumpulan data Diambil dari tanggal proses surat penagihan yang tercatat di tabel riwayat penagihan. Jenis peristiwa explicit | |||
| Sengketa pelanggan dibuka | Aktivitas ini terjadi saat pelanggan mengajukan sengketa atas faktur dan sengketa tersebut dicatat secara resmi di sistem. Aktivitas ini memerlukan modul SAP Dispute Management. | ||
| Mengapa ini penting Menunjukkan masalah pada akurasi penagihan, kualitas produk, atau pengiriman layanan yang menyebabkan keterlambatan pembayaran. Analisis alasan sengketa dapat membantu mengatasi akar masalah dan meningkatkan kepuasan pelanggan. Sumber data Dicatat saat kasus sengketa dibuat di tabel Dispute Management, misalnya UDM_CASE, lalu dihubungkan ke item baris dokumen akuntansi. Pengumpulan data Diambil dari stempel waktu pembuatan catatan kasus sengketa yang terhubung ke faktur. Jenis peristiwa explicit | |||
| Tanggal jatuh tempo pembayaran tercapai | Peristiwa hasil perhitungan yang menunjukkan tanggal resmi jatuh tempo pembayaran faktur sesuai ketentuan pembayaran yang disepakati. Ini bukan peristiwa transaksi, melainkan diturunkan dari data faktur. | ||
| Mengapa ini penting Tanggal ini menjadi acuan penting untuk mengukur ketepatan waktu pembayaran dan menganalisis perilaku pembayaran pelanggan. Dengan acuan ini, Anda dapat membedakan pembayaran tepat waktu dan pembayaran yang terlambat. Sumber data Dihitung berdasarkan tanggal dasar pembayaran (BSEG-ZFBDT) dan ketentuan pembayaran yang tersimpan di item baris pelanggan pada dokumen akuntansi. Pengumpulan data Diperoleh dengan menambahkan jumlah hari sesuai ketentuan pembayaran ke tanggal dasar pembayaran di item baris dokumen akuntansi (BSEG). Jenis peristiwa calculated | |||
Panduan ekstraksi
Langkah
- Prasyarat: Pastikan Anda memiliki akun pengguna SAP S/4HANA dengan otorisasi yang diperlukan untuk menjalankan kueri pada tampilan Core Data Services (CDS). Anda memerlukan akses baca ke tampilan seperti I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase, dan I_DunningHistory.
- Buka alat ekstraksi data: Masuk ke sistem SAP S/4HANA Anda. Anda dapat menggunakan berbagai alat untuk menjalankan kueri SQL pada tampilan CDS, seperti SAP HANA Studio, DBeaver yang terhubung melalui klien SAP HANA, atau plugin SAP Analysis for Microsoft Excel. Panduan ini menggunakan klien SQL standar.
- Tentukan parameter sistem: Sebelum menjalankan kueri, tentukan Company Code dan rentang tanggal yang akan dianalisis. Sebaiknya mulai dengan cakupan terbatas, misalnya data 3 hingga 6 bulan terakhir, agar kueri dapat dijalankan dalam waktu yang wajar.
- Siapkan kueri SQL: Salin seluruh kueri SQL dari bagian 'query' dokumen ini ke klien SQL pilihan Anda.
- Sesuaikan nilai placeholder: Ubah nilai placeholder dalam kueri. Ganti
'YYYY-MM-DD'dengan tanggal mulai dan akhir yang diinginkan. Ganti'XXXX'dengan Company Code yang dituju. Anda mungkin juga perlu menyesuaikan placeholder untuk jenis dokumen nota kredit, misalnya'G2', sesuai konfigurasi sistem Anda. - Jalankan kueri: Jalankan kueri SQL yang telah diubah pada basis data SAP S/4HANA. Waktu eksekusi bergantung pada volume data dalam rentang tanggal yang dipilih.
- Periksa hasilnya: Setelah kueri selesai, periksa hasilnya. Hasil kueri seharusnya berupa tabel datar, dengan setiap baris mewakili satu aktivitas dalam proses penagihan. Inilah log peristiwa Anda.
- Transformasi data (jika diperlukan): Kueri ini dirancang untuk menghasilkan log peristiwa dengan format yang rapi. Namun, periksa format stempel waktu untuk memastikan kompatibilitas dengan alat process mining Anda. Kueri menggunakan
ABAP_SYSTEM_UTCL_TO_TIMESTAMPuntuk mengubah stempel waktu ke format UTC standar yang umumnya kompatibel. - Ekspor log peristiwa: Ekspor seluruh hasil kueri dari klien SQL ke file CSV. Pastikan file menggunakan encoding UTF-8 agar karakter tidak bermasalah.
- Unggah ke ProcessMind: Unggah file CSV yang dihasilkan ke platform ProcessMind. Petakan kolom dalam file, seperti InvoiceNumber, ActivityName, dan EventTime, ke kolom yang sesuai di alat.
Konfigurasi
- Rentang tanggal: Atur tanggal mulai dan akhir dalam klausa
WHEREpada Common Table Expression (CTE) pertama. Untuk analisis awal, disarankan menggunakan rentang 3 hingga 6 bulan agar volume data dan kinerja tetap seimbang. Filter menggunakanBillingDocumentDate. - Company Code: Filter berdasarkan satu atau beberapa nilai
CompanyCodeuntuk membatasi ekstraksi ke entitas hukum yang relevan. Filter ini penting untuk mengendalikan cakupan data. - Jenis dokumen: Kueri ini menggunakan
BillingDocumentTypeuntuk mengenali nota kredit. Atur placeholder, misalnya('G2', 'CR'), ke jenis dokumen nota kredit yang digunakan organisasi Anda. - Prasyarat: Anda wajib memiliki akses ke tampilan CDS yang mendasarinya. Tim keamanan SAP Anda perlu memberikan peran dan otorisasi khusus. Selain itu, aktivitas seperti 'Customer Dispute Opened' atau 'Payment Reminder Issued' hanya tersedia jika modul SAP Dispute Management dan SAP Financials Dunning digunakan secara aktif di sistem Anda.
- Kinerja: Kueri ini menggunakan beberapa join dan union. Untuk kumpulan data yang sangat besar, misalnya data beberapa tahun, jalankan kueri di luar jam sibuk atau gunakan filter yang lebih ketat untuk membatasi pengambilan data awal.
Contoh kueri sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Langkah
- Pastikan tersedia akses baca langsung ke skema SAP HANA yang berisi tabel penagihan dan keuangan terkait. Minta nama skema, detail koneksi, rentang tanggal yang diizinkan, cakupan Company Code, jenis dokumen penagihan, serta filter pelanggan atau wilayah dari pemilik sistem. Ganti hanya placeholder koneksi dan filter dalam kueri.
- Pastikan sumber data SAP S/4HANA yang relevan dan pemetaan kolomnya sesuai dengan sistem tujuan. Kueri menggunakan VBRK dan VBRP untuk data penagihan, serta memerlukan sumber yang telah dikonfigurasi untuk akuntansi, manajemen output, manajemen sengketa, dunning, pembayaran masuk, clearing, dan relasi dokumen. Ganti placeholder sumber dan kolom dalam tanda kurung siku hanya setelah memvalidasinya dengan kamus data sistem.
- Atur periode ekstraksi dengan stempel waktu mulai inklusif dan stempel waktu akhir eksklusif. Untuk proses awal, disarankan menggunakan periode tiga hingga enam bulan. Batasi ekstraksi berdasarkan Company Code dan, jika sesuai, jenis penagihan untuk mengendalikan volume dan menghindari pencampuran proses penagihan yang tidak terkait.
- Jalankan kueri menggunakan pengguna basis data HANA dengan akses baca saja. Kueri membuat satu baris peristiwa untuk setiap aktivitas yang diekstrak secara eksplisit. Kueri tidak mengandalkan ProcessMind untuk menyimpulkan peristiwa. Aktivitas hasil perhitungan, termasuk Payment Due Date Reached dan Billing Rework Identified, dibuat melalui logika SQL dan dikembalikan sebagai baris.
- Validasi skema hasil. Log peristiwa harus memuat InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region, dan EndTime. Pastikan InvoiceNumber, ActivityName, dan EventTime terisi di setiap baris.
- Validasi makna peristiwa dan relasinya. Bandingkan baris Invoice Generated dengan data pembuatan header penagihan, baris Invoice Posted To Accounting dengan status posting akuntansi, baris Invoice Sent To Customer dengan catatan output, baris pembayaran dengan dokumen akuntansi, serta baris clearing dengan item faktur yang telah di-clearing. Tinjau semua bagian yang bergantung pada placeholder sebelum digunakan di lingkungan produksi.
- Siapkan hasil untuk ProcessMind. Pertahankan satu baris per peristiwa, gunakan tipe data dan zona waktu stempel waktu yang konsisten, simpan InvoiceNumber sebagai teks agar angka nol di depan tidak hilang, dan pastikan nilai ActivityName sama persis dengan nama aktivitas yang diwajibkan. Urutkan berdasarkan InvoiceNumber dan EventTime. Jika beberapa peristiwa memiliki stempel waktu yang sama, tambahkan urutan sekunder yang konsisten.
- Ekspor hasil sebagai CSV UTF-8 atau format tabular lain yang didukung ProcessMind. Petakan InvoiceNumber sebagai ID kasus, ActivityName sebagai kolom aktivitas, dan EventTime sebagai stempel waktu peristiwa. Sertakan atribut yang disarankan jika tersedia, lalu unggah file melalui proses impor ProcessMind yang telah dikonfigurasi. Terakhir, periksa jumlah baris dan jumlah aktivitas.
Konfigurasi
- Rentang tanggal: Mulai dengan data tiga hingga enam bulan. Gunakan stempel waktu mulai inklusif dan stempel waktu akhir eksklusif agar peristiwa tidak terduplikasi dalam proses ekstraksi bertahap.
- ID kasus: Gunakan InvoiceNumber dari header dokumen penagihan. Simpan sebagai string karena nomor dokumen SAP dapat diawali angka nol.
- Aktivitas wajib: Ekstraksi harus menghasilkan baris eksplisit untuk Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created, dan Billing Rework Identified.
- Filter: Gunakan filter Company Code, jenis dokumen penagihan, organisasi penjualan, pelanggan, wilayah, dan tanggal hanya setelah memastikan kolom terkait dan cakupan bisnisnya di sistem tujuan. Jangan berasumsi bahwa semua jenis dokumen penagihan mengikuti proses akuntansi atau output yang sama.
- Konfigurasi sumber: VBRK dan VBRP adalah sumber utama data penagihan. Sumber akuntansi, output, sengketa, dunning, pembayaran, clearing, dan alur dokumen harus dikonfigurasi sesuai versi SAP S/4HANA yang diterapkan dan modul yang diaktifkan. Ganti referensi sumber dalam tanda kurung siku dengan objek dan kolom yang sudah divalidasi.
- Peristiwa hasil perhitungan: Payment Due Date Reached dihitung dari data syarat pembayaran dan tanggal jatuh tempo. Billing Rework Identified dihitung dari pola pembatalan dan pembuatan faktur berikutnya. Keduanya adalah baris peristiwa yang dibuat oleh SQL, bukan catatan transaksi asli.
- Kinerja: Terapkan filter tanggal, Company Code, jenis penagihan, dan nomor dokumen di setiap kueri sumber. Pilih hanya kolom yang diperlukan, hindari join tanpa batas ke tabel akuntansi berukuran besar, proses data per bulan atau minggu, dan gunakan rencana eksekusi basis data untuk menemukan join yang lambat.
- Ekstraksi bertahap: Gunakan penanda waktu stabil berdasarkan stempel waktu pembuatan atau posting di sumber. Proses ulang rentang waktu kecil yang saling tumpang tindih untuk menangkap catatan output, pembayaran, sengketa, dan clearing yang terlambat masuk. Setelah itu, hapus duplikat berdasarkan InvoiceNumber, ActivityName, dan EventTime, serta kunci dokumen sumber yang relevan.
- Otorisasi: Pengguna ekstraksi memerlukan otorisasi baca untuk objek dan kolom skema HANA yang dipilih. Pastikan kebijakan keamanan organisasi mengizinkan akses basis data langsung dan persyaratan penanganan data pribadi atau pelanggan telah dipenuhi.
- Prasyarat fungsional: Data manajemen output, integrasi akuntansi, manajemen sengketa, dunning, pembayaran masuk, dan clearing hanya tersedia jika dikonfigurasi dan digunakan di sistem. Jika modul atau catatan sumber tidak tersedia, aktivitas terkait tidak akan muncul dan tidak disimpulkan.
- Zona waktu: Samakan stempel waktu dengan zona waktu yang dibutuhkan ProcessMind. Catat apakah stempel waktu sumber menggunakan UTC, waktu lokal sistem, atau zona waktu lain yang dikonfigurasi.
Contoh kueri sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Siap memulai?
Gunakan templat ini untuk mempercepat persiapan data dan mulai meningkatkan proses Order to Cash - Billing & Invoicing. Ubah data SAP S/4HANA Anda menjadi insight yang dapat ditindaklanjuti.
Percepat arus kas penagihan Order to Cash hingga 30%
Hilangkan inefisiensi dan pangkas waktu siklus penagihan hingga 30%, mulai sekarang.
Tidak perlu kartu kredit. Mulai dalam hitungan menit.