Templat data pemrosesan faktur Purchase to Pay
Templat data pemrosesan faktur Purchase to Pay
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi untuk SAP S/4HANA
Atribut pemrosesan faktur Purchase to Pay
| Nama | Deskripsi | ||
|---|---|---|---|
| Nomor faktur InvoiceNumber | Pengenal unik untuk dokumen faktur vendor yang berfungsi sebagai pengenal kasus utama dalam proses. | ||
| Deskripsi Nomor Faktur adalah pengenal unik yang diberikan kepada setiap faktur vendor di SAP S/4HANA. Nomor ini menghubungkan semua aktivitas terkait, seperti pembuatan, pemarkiran, persetujuan, dan pembayaran, dalam satu rangkaian proses. Dalam process mining, atribut ini menjadi dasar untuk melacak perjalanan setiap faktur dari awal hingga akhir. Atribut ini memungkinkan seluruh alur proses direkonstruksi, dari penerimaan hingga pembayaran, sehingga waktu siklus, hambatan, dan variasi proses dapat dianalisis untuk setiap faktur. Mengapa ini penting Atribut ini menjadi kunci untuk menghubungkan semua peristiwa terkait dan melacak seluruh siklus faktur di dalam sistem. Sumber data Ini adalah Nomor Dokumen Akuntansi yang terdapat pada tabel BKPF, kolom BELNR. Contoh 190000000119000000451900000132 | |||
| Nama aktivitas ActivityName | Nama aktivitas bisnis atau peristiwa yang terjadi pada waktu tertentu dalam proses faktur. | ||
| Deskripsi Nama Aktivitas menjelaskan langkah atau perubahan status tertentu dalam siklus pemrosesan faktur. Contohnya, 'Dokumen Faktur Dibuat', 'Faktur Dikirim untuk Persetujuan', 'Blokir Pembayaran Ditetapkan', dan 'Pembayaran Dilaksanakan'. Atribut ini penting untuk menyusun peta proses yang menggambarkan alur aktivitas secara visual. Analisis urutan, frekuensi, dan durasi antaraktivitas membantu menemukan hambatan, proses ulang, dan variasi proses yang tidak patuh. Atribut ini menjadi dasar analisis process mining. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam proses, sehingga peta proses dapat ditampilkan dan alur serta variasinya dapat dianalisis. Sumber data Diperoleh dari gabungan kode transaksi SAP (SY-TCODE), status objek dokumen perubahan (CDHDR/CDPOS), dan nilai kolom tertentu yang menunjukkan perubahan status. Contoh Faktur diparkirFaktur disetujuiPembayaran dilaksanakan | |||
| Waktu peristiwa EventTime | Tanggal dan waktu persis saat aktivitas terjadi. | ||
| Deskripsi Waktu Peristiwa adalah stempel waktu yang mencatat kapan aktivitas tertentu terjadi. Data ini penting untuk menghitung durasi, waktu siklus, dan waktu tunggu antar langkah dalam proses. Dalam analisis process mining, stempel waktu yang akurat digunakan untuk mengukur KPI kinerja, seperti 'Rata-rata Waktu Siklus Faktur' dan 'Waktu Siklus Persetujuan Faktur'. Dengan menganalisis jeda antaraktivitas, organisasi dapat menemukan hambatan yang menunda faktur dan peluang untuk mempercepat proses. Mengapa ini penting Stempel waktu ini menjadi dasar semua analisis berbasis waktu, termasuk pemantauan kinerja, identifikasi hambatan, dan pelacakan SLA. Sumber data Biasanya diambil dari tabel dokumen perubahan CDHDR (Header) dan CDPOS (Item), menggunakan kolom UDATE dan UTIME. Untuk beberapa peristiwa, datanya dapat berasal dari tanggal pembuatan atau entri pada tabel seperti BKPF (CPUDT, CPUTM). Contoh 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Alasan blokir pembayaran PaymentBlockReason | Kode yang menunjukkan alasan faktur diblokir agar tidak dibayar. | ||
| Deskripsi Saat faktur diblokir untuk pembayaran, atribut ini menunjukkan alasan spesifiknya, seperti 'Selisih Kuantitas' atau 'Ketidaksesuaian Harga'. Alasan ini dikonfigurasi di SAP untuk menyeragamkan penanganan pengecualian. Atribut ini penting untuk dasbor 'Frekuensi dan Durasi Blokir Pembayaran'. Analisis frekuensi tiap alasan blokir membantu menemukan akar penyebab keterlambatan pembayaran, seperti masalah dengan vendor, material, atau proses internal tertentu. Dengan begitu, tindakan perbaikan dapat diarahkan dengan tepat. Mengapa ini penting Atribut ini menunjukkan akar penyebab spesifik blokir pembayaran, sehingga analisis dapat diarahkan untuk mengurangi keterlambatan dan meningkatkan ketepatan sejak awal. Sumber data Terdapat pada item baris vendor di tabel BSEG, kolom ZLSPR (Kunci Blokir Pembayaran). Contoh RIA | |||
| Jenis dokumen DocumentType | Kode untuk mengelompokkan jenis dokumen akuntansi, seperti faktur vendor atau nota kredit. | ||
| Deskripsi Jenis Dokumen digunakan di SAP untuk membedakan berbagai transaksi bisnis. Misalnya, 'KR' biasanya menunjukkan faktur vendor standar, sedangkan 'KG' dapat menunjukkan nota kredit vendor. Analisis berdasarkan jenis dokumen membantu memisahkan proses agar penanganan tiap jenis transaksi dapat dipahami. Contohnya, proses untuk nota kredit mungkin sangat berbeda dari proses untuk faktur standar. Pemisahan ini menghasilkan insight proses yang lebih akurat dan relevan. Mengapa ini penting Atribut ini membantu membedakan berbagai transaksi keuangan, seperti faktur standar dan nota kredit, yang sering mengikuti alur proses berbeda. Sumber data Terdapat pada tabel header dokumen BKPF, kolom BLART. Contoh KRREKG | |||
| Jumlah faktur AmountInCompanyCodeCurrency | Jumlah bruto total faktur dalam mata uang lokal kode perusahaan. | ||
| Deskripsi Atribut ini menunjukkan nilai total faktur. Nilai ini menjadi ukuran utama untuk memahami dampak keuangan dan skala operasional pemrosesan faktur. Analisis jumlah faktur membantu memprioritaskan faktur bernilai tinggi agar diproses lebih cepat, menemukan tren pengeluaran, dan mengaitkan masalah proses dengan nilai keuangan. Misalnya, Anda dapat memeriksa apakah faktur bernilai tinggi lebih sering diblokir atau membutuhkan waktu persetujuan lebih lama. Mengapa ini penting Atribut ini memberi konteks keuangan pada proses dan memungkinkan analisis berdasarkan nilai uang, misalnya untuk mengetahui apakah faktur bernilai tinggi diproses secara berbeda. Sumber data Nilai ini biasanya dihitung dari jumlah item baris terkait pada tabel BSEG, kolom WRBTR (Jumlah dalam mata uang lokal). Contoh 1500.75125000.00850.20 | |||
| Kode perusahaan CompanyCode | Unit organisasi yang mewakili perusahaan independen secara hukum dan menyusun laporan keuangan. | ||
| Deskripsi Kode Perusahaan adalah unit organisasi utama dalam SAP Finance. Setiap faktur dikaitkan dengan kode perusahaan tertentu yang menentukan badan hukum yang bertanggung jawab atas transaksi tersebut. Dalam process mining, memfilter atau membandingkan data berdasarkan Kode Perusahaan penting untuk menganalisis kinerja proses di berbagai unit bisnis, badan hukum, atau negara. Analisis ini membantu menemukan perbedaan regional dalam efisiensi, kepatuhan, dan tingkat otomatisasi, sehingga upaya perbaikan dapat diarahkan dengan tepat. Mengapa ini penting Atribut ini memungkinkan perbandingan kinerja pemrosesan faktur antar badan hukum atau lokasi geografis dalam organisasi. Sumber data Kolom standar ini terdapat pada tabel header dokumen BKPF, kolom BUKRS. Contoh 1000US01DE01 | |||
| Nama pengguna UserName | ID pengguna SAP milik orang atau sistem yang melakukan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan pengguna yang menjalankan transaksi tertentu atau membuat dokumen. Nilainya dapat berupa ID pengguna individu atau ID sistem untuk pekerjaan batch otomatis. Analisis berdasarkan pengguna membantu memahami pembagian beban kerja, menemukan kebutuhan pelatihan, dan mendeteksi perilaku pengguna yang tidak biasa. Misalnya, analisis ini dapat menunjukkan pengguna yang sering menangani pengecualian atau faktur yang diproses otomatis, seperti oleh pengguna 'BATCHUSER'. Informasi ini penting untuk menghitung KPI 'Tingkat Otomatisasi Faktur'. Mengapa ini penting Atribut ini mengaitkan aktivitas proses dengan pengguna atau akun sistem tertentu, sehingga beban kerja dan kinerja dapat dianalisis serta otomatisasi dapat dideteksi. Sumber data Diambil dari kolom seperti BKPF-USNAM (Dimasukkan oleh) atau CDHDR-USERNAME (Diubah oleh). Contoh SMITHJMUELLERTWF-BATCH | |||
| Nomor vendor VendorNumber | Pengenal unik vendor yang mengirimkan faktur. | ||
| Deskripsi Nomor Vendor mengidentifikasi pemasok atau kreditur yang terkait dengan faktur. Nomor ini menghubungkan transaksi faktur dengan data induk vendor. Atribut ini penting untuk analisis berdasarkan vendor, seperti menilai 'Kinerja Pembayaran Vendor' atau menemukan vendor yang sering mengirimkan faktur bermasalah hingga memicu pengecualian atau blokir pembayaran. Informasi ini membantu mengelola hubungan dengan vendor dan menilai keandalan pemasok. Mengapa ini penting Atribut ini memungkinkan analisis kinerja proses berdasarkan vendor, sehingga pola dapat ditemukan, hubungan dapat dikelola, dan masalah terkait pemasok dapat dinilai. Sumber data Biasanya terdapat pada tabel segmen dokumen akuntansi BSEG, kolom LIFNR. Contoh 100345700012V9832 | |||
| Pesanan pembelian PurchasingDocument | Nomor pesanan pembelian yang terkait dengan faktur. | ||
| Deskripsi Nomor Dokumen Pembelian menghubungkan faktur vendor dengan pesanan pembelian (PO) asal. Hubungan ini menjadi dasar proses pencocokan tiga arah, yang memeriksa kesesuaian faktur dengan PO dan penerimaan barang. Analisis berdasarkan atribut ini membantu memahami masalah pada faktur yang terkait atau tidak terkait PO. Atribut ini penting untuk menyelidiki selisih pencocokan dan memahami efisiensi proses pengadaan. Mengapa ini penting Atribut ini menghubungkan faktur dengan proses pengadaan, yang penting untuk menganalisis selisih pencocokan dan kepatuhan terhadap PO. Sumber data Informasi ini biasanya terdapat pada tabel segmen dokumen BSEG, kolom EBELN (Nomor Dokumen Pembelian). Contoh 450000123445000056784500009012 | |||
| Tanggal jatuh tempo pembayaran PaymentDueDate | Tanggal batas pembayaran faktur agar tidak terlambat. | ||
| Deskripsi Tanggal Jatuh Tempo Pembayaran adalah tanggal pembayaran kepada vendor harus dilakukan, berdasarkan tanggal faktur dan syarat pembayaran yang disepakati. Tanggal ini menjadi tenggat penting dalam proses. Atribut ini penting untuk KPI 'Tingkat Pembayaran Tepat Waktu' dan dasbor 'Kinerja Pembayaran Vendor'. Dengan membandingkan tanggal pembayaran aktual dengan tanggal jatuh tempo, perusahaan dapat mengukur kemampuannya memenuhi kewajiban pembayaran. Hal ini berdampak pada hubungan dengan vendor dan reputasi keuangan. Mengapa ini penting Tanggal ini menjadi patokan utama untuk mengukur ketepatan waktu pembayaran, yang penting untuk menjaga hubungan baik dengan vendor dan menghindari biaya keterlambatan. Sumber data Tanggal ini sering tersedia langsung pada item baris vendor di tabel BSEG, kolom ZFBDT (Tanggal dasar untuk menghitung tanggal jatuh tempo). Tanggal jatuh tempo bersih dihitung dari tanggal dasar ini dan syarat pembayaran. Contoh 2023-05-302023-06-152023-07-01 | |||
| Alasan pembatalan ReversalReason | Kode yang menunjukkan alasan dokumen faktur dibatalkan. | ||
| Deskripsi Jika faktur diposting secara keliru, faktur tersebut biasanya dibatalkan. Kode Alasan Pembatalan menjelaskan penyebabnya, misalnya 'Tanggal posting salah' atau 'Kesalahan entri data'. Analisis alasan pembatalan membantu menemukan pola kesalahan dalam proses posting faktur. Insight ini dapat digunakan untuk meningkatkan pelatihan, memperkuat kontrol sistem, atau menangani masalah berulang yang menambah pekerjaan ulang dan beban administrasi. Mengapa ini penting Atribut ini menjelaskan alasan faktur dibatalkan dan memberi gambaran langsung tentang sumber kesalahan serta pekerjaan ulang dalam proses posting. Sumber data Terdapat pada header dokumen asli di tabel BKPF, kolom STGRD (Alasan pembatalan). Contoh 010205 | |||
| Apakah ada pekerjaan ulang IsRework | Penanda yang menunjukkan apakah faktur mengalami aktivitas pekerjaan ulang, seperti persetujuan yang ditolak atau blokir pembayaran yang dihapus. | ||
| Deskripsi Atribut ini menandai faktur yang mengalami satu atau beberapa rangkaian pekerjaan ulang. Pekerjaan ulang dikenali dari urutan aktivitas tertentu, misalnya 'Faktur Disetujui' setelah 'Faktur Ditolak', atau 'Blokir Pembayaran Dihapus' setelah 'Blokir Pembayaran Ditetapkan'. Atribut ini memudahkan penghitungan KPI 'Tingkat Pekerjaan Ulang Faktur'. Analis dapat dengan mudah memisahkan dan memeriksa kasus yang mengalami pekerjaan ulang untuk memahami akar penyebab inefisiensi dan pekerjaan manual berulang. Mengapa ini penting Atribut ini menemukan alur proses yang tidak efisien dan mengharuskan pekerjaan diulang, sehingga pemborosan dapat diukur dan akar penyebab pengecualian proses dapat diketahui. Sumber data Dihitung berdasarkan urutan aktivitas dalam log peristiwa. Misalnya, jika 'Faktur Ditolak' muncul dalam jejak suatu faktur, penanda ini akan bernilai true. Contoh truefalse | |||
| Apakah dibayar tepat waktu IsPaidOnTime | Penanda bernilai true jika faktur dibayar pada atau sebelum tanggal jatuh tempo. | ||
| Deskripsi Atribut boolean ini dihasilkan dengan membandingkan tanggal pembayaran aktual, yaitu stempel waktu aktivitas 'Pembayaran Dilaksanakan', dengan 'Tanggal Jatuh Tempo Pembayaran'. Hasilnya menunjukkan status pembayaran setiap faktur secara jelas dalam dua kemungkinan. Perhitungan ini menjadi dasar KPI 'Tingkat Pembayaran Tepat Waktu'. Atribut ini memudahkan penyaringan dan analisis untuk memahami ciri pembayaran terlambat, misalnya vendor, kode perusahaan, atau jumlah faktur yang sering terkait dengan keterlambatan. Mengapa ini penting Atribut ini mengukur kepatuhan terhadap syarat pembayaran secara langsung. Ini merupakan KPI penting untuk mengelola hubungan dengan vendor dan operasional keuangan. Sumber data Dihitung dengan membandingkan EventTime aktivitas 'Pembayaran Dilaksanakan' dengan atribut PaymentDueDate. (Tanggal Pembayaran <= PaymentDueDate). Contoh truefalse | |||
| Apakah otomatis IsAutomated | Penanda yang menunjukkan apakah aktivitas dilakukan oleh pengguna sistem otomatis. | ||
| Deskripsi Atribut boolean ini bernilai true jika pengguna yang terkait dengan aktivitas merupakan akun sistem atau batch yang dikenal, seperti 'WF-BATCH' atau 'SAP_SYSTEM'. Atribut ini membantu membedakan langkah proses manual dan otomatis. Atribut ini penting untuk menghitung KPI 'Tingkat Otomatisasi Faktur'. Dengan menganalisis bagian proses yang sudah otomatis, organisasi dapat mengukur hasil inisiatif otomatisasi dan menemukan peluang lain untuk mengurangi pekerjaan manual serta meningkatkan efisiensi. Mengapa ini penting Atribut ini membedakan aktivitas manual dan aktivitas yang dijalankan sistem. Pembedaan ini menjadi dasar untuk mengukur tingkat otomatisasi dan menemukan peluang otomatisasi lebih lanjut. Sumber data Diperoleh dari atribut UserName. Pemetaan atau aturan dibuat untuk mengelompokkan ID pengguna tertentu sebagai 'otomatis'. Contoh truefalse | |||
| ID sistem sumber SourceSystemId | Pengenal sistem SAP S/4HANA sumber tempat data diekstrak. | ||
| Deskripsi Atribut ini menunjukkan sistem asal, misalnya 'S4H_PROD' atau 'ERP_EU'. Atribut ini sangat penting jika lingkungan Anda menggunakan beberapa sistem ERP atau gabungan sistem lama dan modern. Dalam analisis, atribut ini memungkinkan perbandingan kinerja proses antar sistem atau wilayah. Atribut ini juga memastikan asal-usul data tercatat dan membantu tata kelola data serta pemecahan masalah saat data dari berbagai sumber digabungkan dalam platform process mining terpusat. Mengapa ini penting Atribut ini memberi konteks tentang asal data, yang penting untuk tata kelola data dan perbandingan proses antar sistem atau lokasi perusahaan. Sumber data Nilai ini biasanya diperoleh dari ID sistem SAP (sy-sysid) saat ekstraksi data atau ditetapkan sebagai nilai statis dalam alur ETL. Contoh S4PS4H_PROD_100ECC_EU | |||
| Jumlah siklus persetujuan ApprovalCycleCount | Jumlah berapa kali faktur diajukan untuk persetujuan. | ||
| Deskripsi Metrik ini menghitung berapa kali aktivitas 'Faktur Dikirim untuk Persetujuan' terjadi untuk satu faktur. Jumlah lebih dari satu menunjukkan bahwa faktur pernah ditolak atau dikembalikan, sehingga perlu melalui siklus persetujuan baru. Atribut ini mendukung KPI 'Tingkat Persetujuan pada Pengajuan Pertama'. Dengan menganalisis faktur yang memiliki banyak siklus persetujuan, organisasi dapat menemukan penyebab kegagalan persetujuan, seperti informasi yang kurang atau kode yang salah, lalu mengambil langkah untuk memperbaiki proses. Mengapa ini penting Atribut ini mengukur pekerjaan ulang dalam subproses persetujuan, sehingga tingkat ketepatan sejak awal dapat dinilai dan alasan penolakan persetujuan dapat ditemukan. Sumber data Dihitung dengan menghitung kemunculan aktivitas 'Faktur Dikirim untuk Persetujuan' untuk setiap InvoiceNumber unik. Contoh 123 | |||
| Nomor dokumen pelunasan. ClearingDocumentNumber | Nomor dokumen yang melunasi faktur, biasanya berupa dokumen pembayaran. | ||
| Deskripsi Nomor Dokumen Pelunasan menghubungkan item faktur terbuka dengan transaksi yang melunasinya, yang hampir selalu berupa dokumen pembayaran. Nomor ini memastikan bahwa faktur telah dibayar. Atribut ini menjadi penghubung pasti antara faktur dan pembayarannya. Atribut ini digunakan untuk mengenali aktivitas 'Pembayaran Dilaksanakan' beserta stempel waktunya, yang penting untuk menghitung waktu siklus dari awal hingga akhir dan tingkat pembayaran tepat waktu. Mengapa ini penting Atribut ini memastikan bahwa faktur telah dibayar dan menghubungkannya dengan transaksi pembayaran tertentu. Informasi ini penting untuk analisis waktu siklus dan kinerja pembayaran. Sumber data Terdapat pada tabel segmen dokumen BSEG, kolom AUGBL (Nomor Dokumen Pelunasan). Contoh 150000000115000000231500000088 | |||
| Stempel waktu ekstraksi ExtractionTimestamp | Tanggal dan waktu saat data diekstrak dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat stempel waktu ekstraksi data. Nilai ini menunjukkan seberapa baru data yang dianalisis di alat process mining. Dalam analisis, atribut ini membantu mengetahui kebaruan insight yang dihasilkan. Atribut ini penting untuk dasbor pemantauan operasional agar keputusan didasarkan pada informasi terbaru dan siklus pembaruan data dapat dikelola dengan baik. Mengapa ini penting Menunjukkan kebaruan data, sehingga analisis dan pelaporan menggunakan informasi terbaru yang tersedia. Sumber data Ini bukan kolom SAP. Alat ekstraksi data atau proses ETL membuat dan menambahkannya saat data diambil. Contoh 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Syarat pembayaran PaymentTerms | Kode yang menentukan ketentuan pembayaran yang disepakati dengan vendor, seperti tanggal jatuh tempo dan periode diskon. | ||
| Deskripsi Syarat Pembayaran menetapkan aturan pembayaran faktur, termasuk diskon yang tersedia untuk pembayaran lebih awal. Misalnya, 'Z030' dapat berarti 'Harus dibayar dalam 30 hari tanpa potongan'. Atribut ini penting untuk perencanaan keuangan dan optimalisasi modal kerja. Dalam process mining, atribut ini digunakan untuk menghitung 'Tanggal Jatuh Tempo Pembayaran' dan menentukan kelayakan diskon pembayaran awal. Atribut ini juga mendukung KPI 'Tingkat Pemanfaatan Diskon Pembayaran Awal'. Mengapa ini penting Atribut ini menetapkan aturan tanggal jatuh tempo dan diskon pembayaran, yang berdampak langsung pada KPI ketepatan waktu pembayaran dan pengelolaan modal kerja. Sumber data Terdapat pada item baris vendor di tabel BSEG, kolom ZTERM (Kunci Syarat Pembayaran). Contoh 0001Z030NT60 | |||
| Tanggal faktur InvoiceDate | Tanggal vendor menerbitkan dokumen faktur. | ||
| Deskripsi Tanggal Faktur, yang juga dikenal sebagai tanggal dokumen, adalah tanggal yang dicantumkan vendor pada faktur. Tanggal ini menjadi titik awal untuk menghitung tanggal jatuh tempo berdasarkan syarat pembayaran yang disepakati. Dalam analisis, tanggal ini menjadi dasar perhitungan keuangan, seperti menentukan umur faktur dan kelayakan untuk mendapat diskon pembayaran awal. Tanggal ini menjadi masukan utama bagi KPI 'Tingkat Pemanfaatan Diskon Pembayaran Awal'. Mengapa ini penting Tanggal ini menjadi dasar untuk menghitung syarat pembayaran dan tanggal jatuh tempo, yang penting untuk mengelola modal kerja dan memanfaatkan diskon. Sumber data Terdapat pada tabel header dokumen BKPF, kolom BLDAT (Tanggal Dokumen). Contoh 2023-04-122023-05-152023-06-20 | |||
Aktivitas pemrosesan faktur Purchase to Pay
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Dokumen faktur dibuat | Ini adalah peristiwa pertama, yang menandai pembuatan dokumen faktur di SAP. Peristiwa ini dapat dicatat saat pengguna menyimpan dokumen faktur baru, baik dalam status parkir maupun sebelum dibukukan. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya siklus pemrosesan faktur. Menganalisis waktu dari peristiwa ini hingga peristiwa lainnya penting untuk mengukur keseluruhan waktu pemrosesan. Sumber data Peristiwa ini dicatat dari tanggal dan waktu pembuatan (CPUDT, CPUTM) di tabel header dokumen, biasanya BKPF atau RBKP untuk faktur logistik. Kode transaksi (BKPF-TCODE), seperti FB60, MIRO, atau MIR7, menunjukkan cara dokumen dibuat. Pengumpulan data Gunakan cap waktu pembuatan dari BKPF-CPUDT dan BKPF-CPUTM untuk dokumen faktur. Jenis peristiwa explicit | |||
| Faktur dibatalkan | Aktivitas ini menandakan pembatalan dokumen faktur yang sebelumnya sudah diposting. Ini menjadi peristiwa akhir untuk faktur yang keliru, yang biasanya kemudian dimasukkan kembali dengan benar. | ||
| Mengapa ini penting Pembatalan menunjukkan adanya kesalahan serius yang tidak terdeteksi pada tahap sebelumnya. Melacak frekuensi dan akar penyebabnya penting untuk memperbaiki proses dan mengurangi kesalahan keuangan. Sumber data Pembatalan dikenali saat dokumen pembalik dibuat. Header dokumen asli (BKPF) memuat nomor dokumen pembalik (BKPF-STBLG), dan sebaliknya. Tanggal posting dokumen pembalik menjadi waktu peristiwa. Pengumpulan data Cari dokumen yang memiliki nilai pada kolom BKPF-STBLG, lalu gunakan tanggal posting dokumen pembalik. Jenis peristiwa explicit | |||
| Faktur dibukukan | Ini adalah peristiwa keuangan penting saat faktur yang diparkir atau disetujui resmi dibukukan ke Buku Besar. Tindakan ini mencatat kewajiban kepada vendor. | ||
| Mengapa ini penting Posting menjadi tonggak penting yang memisahkan tahap entri data dan persetujuan dari tahap penyelesaian keuangan. Waktu dari pembuatan faktur hingga posting menjadi ukuran utama efisiensi pemrosesan internal. Sumber data Peristiwa ini dikenali dari Posting Date (BKPF-BUDAT) pada header dokumen. Untuk dokumen yang diparkir terlebih dahulu, perubahan status menjadi posted memberikan stempel waktu peristiwa. Pengumpulan data Gunakan tanggal posting (BKPF-BUDAT) sebagai stempel waktu peristiwa. Jenis peristiwa explicit | |||
| Faktur disetujui | Aktivitas ini menandakan bahwa faktur telah disetujui oleh pihak yang berwenang. Peristiwa ini dicatat saat alur kerja persetujuan berhasil diselesaikan atau indikator pelepasan ditetapkan. | ||
| Mengapa ini penting Ini adalah tahap penting yang membuat faktur dapat dibayar. Persetujuan yang tertunda sering menjadi hambatan. Dengan memantau aktivitas ini, organisasi dapat menemukan pemberi persetujuan atau tahapan proses yang lambat. Sumber data Peristiwa ini dapat diketahui dari tahap pelepasan terakhir dalam alur kerja SAP atau dengan memantau perubahan kolom status pelepasan di tabel yang terkait dengan faktur atau dokumen pembeliannya. Pengumpulan data Simpulkan peristiwa ini dari selesainya alur kerja atau perubahan kolom status pelepasan dokumen. Jenis peristiwa inferred | |||
| Pembayaran dilaksanakan | Ini adalah aktivitas terakhir dalam proses standar, saat pembayaran dilakukan dan faktur dilunasi. Artinya, dana telah dibayarkan kepada vendor. | ||
| Mengapa ini penting Peristiwa ini menandai akhir siklus faktur P2P. Informasi ini penting untuk menghitung total waktu siklus dari awal hingga akhir dan mengukur ketepatan waktu pembayaran berdasarkan tanggal jatuh tempo. Sumber data Peristiwa ini dicatat dari informasi dokumen pelunasan pada item baris vendor. Clearing Date (BSEG-AUGDT) dan Clearing Document (BSEG-AUGBL) menunjukkan bahwa pembayaran telah dilakukan. Pengumpulan data Gunakan tanggal pelunasan (BSEG-AUGDT) dari item baris vendor yang telah dilunasi. Jenis peristiwa explicit | |||
| Blokir pembayaran dihapus | Menunjukkan bahwa masalah telah diselesaikan dan blokir pembayaran yang sebelumnya ditetapkan telah dihapus. Setelah itu, faktur dapat dibayar kembali. | ||
| Mengapa ini penting Waktu antara penetapan dan penghapusan blokir menunjukkan durasi penyelesaian pengecualian proses. Memperpendek durasi ini penting untuk meningkatkan efisiensi dan memperbaiki hubungan dengan vendor. Sumber data Peristiwa ini dicatat saat kolom Kunci Blokir Pembayaran (BSEG-ZLSPR) dikosongkan. Perubahan tersebut dicatat di tabel CDHDR dan CDPOS, termasuk waktu penghapusan. Pengumpulan data Temukan waktu kolom BSEG-ZLSPR dikosongkan melalui dokumen perubahan (CDHDR/CDPOS). Jenis peristiwa explicit | |||
| Blokir pembayaran ditetapkan | Aktivitas ini terjadi saat blokir sengaja diterapkan pada faktur agar tidak dibayar. Penyebabnya sering berupa ketidaksesuaian harga atau jumlah, atau nota kredit yang masih menunggu penyelesaian. | ||
| Mengapa ini penting Blokir pembayaran merupakan penyebab utama keterlambatan pembayaran dan perselisihan dengan vendor. Menganalisis frekuensi, durasi, dan penyebab blokir penting untuk meningkatkan ketepatan waktu pembayaran. Sumber data Peristiwa ini dicatat dengan memantau perubahan kolom Kunci Blokir Pembayaran (BSEG-ZLSPR) pada item baris faktur. Log perubahan di CDHDR dan CDPOS mencatat waktu serta pengguna yang menetapkan blokir. Pengumpulan data Temukan waktu kolom BSEG-ZLSPR diisi melalui dokumen perubahan (CDHDR/CDPOS). Jenis peristiwa explicit | |||
| Data faktur diperbarui | Aktivitas ini mencatat perubahan pada dokumen faktur setelah pertama kali dibuat. Perubahan seperti ini umum terjadi saat faktur perlu dikerjakan ulang setelah ditolak atau saat kesalahan perlu diperbaiki. | ||
| Mengapa ini penting Pembaruan yang sering menandakan adanya pengulangan kerja dan kemungkinan masalah kualitas data saat entri. Dengan memantau perubahan ini, organisasi dapat mengukur upaya yang digunakan untuk melakukan koreksi dan menemukan kesalahan yang umum terjadi. Sumber data Perubahan pada kolom penting dicatat di tabel dokumen perubahan SAP, CDHDR (header) dan CDPOS (item). Peristiwa dapat dibuat dengan memfilter perubahan pada objek faktur yang relevan. Pengumpulan data Ekstrak peristiwa perubahan untuk objek faktur dari tabel CDHDR dan CDPOS. Jenis peristiwa explicit | |||
| Faktur dikirim untuk disetujui | Aktivitas ini menandai dimulainya alur kerja persetujuan resmi untuk faktur. Biasanya, aktivitas ini diketahui saat status faktur berubah menjadi 'menunggu persetujuan' atau saat item alur kerja dibuat. | ||
| Mengapa ini penting Ini adalah titik awal untuk mengukur waktu siklus persetujuan. Mengetahui kapan proses persetujuan dimulai penting untuk menemukan hambatan dalam alur kerja persetujuan. Sumber data Peristiwa ini biasanya diketahui dari dimulainya SAP Business Workflow (tabel SWW_WI2OBJ) yang terkait dengan objek faktur, seperti BUS2081, atau dari perubahan kolom status khusus pada header dokumen. Pengumpulan data Simpulkan peristiwa ini dari pembuatan item alur kerja yang terkait dengan dokumen faktur. Jenis peristiwa inferred | |||
| Faktur diparkir | Menunjukkan faktur yang telah dimasukkan ke sistem, tetapi belum dibukukan ke buku besar. Faktur diparkir untuk menyimpan data yang belum lengkap atau menunggu peninjauan sebelum dibukukan. | ||
| Mengapa ini penting Faktur yang diparkir menandakan adanya jeda yang disengaja dalam proses. Dengan memantau durasi dan frekuensinya, organisasi dapat menemukan penyebab keterlambatan sebelum proses pembukuan dan persetujuan resmi dimulai. Sumber data Peristiwa ini dapat dikenali dari dokumen yang dibuat melalui transaksi parkir, seperti MIR7 atau FV60, atau dengan memeriksa kolom status tertentu di tabel BKPF maupun tabel khusus dokumen parkir seperti VBKPF. Pengumpulan data Temukan dokumen yang dibuat melalui transaksi parkir atau periksa status dokumen yang diparkir. Jenis peristiwa explicit | |||
| Faktur ditolak | Menunjukkan bahwa faktur ditolak selama proses persetujuan. Peristiwa ini memicu pengulangan kerja, karena faktur perlu diperbaiki dan diajukan kembali. | ||
| Mengapa ini penting Penolakan faktur merupakan indikator penting adanya inefisiensi proses dan masalah kualitas data. Analisis frekuensi dan alasan penolakan membantu menemukan peluang perbaikan dan kebutuhan pelatihan. Sumber data Peristiwa ini diketahui dari pembaruan status tertentu dalam alur kerja SAP, seperti status 'ditolak', atau dari peristiwa yang membatalkan alur kerja persetujuan saat ini dan mengembalikannya kepada petugas pemroses. Pengumpulan data Simpulkan peristiwa ini dari perubahan status alur kerja yang menunjukkan penolakan. Jenis peristiwa inferred | |||
| Pembayaran terlambat dilaksanakan | Ini adalah peristiwa hasil perhitungan yang terjadi saat pembayaran faktur dilaksanakan setelah tanggal jatuh tempo yang dihitung. Peristiwa ini ditentukan dengan membandingkan dua kolom tanggal. | ||
| Mengapa ini penting Aktivitas ini mendukung KPI ketepatan waktu pembayaran dan membantu menemukan vendor atau unit bisnis yang sering terlambat membayar. Keterlambatan dapat merusak hubungan dengan vendor dan menimbulkan denda. Sumber data Peristiwa ini dihitung dengan membandingkan Clearing Date (BSEG-AUGDT) dengan Net Due Date. Tanggal jatuh tempo dihitung dari Baseline Date (BSEG-ZFBDT) dan syarat pembayaran (BSEG-ZTERM). Pengumpulan data Tentukan dengan membandingkan BSEG-AUGDT > (BSEG-ZFBDT + jumlah hari sesuai syarat pembayaran). Jenis peristiwa calculated | |||
| Usulan pembayaran dibuat | Faktur dipilih dan dimasukkan ke dalam usulan pembayaran sebagai bagian dari proses pembayaran. Ini adalah langkah pertama dalam proses pembayaran otomatis. | ||
| Mengapa ini penting Aktivitas ini menandakan rencana untuk membayar. Jeda antara langkah ini dan pelaksanaan pembayaran dapat menunjukkan masalah pada proses pembayaran, persetujuan, atau komunikasi dengan bank. Sumber data Informasi ini tersedia di tabel proses pembayaran, khususnya REGUP, yang memuat item dalam usulan pembayaran. Tanggal proses pada tabel REGUH terkait memberikan stempel waktunya. Pengumpulan data Tentukan kapan faktur muncul di tabel REGUP dari proses usulan pembayaran. Jenis peristiwa explicit | |||
Panduan ekstraksi
Langkah
- Prasyarat dan otorisasi: Pastikan pengguna yang menjalankan ekstraksi memiliki otorisasi yang diperlukan di SAP S/4HANA untuk mengakses CDS View (Core Data Services) yang dibutuhkan. View utama mencakup
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItem, danI_PaymentProposalItem. Pengguna juga memerlukan izin untuk menjalankan kueri melalui antarmuka yang dipilih, seperti layanan OData atau koneksi SQL langsung. - Tentukan metode koneksi: Tentukan cara menghubungkan ke sistem SAP S/4HANA untuk menjalankan kueri SQL. Metode umum mencakup SAP Data Services, SAP Data Intelligence, alat ETL pihak ketiga dengan konektor SAP, atau koneksi SQL langsung ke basis data SAP HANA jika diizinkan oleh kebijakan keamanan organisasi Anda.
- Tentukan parameter ekstraksi: Sebelum menjalankan kueri, tentukan parameter utama. Tetapkan rentang tanggal ekstraksi, misalnya
CreationDateantara'YYYY-MM-DD'dan'YYYY-MM-DD'. Tentukan juga nilaiCompanyCodeyang ingin disertakan untuk membatasi cakupan data. - Sesuaikan kueri SQL: Salin kueri SQL yang disediakan ke klien SQL atau alat ekstraksi data pilihan Anda. Periksa placeholder seperti
'{StartDate}','{EndDate}', dan('{CompanyCode1}', '{CompanyCode2}'). Ganti placeholder tersebut dengan nilai yang telah ditentukan pada langkah sebelumnya. Anda mungkin juga perlu menyesuaikan nama kolom untuk status alur kerja sesuai konfigurasi SAP Anda. - Jalankan kueri: Jalankan kueri SQL lengkap pada basis data SAP S/4HANA atau melalui lapisan layanan yang sesuai. Kueri ini dirancang untuk mencakup banyak data. Waktu prosesnya bisa cukup lama, bergantung pada volume data dan rentang tanggal yang dipilih. Pantau prosesnya untuk mengetahui kemungkinan kesalahan atau batas waktu.
- Periksa hasil awal: Setelah kueri selesai, tinjau hasilnya secara singkat. Pastikan kolom
InvoiceNumber,ActivityName, danEventTimeterisi. Periksa apakah kolomActivityNamememuat beragam aktivitas, bukan hanya 'Invoice Document Created'. - Tangani transformasi data: Kueri ini disusun untuk menghasilkan format log peristiwa yang rapi. Namun, pastikan kolom
EventTimemenggunakan format stempel waktu yang konsisten, sepertiYYYY-MM-DDTHH:MM:SS. Jika diperlukan, kueri yang disediakan menggabungkan kolom tanggal dan waktu menjadi satu stempel waktu. - Ekspor data: Ekspor hasil akhir dari alat Anda ke file CSV (Comma-Separated Values). Format ini kompatibel dengan berbagai alat process mining, termasuk ProcessMind.
- Siapkan data untuk diunggah: Sebelum mengunggah, pastikan file CSV menggunakan encoding UTF-8 agar karakter tidak bermasalah. Pastikan header kolom pada file sama persis dengan atribut yang diwajibkan:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, dan seterusnya. - Unggah ke ProcessMind: Unggah file CSV yang telah disiapkan ke proyek process mining Anda. Petakan kolom dari file ke kolom ID kasus, nama aktivitas, dan stempel waktu yang sesuai dalam konfigurasi model data alat.
Konfigurasi
- CDS View yang digunakan: Sumber data utama adalah CDS View standar SAP. View penting mencakup
I_InvoiceDocumentuntuk data header,I_OperationalAcctgDocItemuntuk detail pencatatan keuangan dan penyelesaian, sertaI_ChangeDocumentbersamaI_ChangeDocumentItemuntuk melacak perubahan historis pada atribut faktur, seperti blokir pembayaran dan status alur kerja. - Filter rentang tanggal: Filter data berdasarkan rentang tanggal tertentu sangat penting untuk menjaga kinerja. Kueri yang disediakan menggunakan placeholder untuk
CreationDatepada viewI_InvoiceDocument. Sebagai awal, disarankan menggunakan data untuk periode 3 hingga 6 bulan. - Filter kode perusahaan: Agar ekstraksi tetap relevan dan mudah dikelola, selalu filter berdasarkan satu atau beberapa
CompanyCode. Kueri menyertakan placeholderWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')untuk keperluan ini. - Filter jenis dokumen: Anda dapat mempersempit ekstraksi dengan memfilter
InvoiceDocumentType. Misalnya, sertakan faktur pemasok standar (RE), tetapi kecualikan nota kredit. Tambahkan filter ini ke klausaWHEREpada CTE awal. - Prasyarat: Pengguna yang menjalankan kueri memerlukan otorisasi untuk melihat dokumen keuangan dan pembelian dalam kode perusahaan yang ditentukan. Akses ke basis data HANA melalui klien SQL bukan akses standar dan memerlukan izin khusus.
- Pertimbangan kinerja: Ekstraksi data dari tabel dokumen perubahan (
I_ChangeDocument,I_ChangeDocumentItem) dapat membebani kinerja. Terapkan filter ketat pada tanggal, kode perusahaan, dan kelas objek (INCOMINGINVOICE) untuk mencegah waktu proses yang terlalu lama.
Contoh kueri sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Langkah
- Pastikan akses baca langsung ke tenant atau skema basis data SAP HANA telah disetujui. Dapatkan pengguna basis data hanya-baca dengan otorisasi untuk tabel SAP yang diperlukan serta tabel riwayat perubahan atau alur kerja yang disetujui. Gunakan SAP HANA Database Explorer, SAP HANA Studio, atau klien SQL yang disetujui. Jangan gunakan akses tulis ke sistem produksi.
- Pastikan nama fisik tabel dan kolom di sistem S/4HANA tujuan. ACDOCA, BKPF, dan RBKP adalah titik awal standar, tetapi data alur kerja, parkir, usulan pembayaran, pelaksanaan pembayaran, riwayat perubahan, dan riwayat blokir pembayaran mungkin menggunakan objek khusus sesuai versi atau pelanggan. Ganti setiap placeholder dalam tanda kurung siku pada kueri dengan objek yang telah diverifikasi di katalog sistem dan sesuai dengan makna bisnisnya.
- Tentukan periode ekstraksi menggunakan [Start timestamp] dan [End timestamp]. Ambil data dokumen dan peristiwa untuk periode yang cukup luas, biasanya tiga hingga enam bulan. Perpanjang periode jika tanggal jatuh tempo atau pembayaran terlambat dapat terjadi di luar periode pembuatan faktur.
- Identifikasi kasus faktur menggunakan kunci faktur yang telah dikonfigurasi. Kueri menggunakan InvoiceNumber sebagai ID kasus dan, jika diperlukan, menggabungkannya secara internal dengan kode perusahaan dan tahun fiskal untuk menghindari duplikasi. Pastikan apakah definisi bisnis mengharuskan tahun fiskal atau kode perusahaan ditambahkan ke ID kasus ProcessMind.
- Petakan data faktur yang telah dibukukan dari RBKP, BKPF, dan ACDOCA. Gunakan RBKP untuk informasi header faktur, BKPF untuk stempel waktu dan pengguna dokumen akuntansi, serta ACDOCA untuk informasi pemasok, jumlah, dokumen pembelian, penyelesaian, dan akuntansi terkait pembayaran jika tersedia. Jangan berasumsi semua kolom terisi dalam setiap skenario pembukuan.
- Petakan peristiwa parkir, persetujuan, penolakan, pembaruan, blokir pembayaran, pembalikan, usulan, dan pelaksanaan pembayaran dari sumber khusus sistem yang telah diverifikasi. Ganti view sumber placeholder dengan view atau tabel yang disetujui dan menyediakan stempel waktu peristiwa, referensi faktur, pengguna, status, serta nilai lama dan baru. Setiap aktivitas harus dicatat sebagai baris peristiwa tersendiri karena ProcessMind tidak menyimpulkan peristiwa.
- Jalankan kueri SQL lengkap dalam sesi nonproduksi atau hanya-baca. Tinjau rencana eksekusi dan batasi kueri berdasarkan kode perusahaan, jenis dokumen, tahun fiskal, dan stempel waktu peristiwa jika sesuai. Hindari penggabungan tanpa batas antara tabel jurnal dan tabel riwayat berukuran besar.
- Validasi hasil menggunakan pemeriksaan yang dijelaskan di bawah. Pastikan semua kolom wajib tersedia,
EventTimeterisi untuk setiap peristiwa,InvoiceNumberterisi untuk setiap kasus, dan semua 13 nama aktivitas muncul jika data sumber terkait tersedia. - Ekspor hasil sebagai file berpemisah yang didukung ProcessMind, sebaiknya CSV UTF-8, dengan satu baris per peristiwa dan kolom InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason, dan PurchasingDocument. Gunakan zona waktu yang konsisten untuk stempel waktu dan pertahankan angka nol di awal pada pengenal.
- Unggah log peristiwa ke ProcessMind dan tetapkan InvoiceNumber sebagai ID kasus, ActivityName sebagai kolom aktivitas, dan EventTime sebagai kolom stempel waktu. Jika konfigurasi ProcessMind mendukung kunci kasus tambahan, gunakan kebijakan kunci gabungan yang sama seperti saat ekstraksi.
Konfigurasi
- Rentang tanggal: Untuk ekstraksi awal, gunakan periode bergulir tiga hingga enam bulan. Sertakan riwayat tambahan jika peristiwa persetujuan, pembayaran, penyelesaian, pembalikan, atau keterlambatan pembayaran dapat terjadi setelah periode pembuatan faktur.
- Cakupan perusahaan: Filter berdasarkan [Company code filter] dan pastikan kode perusahaan yang dipilih diizinkan untuk ekstraksi.
- Cakupan dokumen: Filter berdasarkan [Document type filter] dan sertakan jenis dokumen yang mewakili faktur pemasok, nota kredit, faktur yang diparkir, dan pembalikan dalam proses yang dituju.
- ID kasus: Gunakan InvoiceNumber sesuai definisi proses. Jika nomor faktur tidak unik secara global, pertahankan kode perusahaan dan tahun fiskal dalam hasil sumber atau konfigurasi kunci kasus gabungan sesuai model ProcessMind.
- Sumber peristiwa: Pastikan sumber fisik untuk perubahan status alur kerja, keputusan persetujuan, parkir, riwayat perubahan, blokir pembayaran, usulan pembayaran, dan pelaksanaan pembayaran. Sumber ini berbeda-beda menurut versi S/4HANA, cakupan yang diaktifkan, desain alur kerja, dan ekstensi pelanggan.
- Kebijakan stempel waktu: Pilih stempel waktu peristiwa bisnis, bukan stempel waktu ekstraksi. Catat zona waktu dan konversikan semua stempel waktu peristiwa secara konsisten sebelum mengunggah.
- Kebijakan jumlah: Gunakan jumlah dalam mata uang kode perusahaan dan pastikan tanda debit dan kredit disimpan secara konsisten di sumber yang dipilih. Jangan menjumlahkan baris jurnal sebelum aturan agregasinya divalidasi untuk kasus faktur.
- Kebijakan pembayaran: Tentukan apakah Payment Executed berarti penyelesaian, pembukuan dokumen pembayaran, pelaksanaan melalui bank, atau pencapaian bisnis lainnya. Gunakan sumber yang sesuai dengan definisi proses yang disepakati.
- Pembayaran terlambat: Catat Late Payment Executed hanya jika Payment Executed terjadi setelah PaymentDueDate. Kueri menghitung peristiwa ini secara eksplisit dan tidak mengandalkan kesimpulan ProcessMind.
- Kinerja: Batasi pembacaan sumber berdasarkan tanggal, kode perusahaan, jenis dokumen, dan tahun fiskal yang relevan. Pilih hanya kolom yang diperlukan, periksa rencana kueri, dan wujudkan view perantara yang disetujui jika data riwayat sumber berukuran besar.
- Prasyarat: Konektivitas langsung ke SAP HANA, otorisasi baca untuk semua objek yang dipilih, izin untuk memeriksa metadata, serta akses ke data Accounts Payable, General Ledger, pembelian, alur kerja, dan pembayaran yang relevan. Pastikan lisensi SAP, kebijakan akses basis data, dan persetujuan perlindungan data yang diperlukan sudah tersedia.
- Keamanan: Gunakan pengguna teknis hanya-baca, lindungi data pemasok dan pembayaran, serta ikuti kebijakan organisasi terkait transportasi, audit, penyamaran data, dan pengelolaan kredensial.
Contoh kueri sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Langkah
- Buka ABAP Editor: Masuk ke sistem SAP S/4HANA Anda. Buka transaksi
SE38(ABAP Editor). - Buat program: Masukkan nama program baru di kolom Program, misalnya
Z_PM_INVOICE_EXTRACT, lalu klik tombol 'Create'. Isi judul, tetapkan Type sebagai 'Executable Program', lalu simpan dalam paket yang sesuai. - Tentukan struktur program dan layar seleksi: Di editor, tentukan struktur data untuk keluaran akhir log peristiwa. Lalu buat layar seleksi agar pengguna dapat memasukkan parameter seperti rentang tanggal pencatatan faktur, kode perusahaan, dan jenis dokumen. Dengan begitu, program dapat digunakan kembali dan disesuaikan dengan kebutuhan.
- Terapkan logika pemilihan data: Tulis pernyataan ABAP SQL utama untuk memilih data dari berbagai tabel SAP. Program akan menjalankan kueri secara berurutan untuk setiap 13 aktivitas yang diperlukan.
- Ekstrak data header dan item: Untuk peristiwa dasar seperti 'Invoice Document Created' dan 'Invoice Posted', pilih data dari tabel utama seperti
RBKP(Logistics Invoice Header) danBKPF(Accounting Document Header). - Ekstrak data dokumen perubahan: Untuk aktivitas seperti 'Payment Block Set' dan 'Payment Block Removed', kueri tabel dokumen perubahan
CDHDR(Change document header) danCDPOS(Change document items). Anda perlu mengidentifikasi perubahan pada kolom tertentu, misalnyaZLSPRdi tabelBSEG. - Ekstrak data pembayaran: Untuk mencatat aktivitas terkait pembayaran, kueri tabel seperti
REGUP(Processed items from payment program) untuk usulan pembayaran danBSAK(Cleared Vendor Items) untuk pembayaran yang dilaksanakan. Bedakan 'Late Payment Executed' dengan membandingkan tanggal penyelesaian (AUGDT) dan tanggal jatuh tempo bersih (ZFBDT). - Ekstrak data alur kerja: Untuk aktivitas persetujuan, kueri tabel SAP Business Workflow seperti
SWW_WI2OBJuntuk menghubungkan item alur kerja dengan objek faktur. Bagian ini sangat bergantung pada konfigurasi alur kerja Anda dan mungkin memerlukan banyak penyesuaian. - Satukan data dalam format log peristiwa: Untuk setiap aktivitas yang dipilih, format data ke dalam struktur tabel internal yang seragam. Setiap baris mewakili satu peristiwa dan harus memuat ID kasus (
InvoiceNumber),ActivityName, danEventTime, beserta atribut lain yang disarankan. - Buat file keluaran: Gunakan pernyataan ABAP
OPEN DATASET,TRANSFER, danCLOSE DATASETuntuk menulis isi tabel internal akhir ke file datar di server aplikasi SAP. Format CSV (Comma-Separated Values) disarankan. - Jadwalkan dan jalankan: Jalankan program di latar depan untuk pengujian (gunakan
F8). Untuk penggunaan produksi, jadwalkan sebagai pekerjaan latar belakang melalui transaksiSM36pada jam sibuk rendah agar kinerja sistem tidak terganggu. - Ambil dan unggah file: Gunakan transaksi
AL11untuk membuka direktori server aplikasi tempat file disimpan. Unduh file ke sistem lokal Anda. Pastikan file menggunakan encoding UTF-8 dan format yang benar sebelum mengunggahnya ke alat process mining.
Konfigurasi
- Rentang tanggal: Tentukan rentang tanggal ekstraksi berdasarkan tanggal pencatatan faktur (
RBKP-CPUDT) atau tanggal pembukuan (BKPF-BUDAT). Untuk analisis awal, disarankan periode 3 hingga 6 bulan agar volume data tetap mudah dikelola. - Kode perusahaan (BUKRS): Filter berdasarkan satu atau beberapa kode perusahaan. Mengekstrak data dari semua kode perusahaan di organisasi besar dapat menyebabkan waktu proses sangat lama dan menghasilkan file berukuran besar.
- Jenis dokumen (BLART): Filter jenis dokumen yang relevan untuk memisahkan faktur pemasok. Jenis yang umum mencakup 'RE' (Invoice - Gross) dan 'KR' (Vendor Invoice). Filter ini membantu mengecualikan dokumen yang tidak relevan dari analisis.
- Akun pemasok (LIFNR): Program dapat menyediakan filter opsional untuk nomor pemasok tertentu. Filter ini berguna untuk analisis terarah atau pengujian.
- Konfigurasi file keluaran: Program sebaiknya menyediakan parameter untuk menentukan jalur file keluaran di server aplikasi dan pemisah kolom, misalnya koma atau titik koma.
- Prasyarat: Pengguna atau akun sistem yang menjalankan program ini memerlukan akses pengembang untuk membuat dan menjalankan program ABAP (melalui
SE38), serta otorisasi baca yang luas untuk tabel FI, MM, dan Basis, termasukBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOS, dan tabel alur kerja.
Contoh kueri abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. Siap memulai?
Mulai optimalkan pemrosesan faktur Anda hari ini. Templat ini menjadi langkah awal untuk meningkatkan kinerja operasional dan efisiensi secara signifikan.
Optimalkan pemrosesan faktur P2P di SAP S/4HANA sekarang
Temukan hambatan dan kurangi waktu siklus faktur hingga 30% atau lebih.
Tidak perlu kartu kredit. Siapkan dalam hitungan menit.