Templat data pemrosesan faktur utang usaha
Templat data pemrosesan faktur utang usaha
- Atribut yang disarankan untuk analisis menyeluruh
- Aktivitas proses utama yang perlu dilacak
- Panduan langkah demi langkah untuk mengambil data
Atribut pemrosesan faktur utang usaha
| Nama | Deskripsi | ||
|---|---|---|---|
| Aktivitas ActivityName | Nama peristiwa atau langkah bisnis tertentu yang terjadi selama siklus pemrosesan faktur. | ||
| Deskripsi Aktivitas menunjukkan tahap atau tindakan tertentu dalam proses utang usaha, seperti 'Faktur diterima', 'Faktur dibukukan', atau 'Pembayaran dijalankan'. Aktivitas ini menjadi bagian dasar peta proses. Analisis aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan alur proses, menemukan jalur yang umum, mendeteksi penyimpangan dari proses standar, serta mengukur frekuensi dan durasi setiap langkah. Urutan aktivitas untuk suatu faktur membentuk perjalanan prosesnya. Mengapa ini penting Aktivitas menentukan langkah-langkah proses sehingga Anda dapat memvisualisasikan dan menganalisis alur proses, menemukan hambatan, serta mendeteksi siklus pengerjaan ulang. Sumber data Diambil dari berbagai sumber, termasuk perubahan status dokumen (misalnya BKPF-BSTAT), dokumen perubahan (tabel CDHDR/CDPOS), atau log workflow. Biasanya, data ini memerlukan logika ekstraksi khusus. Contoh Faktur diterimaFaktur disetujuiPembayaran dijalankanFaktur diblokir untuk pembayaran | |||
| Faktur Invoice | Pengenal unik dokumen faktur yang berfungsi sebagai ID kasus utama untuk proses utang usaha. | ||
| Deskripsi Faktur adalah objek utama yang menghubungkan semua aktivitas terkait, dari penerimaan hingga pembayaran. Di SAP S/4HANA, faktur biasanya menggunakan kunci gabungan yang terdiri dari Kode Perusahaan (BUKRS), Nomor Dokumen unik (BELNR), dan Tahun Fiskal (GJAHR). Analisis berdasarkan faktur memberikan gambaran lengkap tentang siklus faktur dari awal hingga akhir. Ini menjadi dasar untuk menghitung metrik utama seperti total waktu siklus, menemukan hambatan pada faktur tertentu, dan memahami berbagai jalur yang dapat dilalui faktur dalam proses. Mengapa ini penting Faktur menjadi penanda unik untuk setiap perjalanan faktur. Dengan begitu, Anda dapat menelusuri seluruh siklusnya dan menganalisis kinerja proses untuk setiap kasus. Sumber data Kunci gabungan ini berasal dari tabel BKPF (Header Dokumen Akuntansi) atau RBKP (Header Dokumen: Penerimaan Faktur), menggunakan kolom BUKRS, BELNR, dan GJAHR. Contoh 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Waktu peristiwa EventTime | Tanggal dan waktu persis saat aktivitas terjadi. | ||
| Deskripsi Waktu peristiwa adalah stempel waktu untuk setiap aktivitas yang menunjukkan urutan kronologis peristiwa pada suatu faktur. Data ini penting untuk memahami alur proses dan melakukan analisis berbasis waktu. Dalam analisis, Waktu peristiwa digunakan untuk mengurutkan aktivitas dengan benar, menghitung waktu siklus antar langkah, menemukan waktu tunggu, dan menganalisis kinerja proses dalam periode tertentu, misalnya dari bulan ke bulan. Data ini menjadi dasar semua KPI berbasis durasi. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis dan menghitung semua metrik berbasis waktu, seperti waktu siklus dan durasi, yang menjadi dasar process mining. Sumber data Bersumber dari berbagai kolom tanggal dan waktu di tabel SAP, seperti Tanggal Pembuatan (BKPF-CPUDT), Tanggal Pembukuan (BKPF-BUDAT), Tanggal Kliring (BSAK-AUGDT), atau stempel waktu log perubahan (CDHDR-UDATE/UTIME). Contoh 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk catatan ini terakhir diperbarui dari sistem sumber. | ||
| Deskripsi Atribut ini menunjukkan tanggal dan waktu ekstraksi atau pembaruan data terbaru dari SAP S/4HANA. Kolom metadata ini penting untuk mengetahui seberapa baru data yang dianalisis. Informasi ini membantu pengguna memahami seberapa mutakhir analisis proses. Data ini juga membantu menetapkan ekspektasi tentang jeda pembaruan data, menjadwalkan pembaruan data, dan menjaga integritas data. Mengapa ini penting Menunjukkan kemutakhiran data agar pengguna mengetahui seberapa baru analisis proses yang mereka lihat. Sumber data Nilai ini dibuat dan dicatat pada setiap rekaman saat data diambil dari sistem sumber. Contoh 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Sistem sumber SourceSystem | Sistem tempat data diambil. | ||
| Deskripsi Atribut ini menunjukkan asal data proses. Untuk tampilan ini, nilainya biasanya 'SAP S/4HANA'. Di lingkungan dengan beberapa ERP atau sistem terintegrasi, kolom ini penting untuk menelusuri asal data dan memisahkan data. Kolom ini memastikan analisis menggunakan kumpulan data yang tepat dan membantu mencari masalah kualitas data hingga ke sumbernya. Mengapa ini penting Menunjukkan asal data. Informasi ini penting untuk tata kelola data, pemecahan masalah, dan lingkungan dengan beberapa sistem. Sumber data Biasanya berupa nilai statis yang ditambahkan saat ekstraksi data untuk menandai asal kumpulan data. Contoh SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Jumlah faktur InvoiceAmount | Jumlah bruto faktur dalam mata uang asli dokumen. | ||
| Deskripsi Ini adalah total nilai faktur yang diajukan pemasok. Jumlah ini mencakup biaya barang atau jasa, pajak, dan biaya lainnya sebelum potongan atau diskon. Jumlah faktur merupakan atribut keuangan penting untuk berbagai analisis. Data ini membantu memprioritaskan faktur bernilai tinggi, memahami dampak keuangan dari keterlambatan proses, seperti biaya keterlambatan pada faktur bernilai besar, dan mengelompokkan proses, misalnya 'Apakah faktur bernilai tinggi mengikuti jalur persetujuan yang berbeda?'. Data ini juga penting untuk menemukan kemungkinan pembayaran ganda. Mengapa ini penting Memberikan konteks keuangan untuk proses, sehingga Anda dapat menganalisis berdasarkan nilai, memprioritaskan faktur bernilai tinggi, dan mengukur dampak keuangan. Sumber data Ditemukan di tabel seperti RBKP-RMWWR (Jumlah bruto faktur) untuk faktur MM, atau dihitung dari item baris di BSEG (kolom WRBTR) untuk faktur FI. Contoh 1500.00250.7512345.50 | |||
| Kode perusahaan CompanyCode | Unit organisasi tempat faktur diproses. | ||
| Deskripsi Kode Perusahaan adalah unit organisasi terkecil yang dapat menyusun laporan keuangan lengkap dan mandiri untuk pelaporan eksternal. Dalam proses utang usaha, kode ini mewakili badan hukum yang berutang kepada pemasok. Analisis berdasarkan Kode Perusahaan memungkinkan Anda membandingkan kinerja proses antar badan hukum dalam organisasi. Dengan begitu, Anda dapat menemukan bagian bisnis yang mengikuti proses standar dan bagian yang memiliki efisiensi lebih rendah, waktu siklus lebih lama, atau tingkat pengerjaan ulang lebih tinggi. Mengapa ini penting Memungkinkan perbandingan kinerja proses antar badan hukum, sehingga Anda dapat menemukan masalah dan praktik baik yang spesifik untuk wilayah atau unit bisnis tertentu. Sumber data Ditemukan di tabel header dokumen, terutama BKPF-BUKRS untuk faktur FI dan RBKP-BUKRS untuk faktur MM. Contoh 10001710US01DE01 | |||
| Nama pemasok VendorName | Nama pemasok yang mengirimkan faktur. | ||
| Deskripsi Atribut ini memuat nama resmi pemasok. Nama tersebut ditautkan melalui Nomor Pemasok yang tersimpan di dokumen faktur. Analisis pemasok penting untuk mengelola hubungan dengan pemasok dan menemukan masalah proses yang terkait dengan pemasok tertentu. Analisis ini dapat menjawab pertanyaan seperti 'Pemasok mana yang paling sering mengirim faktur dengan selisih?' atau 'Apakah kita selalu membayar pemasok strategis tertentu tepat waktu?'. Bersama nomor dan jumlah faktur, atribut ini juga penting untuk mendeteksi kemungkinan pembayaran ganda. Mengapa ini penting Memungkinkan analisis kinerja proses berdasarkan pemasok, sehingga Anda dapat menemukan pemasok bermasalah dan mengelola hubungan dengan pemasok strategis secara efektif. Sumber data Diambil dari tabel data induk pemasok LFA1 (kolom NAME1), dengan menautkan Nomor Pemasok (LIFNR) yang ditemukan di BKPF atau RBKP. Contoh Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Nama pengguna UserName | ID pengguna yang melakukan aktivitas. | ||
| Deskripsi Atribut ini mencatat ID pengguna SAP yang bertanggung jawab atas aktivitas tertentu, seperti membukukan, menyetujui, atau melunasi faktur. Atribut ini menghubungkan langkah proses dengan pengguna tertentu. Analisis berdasarkan Nama pengguna penting untuk memahami pembagian beban kerja, menemukan pengguna dengan kinerja terbaik, dan mengidentifikasi pengguna yang mungkin memerlukan pelatihan tambahan. Atribut ini juga penting untuk menganalisis hambatan persetujuan di dashboard karena membantu menemukan pemberi persetujuan tertentu yang menyebabkan keterlambatan proses. Mengapa ini penting Mengaitkan aktivitas dengan orang tertentu sehingga Anda dapat menganalisis kinerja pengguna, beban kerja, dan kepatuhan terhadap kebijakan pemisahan tugas. Sumber data Biasanya ditemukan di tabel header seperti BKPF-USNAM (Dimasukkan oleh) atau di tabel dokumen perubahan CDHDR-USERNAME (Diubah oleh). Contoh ABROWNJSMITHAP_AUTOMATION | |||
| Nomor pesanan pembelian PurchaseOrderNumber | Pengenal unik pesanan pembelian yang terkait dengan faktur, jika ada. | ||
| Deskripsi Atribut ini menghubungkan faktur dengan pesanan pembelian (PO) yang telah disetujui sebelumnya. Adanya nomor PO menjadi dasar proses pencocokan 3 arah (PO-faktur-penerimaan barang). Atribut ini penting untuk analisis kepatuhan dan efisiensi. Atribut ini digunakan untuk menghitung KPI 'Persentase faktur tanpa PO', yang mengukur kepatuhan terhadap kebijakan pengadaan. Atribut ini juga menjadi dasar dashboard 'Kinerja pencocokan 3 arah' untuk menganalisis proses pencocokan faktur yang didukung PO. Mengapa ini penting Penting untuk menganalisis efisiensi pencocokan 3 arah dan mengukur kepatuhan terhadap kebijakan pengadaan dengan menemukan faktur yang diproses tanpa PO. Sumber data Ditemukan di tabel item baris faktur, seperti RSEG-EBELN (untuk faktur MM) atau BSEG-EBELN (untuk faktur FI). Contoh 45000012344500005678 | |||
| Tanggal jatuh tempo faktur InvoiceDueDate | Tanggal batas pembayaran faktur kepada pemasok. | ||
| Deskripsi Tanggal jatuh tempo faktur adalah batas waktu pembayaran kepada pemasok agar terhindar dari biaya keterlambatan dan hubungan dengan pemasok tetap terjaga. Tanggal ini dihitung berdasarkan tanggal dasar faktur dan ketentuan pembayaran yang disepakati dengan pemasok. Tanggal ini penting untuk dashboard 'Kepatuhan pembayaran dan umur utang' serta KPI 'Tingkat pembayaran tepat waktu'. Dengan membandingkan tanggal jatuh tempo dan tanggal pembayaran aktual, analisis dapat menunjukkan apakah pembayaran dilakukan tepat waktu, lebih awal, atau terlambat. Hal ini berdampak langsung pada keuangan dan hubungan dengan pemasok. Mengapa ini penting Tanggal ini menjadi dasar utama analisis pembayaran tepat waktu. Data ini membantu mengukur kinerja pembayaran dan dampaknya terhadap hubungan dengan pemasok serta biaya keterlambatan. Sumber data Tanggal ini sering kali dihitung. Tanggal jatuh tempo bersih tersedia di kolom BSEG-NETDT. Tanggal ini juga dapat dihitung dari tanggal dasar pembayaran (BSEG-ZFBDT) dan ketentuan pembayaran (BSEG-ZTERM). Contoh 2023-10-312023-11-152024-01-10 | |||
| Alasan pemblokiran BlockingReason | Alasan faktur diblokir agar tidak dibayar, yang menunjukkan adanya ketidaksesuaian. | ||
| Deskripsi Jika faktur tidak lolos pemeriksaan validasi dalam pencocokan 3 arah atau tahap verifikasi lainnya, faktur akan diblokir agar tidak dibayar. Alasan pemblokiran menjelaskan jenis masalahnya, seperti perbedaan jumlah, selisih harga, atau tanda terima barang yang belum ada. Atribut ini penting untuk dashboard 'Analisis Pengerjaan Ulang akibat Ketidaksesuaian Faktur'. Analisis frekuensi berbagai alasan pemblokiran membantu menemukan akar penyebab proses yang tidak efisien. Misalnya, jika 'Selisih harga' sering menjadi alasan, hal ini mungkin menunjukkan masalah pada data induk di sistem pembelian. Mengapa ini penting Menunjukkan secara langsung akar penyebab ketidaksesuaian faktur dan pengerjaan ulang, sehingga upaya perbaikan proses dapat diarahkan dengan tepat. Sumber data Tersimpan di tabel item baris faktur seperti RSEG, pada kolom yang diawali SPGR* (misalnya, SPGRP, SPGRQ, SPGRT). Data ini juga dapat ditemukan di RBKP_BLOCKED. Contoh Selisih hargaPerbedaan jumlahTanda terima barang belum ada | |||
| Apakah terlambat dibayar IsLatePayment | Penanda boolean yang menunjukkan apakah faktur dibayar setelah tanggal jatuh tempo. | ||
| Deskripsi Atribut hasil perhitungan ini berupa penanda benar/salah yang menunjukkan apakah faktur dibayar setelah tanggal jatuh tempo resmi. Nilainya diperoleh dengan membandingkan 'Tanggal pelunasan' dengan 'Tanggal jatuh tempo faktur'. Penanda ini memudahkan analisis untuk dashboard 'Kepatuhan Pembayaran dan Umur Utang' serta KPI 'Tingkat Pembayaran Tepat Waktu'. Anda dapat memfilter dan mengelompokkan data untuk menghitung jumlah pembayaran terlambat, persentase pembayaran tepat waktu, serta mengidentifikasi vendor atau kode perusahaan dengan tingkat keterlambatan tinggi. Mengapa ini penting Mengukur kepatuhan terhadap syarat pembayaran secara langsung, memudahkan penghitungan KPI pembayaran tepat waktu, dan membantu menemukan area dengan kinerja pembayaran yang buruk. Sumber data Atribut hasil perhitungan. Logikanya: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Contoh truefalse | |||
| Diotomatisasi IsAutomated | Penanda yang menunjukkan apakah aktivitas dilakukan otomatis oleh sistem, bukan oleh pengguna. | ||
| Deskripsi Atribut boolean ini membedakan aktivitas yang dimulai oleh manusia dari aktivitas yang dijalankan oleh pekerjaan sistem, workflow, atau bot. Misalnya, proses pembayaran otomatis atau pembukuan faktur yang dibuat sistem akan ditandai sebagai otomatis. Analisis atribut ini membantu memahami tingkat otomatisasi dalam proses utang usaha. Atribut ini dapat digunakan untuk mengukur keberhasilan inisiatif otomatisasi, membandingkan efisiensi langkah otomatis dan manual, serta menemukan peluang otomatisasi lainnya. Mengapa ini penting Membantu mengukur tingkat otomatisasi proses, menganalisis efektivitasnya, dan menemukan peluang untuk perbaikan lebih lanjut. Sumber data Disimpulkan berdasarkan Nama pengguna, misalnya ID pengguna sistem seperti 'SAP_SYSTEM' atau 'BATCHUSER', atau kode transaksi tertentu yang terkait dengan pekerjaan otomatis. Contoh truefalse | |||
| Diskon diperoleh DiscountTaken | Penanda boolean yang menunjukkan apakah diskon pembayaran awal berhasil diperoleh. | ||
| Deskripsi Atribut ini menunjukkan apakah diskon tunai benar-benar diperoleh saat faktur dibayar. Atribut ini penting untuk mengukur efisiensi keuangan dalam proses utang usaha. Penanda ini menjadi dasar KPI 'Tingkat Pemanfaatan Diskon Pembayaran Awal'. Filter faktur yang memenuhi syarat untuk mendapatkan diskon berdasarkan syarat pembayaran, lalu analisis penanda ini untuk menghitung dengan tepat jumlah penghematan dan peluang penghematan yang terlewat. Hasilnya memberi ukuran kinerja utang usaha yang jelas dan terukur. Mengapa ini penting Mengukur langsung keberhasilan memperoleh diskon pembayaran awal yang tersedia, yang berdampak langsung pada laba perusahaan. Sumber data Diperoleh dengan memeriksa apakah kolom jumlah diskon (BSEG-SKNTO) lebih besar dari nol pada dokumen pembayaran. Contoh truefalse | |||
| Jenis dokumen faktur InvoiceDocumentType | Klasifikasi dokumen faktur yang menentukan cara dokumen tersebut diproses di SAP. | ||
| Deskripsi Jenis Dokumen adalah elemen konfigurasi utama di SAP yang mengelompokkan dokumen akuntansi. Misalnya, 'KR' biasanya digunakan untuk faktur pemasok, 'RE' untuk faktur MM, dan 'KG' untuk nota kredit pemasok. Jenis ini menentukan hal-hal seperti rentang nomor dan kolom yang wajib diisi. Dalam analisis proses, pemfilteran berdasarkan Jenis Dokumen memungkinkan Anda membandingkan alur proses untuk berbagai jenis faktur. Misalnya, proses persetujuan nota kredit mungkin berbeda dari proses untuk faktur biasa. Informasi ini berguna untuk dashboard 'Variasi rute persetujuan faktur'. Mengapa ini penting Memungkinkan proses dikelompokkan berdasarkan penanganan tiap jenis faktur, sehingga variasi jalur pemrosesan dan waktu siklus dapat terlihat. Sumber data Diambil langsung dari kolom BKPF-BLART pada tabel header dokumen. Contoh KRREKG | |||
| Mata uang faktur InvoiceCurrency | Kode mata uang untuk jumlah faktur (misalnya, USD, EUR). | ||
| Deskripsi Atribut ini menunjukkan mata uang yang digunakan untuk menyatakan jumlah faktur. Informasi ini penting untuk memahami setiap nilai keuangan. Di organisasi multinasional, analisis faktur tanpa mempertimbangkan mata uang dapat menghasilkan kesimpulan yang keliru. Kolom ini memungkinkan data keuangan ditangani dengan tepat, baik dengan mengonversi semua jumlah ke satu mata uang pelaporan maupun dengan mengelompokkan analisis berdasarkan mata uang untuk memahami aktivitas keuangan di tiap wilayah. Mengapa ini penting Memberi konteks yang diperlukan untuk memahami jumlah faktur dan mendukung analisis serta pelaporan keuangan yang akurat, terutama di organisasi multinasional. Sumber data Tersedia di tabel header dokumen, terutama BKPF-WAERS atau RBKP-WAERS. Contoh USDEURGBPJPY | |||
| Nomor faktur vendor VendorInvoiceNumber | Nomor faktur yang dicantumkan vendor pada dokumennya. | ||
| Deskripsi Nomor referensi dari sistem akuntansi vendor, yang tercetak pada faktur fisik atau elektronik. Nomor ini dimasukkan secara manual atau diambil dengan OCR saat faktur diterima. Kolom ini sangat penting untuk keperluan operasional dan analisis, terutama untuk dashboard 'Potensi Pembayaran Faktur Duplikat'. Salah satu cara umum untuk mendeteksi duplikat adalah mencari beberapa dokumen faktur internal dengan Nama Vendor, Nomor Faktur Vendor, dan Jumlah Faktur yang sama. Nomor ini menjadi referensi eksternal utama untuk sebuah faktur. Mengapa ini penting Kolom penting untuk mendeteksi potensi pembayaran duplikat dan menjadi referensi eksternal utama saat berkomunikasi dengan vendor. Sumber data Tersimpan di kolom 'Referensi' pada header dokumen, biasanya BKPF-XBLNR. Contoh INV-2023-9876733401120231015-001 | |||
| Syarat pembayaran PaymentTerms | Ketentuan yang disepakati dengan vendor untuk membayar faktur, sering kali termasuk peluang mendapatkan diskon. | ||
| Deskripsi Syarat pembayaran menetapkan aturan tanggal jatuh tempo dan kemungkinan diskon untuk pembayaran lebih awal. Contohnya, syarat seperti 'Z001' dapat berarti 'Dibayar dalam 30 hari, diskon 2% jika dibayar dalam 10 hari'. Atribut ini menjadi dasar bagi dashboard 'Tingkat Pemanfaatan Diskon Pembayaran Awal'. Dengan menganalisis syarat pembayaran, Anda dapat mengidentifikasi semua faktur yang memenuhi syarat untuk mendapatkan diskon. Bandingkan dengan diskon yang benar-benar diperoleh untuk mengetahui peluang penghematan yang terlewat dan mengukur efisiensi proses pembayaran. Mengapa ini penting Atribut ini penting untuk menganalisis peluang diskon pembayaran awal, mengukur kinerja keuangan proses pembayaran, dan mengidentifikasi penghematan yang terlewat. Sumber data Tersedia di item baris vendor, tabel BSEG-ZTERM, atau di header faktur pada RBKP-ZTERM. Contoh Z0010001NT30 | |||
| Tanggal pelunasan ClearingDate | Tanggal pembayaran dilakukan dan faktur dilunasi dari item terbuka. | ||
| Deskripsi Tanggal pelunasan menandai penyelesaian keuangan faktur. Pada tanggal ini, aktivitas 'Pembayaran Dilunasi' terjadi, yang menjadi langkah terakhir dalam sebagian besar proses faktur yang berhasil. Tanggal ini digunakan untuk menghitung tanggal pembayaran aktual dan membandingkannya dengan tanggal jatuh tempo faktur. Karena itu, tanggal ini penting untuk menghitung KPI 'Tingkat Pembayaran Tepat Waktu' dan menganalisis kinerja pembayaran. Tanggal ini juga menjadi titik akhir untuk menghitung waktu siklus faktur dari awal hingga akhir. Mengapa ini penting Menandai pelunasan akhir faktur, menjadi titik akhir penghitungan waktu siklus dan dasar analisis pembayaran tepat waktu. Sumber data Tersedia di tabel item yang telah dilunasi, seperti BSAK-AUGDT untuk vendor. Contoh 2023-10-282023-11-142024-01-09 | |||
Aktivitas pemrosesan faktur utang usaha
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Faktur dibatalkan | Dokumen faktur dibalik sehingga dampak keuangannya dibatalkan. Ini merupakan kemungkinan status akhir proses, biasanya karena entri yang keliru atau sengketa dengan pemasok. | ||
| Mengapa ini penting Pelacakan pembatalan membantu menemukan penyebab kegagalan proses, seperti pengiriman ganda atau data faktur yang keliru. Temuan ini dapat menunjukkan masalah pada tahap sebelumnya. Sumber data Peristiwa ini tercatat secara eksplisit saat dokumen pembalik dibuat. Header dokumen asli (BKPF) akan memuat nomor dokumen pembalik (STBLG) dan alasan pembalikan. Pengumpulan data Temukan tanggal pembukuan dokumen pembalik yang ditautkan di header dokumen asli (BKPF-STBLG). Jenis peristiwa explicit | |||
| Faktur diblokir untuk pembayaran | Sistem memblokir faktur, secara otomatis atau manual, sehingga faktur tidak dapat dibayar. Biasanya, pemblokiran terjadi karena selisih harga atau kuantitas, atau karena persetujuan belum lengkap. | ||
| Mengapa ini penting Ini merupakan indikator penting adanya masalah dan pengerjaan ulang. Analisis alasan dan durasi pemblokiran membantu menemukan akar penyebab keterlambatan pembayaran dan inefisiensi proses. Sumber data Status ini tercatat secara eksplisit di kolom Kunci Blokir Pembayaran (ZLSPR) pada item baris pemasok dalam dokumen akuntansi (tabel BSEG). Pengumpulan data Dicatat melalui dokumen perubahan saat kolom BSEG-ZLSPR diisi dengan alasan pemblokiran. Jenis peristiwa explicit | |||
| Faktur dibukukan | Faktur dicatat secara resmi di buku besar, sehingga menimbulkan kewajiban keuangan. Dokumen yang ditangguhkan berubah menjadi dokumen yang dibukukan, atau faktur langsung dibukukan. | ||
| Mengapa ini penting Ini merupakan tahap penting dalam pencatatan keuangan. Tahap ini menegaskan kewajiban perusahaan untuk membayar dan sering menjadi prasyarat untuk menjadwalkan pembayaran. Sumber data Peristiwa ini dikenali dari Tanggal Pembukuan (BUDAT) pada header dokumen (BKPF). Dokumen yang sudah dibukukan memiliki status dokumen (BKPF-BSTAT) kosong. Pengumpulan data Gunakan stempel waktu pembukuan (BKPF-BUDAT) untuk dokumen yang tidak ditangguhkan (BKPF-BSTAT kosong). Jenis peristiwa explicit | |||
| Faktur disetujui | Faktur telah menerima semua persetujuan yang diperlukan dalam sistem workflow. Ini biasanya menjadi langkah terakhir sebelum faktur dapat dibukukan atau blokir pembayarannya dihapus. | ||
| Mengapa ini penting Tahap penting ini menandai berakhirnya siklus persetujuan. Waktu antara penerusan dan persetujuan menjadi metrik penting untuk mengukur efisiensi. Sumber data Peristiwa ini diambil dari log SAP Business Workflow sebagai langkah penyelesaian atau persetujuan akhir. Peristiwa ini juga dapat disimpulkan dari penghapusan blokir pembayaran setelah faktur diteruskan untuk persetujuan. Pengumpulan data Ambil peristiwa penyelesaian workflow dari log SAP workflow atau temukan peristiwa 'release' terakhir. Jenis peristiwa explicit | |||
| Faktur diterima | Aktivitas ini menandai pembuatan dokumen faktur di SAP, baik secara manual maupun melalui antarmuka otomatis seperti OCR/VIM. Peristiwa ini biasanya diambil dari tanggal dan waktu pembuatan header dokumen akuntansi. | ||
| Mengapa ini penting Sebagai titik awal proses, aktivitas ini penting untuk menghitung waktu siklus faktur dari awal hingga akhir dan mengukur throughput seluruh proses utang usaha. Sumber data Peristiwa ini diambil dari tabel header dokumen akuntansi (BKPF), menggunakan tanggal pembuatan dokumen (CPUDT) dan waktu (CPUTM). Pengumpulan data Gunakan stempel waktu pembuatan dokumen faktur (BKPF-CPUDT, BKPF-CPUTM). Jenis peristiwa explicit | |||
| Pembayaran dijalankan | Pembayaran untuk faktur telah dilakukan. Peristiwa ini tercatat saat proses pembayaran selesai dan dokumen pembayaran dibuat serta dibukukan. | ||
| Mengapa ini penting Aktivitas ini penting untuk analisis arus kas dan pengukuran KPI 'Tingkat pembayaran tepat waktu' dengan membandingkan tanggal pembayaran dengan tanggal jatuh tempo faktur. Sumber data Peristiwa ini diambil dari tanggal pembukuan dokumen pembayaran yang melunasi faktur. Nomor dokumen pembayaran ditautkan melalui kolom dokumen kliring (AUGBL) pada item baris faktur (BSEG). Pengumpulan data Temukan tanggal pembukuan (BUDAT) dokumen pembayaran yang melunasi item baris faktur. Jenis peristiwa explicit | |||
| Pembayaran dikliring | Aktivitas ini menandai penutupan akhir faktur. Pembayaran dan faktur direkonsiliasi dalam subbuku besar, yang menandakan proses telah selesai. | ||
| Mengapa ini penting Sebagai akhir proses yang pasti, aktivitas ini penting untuk menghitung waktu siklus dari awal hingga akhir secara akurat. Aktivitas ini menegaskan bahwa kewajiban telah dilunasi. Sumber data Peristiwa ini tercatat secara eksplisit saat kolom Tanggal Kliring (AUGDT) diisi pada item baris pemasok di dokumen faktur (tabel BSEG). Pengumpulan data Gunakan tanggal kliring (BSEG-AUGDT) dari item baris faktur. Jenis peristiwa explicit | |||
| Faktur ditangguhkan | Faktur telah dimasukkan ke sistem, tetapi belum dibukukan ke buku besar. Penangguhan biasanya dilakukan untuk menyimpan dokumen yang belum lengkap agar dapat diproses atau disetujui nanti. | ||
| Mengapa ini penting Dengan melacak faktur yang ditangguhkan, Anda dapat menemukan keterlambatan sebelum proses pembukuan resmi dimulai. Data ini juga dapat menunjukkan masalah kelengkapan data atau validasi awal. Sumber data Status ini disimpulkan dari kolom status dokumen pada header dokumen akuntansi (BKPF-BSTAT = 'V' untuk Parked). Peristiwa terjadi saat status tersebut ditetapkan. Pengumpulan data Temukan dokumen perubahan untuk tabel BKPF saat kolom BSTAT diisi 'V' (Vor-erfasst/Pre-entered). Jenis peristiwa inferred | |||
| Faktur diteruskan untuk persetujuan | Faktur dikirim ke workflow untuk mendapatkan persetujuan yang diwajibkan sesuai aturan bisnis. Ini menandai dimulainya subproses persetujuan. | ||
| Mengapa ini penting Aktivitas ini menjadi titik awal untuk mengukur KPI 'Rata-rata waktu persetujuan faktur' dan menganalisis hambatan persetujuan. Sumber data Peristiwa ini dapat diambil dari log SAP Business Workflow (tabel SWW*) yang mencatat dimulainya instans workflow yang ditautkan ke objek faktur, misalnya BUS2081. Pengumpulan data Ambil peristiwa awal workflow dari log SAP workflow, misalnya tabel SWW_WIHEAD, yang ditautkan ke dokumen faktur. Jenis peristiwa explicit | |||
| Faktur ditolak | Pemberi persetujuan menolak faktur dalam workflow persetujuan. Biasanya, faktur dikembalikan kepada petugas pemroses untuk diperbaiki atau diklarifikasi. | ||
| Mengapa ini penting Pelacakan penolakan membantu menemukan siklus pengerjaan ulang dalam proses persetujuan dan dapat menunjukkan masalah kepatuhan terhadap kebijakan atau pengodean faktur yang keliru. Sumber data Peristiwa ini dicatat sebagai hasil khusus dalam log SAP Business Workflow yang terkait dengan faktur. Pengumpulan data Ambil peristiwa status 'rejected' dari log SAP workflow. Jenis peristiwa explicit | |||
| Penerimaan barang cocok | Aktivitas ini menandakan bahwa kuantitas dan nilai faktur berhasil dicocokkan dengan dokumen penerimaan barang terkait. Ini merupakan validasi terakhir dalam pencocokan 3 arah. | ||
| Mengapa ini penting Pelacakan aktivitas ini membantu menemukan inefisiensi dalam proses pencocokan 3 arah dan mengidentifikasi selisih antara barang yang diterima dan barang yang ditagihkan pemasok. Sumber data Peristiwa ini disimpulkan dari adanya referensi dokumen material (penerimaan barang) pada item baris faktur, yang sering kali ditautkan melalui riwayat item pesanan pembelian. Pengumpulan data Disimpulkan dari adanya referensi dokumen Penerimaan Barang pada item baris faktur, misalnya di RSEG untuk faktur MIRO. Jenis peristiwa inferred | |||
| Pesanan pembelian cocok | Aktivitas ini menandakan bahwa faktur berhasil dicocokkan dengan pesanan pembelian terkait. Ini merupakan langkah penting dalam proses pencocokan 3 arah untuk faktur berbasis pengadaan. | ||
| Mengapa ini penting Analisis aktivitas ini membantu mengukur efisiensi proses pencocokan dan menjadi dasar KPI 'Kinerja pencocokan 3 arah' serta 'Persentase faktur tanpa PO'. Sumber data Peristiwa ini disimpulkan saat item baris faktur di tabel BSEG atau ACDOCA memuat nomor Pesanan Pembelian (EBELN) dan item (EBELP) yang valid. Pengumpulan data Disimpulkan dari adanya referensi Pesanan Pembelian (BSEG-EBELN) pada dokumen faktur saat dibuat. Jenis peristiwa inferred | |||
| Selisih diselesaikan | Aktivitas ini menunjukkan bahwa masalah yang sebelumnya ditemukan, dan kemungkinan menyebabkan pemblokiran pembayaran, telah diperiksa dan diselesaikan. Peristiwa ini tercatat saat blokir pembayaran pada faktur dihapus. | ||
| Mengapa ini penting Melacak siklus pengerjaan ulang ini penting untuk dashboard 'Analisis pengerjaan ulang akibat selisih faktur'. Data ini membantu mengukur waktu dan upaya yang digunakan untuk memperbaiki kesalahan. Sumber data Peristiwa ini disimpulkan dari dokumen perubahan yang menunjukkan penghapusan blokir pembayaran. Sumber utamanya adalah log perubahan untuk kolom BSEG-ZLSPR. Pengumpulan data Temukan dokumen perubahan untuk tabel BSEG saat nilai kolom ZLSPR diubah menjadi kosong. Jenis peristiwa inferred | |||
| Tanggal jatuh tempo faktur terlewati | Peristiwa hasil perhitungan yang menandakan tanggal jatuh tempo bersih faktur telah lewat, tetapi pembayaran belum digunakan untuk melunasinya. Ini menunjukkan pembayaran terlambat atau tertunggak. | ||
| Mengapa ini penting Aktivitas ini penting untuk dashboard 'Kepatuhan pembayaran dan umur utang'. Data ini membantu menemukan dan menangani faktur yang terlambat dibayar, serta menganalisis akar penyebab keterlambatan. Sumber data Peristiwa ini tidak tercatat secara eksplisit di SAP. Peristiwa dihitung dengan membandingkan tanggal saat ini di sistem dengan Tanggal Jatuh Tempo Bersih, yang dihitung dari BSEG-ZFBDT atau tanggal dasar dan ketentuan pembayaran. Pengumpulan data Peristiwa hasil perhitungan yang dipicu saat stempel waktu peristiwa melewati tanggal jatuh tempo bersih faktur. Jenis peristiwa calculated | |||
| Usulan pembayaran dibuat | Faktur telah dimasukkan ke usulan pembayaran sebagai bagian dari proses pembayaran, misalnya F110. Faktur kini dijadwalkan untuk dibayar setelah proses pembayaran dijalankan. | ||
| Mengapa ini penting Aktivitas ini menunjukkan perubahan dari kewajiban yang masih terbuka menjadi item yang sedang disiapkan untuk dibayar. Data ini membantu menganalisis efisiensi operasional pembayaran. Sumber data Peristiwa ini dicatat secara eksplisit dalam tabel data proses pembayaran, khususnya REGUP (Item yang Diproses oleh Program Pembayaran) dan REGUH (Header). Pengumpulan data Temukan saat faktur muncul di tabel REGUP untuk proses pembayaran yang tercatat di REGUH. Jenis peristiwa explicit | |||
Panduan ekstraksi
Langkah
- Prasyarat dan akses: Pastikan Anda memiliki pengguna dengan akses baca ke skema database SAP S/4HANA (biasanya SAPABAP1 atau yang serupa) tempat CDS view berada. Anda memerlukan alat klien SQL yang dapat terhubung ke database SAP HANA, seperti SAP HANA Studio, DBeaver, atau alat kueri database serupa.
- Identifikasi CDS view utama: CDS view utama untuk ekstraksi ini adalah I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails, dan I_PaymentProposalItem. Kenali kolom-kolom penting di dalamnya.
- Tentukan cakupan kueri: Buka klien SQL dan hubungkan ke database SAP HANA. Sebelum menjalankan kueri lengkap, tentukan cakupan ekstraksi. Atur pengenal sistem sumber, rentang tanggal faktur (CreationDateTime), dan Company Code yang relevan.
- Siapkan kueri utama: Salin seluruh kueri SQL dari bagian kueri ke klien SQL Anda. Kueri ini menggunakan Common Table Expressions (CTE) untuk memilih kumpulan faktur dasar, lalu menyusun log peristiwa dengan menggabungkan data dari 15 aktivitas berbeda.
- Atur parameter kueri: Temukan variabel placeholder dalam kueri SQL yang disalin. Ganti '[YYYY-MM-DD]' dengan tanggal awal dan akhir periode analisis. Ganti '[Your Company Code 1]', '[Your Company Code 2]' dengan daftar SAP Company Code yang ingin Anda analisis.
- Jalankan kueri ekstraksi: Jalankan seluruh kueri SQL. Bergantung pada volume data dan rentang tanggal yang dipilih, proses ini dapat berlangsung beberapa menit hingga beberapa jam.
- Tinjau hasil awal: Setelah kueri selesai, periksa beberapa ratus baris pertama hasilnya. Pastikan data konsisten, semua kolom terisi sesuai harapan, dan terdapat beberapa nilai ActivityName yang berbeda.
- Ekspor log peristiwa: Ekspor seluruh hasil dari klien SQL ke file CSV. Pastikan file menggunakan encoding UTF-8 agar karakter tidak bermasalah. Beri nama file yang jelas, misalnya sap_s4hana_ap_event_log.csv.
- Siapkan data untuk diunggah: Sebelum mengunggahnya ke alat process mining, pastikan nama header kolom dalam file CSV sama persis dengan nama atribut yang diwajibkan: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, dan seterusnya.
- Unggah ke alat process mining: Unggah file CSV yang dihasilkan ke platform process mining Anda. Petakan kolom ke kolom ID kasus, aktivitas, dan stempel waktu yang sesuai.
Konfigurasi
- CDS view utama: Ekstraksi ini mengandalkan gabungan CDS View standar S/4HANA. View utamanya adalah:
- I_JournalEntry & I_JournalEntryItem: Untuk header dokumen keuangan, item, detail posting, dan informasi penyelesaian.
- I_SupplierInvoiceAPI01: Untuk detail khusus faktur MM (Logistics), termasuk referensi PO dan blokir pembayaran.
- I_ChangeDocument: Untuk melacak stempel waktu perubahan secara tepat, seperti saat blokir pembayaran dipasang atau dihapus.
- I_WorkflowStatusDetails: Untuk mengekstrak peristiwa terkait workflow persetujuan faktur.
- I_PaymentProposalItem: Untuk mengetahui kapan faktur disertakan dalam usulan proses pembayaran.
- I_Supplier: Untuk melengkapi data dengan informasi master pemasok, seperti VendorName.
- Filter rentang tanggal: Terapkan filter rentang tanggal untuk membatasi volume data. Kueri yang disediakan memfilter CreationDateTime di CTE Invoices_Base. Untuk analisis awal, disarankan menggunakan rentang 3-6 bulan agar kinerja tetap terkendali.
- Filter wajib: Selalu filter berdasarkan CompanyCode. Menganalisis semua kode perusahaan sekaligus dapat berlangsung sangat lama dan mungkin tidak relevan bagi bisnis. Filter juga berdasarkan JournalEntryType untuk memilih dokumen terkait pemasok saja, misalnya 'KR' dan 'RE'.
- Prasyarat: Pengguna database yang menjalankan kueri harus memiliki otorisasi SELECT untuk semua CDS view yang digunakan serta skema HANA yang mendasarinya. Akses tingkat aplikasi melalui SAP GUI saja tidak cukup.
- Pertimbangan kinerja: Kueri langsung pada I_ChangeDocument dapat menghabiskan banyak sumber daya. Kueri yang disediakan berupaya mengurangi beban ini dengan memfilter faktur terlebih dahulu. Untuk kumpulan data yang sangat besar, jalankan ekstraksi di luar jam sibuk atau dalam beberapa batch dengan rentang tanggal lebih kecil.
Contoh kueri sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X'; Langkah
- Pastikan tersedia akses baca langsung ke skema SAP HANA yang berisi tabel SAP S/4HANA terkait. Dapatkan string koneksi, kredensial, nama skema, dan otorisasi untuk membaca BKPF, ACDOCA, serta tabel tambahan yang dikonfigurasi untuk dokumen parkir, workflow, pembelian, penerimaan barang, usulan pembayaran, penyelesaian, dan data pembalikan.
- Pastikan model data teknis di sistem target sebelum menjalankan kueri. Validasi nama fisik, kolom kunci, kolom stempel waktu, hubungan pembalikan, hubungan pembayaran, dan penyimpanan workflow yang digunakan sistem. Ganti setiap placeholder dalam tanda kurung siku di kueri dengan objek atau kolom yang sesuai dari sistem. Jangan berasumsi bahwa data workflow atau dokumen parkir disimpan dalam satu tabel universal.
- Atur parameter ekstraksi. Isi [Start date], [End date], [Company code filter], [Document type filter], dan [Schema name]. Mulai dengan rentang tiga hingga enam bulan, lalu perluas setelah kinerja dan kelengkapan data tervalidasi.
- Jalankan kueri SQL di klien SQL SAP HANA yang disetujui, seperti SAP HANA Database Explorer atau alat eksekusi SQL resmi lainnya. Kueri menghasilkan satu baris untuk setiap aktivitas yang diekstrak secara eksplisit dan tidak mengandalkan ProcessMind untuk menyimpulkan peristiwa.
- Validasi hasil kueri. Pastikan Invoice menjadi ID kasus, ActivityName memuat semua 15 nama aktivitas yang diwajibkan, EventTime terisi dan urutannya masuk akal, SourceSystem menunjukkan SAP S/4HANA, serta LastDataUpdate berisi stempel waktu pembaruan ekstraksi. Periksa peristiwa duplikat, hubungan pembalikan, dan penggabungan dokumen sebelum memuat data.
- Terapkan pemetaan khusus sistem jika diperlukan. Misalnya, petakan sumber dokumen parkir yang dikonfigurasi ke Invoice Parked, sumber workflow ke Invoice Routed For Approval, Invoice Approved, dan Invoice Rejected, serta sumber pembayaran ke Payment Proposal Created dan Payment Executed. Simpan pengenal sumber di kolom tambahan jika diperlukan untuk keperluan audit.
- Ekspor hasil sebagai file ber-delimiter atau kumpulan hasil database dengan satu peristiwa di setiap baris. Gunakan encoding UTF-8, pertahankan stempel waktu dalam zona waktu yang konsisten, dan gunakan nama kolom persis seperti Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber, dan InvoiceDueDate. Jangan gabungkan beberapa aktivitas menjadi satu baris faktur.
- Unggah log peristiwa ke ProcessMind dan tetapkan Invoice sebagai ID kasus, ActivityName sebagai kolom aktivitas, dan EventTime sebagai kolom waktu peristiwa. Pastikan atribut opsional dipetakan ke kolom yang sesuai. ProcessMind membaca log peristiwa apa adanya, jadi pastikan setiap aktivitas yang ingin divisualisasikan sudah tersedia sebagai baris sebelum diunggah.
Konfigurasi
- Rentang tanggal: Mulai dengan tiga hingga enam bulan. Gunakan tanggal posting, tanggal pembuatan dokumen, atau tanggal peristiwa sumber yang relevan sesuai aktivitas yang diekstrak. Perluas rentang hanya setelah waktu eksekusi kueri dan retensi sumber tervalidasi.
- Filter perusahaan: Atur [Company code filter] untuk membatasi ekstraksi ke kode perusahaan yang diperlukan. Jika tidak perlu membatasi, gunakan pilihan semua perusahaan yang terkontrol, bukan kueri produksi tanpa batas.
- Filter dokumen: Atur [Document type filter] setelah memastikan jenis dokumen yang digunakan untuk faktur pemasok, nota kredit, dokumen parkir, dokumen pembayaran, dan pembalikan di sistem target.
- Pemetaan skema dan objek: Ganti [Schema name] serta setiap objek atau kolom sumber dalam tanda kurung siku dengan nilai yang sudah diverifikasi di sistem SAP S/4HANA target. Kueri HANA langsung harus disesuaikan dengan aplikasi yang diaktifkan, ekstensi, desain workflow, dan model data sistem.
- Penanganan stempel waktu: Samakan semua stempel waktu sumber ke satu zona waktu. Jika hanya tanggal yang tersedia, gunakan komponen waktu default yang terdokumentasi dan catat batasan tersebut dalam kamus data.
- Makna peristiwa: Ekstrak setiap aktivitas sebagai baris terpisah. Jangan gabungkan beberapa aktivitas ke dalam satu catatan faktur dan jangan mengharapkan ProcessMind menyimpulkan peristiwa pencocokan, persetujuan, jatuh tempo, atau penyelesaian.
- Peristiwa tanggal jatuh tempo: Buat Invoice Due Date Passed hanya untuk faktur yang tanggal jatuh temponya lebih awal daripada stempel waktu evaluasi yang ditetapkan dan belum memiliki peristiwa penyelesaian pada waktu tersebut. Kueri menggunakan [Evaluation timestamp] untuk perhitungan ini.
- Kinerja: Batasi periode dan cakupan perusahaan pada tahap awal, filter kolom yang diindeks atau relevan dengan partisi, hindari mengambil kolom lebar yang tidak diperlukan, dan jalankan kueri pada waktu pelaporan yang disetujui. Pertimbangkan untuk menyiapkan subset data sumber jika kueri produksi melampaui waktu eksekusi yang disepakati.
- Strategi pembaruan: Isi LastDataUpdate dengan stempel waktu saat ekstraksi dijalankan. Untuk pemuatan inkremental, simpan watermark berdasarkan stempel waktu perubahan sumber yang relevan dan sertakan periode penelusuran ulang untuk menangkap pembaruan terlambat dan pembalikan.
- Prasyarat: Otorisasi database yang diperlukan, akses produksi yang disetujui, pemahaman tentang konfigurasi Universal Journal sistem, akses ke sumber dokumen parkir, pembelian, penerimaan barang, workflow, pembayaran, penyelesaian, dan pembalikan yang dikonfigurasi, serta persetujuan lisensi atau tata kelola SAP yang berlaku.
Contoh kueri sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Langkah
- Spesifikasi dan desain: Sebelum menulis kode, bekerja sama dengan analis bisnis untuk memastikan kondisi pemicu dan kolom data yang tepat bagi masing-masing dari 15 aktivitas yang diwajibkan. Identifikasi tabel SAP terkait, jenis dokumen (misalnya 'KR', 'RE'), dan kode perusahaan yang akan disertakan.
- Buat program ABAP: Buka ABAP Editor menggunakan kode transaksi SE38. Buat program baru yang dapat dijalankan, misalnya Z_PM_AP_INVOICE_EXTRACT. Beri judul yang jelas dan atur aplikasi ke 'Financial Accounting'.
- Tentukan layar seleksi: Di dalam program, buat layar seleksi (menggunakan kata kunci PARAMETERS dan SELECT-OPTIONS) agar pengguna dapat menentukan rentang tanggal ekstraksi (tanggal pembuatan faktur), Company Code tujuan (BUKRS), dan jenis dokumen faktur (BLART) yang relevan. Sertakan juga parameter untuk lokasi file keluaran di server aplikasi.
- Deklarasi data: Tentukan struktur tabel internal yang sesuai dengan format akhir log peristiwa (misalnya TY_EVENT_LOG), termasuk semua atribut wajib dan yang disarankan. Deklarasikan tabel internal untuk menampung data dari berbagai tabel sumber SAP, seperti BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS, dan REGUH.
- Pemilihan data utama: Mulai logika ekstraksi dengan memilih kumpulan faktur utama dari RBKP (Logistics Invoices) dan BKPF (Financial Invoices) berdasarkan kriteria di layar seleksi. Simpan kunci faktur utama dalam tabel internal untuk digunakan dalam pencarian data berikutnya.
- Ekstrak aktivitas secara berurutan: Untuk setiap faktur dalam kumpulan utama, lakukan serangkaian pemilihan data untuk menemukan stempel waktu dan detail setiap aktivitas bisnis. Misalnya, kueri CDHDR dan CDPOS untuk perubahan blokir pembayaran, REGUH dan REGUP untuk data proses pembayaran, serta BKPF untuk detail dokumen pembalikan. Tambahkan satu catatan ke tabel akhir log peristiwa untuk setiap aktivitas yang ditemukan.
- Logika untuk peristiwa hasil perhitungan: Terapkan logika ABAP untuk aktivitas yang tidak tersimpan langsung dalam kolom tabel. Untuk peristiwa 'Invoice Due Date Passed', gunakan tanggal jatuh tempo faktur (BSEG-ZFBDT + ketentuan pembayaran) dan tanggal penyelesaian (BSEG-AUGDT). Jika tanggal penyelesaian lebih lambat daripada tanggal jatuh tempo, buat catatan peristiwa baru dengan stempel waktu pada tanggal jatuh tempo.
- Transformasi dan pengayaan data: Saat mengumpulkan data untuk setiap aktivitas, isi semua atribut yang diwajibkan. Cari nama pemasok dari LFA1, gabungkan tanggal dan waktu menjadi satu teks stempel waktu (CONCATENATE...INTO...), lalu isi nilai SourceSystem.
- Buat file keluaran: Setelah semua faktur dan aktivitas terkait diproses dan dikumpulkan dalam tabel internal akhir, gunakan pernyataan OPEN DATASET, LOOP AT ... TRANSFER, dan CLOSE DATASET untuk menulis data ke file di lokasi server aplikasi yang ditentukan pada layar seleksi.
- Unduh dan siapkan untuk diunggah: Gunakan kode transaksi CG3Y untuk mengunduh file yang dihasilkan dari server aplikasi ke komputer lokal. Simpan file dalam format CSV dengan encoding UTF-8. Pastikan header kolom sesuai dengan atribut yang diwajibkan (Invoice, ActivityName, EventTime, dan seterusnya) sebelum mengunggahnya ke alat process mining.
Konfigurasi
- Rentang tanggal: Tentukan opsi seleksi P_CPUDT untuk tanggal pembuatan faktur (BKPF-CPUDT atau RBKP-CPUDT). Untuk analisis awal, disarankan menggunakan data selama 6-12 bulan.
- Company Code (P_BUKRS): Parameter SELECT-OPTIONS wajib untuk memfilter kode perusahaan tertentu. Pemrosesan semua kode perusahaan sekaligus tidak disarankan kecuali benar-benar diperlukan.
- Jenis dokumen faktur (P_BLART): Parameter SELECT-OPTIONS untuk memfilter jenis dokumen faktur yang relevan. Jenis yang umum mencakup 'KR' (Vendor Invoice), 'KG' (Vendor Credit Memo), dan 'RE' (Logistics Invoice Verification).
- Mode eksekusi: Untuk volume data besar, jalankan program sebagai background job (SM36/SM37) agar proses dialog di latar depan tidak mengalami timeout. Jadwalkan di luar jam sibuk.
- Lokasi file keluaran: Gunakan PARAMETER untuk menentukan lokasi dan nama file di server aplikasi SAP, misalnya di direktori /tmp/. File akan ditulis di sini sebelum diunduh.
- Prasyarat: Pengguna yang menjalankan laporan memerlukan otorisasi untuk membaca tabel FI, CO, dan MM (BKPF, BSEG, RBKP, RSEG, LFA1), tabel perubahan dokumen (CDHDR, CDPOS), dan tabel workflow. Selain itu, objek otorisasi S_DATASET diperlukan untuk menulis file ke server aplikasi.
Contoh kueri abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM. Siap memulai?
Gunakan templat ini untuk memulai inisiatif process mining dan meningkatkan efisiensi operasional utang usaha. Mulai analisis Anda hari ini untuk menyederhanakan proses dan meningkatkan kinerjanya.
Hindari denda keterlambatan, optimalkan pemrosesan faktur utang usaha hari ini
Kurangi biaya pemrosesan hingga 60% dan cegah pembayaran ganda dengan mudah.
Tidak perlu kartu kredit. Anda bisa mulai dalam hitungan menit.