Templat data pemrosesan faktur Procure to Pay
Templat data pemrosesan faktur Procure to Pay
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dicatat
- Panduan ekstraksi untuk SAP ECC
Atribut pemrosesan faktur Procure to Pay
| Nama | Deskripsi | ||
|---|---|---|---|
| Aktivitas Activity | Nama langkah bisnis atau peristiwa tertentu yang terjadi selama siklus pemrosesan invoice. | ||
| Deskripsi Atribut Aktivitas menunjukkan tahap atau tindakan tertentu dalam alur kerja pemrosesan invoice. Aktivitas ini berasal dari berbagai peristiwa sistem, seperti pembuatan dokumen, perubahan status, persetujuan, atau tindakan pengguna yang tercatat dalam log perubahan SAP. Analisis aktivitas merupakan inti process mining. Analisis ini membantu memetakan proses, menemukan hambatan, misalnya waktu tunggu yang lama setelah 'Invoice dikirim untuk disetujui', proses berulang, misalnya siklus 'Pemblokiran pembayaran diterapkan' dan 'Pemblokiran pembayaran dilepas' yang berulang, serta penyimpangan dari aturan kepatuhan. Urutan dan frekuensi aktivitas menunjukkan alur proses yang benar-benar terjadi. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam peta proses, sehingga alur proses dapat divisualisasikan, hambatan ditemukan, dan pengerjaan ulang diidentifikasi. Sumber data Atribut ini biasanya berasal dari beberapa sumber, termasuk kode transaksi (SY-TCODE), kolom status di tabel seperti RBKP (misalnya RBSTAT), serta peristiwa perubahan dari tabel CDHDR dan CDPOS. Contoh Invoice diparkirInvoice dikirim untuk disetujuiInvoice disetujuiInvoice dibukukanInvoice dilunasi | |||
| Nomor invoice InvoiceNumber | Pengenal unik untuk dokumen invoice vendor. | ||
| Deskripsi Nomor invoice menjadi pengenal kasus unik untuk perjalanan pemrosesan invoice. Setiap nomor merujuk pada satu invoice dari vendor. Dengan nomor ini, semua aktivitas terkait, mulai dari pencatatan data hingga pembayaran akhir, dapat dilacak sebagai satu rangkaian proses. Dalam analisis process mining, atribut ini menjadi dasar untuk menyusun kembali siklus setiap invoice dari awal hingga akhir. Atribut ini menghubungkan berbagai peristiwa yang tercatat di SAP, seperti pemarkiran, pembukuan, pemblokiran, dan pelunasan, menjadi urutan kronologis. Hasilnya, Anda dapat melihat dengan jelas cara setiap invoice ditangani, waktu yang dibutuhkan, dan bagian yang menyimpang dari proses standar. Mengapa ini penting Ini adalah kunci utama yang menghubungkan semua peristiwa terkait satu invoice, sehingga menjadi dasar penting untuk analisis proses dan penelusuran variasi. Sumber data Biasanya, atribut ini menggunakan Nomor Dokumen dari tabel SAP RBKP, kolom BELNR, yang sering digabungkan dengan Kode Perusahaan (BUKRS) dan Tahun Fiskal (GJAHR) agar benar-benar unik. Contoh 510004567851000456795100045680 | |||
| Waktu peristiwa EventTime | Stempel waktu yang tepat, mencakup tanggal dan waktu terjadinya aktivitas. | ||
| Deskripsi Waktu peristiwa mencatat saat tepat suatu aktivitas bisnis dilakukan dan dicatat di sistem sumber. Stempel waktu ini menjadi dasar urutan kronologis, yang menyusun semua aktivitas untuk setiap invoice menjadi rangkaian yang jelas. Dalam analisis, waktu peristiwa diperlukan untuk menghitung semua metrik berbasis durasi, seperti waktu siklus, waktu tunggu, dan waktu pemrosesan antaraktivitas. Data ini mendukung dashboard seperti 'Waktu siklus invoice dari awal hingga akhir' dan 'Durasi penyelesaian pemblokiran pembayaran' dengan mengukur waktu antara dua titik dalam proses. Stempel waktu yang akurat penting untuk menemukan keterlambatan dan hambatan kinerja. Mengapa ini penting Stempel waktu ini diperlukan untuk mengurutkan peristiwa dengan benar dan menghitung semua metrik kinerja, seperti waktu siklus dan durasi hambatan. Sumber data Biasanya, atribut ini diperoleh dengan menggabungkan tanggal perubahan (UDATE) dan waktu perubahan (UTIME) dari tabel header dokumen perubahan CDHDR. Untuk peristiwa pembuatan tertentu, atribut ini dapat menggunakan tanggal dan waktu pembuatan dari tabel seperti RBKP (ERNAM, ERZET). Contoh 2023-03-15T10:30:00Z2023-03-16T14:05:21Z2023-03-28T09:00:00Z | |||
| Alasan pemblokiran pembayaran PaymentBlockReason | Kode yang menjelaskan alasan faktur diblokir agar tidak dibayar. | ||
| Deskripsi Jika faktur memiliki selisih atau perlu diperiksa lebih lanjut, pembayaran akan diblokir. Kode alasan pemblokiran pembayaran menjelaskan penyebabnya, misalnya selisih kuantitas, selisih harga, atau pemblokiran manual. Atribut ini penting untuk dashboard 'Payment Block Resolution Duration'. Analisis frekuensi dan durasi pemblokiran berdasarkan alasan membantu menemukan penyebab utama keterlambatan pembayaran. Misalnya, jika 'Price Discrepancy' paling sering menyebabkan pemblokiran yang lama, mungkin ada masalah pada data induk atau proses pesanan pembelian yang perlu ditangani. Mengapa ini penting Atribut ini menjelaskan penyebab keterlambatan faktur, membantu menemukan akar masalah pemblokiran pembayaran, dan menentukan prioritas perbaikan proses. Sumber data Alasan pemblokiran pembayaran dapat ditemukan di tingkat item pada tabel RSEG (kolom SPGRS) atau di tabel dokumen akuntansi BSEG (kolom ZLSPR). Contoh RIM | |||
| Nama pengguna UserName | ID pengguna SAP dari orang yang melakukan aktivitas. | ||
| Deskripsi Atribut Nama pengguna menunjukkan orang yang bertanggung jawab melakukan aktivitas tertentu dalam proses. Biasanya, atribut ini menggunakan nama pengguna SAP yang tercatat bersama transaksi atau peristiwa perubahan. Atribut ini penting untuk menganalisis kinerja pengguna atau tim. Anda dapat menjawab pertanyaan seperti 'Siapa pemberi persetujuan tercepat?' atau 'Pengguna mana yang paling sering menyebabkan pengerjaan ulang?'. Dashboard menggunakan atribut ini untuk menganalisis pembagian beban kerja, menemukan kebutuhan pelatihan, dan memahami perbedaan kinerja antarpegawai. Mengapa ini penting Atribut ini memungkinkan analisis kinerja dan beban kerja per individu atau tim, serta membantu menemukan karyawan berkinerja tinggi, kebutuhan pelatihan, dan ketimpangan sumber daya. Sumber data Atribut ini menggunakan kolom 'Diubah oleh' (USERNAME) dari tabel header dokumen perubahan CDHDR. Untuk peristiwa pembuatan, atribut ini dapat menggunakan kolom 'Dimasukkan oleh' (ERNAM) di tabel seperti RBKP. Contoh JSMITHBWILSONCHEN | |||
| Nilai invoice InvoiceAmount | Total nilai bruto invoice dalam mata uang asli dokumen. | ||
| Deskripsi Nilai invoice menunjukkan total nilai invoice yang diajukan vendor. Ini adalah metrik keuangan utama untuk setiap kasus invoice. Dalam process mining, atribut ini penting untuk analisis berdasarkan nilai. Anda dapat memfilter dan mengelompokkan proses berdasarkan nilai invoice, yang sering berkaitan dengan tingkat kerumitan proses dan persyaratan persetujuan. Misalnya, invoice bernilai tinggi mungkin mengikuti jalur persetujuan yang berbeda dan lebih ketat. Atribut ini juga digunakan dalam analisis kepatuhan, misalnya untuk memeriksa apakah invoice bernilai tinggi melewati tahap persetujuan yang diwajibkan. Mengapa ini penting Atribut ini memungkinkan analisis berdasarkan nilai, membantu Anda memprioritaskan invoice bernilai tinggi dan memahami pengaruh nilai invoice terhadap alur proses serta kepatuhan. Sumber data Atribut ini menggunakan kolom 'Nilai bruto invoice' (RMWWR) dari tabel header dokumen invoice RBKP. Contoh 1500.7512500.00850.20 | |||
| Nomor pesanan pembelian PurchaseOrderNumber | Pengenal pesanan pembelian (PO) yang digunakan untuk mencocokkan invoice. | ||
| Deskripsi Nomor pesanan pembelian menghubungkan invoice dengan dokumen pengadaan asal. Atribut ini menjadi dasar pencocokan tiga arah antara PO, penerimaan barang, dan invoice, serta analisis efisiensi proses invoice yang terkait dengan PO. Atribut ini penting untuk dashboard seperti 'Tingkat ketidaksesuaian pencocokan invoice dengan PO'. Anda dapat memisahkan invoice yang terkait dengan PO dari invoice yang tidak terkait, karena keduanya sering memiliki alur dan tingkat kerumitan yang berbeda. Analisis masalah pada PO tertentu juga dapat membantu menemukan masalah di tahap awal proses pengadaan. Mengapa ini penting Atribut ini menghubungkan invoice dengan proses pengadaan, sehingga Anda dapat menganalisis invoice yang terkait dan tidak terkait dengan PO serta menemukan ketidaksesuaian pencocokan. Sumber data Atribut ini biasanya tersedia di tingkat item baris. 'Nomor pesanan pembelian' (EBELN) terdapat di tabel item invoice RSEG. Anda mungkin perlu menggabungkannya ke tingkat header. Contoh 450001756345000175644500017565 | |||
| Nomor vendor VendorNumber | Pengenal unik untuk vendor atau pemasok yang mengirimkan invoice. | ||
| Deskripsi Nomor vendor adalah kunci data induk yang mengidentifikasi pemasok. Atribut ini menghubungkan transaksi invoice dengan mitra bisnis tertentu sehingga Anda dapat menganalisis proses berdasarkan karakteristik vendor. Analisis berdasarkan nomor vendor dapat menunjukkan pola penting dalam hubungan dan kinerja pemasok. Misalnya, Anda dapat menemukan vendor yang sering mengirimkan invoice bermasalah hingga memicu pemblokiran pembayaran atau ketidaksesuaian, serta vendor yang invoice-nya diproses paling efisien. Informasi ini berguna untuk manajemen vendor dan strategi pengadaan. Mengapa ini penting Atribut ini memungkinkan analisis per vendor untuk menemukan pola, masalah, atau efisiensi yang terkait dengan pemasok tertentu. Sumber data Atribut ini menggunakan kolom 'Pihak penagih' (LIFNR) dari tabel header dokumen invoice RBKP. Contoh 100345100876200112 | |||
| Tanggal jatuh tempo pembayaran PaymentDueDate | Tanggal batas pembayaran faktur kepada vendor sesuai ketentuan pembayaran. | ||
| Deskripsi Tanggal jatuh tempo pembayaran dihitung berdasarkan tanggal dasar faktur dan ketentuan pembayaran yang disepakati. Tanggal ini menjadi batas waktu pembayaran agar tidak terlambat, terkena denda, atau merusak hubungan dengan vendor. Atribut ini penting untuk KPI kinerja dan kepatuhan, seperti 'On-Time Payment Rate' dan 'Cash Discount Opportunity Loss'. Dengan membandingkan tanggal pembayaran aktual (Clearing Date) dengan tanggal jatuh tempo, analisis dapat menentukan apakah pembayaran dilakukan tepat waktu, lebih awal, atau terlambat. Atribut ini juga menjadi dasar dashboard Payment Terms Adherence. Mengapa ini penting Tanggal ini menjadi acuan untuk mengukur ketepatan waktu pembayaran dan menemukan peluang memperoleh diskon pembayaran lebih awal. Sumber data Tanggal ini sering kali dihitung. Tanggal dasar pembayaran (ZFBDT) terdapat di tabel BSEG. Logika tanggal jatuh tempo juga bergantung pada ketentuan pembayaran (BSEG-ZTERM). Contoh 2023-04-192023-05-052023-05-11 | |||
| Tanggal pelunasan ClearingDate | Tanggal pembayaran dilakukan dan faktur dilunasi dari utang usaha. | ||
| Deskripsi Clearing Date menandai tahap akhir siklus faktur, yaitu pembayaran. Tanggal ini menunjukkan kapan item faktur terbuka dilunasi melalui dokumen pembayaran di sistem. Tanggal ini mencatat waktu pembayaran benar-benar dilakukan. Atribut ini menjadi titik akhir bagi banyak KPI penting, termasuk 'Average Invoice Cycle Time' dan 'On-Time Payment Rate'. Tanggal ini dibandingkan dengan tanggal jatuh tempo untuk mengukur kinerja pembayaran. Untuk analisis diskon tunai, tanggal ini dibandingkan dengan periode diskon guna mengetahui apakah pembayaran dilakukan tepat waktu untuk memperoleh diskon. Mengapa ini penting Tanggal ini menandai selesainya proses dan menjadi dasar untuk menghitung total waktu siklus, tingkat pembayaran tepat waktu, serta realisasi diskon tunai. Sumber data Untuk item yang telah dilunasi, ini adalah kolom 'Clearing Date' (AUGDT) dari tabel item vendor yang telah dilunasi, BSAK. Contoh 2023-04-152023-05-022023-05-20 | |||
| Tanggal pembukuan PostingDate | Tanggal saat faktur resmi dibukukan ke buku besar keuangan. | ||
| Deskripsi Tanggal pembukuan menjadi tanggal penting dalam proses akuntansi. Tanggal ini menentukan periode fiskal saat beban faktur diakui di General Ledger. Biasanya, staf utang usaha menetapkannya saat memproses faktur. Dalam analisis proses, aktivitas 'Invoice Posted' yang ditandai oleh tanggal ini menjadi tonggak penting. Durasi dari penerimaan faktur hingga tanggal pembukuan merupakan bagian penting dari total waktu siklus. Tanggal ini juga menjadi dasar pelaporan keuangan dan analisis throughput, misalnya untuk melacak jumlah faktur yang dibukukan per minggu atau bulan. Mengapa ini penting Tanggal ini menandai tonggak penting dalam proses, menentukan periode keuangan transaksi, dan menjadi komponen utama dalam menghitung waktu siklus. Sumber data Ini adalah kolom 'Posting Date' (BUDAT) dari tabel header dokumen faktur RBKP. Contoh 2023-03-202023-04-052023-04-11 | |||
| Akun General Ledger GeneralLedgerAccount | Nomor akun G/L tempat beban atau biaya faktur dibukukan. | ||
| Deskripsi Akun General Ledger (G/L) adalah akun tujuan dalam bagan akun tempat dampak keuangan faktur dicatat. Data ini penting untuk pelaporan keuangan dan pengelolaan biaya. Dalam process mining, analisis akun G/L menambahkan dimensi keuangan pada alur proses. Dashboard 'General Ledger Account Usage Analysis' dapat menunjukkan pola pengeluaran, menemukan kemungkinan kesalahan pengodean faktur, dan memastikan biaya dialokasikan ke departemen atau proyek yang tepat. Analisis ini menghubungkan pelaksanaan proses dengan dampak keuangannya. Mengapa ini penting Atribut ini menambahkan dimensi keuangan pada proses, sehingga alokasi biaya, pola pengeluaran, dan kemungkinan kesalahan pengodean faktur dapat dianalisis. Sumber data Data ini terdapat di tingkat item baris. 'G/L Account Number' (HKONT) ada di tabel item faktur RSEG untuk faktur PO atau BSEG untuk faktur FI langsung. Contoh 630000655100741000 | |||
| Alasan penolakan RejectionReason | Kode atau teks yang menjelaskan alasan faktur ditolak dalam alur kerja persetujuan. | ||
| Deskripsi Saat menolak faktur, pemberi persetujuan sebaiknya menyertakan alasannya. Alasannya dapat berupa kode standar atau komentar bebas yang menunjukkan masalah, seperti 'Nomor PO tidak benar', 'Faktur duplikat', atau 'Jumlah tidak benar'. Data ini penting untuk dashboard 'Invoice Rejection Reasons & Trends'. Dengan menganalisis frekuensi setiap alasan penolakan, bisnis dapat menemukan masalah yang sering terjadi dan mengambil tindakan perbaikan. Misalnya, jika 'Nomor PO tidak benar' sering muncul, komunikasi dengan vendor mungkin perlu ditingkatkan atau staf entri data perlu mendapat pelatihan. Analisis ini membantu mengurangi pekerjaan ulang dalam proses. Mengapa ini penting Atribut ini menunjukkan penyebab utama penolakan, sehingga perbaikan proses dapat dilakukan secara terarah untuk mengurangi pekerjaan ulang dan meningkatkan tingkat penyelesaian yang benar sejak awal. Sumber data Informasi ini sering kali tidak tersimpan dalam satu kolom standar. Data mungkin terdapat di log kontainer workflow, kolom teks panjang yang terkait dengan dokumen, atau kolom khusus dalam solusi workflow kustom. Contoh DUPLICATE_INVWRONG_AMTNO_PO_MATCH | |||
| Diskon tunai tidak dimanfaatkan IsCashDiscountLost | Penanda hasil perhitungan yang menunjukkan apakah diskon tunai yang tersedia tidak dimanfaatkan. | ||
| Deskripsi Atribut boolean ini dihitung berdasarkan ketentuan pembayaran dan tanggal pembayaran aktual. Nilainya true jika 'Payment Terms' menawarkan diskon untuk pembayaran lebih awal, tetapi 'Clearing Date' jatuh setelah periode diskon berakhir. Atribut ini mengukur langsung kerugian keuangan akibat proses yang tidak efisien. Atribut ini menjadi dasar dashboard 'Cash Discount Opportunity Loss'. Atribut ini memudahkan penghitungan dampak keuangan dari keterlambatan pemrosesan. Dengan memfilter kasus yang bernilai true, analis dapat menyelidiki varian proses dan hambatan yang paling sering menyebabkan diskon terlewat. Hasilnya dapat menjadi dasar yang kuat untuk perbaikan proses. Mengapa ini penting Atribut ini mengukur langsung kerugian keuangan akibat keterlambatan proses dan memperkuat alasan untuk mengoptimalkan alur kerja pemrosesan faktur. Sumber data Atribut ini tidak tersedia di SAP. Nilainya dihitung saat transformasi data dengan menafsirkan 'PaymentTerms' dan membandingkan 'ClearingDate' dengan tanggal jatuh tempo diskon. Contoh truefalse | |||
| Jenis dokumen DocumentType | Kode yang mengelompokkan dokumen akuntansi, misalnya sebagai faktur vendor atau nota kredit. | ||
| Deskripsi Document Type digunakan untuk mengelompokkan berbagai jenis transaksi bisnis di SAP. Dalam pemrosesan faktur, jenis yang umum antara lain 'RE' untuk faktur standar dan 'KG' untuk nota kredit vendor. Jenis dokumen mengatur beberapa aspek pembukuan, seperti rentang nomor yang digunakan. Dalam analisis, atribut ini dapat digunakan untuk memfilter proses berdasarkan jenis transaksi tertentu. Misalnya, proses penanganan nota kredit bisa sangat berbeda dari proses faktur standar. Memisahkan alur berdasarkan Document Type menghasilkan gambaran proses yang lebih akurat dan bermakna. Mengapa ini penting Atribut ini memungkinkan pemisahan dan analisis berbagai transaksi bisnis, seperti faktur dan nota kredit, yang mengikuti proses berbeda. Sumber data Ini adalah kolom 'Document Type' (BLART) dari tabel header dokumen faktur RBKP. Contoh REKRKG | |||
| Ketentuan pembayaran PaymentTerms | Kode yang menetapkan ketentuan pembayaran yang disepakati dengan vendor, seperti periode diskon dan tanggal jatuh tempo. | ||
| Deskripsi Payment Terms menetapkan batas waktu pembayaran faktur dan diskon tunai yang tersedia jika pembayaran dilakukan lebih awal. Contohnya, 'Net 30 days' atau '2% 10, Net 30'. Artinya, pembayaran dalam 10 hari mendapat diskon 2%; jika tidak, jumlah penuh harus dibayar dalam 30 hari. Atribut ini menjadi dasar dashboard 'Cash Discount Opportunity Loss' dan KPI 'Cash Discount Capture Rate'. Analisis menggunakan ketentuan pembayaran bersama tanggal pembukuan dan pembayaran untuk menentukan apakah diskon tersedia dan berhasil dimanfaatkan. Atribut ini juga penting untuk dashboard Payment Terms Adherence. Mengapa ini penting Atribut ini penting untuk menganalisis tingkat pemanfaatan diskon tunai dan memahami dampak keuangan dari keterlambatan proses. Sumber data Ini adalah kolom 'Terms of Payment Key' (ZTERM) dari tabel header dokumen faktur RBKP. Contoh Z0010001NT30 | |||
| Kode perusahaan CompanyCode | Identitas badan hukum atau perusahaan tempat faktur diproses. | ||
| Deskripsi Company Code adalah unit organisasi dasar di SAP Financials yang mewakili badan hukum independen. Semua transaksi keuangan, termasuk faktur, dibukukan ke kode perusahaan tertentu. Atribut ini memungkinkan analisis proses dipilah berdasarkan badan hukum. Atribut ini penting untuk membandingkan kinerja proses, kepatuhan, dan efisiensi antarperusahaan dalam satu grup. Filter Company Code pada dashboard menampilkan KPI pemrosesan faktur untuk perusahaan tertentu. Mengapa ini penting Atribut ini memungkinkan perbandingan proses dan tolok ukur kinerja antar badan hukum dalam organisasi. Sumber data Ini adalah kolom 'Company Code' (BUKRS) dari tabel header dokumen faktur RBKP. Contoh 10002000US01 | |||
| Mata uang Currency | Kode mata uang untuk nilai invoice. | ||
| Deskripsi Atribut Currency menunjukkan mata uang yang digunakan untuk menyatakan nilai faktur, misalnya USD, EUR, atau JPY. Atribut ini memberi konteks penting untuk Invoice Amount. Dengan begitu, data keuangan dapat ditafsirkan dan dijumlahkan dengan tepat, terutama di organisasi global yang menggunakan beberapa mata uang. Analisis dapat difilter berdasarkan mata uang untuk membandingkan efisiensi pemrosesan atau masalah di berbagai wilayah mata uang. Agar penjumlahan keuangan bermakna, nilai mungkin perlu dikonversi ke satu mata uang pelaporan. Mengapa ini penting Atribut ini memberi konteks yang diperlukan untuk setiap nilai keuangan, sehingga dapat ditafsirkan dengan tepat serta difilter dan dianalisis berdasarkan mata uang. Sumber data Ini adalah kolom 'Currency Key' (WAERS) dari tabel header dokumen faktur RBKP. Contoh USDEURGBP | |||
| Pembaruan data terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data proses terakhir kali diperbarui dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu ekstraksi atau pembaruan data terakhir. Atribut ini berlaku untuk seluruh kumpulan data, bukan untuk setiap peristiwa, sehingga menunjukkan dengan jelas seberapa baru data tersebut. Metadata ini penting bagi pengguna dashboard dan analis. Atribut ini membantu mereka memahami periode yang tercakup dalam analisis dan memastikan keputusan dibuat berdasarkan informasi terbaru. Biasanya, informasi ini ditampilkan dengan jelas di dashboard agar pengguna tahu kapan data terakhir diperbarui. Mengapa ini penting Atribut ini memberi tahu pengguna seberapa baru data yang tersedia, sehingga analisis dan keputusan menggunakan informasi terkini. Sumber data Nilai ini dibuat dan dimasukkan ke dalam kumpulan data oleh alat ekstraksi data atau ETL saat data diperbarui. Contoh 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z | |||
| Sistem sumber SourceSystem | Menunjukkan sistem sumber tempat data diekstrak. | ||
| Deskripsi Atribut Sistem sumber menunjukkan asal data peristiwa, misalnya nama instans SAP ECC tertentu. Atribut ini sangat penting jika Anda menggunakan beberapa sistem ERP atau menggabungkan data dari berbagai sumber. Dalam analisis, atribut ini membantu membandingkan proses dan kinerja di berbagai sistem, wilayah, atau unit bisnis yang mungkin menggunakan instans terpisah. Atribut ini memperjelas asal-usul data dan memungkinkan pemfilteran serta analisis khusus untuk setiap sistem. Mengapa ini penting Atribut ini memberi konteks penting saat Anda menggunakan beberapa sistem, sehingga data dapat dipisahkan dengan tepat dan kinerja tiap sistem dapat dianalisis. Sumber data Biasanya, nilai statis ini ditambahkan saat ekstraksi data. Nilai tersebut menunjukkan ID Sistem SAP (TADIR-SRCSYSTEM) atau pengenal yang ditetapkan secara manual untuk instans SAP tertentu. Contoh SAPECC_PROD_EUECC_US_FINSAP_ERP_6_EHP8 | |||
| Terlambat dibayar IsOverdue | Penanda hasil perhitungan yang menunjukkan apakah faktur dibayar setelah tanggal jatuh tempo. | ||
| Deskripsi Atribut boolean ini dihitung dengan membandingkan 'Clearing Date' (tanggal pembayaran aktual) dengan 'Payment Due Date'. Jika tanggal pelunasan melewati tanggal jatuh tempo, nilainya true; jika tidak, nilainya false. Atribut ini memberikan ukuran langsung dan sederhana untuk kinerja pembayaran tepat waktu setiap faktur. Atribut ini memudahkan analisis dan visualisasi di dashboard. Anda dapat memfilter dan mengelompokkan data untuk menghitung KPI 'On-Time Payment Rate'. Pengguna dapat dengan cepat membandingkan alur proses faktur yang terlambat dengan yang dibayar tepat waktu, lalu menemukan pola proses yang mungkin menyebabkan keterlambatan. Mengapa ini penting Atribut ini memudahkan analisis kinerja pembayaran tepat waktu dan perbandingan proses faktur yang dibayar tepat waktu dengan yang terlambat. Sumber data Atribut ini tidak tersedia di SAP. Nilainya dihitung saat transformasi data menggunakan rumus: ClearingDate > PaymentDueDate. Contoh truefalse | |||
| Waktu selesai EndTime | Stempel waktu yang menunjukkan kapan suatu aktivitas selesai. Untuk peristiwa yang terjadi seketika, nilainya sama dengan waktu mulai. | ||
| Deskripsi Atribut Waktu selesai menandai selesainya suatu aktivitas. Banyak peristiwa di SAP dicatat sebagai satu titik waktu, sehingga waktu selesai sama dengan waktu mulai. Namun, untuk aktivitas yang memiliki durasi terukur, seperti tahap persetujuan yang sedang dikerjakan, atribut ini dapat menunjukkan kapan pekerjaan tersebut selesai. Dalam analisis proses, waktu selesai yang terpisah memungkinkan Anda mengukur waktu pemrosesan aktivitas, bukan hanya waktu tunggu sebelumnya. Dengan begitu, Anda dapat membedakan waktu yang diperlukan untuk menyelesaikan aktivitas dari waktu kasus menunggu aktivitas dimulai, sehingga efisiensi sumber daya dapat dianalisis lebih mendalam. Mengapa ini penting Atribut ini memungkinkan penghitungan waktu pemrosesan aktivitas, membedakannya dari waktu tunggu antaraktivitas, dan membantu analisis hambatan. Sumber data Sering kali nilainya sama dengan waktu mulai dan diperoleh dari CDHDR-UDATE serta CDHDR-UTIME. Dalam beberapa kasus, nilainya dapat diambil dari log workflow yang mencatat waktu mulai dan selesai tugas secara eksplisit. Contoh 2023-03-15T10:35:10Z2023-03-16T14:10:00Z2023-03-28T09:02:45Z | |||
Aktivitas pemrosesan faktur Procure to Pay
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Data invoice direkam | Menandai pembuatan awal dokumen invoice di SAP, baik sebagai dokumen parkir maupun dokumen yang sudah dibukukan. Biasanya, ini adalah peristiwa pertama yang tercatat di sistem dalam siklus invoice dan menjadi waktu mulai proses. | ||
| Mengapa ini penting Aktivitas ini menjadi titik awal utama untuk mengukur waktu siklus pemrosesan invoice dari awal hingga akhir. Dengan menganalisis durasi sejak titik ini, Anda dapat menemukan keterlambatan pada tahap awal entri data dan pembuatan dokumen. Sumber data Stempel waktu pembuatan tercatat di tabel SAP BKPF, pada kolom CPUDT (tanggal dokumen akuntansi dimasukkan) dan CPUTM (waktu entri). Pengumpulan data Gunakan stempel waktu pembuatan dokumen dari header tabel BKPF (CPUDT). Jenis peristiwa explicit | |||
| Invoice dibalik | Menandai pembatalan dokumen invoice yang sudah dibukukan. Dokumen pembalik dibuat untuk meniadakan dampak keuangan dari invoice asli. | ||
| Mengapa ini penting Aktivitas ini menandai pengecualian penting dan jalur pengerjaan ulang. Dengan menganalisis frekuensi dan alasan pembalikan, Anda dapat menemukan masalah sistemik dalam validasi dan pembukuan invoice. Sumber data Peristiwa ini tercatat secara eksplisit di tabel header dokumen BKPF. Header dokumen yang dibalik berisi nomor dokumen pembalik (STBLG) dan tahun fiskal (STJAH). Pengumpulan data Temukan dokumen yang kolom BKPF-STBLG-nya terisi. Stempel waktu peristiwa menggunakan tanggal pembukuan dokumen pembalik. Jenis peristiwa explicit | |||
| Invoice dibukukan | Ini adalah peristiwa keuangan penting saat invoice resmi dicatat di buku besar dan menimbulkan kewajiban. Dokumen berubah dari status sementara (diparkir) menjadi entri akuntansi permanen. | ||
| Mengapa ini penting Pembukuan menjadi tonggak penting yang menegaskan keabsahan invoice. Pembukuan merupakan prasyarat pembayaran dan indikator utama kelancaran pemrosesan. Sumber data Peristiwa ini tercatat secara eksplisit di tabel header dokumen BKPF. Stempel waktunya adalah tanggal pembukuan, BKPF-BUDAT. Status dokumen tidak lagi 'diparkir'. Pengumpulan data Gunakan tanggal pembukuan (BKPF-BUDAT) untuk dokumen yang tidak diparkir (BKPF-BSTAT kosong atau ' '). Jenis peristiwa explicit | |||
| Invoice dilunasi | Aktivitas ini menandai tahap akhir siklus invoice yang berhasil, saat kewajiban terbuka dilunasi melalui dokumen pembayaran. Ini menunjukkan bahwa pembayaran telah dilakukan. | ||
| Mengapa ini penting Sebagai peristiwa akhir utama, aktivitas ini penting untuk menghitung total waktu siklus dari awal hingga akhir. Aktivitas ini memastikan proses telah selesai dan digunakan untuk mengukur kinerja pembayaran tepat waktu. Sumber data Peristiwa ini tercatat secara eksplisit di tabel item baris invoice BSEG. Tanggal pelunasan tersimpan di kolom AUGDT, sedangkan nomor dokumen pelunasan tersimpan di AUGBL. Pengumpulan data Gunakan tanggal pelunasan (BSEG-AUGDT) dari item baris dokumen invoice. Jenis peristiwa explicit | |||
| Pemblokiran pembayaran diterapkan | Aktivitas ini terjadi saat pemblokiran diterapkan pada item baris invoice sehingga item tersebut tidak dapat dibayar. Pemblokiran dapat diterapkan otomatis karena ketidaksesuaian dalam pencocokan tiga arah atau secara manual karena berbagai alasan. | ||
| Mengapa ini penting Peristiwa ini penting untuk mengukur durasi penyelesaian pemblokiran pembayaran dan menemukan akar penyebab keterlambatan pembayaran. Data ini menyoroti masalah harga, kuantitas, atau persetujuan yang diperlukan. Sumber data Peristiwa ini tercatat secara eksplisit di log dokumen perubahan, yaitu tabel CDHDR dan CDPOS, untuk kolom ZLSPR (kunci pemblokiran pembayaran) pada tabel BSEG. Pengumpulan data Stempel waktu dari dokumen perubahan (CDHDR) saat nilai BSEG-ZLSPR berubah dari kosong menjadi terisi. Jenis peristiwa explicit | |||
| Invoice dikirim untuk disetujui | Menandai saat invoice diajukan ke alur kerja persetujuan formal. Cara merekamnya sangat bergantung pada penerapan SAP Workflow atau sistem pihak ketiga yang digunakan. | ||
| Mengapa ini penting Aktivitas ini memulai pengukuran KPI waktu siklus persetujuan invoice. Data ini penting untuk menemukan keterlambatan dalam rangkaian persetujuan dan menganalisis kinerja pemberi persetujuan. Sumber data Peristiwa ini biasanya diambil dari tabel SAP Business Workflow, seperti SWW_WI2OBJ dan SWWLOG, dengan mencari awal tugas persetujuan tertentu. Dalam skenario yang lebih sederhana, peristiwa ini dapat disimpulkan dari perubahan status pada kolom khusus. Pengumpulan data Perlu menganalisis log SAP Workflow atau kolom status khusus yang terhubung dengan dokumen invoice. Jenis peristiwa inferred | |||
| Invoice diparkir | Menunjukkan bahwa invoice sudah dimasukkan ke SAP, tetapi belum dibukukan ke buku besar. Status sementara ini memungkinkan invoice ditinjau, dikoreksi, atau disetujui sebelum pembukuan keuangan. | ||
| Mengapa ini penting Dengan melacak kapan invoice diparkir dan berapa lama status ini berlangsung, Anda dapat menemukan hambatan dalam validasi dan persetujuan sebelum pembukuan. Data ini juga memisahkan waktu entri data dari waktu pemrosesan keuangan. Sumber data Status ini disimpulkan dari kolom BSTAT pada tabel BKPF. Nilai 'V' (dokumen parkir) atau 'W' (dokumen parkir dengan persetujuan perubahan) menunjukkan bahwa dokumen sedang diparkir. Pengumpulan data Temukan dokumen dengan nilai 'V' pada kolom status BKPF-BSTAT. Stempel waktu peristiwanya menggunakan tanggal pembuatan BKPF-CPUDT. Jenis peristiwa inferred | |||
| Invoice disetujui | Menandakan bahwa pihak berwenang telah menyetujui invoice secara resmi sehingga invoice dapat dilanjutkan ke pembukuan dan pembayaran. Ini sering menjadi tahap akhir dalam alur kerja. | ||
| Mengapa ini penting Tonggak ini mengakhiri pengukuran waktu siklus persetujuan. Persetujuan membuka jalan bagi pembayaran tepat waktu dan membantu menganalisis pembagian beban kerja di antara para pemberi persetujuan. Sumber data Peristiwa ini biasanya diambil dari tabel SAP Business Workflow dengan mencari penyelesaian tugas persetujuan. Alternatifnya, peristiwa ini dapat disimpulkan dari pelepasan pemblokiran pembayaran yang terkait dengan persetujuan. Pengumpulan data Stempel waktu penyelesaian tahap persetujuan dalam log workflow atau waktu penghapusan pemblokiran pembayaran tertentu. Jenis peristiwa inferred | |||
| Invoice ditolak | Menunjukkan bahwa invoice ditolak selama proses persetujuan. Biasanya, invoice perlu dikoreksi dan diajukan kembali sehingga terjadi pengerjaan ulang. | ||
| Mengapa ini penting Melacak penolakan penting untuk menemukan penyebab umum, seperti data yang salah atau pelanggaran kebijakan. Data ini membantu mengukur pengerjaan ulang dan menentukan bagian yang perlu diperbaiki atau menjadi sasaran edukasi vendor. Sumber data Peristiwa ini biasanya tercatat sebagai tahap penolakan dalam log SAP Business Workflow. Peristiwa ini juga dapat disimpulkan dari perubahan status tertentu atau catatan yang ditambahkan ke dokumen invoice. Pengumpulan data Stempel waktu tahap penolakan dalam log workflow atau perubahan status dokumen yang menunjukkan penolakan. Jenis peristiwa inferred | |||
| Invoice jatuh tempo | Peristiwa hasil perhitungan yang terjadi saat tanggal saat ini melewati tanggal jatuh tempo bersih invoice dan invoice belum dibayar. Tanggal jatuh tempo ditentukan berdasarkan ketentuan pembayaran dan tanggal dasar. | ||
| Mengapa ini penting Aktivitas ini penting untuk memantau KPI tingkat pembayaran tepat waktu. Aktivitas ini menandai lebih awal invoice yang berisiko terlambat dibayar, yang dapat merusak hubungan dengan vendor dan menimbulkan denda. Sumber data Peristiwa ini dihitung dengan membandingkan tanggal saat ini dengan tanggal jatuh tempo bersih. Tanggal jatuh tempo ditentukan dari tanggal dasar (BSEG-ZFBDT) dan ketentuan pembayaran (BSEG-ZTERM). Pengumpulan data Peristiwa dipicu saat Jenis peristiwa calculated | |||
| Pemblokiran pembayaran dilepas | Menandai penghapusan pemblokiran pembayaran dari item baris invoice sehingga item tersebut dapat dilanjutkan ke proses pembayaran. Ini menunjukkan bahwa masalah yang sebelumnya ditemukan telah diselesaikan. | ||
| Mengapa ini penting Aktivitas ini mengakhiri pengukuran durasi pemblokiran. Dengan menganalisis waktu antara penerapan dan pelepasan pemblokiran, Anda dapat mengetahui efisiensi proses penyelesaian masalah. Sumber data Peristiwa ini dilacak melalui log dokumen perubahan, yaitu tabel CDHDR dan CDPOS, untuk kolom ZLSPR (kunci pemblokiran pembayaran) pada tabel BSEG saat pemblokiran dihapus. Pengumpulan data Stempel waktu dari dokumen perubahan (CDHDR) saat nilai BSEG-ZLSPR berubah dari terisi menjadi kosong. Jenis peristiwa explicit | |||
Panduan ekstraksi
Langkah
- Buat program ABAP: Gunakan transaksi
SE38atauSE80untuk membuat program baru yang dapat dijalankan, misalnyaZ_PM_INVOICE_EXTRACT. Beri judul yang sesuai dan tetapkan jenisnya sebagai 'Executable Program'. - Tentukan layar seleksi: Di dalam program, buat layar seleksi agar pengguna dapat memfilter data. Parameter utama mencakup Company Code (
BUKRS), Fiscal Year (GJAHR), rentang Posting Date (BUDAT), dan lokasi file keluaran di server aplikasi. - Deklarasikan struktur data: Tentukan struktur tabel internal untuk menampung log peristiwa akhir. Struktur ini harus mencakup semua atribut yang diperlukan dan disarankan:
InvoiceNumber,Aktivitas,EventTime,UserName,VendorNumber,PurchaseOrderNumber,InvoiceAmount,PostingDate,PaymentDueDate,PaymentBlockReason, danClearingDate. - Terapkan logika pemilihan data: Tulis logika inti ABAP untuk memilih data faktur. Caranya, ambil data melalui beberapa kueri, lalu gabungkan hasilnya ke dalam tabel log peristiwa akhir.
- Pertama, pilih data header dan item dari tabel faktur utama
BKPF,BSEG,RBKP, danRSEGberdasarkan kriteria di layar seleksi. - Untuk setiap faktur, buat peristiwa dasar seperti 'Invoice Data Captured' (dari stempel waktu pembuatan) dan 'Invoice Posted' (dari stempel waktu posting).
- Periksa tabel dokumen perubahan
CDHDRdanCDPOSuntuk menemukan perubahan terkait blokir pembayaran (kolomZLSPRdiBSEG). Buat peristiwa 'Payment Block Set' dan 'Payment Block Released' untuk setiap perubahan yang relevan. - Identifikasi peristiwa 'Invoice Cleared' dengan memeriksa dokumen kliring (
AUGBL) dan tanggal kliring (AUGDT) di tabelBSEG. - Identifikasi peristiwa 'Invoice Reversed' dengan memeriksa dokumen pembalik (
STBLG) di headerBKPF. - Terapkan logika khusus untuk mencatat peristiwa alur kerja ('Invoice Sent For Approval', 'Approved', 'Rejected'). Bagian ini sangat bergantung pada konfigurasi pelanggan, sehingga kode perlu disesuaikan dengan tabel atau kolom status alur kerja Anda.
- Pertama, pilih data header dan item dari tabel faktur utama
- Buat peristiwa hasil perhitungan: Di dalam logika program, hitung peristiwa
Invoice Becomes Overdue. Bandingkan tanggal jatuh tempo pembayaran faktur (PaymentDueDate) dengan tanggal saat ini untuk semua faktur yang belum dibayar. Jika tanggal jatuh tempo sudah lewat, buat peristiwa denganEventTimeyang sama dengan tanggal jatuh tempo. - Isi tabel log peristiwa: Saat mengumpulkan data setiap faktur dari berbagai sumber, format data tersebut dan tambahkan baris baru ke tabel internal log peristiwa akhir, satu baris untuk setiap aktivitas.
- Ekspor data ke file: Gunakan pernyataan
OPEN DATASET,TRANSFER, danCLOSE DATASETuntuk menulis isi tabel internal akhir ke file datar di lokasi server aplikasi SAP yang ditentukan pada layar seleksi. Gunakan pemisah yang konsisten, seperti titik koma atau tab, untuk membuat file CSV. - Jadwalkan ekstraksi: Untuk ekstraksi rutin, buat varian program dengan kriteria seleksi yang diinginkan, lalu jadwalkan sebagai tugas latar belakang menggunakan transaksi
SM36. - Ambil file keluaran: Akses direktori server aplikasi SAP menggunakan transaksi
AL11untuk menemukan file yang dibuat. Gunakan transaksiCG3Yuntuk mengunduh file dari server aplikasi ke komputer Anda. - Siapkan file untuk diunggah: Sebelum mengunggah file ke alat process mining, buka CSV untuk memastikan header sudah benar, format data konsisten, terutama untuk stempel waktu, dan pemisahnya sesuai. Pastikan file disimpan dengan encoding UTF-8.
Konfigurasi
- Kriteria seleksi: Laporan ABAP harus memiliki layar seleksi yang memadai. Filter terpenting meliputi:
Company Code (BUKRS): Membatasi ekstraksi ke entitas hukum tertentu.Posting Date (BUDAT): Menentukan rentang waktu ekstraksi. Sebaiknya ekstrak data dalam rentang yang mudah dikelola, misalnya 3 hingga 6 bulan setiap kali.Document Type (BLART): Memilih hanya jenis dokumen faktur yang relevan, seperti 'RE' untuk faktur logistik dan 'KR' untuk faktur vendor.
- Jalur file keluaran: Parameter wajib untuk menentukan jalur lengkap dan nama file di server aplikasi SAP tempat file keluaran akan dibuat. Pengguna yang menjalankan laporan harus memiliki izin menulis ke direktori tersebut.
- Pertimbangan kinerja: Untuk kumpulan data besar, jalankan laporan sebagai pekerjaan latar belakang di luar jam sibuk agar kinerja sistem tidak terganggu. Pilih hanya kolom yang diperlukan dari tabel dan gunakan indeks basis data SAP standar jika tersedia.
- Prasyarat dan otorisasi: Pengguna atau akun layanan yang menjalankan ekstraksi memerlukan:
- Izin untuk menjalankan laporan ABAP (bagian dari
S_PROGRAM). - Akses baca ke tabel keuangan dan logistik, termasuk
BKPF,BSEG,RBKP,RSEG,CDHDR, danCDPOS. - Izin untuk menulis file ke direktori server aplikasi yang ditentukan (
S_DATASET). - Akses ke transaksi
SE38,SM36,AL11, danCG3Yuntuk pengembangan, penjadwalan, dan pengambilan file.
- Izin untuk menjalankan laporan ABAP (bagian dari
Contoh kueri abap
REPORT Z_PM_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables for Selection Screen
*&---------------------------------------------------------------------*
TABLES: BKPF, RBKP.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
InvoiceNumber TYPE belnr_v,
Activity TYPE string,
EventTime TYPE timestamp,
UserName TYPE uname,
VendorNumber TYPE lifnr,
PurchaseOrderNumber TYPE ebeln,
InvoiceAmount TYPE wrbtr,
PostingDate TYPE budat,
PaymentDueDate TYPE faedt,
PaymentBlockReason TYPE rstgr,
ClearingDate TYPE augdt,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_bkpf TYPE bkpf,
lt_bseg TYPE TABLE OF bseg,
ls_bseg TYPE bseg.
DATA: lt_rbkp TYPE TABLE OF rbkp,
ls_rbkp TYPE rbkp.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_gjahr FOR bkpf-gjahr OBLIGATORY,
s_budat FOR bkpf-budat.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/tmp/invoice_events.csv'.
*&---------------------------------------------------------------------*
*& Start of Program Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Select FI Invoices (e.g., Doc Type KR)
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND gjahr IN s_gjahr
AND budat IN s_budat
AND blart = 'KR'.
" Select MM Invoices
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND gjahr IN s_gjahr
AND budat IN s_budat.
* --- Process FI Invoices ---
LOOP AT lt_bkpf INTO ls_bkpf.
CLEAR gs_event_log.
gs_event_log-InvoiceNumber = ls_bkpf-belnr.
gs_event_log-PostingDate = ls_bkpf-budat.
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = ls_bkpf-bukrs
AND belnr = ls_bkpf-belnr
AND gjahr = ls_bkpf-gjahr
AND koart = 'K'. " Vendor Line Item
IF sy-subrc = 0.
gs_event_log-VendorNumber = ls_bseg-lifnr.
gs_event_log-InvoiceAmount = ls_bseg-wrbtr.
gs_event_log-ClearingDate = ls_bseg-augdt.
" Calculate Due Date
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_bseg = ls_bseg
IMPORTING
e_faedt = gs_event_log-PaymentDueDate.
ENDIF.
" Activity: Invoice Data Captured
gs_event_log-Activity = 'Invoice Data Captured'.
CONVERT DATE ls_bkpf-cpudt TIME ls_bkpf-cputm INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Parked (if BSTAT = 'V')
IF ls_bkpf-bstat = 'V'.
gs_event_log-Activity = 'Invoice Parked'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Posted
gs_event_log-Activity = 'Invoice Posted'.
CONVERT DATE ls_bkpf-budat TIME ls_bkpf-cputm INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Cleared
IF ls_bseg-augbl IS NOT INITIAL.
gs_event_log-Activity = 'Invoice Cleared'.
CONVERT DATE ls_bseg-augdt INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_bseg-usnam_cl.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Becomes Overdue
IF gs_event_log-PaymentDueDate IS NOT INITIAL AND gs_event_log-PaymentDueDate < sy-datum AND ls_bseg-augbl IS INITIAL.
gs_event_log-Activity = 'Invoice Becomes Overdue'.
CONVERT DATE gs_event_log-PaymentDueDate INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = 'SYSTEM'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Reversed
IF ls_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE budat, usnam FROM bkpf INTO ls_rev_bkpf
WHERE belnr = ls_bkpf-stblg AND bukrs = ls_bkpf-bukrs AND gjahr = ls_bkpf-gjahr.
IF sy-subrc = 0.
gs_event_log-Activity = 'Invoice Reversed'.
CONVERT DATE ls_rev_bkpf-budat INTO TIME STAMP gs_event_log-EventTime TIME ZONE sy-zonlo.
gs_event_log-UserName = ls_rev_bkpf-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDLOOP.
* --- NOTE: The logic for MM invoices (from lt_rbkp) would be similar, joining RBKP with RSEG.
* --- NOTE: The logic for Payment Blocks and Workflow events requires reading change documents (CDHDR/CDPOS)
* --- or custom workflow tables. Below is a conceptual example for payment blocks.
* --- Conceptual Example for 'Payment Block Set' / 'Released' using Change Docs
* DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_cdhdr TYPE cdhdr,
* lt_cdpos TYPE TABLE OF cdpos, ls_cdpos TYPE cdpos.
* SELECT * FROM cdhdr INTO TABLE lt_cdhdr
* WHERE objectclas = 'BELEG' AND objectid IN (SELECT belnr FROM bkpf WHERE ...).
* LOOP AT lt_cdhdr.
* SELECT * FROM cdpos INTO TABLE lt_cdpos
* WHERE changenr = ls_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
* LOOP AT lt_cdpos.
* "... logic to create 'Payment Block Set' (if VALUE_NEW is not blank)
* "... or 'Payment Block Released' (if VALUE_NEW is blank) events.
* ENDLOOP.
* ENDLOOP.
* --- Conceptual Example for Workflow events ('Sent For Approval', 'Approved', 'Rejected')
* --- This part MUST be customized based on your specific workflow implementation (e.g., OpenText VIM, SAP WF).
* --- You would query the relevant workflow tables or status change tables here.
*&---------------------------------------------------------------------*
*& Write to File
*&---------------------------------------------------------------------*
END-OF-SELECTION.
DATA: lv_string TYPE string,
lv_header TYPE string.
" Create Header
lv_header = 'InvoiceNumber;Activity;EventTime;UserName;VendorNumber;PurchaseOrderNumber;InvoiceAmount;PostingDate;PaymentDueDate;PaymentBlockReason;ClearingDate'.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
TRANSFER lv_header TO p_fpath.
LOOP AT gt_event_log INTO gs_event_log.
CONCATENATE gs_event_log-InvoiceNumber
gs_event_log-Activity
gs_event_log-EventTime
gs_event_log-UserName
gs_event_log-VendorNumber
gs_event_log-PurchaseOrderNumber
gs_event_log-InvoiceAmount
gs_event_log-PostingDate
gs_event_log-PaymentDueDate
gs_event_log-PaymentBlockReason
gs_event_log-ClearingDate
INTO lv_string SEPARATED BY ';'.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
ELSE.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF. Siap memulai?
Gunakan templat ini untuk menemukan wawasan penting dan mendorong perbaikan nyata dalam pemrosesan faktur Procure to Pay. Mulai ekstrak data hari ini untuk meningkatkan operasional Anda.
Tingkatkan pemrosesan faktur Procure to Pay sekarang
Temukan inefisiensi dan pangkas waktu siklus faktur hingga 30%.
Tidak perlu kartu kredit. Penyiapan hanya beberapa menit.