Templat data Purchase to Pay - Requisition Anda
Templat data Purchase to Pay - Requisition Anda
- Atribut yang disarankan untuk analisis terperinci
- Aktivitas utama yang perlu dilacak untuk menemukan proses
- Panduan ekstraksi data dari SAP S/4HANA
Atribut Purchase to Pay - Requisition
| Nama | Deskripsi | ||
|---|---|---|---|
| ID permintaan pembelian PurchaseRequisitionId | Pengenal unik untuk dokumen permintaan pembelian. | ||
| Deskripsi ID permintaan pembelian adalah kunci utama yang membedakan setiap permintaan barang atau jasa di SAP S/4HANA. ID ini menjadi pengenal utama untuk kasus tersebut dan menghubungkan semua aktivitas serta perubahan terkait, mulai dari pembuatan hingga status akhir, seperti disetujui, ditolak, atau dikonversi menjadi pesanan pembelian. Dalam process mining, atribut ini menjadi dasar untuk menyusun kembali siklus hidup setiap permintaan dari awal hingga akhir. Dengan mengelompokkan semua peristiwa terkait berdasarkan satu ID permintaan pembelian, analis dapat mengukur waktu siklus secara akurat, melacak perubahan status, dan menganalisis berbagai jalur yang dilalui permintaan selama proses persetujuan. Mengapa ini penting Pengenal kasus utama ini menghubungkan semua langkah proses terkait sehingga siklus hidup permintaan pembelian dapat dilihat secara utuh dan runtut. Sumber data Ini adalah Nomor Permintaan Pembelian yang terdapat pada tabel EBAN, kolom BANFN. Contoh 100178901001789110017892 | |||
| Nama aktivitas ActivityName | Nama aktivitas bisnis yang terjadi pada tahap tertentu dalam proses permintaan pembelian. | ||
| Deskripsi Nama Aktivitas menjelaskan peristiwa atau tugas tertentu dalam siklus hidup permintaan pembelian. Aktivitas ini diambil dari log sistem, seperti dokumen perubahan dan riwayat alur kerja, lalu menunjukkan tonggak penting dalam proses, misalnya 'Permintaan pembelian dibuat', 'Tahap persetujuan dimulai', atau 'Pesanan pembelian dibuat'. Analisis aktivitas membantu memvisualisasikan alur proses, menemukan hambatan, dan mengukur waktu yang dihabiskan pada setiap tahap. Memahami urutan dan frekuensi aktivitas seperti 'Permintaan pembelian diubah' atau 'Permintaan pembelian ditolak' penting untuk menemukan ketidakefisienan dan peluang perbaikan proses. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam proses. Langkah tersebut menjadi dasar peta proses dan memungkinkan analisis alur, variasi, serta hambatan. Sumber data Atribut ini diturunkan dengan menafsirkan data dari tabel dokumen perubahan (CDHDR, CDPOS) dan log alur kerja (misalnya SWWLOGHIST). Contoh Permintaan pembelian dibuatTahap persetujuan selesaiPermintaan pembelian disetujuiPesanan pembelian dibuat | |||
| Waktu peristiwa EventTime | Tanggal dan waktu tepat saat aktivitas tertentu terjadi. | ||
| Deskripsi Waktu Peristiwa adalah cap waktu yang mencatat kapan suatu aktivitas terjadi. Data ini penting untuk mengurutkan peristiwa dalam satu kasus dan menjadi dasar semua perhitungan durasi serta kinerja dalam process mining. Contohnya, selisih waktu antara peristiwa 'Permintaan pembelian diajukan' dan 'Permintaan pembelian disetujui' menunjukkan waktu siklus persetujuan. Cap waktu yang akurat penting untuk menganalisis kinerja proses, menemukan keterlambatan, dan memantau kepatuhan terhadap perjanjian tingkat layanan. Atribut ini mendukung dashboard untuk menampilkan waktu siklus, melacak permintaan yang tertahan, dan membandingkan kinerja dari waktu ke waktu. Mengapa ini penting Cap waktu ini penting untuk mengurutkan peristiwa, menghitung waktu siklus, serta menganalisis kinerja proses dan hambatan. Sumber data Cap waktu biasanya bersumber dari header dokumen perubahan (CDHDR-UDATE, CDHDR-UTIME) atau log peristiwa alur kerja. Contoh 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Departemen Department | Departemen atau pusat biaya yang menanggung biaya permintaan pembelian. | ||
| Deskripsi Atribut Departemen, yang sering diwakili oleh Pusat Biaya di SAP, menunjukkan unit bisnis yang bertanggung jawab atas pembelian yang diminta. Informasi keuangan dan organisasi ini penting dan ditetapkan pada tingkat item permintaan. Dalam process mining, atribut ini penting untuk menganalisis kinerja tiap departemen. Atribut ini mendukung dashboard untuk membandingkan metrik utama, seperti waktu siklus, tingkat perubahan, dan tingkat penolakan antar departemen. Analisis ini membantu menemukan departemen berkinerja baik yang praktiknya dapat diterapkan di tempat lain, serta departemen yang mungkin memerlukan pelatihan atau dukungan proses tambahan. Mengapa ini penting Memungkinkan perbandingan kinerja antar unit bisnis. Perbedaan waktu siklus atau tingkat penolakan dapat menunjukkan praktik yang baik dan area yang perlu diperbaiki. Sumber data Ini adalah Pusat Biaya, yang biasanya terdapat pada tabel penetapan akun EBKN, kolom KOSTL. Contoh FIN-1001IT-2005MKT-3010 | |||
| ID pemberi persetujuan ApproverId | Pengenal pengguna yang menyetujui atau menolak permintaan. | ||
| Deskripsi ID Pemberi Persetujuan menunjukkan secara khusus pengguna yang menyelesaikan aktivitas persetujuan atau penolakan. Berbeda dari ID Pengguna umum, atribut ini hanya berfokus pada pengambil keputusan dalam alur kerja persetujuan. Informasi ini penting untuk menganalisis proses persetujuan secara terperinci. Atribut ini membantu menganalisis perilaku persetujuan, misalnya menemukan manajer yang membutuhkan waktu lama untuk menyetujui atau sering menolak permintaan. Data ini menjadi dasar dashboard yang berfokus pada waktu siklus setiap tahap persetujuan dan analisis hambatan alur kerja. Dengan begitu, Anda dapat menemukan orang atau peran tertentu yang menyebabkan keterlambatan. Mengapa ini penting Menunjukkan pengambil keputusan pada setiap tahap persetujuan sehingga waktu siklus dan hambatan dapat dianalisis berdasarkan individu atau peran. Sumber data Informasi ini biasanya diambil dari tabel SAP Business Workflow seperti SWW_WI2OBJ dan SWWLOGHIST, yang menghubungkan item kerja dengan pengguna yang menyelesaikannya. Contoh MJOHNSONCWILLIAMSLBLACK | |||
| ID pengguna UserId | Pengenal pengguna yang membuat permintaan pembelian atau melakukan aktivitas tertentu. | ||
| Deskripsi ID Pengguna menunjukkan karyawan atau pengguna sistem yang bertanggung jawab atas suatu peristiwa dalam siklus hidup permintaan pembelian. Pengguna tersebut bisa jadi orang yang membuat permintaan, manajer yang menyetujuinya, atau petugas yang mengubahnya. Untuk langkah otomatis, ID ini dapat berupa ID pengguna sistem atau pengguna batch. Analisis berdasarkan ID Pengguna membantu memahami perilaku pengguna, pembagian beban kerja, dan kinerja. Data ini penting untuk menemukan kebutuhan pelatihan, mengenali kinerja yang baik, dan memastikan akuntabilitas dalam proses. Jika digabungkan dengan data induk pengguna, atribut ini juga mendukung analisis kinerja departemen. Mengapa ini penting Mendukung analisis kinerja pengguna, pembagian beban kerja, dan kepatuhan proses. Atribut ini penting untuk menemukan kebutuhan pelatihan dan hambatan terkait sumber daya. Sumber data ID pembuat terdapat di EBAN-ERNAM. Untuk perubahan berikutnya, ID pengguna tercatat di CDHDR-USERNAME. Untuk persetujuan, datanya terdapat di log alur kerja. Contoh JSMITHRROEWF-BATCH | |||
| Jenis permintaan pembelian RequisitionType | Kode yang mengelompokkan permintaan pembelian, misalnya untuk barang standar, jasa, atau belanja modal. | ||
| Deskripsi Jenis Permintaan Pembelian, yang juga dikenal sebagai Jenis Dokumen di SAP, adalah kolom konfigurasi penting untuk mengelompokkan permintaan pembelian. Jenis yang berbeda dapat memicu alur kerja persetujuan yang berbeda, memiliki pengaturan kolom tersendiri, dan digunakan untuk kebutuhan bisnis yang berbeda, seperti barang stok standar, jasa eksternal, atau pembelian aset. Dengan menganalisis proses berdasarkan Jenis Permintaan Pembelian, organisasi dapat memahami cara menangani berbagai jenis permintaan. Analisis ini memungkinkan perbandingan kinerja, waktu siklus, dan jalur persetujuan antar kategori. Hasilnya dapat menunjukkan jenis permintaan yang lebih atau kurang efisien dan membantu menentukan perbaikan proses yang sesuai. Mengapa ini penting Mengelompokkan permintaan untuk perbandingan, sehingga Anda dapat mengetahui apakah jenis permintaan yang berbeda memiliki alur proses, hambatan, atau waktu siklus yang berbeda. Sumber data Ini adalah kolom Jenis Dokumen pada tabel EBAN, kolom BSART. Contoh NBFORV | |||
| Nilai permintaan pembelian RequisitionAmount | Total nilai uang dari permintaan pembelian. | ||
| Deskripsi Nilai Permintaan Pembelian menunjukkan perkiraan total biaya barang atau jasa yang diminta. Nilai ini sering menentukan tingkat kerumitan dan lamanya alur kerja persetujuan. Permintaan bernilai tinggi biasanya memerlukan lebih banyak tingkat persetujuan. Analisis atribut ini memungkinkan proses dikelompokkan berdasarkan nilai. Anda dapat menjawab pertanyaan seperti, 'Apakah permintaan bernilai tinggi membutuhkan waktu lebih lama untuk disetujui?' atau 'Berapa nilai permintaan yang sering ditolak?'. Atribut ini penting untuk memahami dampak finansial dari ketidakefisienan proses. Mengapa ini penting Membantu mengelompokkan proses berdasarkan dampak finansial, yang sering berkaitan dengan kerumitan persetujuan dan waktu siklus. Atribut ini penting untuk analisis proses berdasarkan nilai. Sumber data Total nilai terdapat pada tabel EBAN, kolom GFWERT. Nilai per item terdapat pada EBAN-PREIS. Contoh 1500.0075000.50250.75 | |||
| Status permintaan pembelian RequisitionStatus | Status pemrosesan atau persetujuan terkini dari permintaan pembelian. | ||
| Deskripsi Status Permintaan Pembelian menunjukkan posisi permintaan dalam siklus hidupnya. Di SAP, status ini sering diwakili oleh Indikator Pelepasan, yang menunjukkan apakah permintaan diblokir, sedang menunggu persetujuan, disetujui sebagian, atau disetujui sepenuhnya. Status berubah seiring permintaan bergerak melalui alur kerja. Melacak status dari waktu ke waktu penting untuk memahami alur proses. Data ini membantu menemukan permintaan yang tertahan dan mengetahui berapa lama permintaan tersebut tertahan. Analisis perubahan status memberikan gambaran terperinci tentang proses persetujuan dan variasinya. Mengapa ini penting Menunjukkan posisi terkini permintaan pembelian. Informasi ini penting untuk melacak kemajuan, menemukan hambatan, dan menganalisis alur proses. Sumber data Status pelepasan biasanya ditentukan oleh Indikator Pelepasan pada tabel EBAN, kolom FRGZU. Contoh B1S | |||
| Alasan penolakan RejectionReason | Alasan yang diberikan saat permintaan pembelian ditolak. | ||
| Deskripsi Alasan Penolakan menjelaskan mengapa pemberi persetujuan menolak permintaan pembelian. Alasannya dapat berupa anggaran terlampaui, informasi yang salah, ketidakpatuhan terhadap kebijakan, atau permintaan duplikat. Informasi ini memberikan konteks penting untuk memahami kegagalan proses. Analisis alasan penolakan membantu menemukan akar penyebab ketidakefisienan proses dan pengerjaan ulang. Misalnya, jika 'Pusat Biaya Salah' sering menjadi alasan, hal ini menunjukkan perlunya pelatihan pengguna yang lebih baik atau validasi sistem. Atribut ini menjadi dasar dashboard Analisis Penolakan Permintaan dan penting untuk perbaikan proses yang terarah. Mengapa ini penting Menunjukkan akar penyebab kegagalan proses sehingga perbaikan dapat diarahkan untuk mengurangi pengerjaan ulang dan meningkatkan tingkat permintaan yang benar sejak awal. Sumber data Alasan ini sering kali tidak tersedia sebagai kolom standar. Informasinya mungkin tercatat dalam elemen kontainer alur kerja, teks panjang yang terkait dengan permintaan, atau kolom khusus. Contoh Anggaran terlampauiPemasok tidak sesuaiPermintaan duplikat | |||
| Apakah pengerjaan ulang IsRework | Penanda yang menunjukkan apakah suatu aktivitas termasuk pengerjaan ulang, misalnya perubahan setelah pengajuan. | ||
| Deskripsi Is Rework adalah penanda boolean hasil perhitungan yang mengidentifikasi aktivitas yang tidak menambah nilai atau mengulang pekerjaan. Contoh umum dalam proses ini adalah aktivitas 'Permintaan pembelian diubah' setelah permintaan diajukan untuk persetujuan, sehingga proses persetujuan harus dimulai kembali. Atribut ini penting untuk menghitung jumlah pengerjaan ulang dan dampaknya terhadap waktu siklus secara keseluruhan. Dasbor Requisition Amendment and Rework Rate menggunakan penanda ini untuk menunjukkan inefisiensi proses. Mengurangi pengerjaan ulang sering menjadi sasaran utama perbaikan proses karena dapat menghemat waktu dan tenaga secara langsung. Mengapa ini penting Menandai aktivitas yang membuang waktu atau mengulang pekerjaan, sehingga jumlah pengerjaan ulang dan dampaknya terhadap efisiensi proses dapat diukur secara langsung. Sumber data Atribut ini dihitung. Logikanya biasanya menandai setiap aktivitas 'Permintaan pembelian diubah' yang terjadi setelah aktivitas 'Permintaan pembelian diajukan untuk persetujuan' pertama sebagai pengerjaan ulang. Contoh truefalse | |||
| Diproses otomatis IsAutomated | Penanda yang menunjukkan apakah aktivitas dilakukan oleh pengguna sistem, bukan oleh manusia. | ||
| Deskripsi Atribut Is Automated adalah penanda boolean yang bernilai true jika aktivitas dijalankan oleh sistem atau pengguna batch, seperti 'WF-BATCH' untuk tindakan workflow. Atribut ini membantu membedakan langkah manual dan otomatis dalam proses. Atribut ini penting untuk mengukur tingkat otomatisasi proses permintaan pembelian dan menghitung KPI 'Automated Approval Rate'. Dengan memfilter langkah otomatis atau manual, analis dapat membandingkan efisiensinya dan menemukan peluang untuk meningkatkan otomatisasi, mengurangi waktu pemrosesan, serta mengurangi pekerjaan manual. Mengapa ini penting Membedakan aktivitas yang dilakukan manusia dan sistem. Informasi ini penting untuk mengukur tingkat otomatisasi dan menemukan peluang mengotomatisasi tugas manual. Sumber data Atribut turunan ini biasanya ditentukan dengan aturan yang memeriksa apakah User ID suatu peristiwa termasuk dalam daftar pengguna sistem atau batch yang diketahui. Contoh truefalse | |||
| Mata uang Currency | Kode mata uang untuk nilai permintaan pembelian. | ||
| Deskripsi Atribut ini menunjukkan mata uang yang digunakan untuk menyatakan nilai permintaan pembelian, misalnya USD, EUR, atau JPY. Informasi ini melengkapi atribut Nilai Permintaan Pembelian, terutama bagi organisasi multinasional yang menggunakan beberapa mata uang. Mata uang perlu diperhitungkan agar analisis dan pelaporan keuangan akurat. Sebelum menggabungkan atau membandingkan nilai permintaan, semua jumlah perlu dikonversi ke mata uang yang sama. Atribut ini diperlukan untuk melakukan konversi tersebut. Mengapa ini penting Memberikan konteks penting untuk Nilai Permintaan Pembelian sehingga analisis dan perbandingan keuangan tetap akurat saat menggunakan beberapa mata uang. Sumber data Data ini terdapat pada tabel EBAN, kolom WAERS. Contoh USDEURGBP | |||
| Nama tahap persetujuan ApprovalStepName | Nama atau keterangan khusus untuk suatu tahap persetujuan dalam workflow. | ||
| Deskripsi Nama tahap persetujuan memberikan keterangan yang mudah dipahami untuk setiap tahap dalam workflow persetujuan, seperti 'Persetujuan manajer' atau 'Persetujuan VP keuangan'. Keterangan ini lebih jelas daripada aktivitas umum seperti 'Tahap persetujuan selesai'. Atribut ini penting untuk dasbor Approval Step Cycle Time dan Workflow Bottleneck Analysis. Atribut ini menampilkan proses persetujuan secara terperinci, sehingga Anda dapat mengetahui tahap mana yang paling banyak menyebabkan keterlambatan dan penumpukan pekerjaan. Informasi ini diperlukan agar perbaikan dapat dilakukan pada bagian rantai persetujuan yang tepat. Mengapa ini penting Menampilkan detail setiap tahap persetujuan agar hambatan dalam workflow persetujuan bertingkat dapat ditemukan dengan tepat. Sumber data Informasi ini diambil dari deskripsi tugas workflow, yang dapat ditemukan dengan menghubungkan log workflow ke tabel definisi tugas seperti T528T. Contoh Persetujuan manajerPersetujuan direkturPersetujuan VP keuangan | |||
| Nomor pesanan pembelian PurchaseOrderNumber | Nomor pesanan pembelian yang dibuat dari permintaan. | ||
| Deskripsi Nomor Pesanan Pembelian adalah pengenal dokumen pembelian resmi yang dibuat dari permintaan yang telah disetujui. Pembuatan pesanan pembelian sering menjadi hasil akhir yang diharapkan dari permintaan, karena menandakan bahwa permintaan telah menjadi pesanan resmi kepada pemasok. Atribut ini penting untuk mengukur KPI Waktu dari Permintaan ke Pesanan Pembelian dan tingkat konversi keseluruhan. Atribut ini menghubungkan proses permintaan dengan proses pengadaan berikutnya sehingga seluruh siklus Purchase-to-Pay dapat dilihat dari awal hingga akhir. Mengapa ini penting Menghubungkan permintaan dengan dokumen pengadaan berikutnya sehingga tingkat konversi permintaan menjadi PO dan waktu penyelesaiannya dapat diukur. Sumber data Terdapat pada tabel EBAN, kolom EBELN, setelah PO dibuat dari item permintaan pembelian. Contoh 450001789045000178914500017892 | |||
| Pembaruan data terakhir LastDataUpdate | Cap waktu yang menunjukkan kapan data untuk rekaman ini terakhir diperbarui dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu ekstraksi atau pembaruan data terakhir dari sistem sumber. Metadata ini penting untuk mengetahui seberapa baru data yang dianalisis. Analis dan pengguna bisnis mengandalkan cap waktu ini untuk memastikan data proses mencerminkan kondisi operasional terkini. Dalam analisis proses, mengetahui kebaruan data penting untuk mengambil keputusan yang tepat. Atribut ini membantu menyelaraskan ekspektasi pengguna dan memastikan kesimpulan dibuat berdasarkan data yang cukup mutakhir untuk kebutuhan analisis. Mengapa ini penting Menunjukkan kebaruan data, yang penting untuk mempercayai hasil analisis dan mengambil keputusan bisnis tepat waktu. Sumber data Cap waktu ini dibuat dan ditambahkan selama proses ekstraksi, transformasi, dan pemuatan data (ETL). Contoh 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Sistem sumber SourceSystem | Menunjukkan instans SAP S/4HANA tertentu yang menjadi sumber ekstraksi data. | ||
| Deskripsi Atribut Sistem Sumber menunjukkan sistem asal tempat data proses dihasilkan. Di organisasi yang menggunakan beberapa instans SAP, misalnya sistem terpisah untuk pengembangan, jaminan kualitas, dan produksi, atau untuk wilayah yang berbeda, kolom ini penting untuk tata kelola data dan konteks analisis. Atribut ini membedakan data dari berbagai sumber, mencegah penggabungan yang keliru, dan memungkinkan analisis khusus untuk setiap sistem. Atribut ini wajib untuk menjaga asal-usul data dan memastikan data proses dapat ditelusuri. Mengapa ini penting Memberikan konteks penting tentang asal data dan tata kelolanya, terutama saat organisasi menggunakan beberapa sistem, serta memastikan data dapat ditelusuri. Sumber data Biasanya berupa SAP System ID (SID), yang dapat diambil dari variabel sistem atau tabel konfigurasi. Contoh S4PECCS4H_PROD_01 | |||
| Tanggal dibutuhkan RequiredByDate | Tanggal saat pemohon membutuhkan barang atau jasa yang diminta. | ||
| Deskripsi Tanggal Dibutuhkan, atau Tanggal Pengiriman di SAP, menunjukkan kapan barang atau jasa pada item permintaan diperlukan. Pemohon menetapkan tanggal ini sebagai target untuk seluruh proses pengadaan. Atribut ini penting untuk menghitung KPI 'Tingkat Penyelesaian Permintaan Tepat Waktu'. Dengan membandingkan Tanggal Dibutuhkan dengan tanggal persetujuan akhir atau pembuatan PO, organisasi dapat mengukur kemampuannya memenuhi tingkat layanan internal dan kebutuhan bisnis. Analisis permintaan yang melewati tanggal ini dapat mengungkap keterlambatan sistemis dalam proses pengadaan. Mengapa ini penting Menetapkan tanggal target penyelesaian permintaan sehingga ketepatan waktu pemenuhan dan kepatuhan terhadap tingkat layanan internal dapat diukur. Sumber data Ini adalah Tanggal Pengiriman pada tingkat item di tabel EBAN, kolom LFDAT. Contoh 2023-11-152023-12-012024-01-20 | |||
| Tingkat urgensi UrgencyLevel | Klasifikasi tingkat urgensi permintaan pembelian yang dapat memengaruhi prioritas pemrosesannya. | ||
| Deskripsi Tingkat urgensi menunjukkan prioritas permintaan pembelian. Meski tidak ada kolom khusus yang standar, beberapa organisasi menggunakan kolom seperti Requirement Tracking Number untuk mencatat informasi ini. Dengan begitu, pemohon dapat menandai kebutuhan mendesak yang mungkin perlu diproses lebih cepat. Analisis dampak urgensi membantu menilai apakah proses benar-benar memprioritaskan permintaan penting. Dasbor Urgency Level Impact Analysis menggunakan atribut ini untuk membandingkan waktu siklus dan tingkat persetujuan permintaan mendesak dengan permintaan biasa. Hasilnya membantu Anda menilai apakah penanganan prioritas sudah berjalan sesuai harapan. Mengapa ini penting Membantu menganalisis perbedaan kinerja proses untuk permintaan berprioritas tinggi dan memastikan apakah permintaan mendesak benar-benar diproses lebih cepat. Sumber data Tidak ada kolom urgensi standar. Beberapa perusahaan menggunakan Requirement Tracking Number (EBAN-BEDAR) untuk keperluan ini. Informasi tersebut juga dapat disimpan dalam kolom khusus. Contoh TinggiSedangRendah | |||
| Waktu selesai EndTime | Tanggal dan waktu tepat saat suatu aktivitas selesai. | ||
| Deskripsi EndTime adalah stempel waktu yang mencatat kapan suatu aktivitas selesai. Banyak peristiwa yang dibuat sistem berlangsung seketika, sehingga StartTime sama dengan EndTime. Namun, tugas yang dilakukan manusia, seperti persetujuan, dapat memiliki waktu mulai dan selesai yang berbeda. Stempel waktu ini menandai selesainya pekerjaan tersebut. EndTime yang terpisah membantu mengukur waktu pemrosesan aktif dengan lebih akurat dibandingkan waktu tunggu. Nilai ini digunakan bersama StartTime untuk menghitung metrik ProcessingTime. Detail ini juga membantu menganalisis pemanfaatan sumber daya dan efisiensi tugas manual. Mengapa ini penting Menandai selesainya aktivitas, sehingga waktu pemrosesan aktif dapat dihitung dan durasi tugas dapat dianalisis lebih terperinci. Sumber data Nilai ini diambil dari log workflow yang dapat mencatat waktu pembuatan item pekerjaan (StartTime) dan waktu penyelesaiannya (EndTime). Contoh 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
Aktivitas Purchase to Pay - Requisition
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Permintaan pembelian dibuat | Menandai saat dokumen permintaan pembelian pertama kali dibuat di sistem. Peristiwa ini tercatat secara eksplisit saat pengguna menyimpan permintaan baru untuk pertama kalinya, beserta waktu pembuatannya. | ||
| Mengapa ini penting Aktivitas ini menjadi titik awal utama untuk menganalisis siklus permintaan pembelian. Data ini penting untuk mengukur waktu siklus dari identifikasi kebutuhan hingga persetujuan akhir atau konversi menjadi pesanan pembelian. Sumber data Peristiwa ini tercatat secara eksplisit dari tabel EBAN, menggunakan kolom tanggal pembuatan (ERDAT) dan waktu pembuatan (ERZEIT) untuk nomor permintaan pembelian (BANFN) terkait. Pengumpulan data Gunakan kolom waktu pembuatan (ERDAT, ERZEIT) dari tabel EBAN untuk setiap permintaan pembelian (BANFN). Jenis peristiwa explicit | |||
| Permintaan pembelian disetujui | Menandai persetujuan akhir dan penuh atas permintaan pembelian sehingga permintaan tersebut dapat dikonversi menjadi pesanan pembelian. Tonggak ini disimpulkan saat status pelepasan keseluruhan mencapai status persetujuan akhir. | ||
| Mengapa ini penting Ini adalah tonggak keberhasilan yang penting dan sering menjadi titik akhir analisis waktu siklus. Artinya, permintaan pembelian telah melewati semua pemeriksaan dan siap ditindaklanjuti oleh bagian pengadaan. Sumber data Disimpulkan dari perubahan status pada tabel EBAN, khususnya saat indikator pelepasan keseluruhan (FRGZU) atau status pemrosesan (PROCSTAT) diperbarui ke nilai akhir 'Approved'. Pengumpulan data Temukan waktu saat kode pelepasan terakhir diterapkan atau status keseluruhan permintaan pembelian berubah menjadi 'Approved'. Jenis peristiwa inferred | |||
| Permintaan pembelian ditolak | Menandai penolakan akhir atas permintaan pembelian oleh pemberi persetujuan sehingga proses dihentikan. Peristiwa ini tercatat melalui pembaruan status khusus yang menunjukkan penolakan. | ||
| Mengapa ini penting Aktivitas ini menandai titik akhir kegagalan yang penting. Analisis frekuensi, alasan, dan tahap penolakan dapat mengungkap masalah terkait kepatuhan kebijakan, anggaran, atau kualitas permintaan. Sumber data Disimpulkan dari perubahan status pada tabel EBAN. Status pemrosesan (PROCSTAT) atau indikator pelepasan diatur ke nilai yang secara eksplisit berarti 'Rejected'. Pengumpulan data Temukan waktu saat status keseluruhan di EBAN diperbarui menjadi 'Rejected' melalui dokumen perubahan. Jenis peristiwa inferred | |||
| Permintaan pembelian ditutup | Menunjukkan bahwa item permintaan pembelian telah selesai diproses dan tidak dapat lagi digunakan untuk membuat pesanan pembelian. Status ini biasanya ditetapkan otomatis setelah seluruh jumlah barang dipesan. | ||
| Mengapa ini penting Aktivitas ini menandai penyelesaian akhir yang berhasil dalam siklus hidup item permintaan pembelian. Artinya, kebutuhan bisnis telah sepenuhnya diterjemahkan menjadi pesanan pengadaan. Sumber data Disimpulkan dari tabel EBAN. Peristiwa ini terjadi saat indikator 'Closed' (EBAKZ) ditetapkan, biasanya setelah jumlah yang dipesan melalui PO sama dengan jumlah pada permintaan. Pengumpulan data Temukan peristiwa saat indikator 'Closed' (EBAKZ) ditetapkan pada tabel EBAN melalui dokumen perubahan. Jenis peristiwa inferred | |||
| Pesanan pembelian dibuat | Menunjukkan bahwa pesanan pembelian dibuat dengan merujuk pada item permintaan pembelian. Peristiwa sistem ini secara eksplisit menghubungkan permintaan dengan dokumen pengadaan berikutnya. | ||
| Mengapa ini penting Ini adalah tonggak penting dan hasil yang diharapkan dari proses permintaan pembelian. Waktu antara persetujuan permintaan dan pembuatan PO merupakan KPI penting untuk mengukur efisiensi pengadaan. Sumber data Tercatat secara eksplisit saat item pesanan pembelian dibuat. Hubungannya tersimpan di tabel EKPO (Item Pesanan Pembelian), yang memuat nomor permintaan pembelian sumber (BANFN) dan nomor item (BNFPO). Pengumpulan data Gabungkan tabel EKPO dengan EBAN berdasarkan nomor permintaan dan item. Tanggal pembuatan item PO menandai peristiwa ini. Jenis peristiwa explicit | |||
| Tahap persetujuan selesai | Terjadi saat pemberi persetujuan menyetujui permintaan pembelian dan menyelesaikan satu tahap dalam alur kerja persetujuan bertingkat. Peristiwa ini disimpulkan dari perubahan status pelepasan permintaan. | ||
| Mengapa ini penting Aktivitas ini memungkinkan analisis terperinci atas alur kerja persetujuan, termasuk pengukuran waktu yang dibutuhkan pada setiap tahap. Analisis ini membantu membedakan pemberi persetujuan yang efisien dari hambatan dalam proses. Sumber data Disimpulkan dari dokumen perubahan (CDHDR/CDPOS) untuk tabel EBAN. Peristiwa ini ditandai dengan perubahan status kode pelepasan (misalnya pada kolom FRGZU) dari belum dilepas menjadi dilepas untuk kode tertentu. Pengumpulan data Lacak perubahan pada kolom status pelepasan di EBAN untuk setiap kode pelepasan yang ditetapkan dalam strategi. Jenis peristiwa inferred | |||
| Permintaan pembelian diajukan untuk persetujuan | Menandai saat pemohon secara resmi mengajukan permintaan pembelian sehingga alur kerja persetujuan dimulai. Peristiwa ini biasanya disimpulkan saat strategi pelepasan permintaan ditentukan dan status berubah menjadi 'In Approval'. | ||
| Mengapa ini penting Ini adalah tonggak penting yang memulai penghitungan KPI waktu siklus persetujuan. Analisis waktu antara pembuatan dan pengajuan dapat mengungkap keterlambatan pada tahap persiapan permintaan pembelian. Sumber data Disimpulkan dari dokumen perubahan (CDHDR/CDPOS) untuk tabel EBAN, khususnya saat kolom strategi pelepasan (misalnya FRGST) terisi atau status keseluruhan (PROCSTAT) berubah menjadi status persetujuan. Pengumpulan data Temukan entri dokumen perubahan pertama yang menunjukkan dimulainya alur kerja persetujuan atau perubahan status menjadi 'In Approval'. Jenis peristiwa inferred | |||
| Permintaan pembelian ditarik | Terjadi saat pemohon awal membatalkan atau menghapus permintaan pembelian sebelum proses selesai. Biasanya, tindakan ini secara eksplisit menetapkan tanda penghapusan pada item permintaan. | ||
| Mengapa ini penting Melacak penarikan membantu memahami perubahan kebutuhan dan alasan pembatalan. Penarikan menandai status akhir permintaan pembelian sehingga proses lebih lanjut tidak dapat dilakukan. Sumber data Tercatat secara eksplisit saat kolom indikator penghapusan (LOEKZ) pada tabel EBAN ditetapkan untuk item permintaan pembelian. Perubahan ini dicatat di CDHDR/CDPOS. Pengumpulan data Temukan peristiwa saat indikator penghapusan (LOEKZ) pada tabel EBAN ditetapkan ke 'L'. Jenis peristiwa explicit | |||
| Permintaan pembelian diubah | Terjadi saat pengguna mengubah kolom penting pada permintaan pembelian setelah pertama kali dibuat, seperti jumlah, harga, atau material. Perubahan ini tercatat secara eksplisit di sistem dokumen perubahan SAP. | ||
| Mengapa ini penting Melacak perubahan penting untuk menemukan siklus pengerjaan ulang dan dampaknya terhadap waktu siklus. Perubahan yang sering terjadi dapat menandakan masalah kualitas data atau perubahan kebutuhan, yang perlu menjadi fokus perbaikan proses. Sumber data Tercatat secara eksplisit di tabel dokumen perubahan SAP (CDHDR dan CDPOS) untuk perubahan pada tabel EBAN. Setiap perubahan pada kolom yang dipantau akan membuat entri. Pengumpulan data Ekstrak peristiwa perubahan dari CDHDR/CDPOS dengan kelas objek BANF untuk permintaan pembelian. Jenis peristiwa explicit | |||
| Persetujuan diatur ulang | Menandai saat seluruh alur kerja persetujuan diatur ulang, biasanya karena perubahan besar pada permintaan pembelian. Proses persetujuan pun harus dimulai lagi dari tingkat pertama. | ||
| Mengapa ini penting Aktivitas ini menunjukkan pengerjaan ulang besar yang sangat memengaruhi waktu siklus. Menemukan penyebab pengaturan ulang persetujuan penting untuk menyederhanakan proses dan mengurangi keterlambatan. Sumber data Disimpulkan dari dokumen perubahan (CDHDR/CDPOS) pada tabel EBAN. Peristiwa ini terdeteksi saat kolom status pelepasan (seperti FRGKZ atau FRGZU) dikosongkan setelah sebelumnya terisi sebagian atau seluruhnya. Pengumpulan data Cari perubahan status pelepasan dari sudah dilepas kembali menjadi belum dilepas di log perubahan. Jenis peristiwa inferred | |||
| Sumber pasokan ditetapkan | Menandai tindakan pembeli yang menetapkan pemasok, kontrak, atau catatan informasi tertentu ke item permintaan pembelian yang telah disetujui. Ini adalah langkah penting untuk menyiapkan permintaan menjadi pesanan pembelian. | ||
| Mengapa ini penting Aktivitas ini menghubungkan tahap persetujuan dengan pemesanan. Mengukur waktu yang dibutuhkan untuk menetapkan sumber pasokan dapat mengungkap keterlambatan dalam beban kerja pembeli dan efisiensi pencarian sumber. Sumber data Disimpulkan saat nilai dimasukkan ke kolom terkait sumber pasokan pada tabel EBAN, seperti pemasok tetap (LIFNR), catatan informasi (INFNR), atau kontrak (KONNR). Pengumpulan data Lacak pengisian kolom seperti LIFNR, INFNR, atau KONNR pada tabel EBAN melalui dokumen perubahan. Jenis peristiwa inferred | |||
| Tahap persetujuan dimulai | Menunjukkan bahwa permintaan pembelian menunggu tindakan dari pemberi persetujuan atau kelompok persetujuan tertentu. Peristiwa ini disimpulkan saat status permintaan menunjukkan bahwa kode pelepasan tertentu sedang ditunggu. | ||
| Mengapa ini penting Aktivitas ini penting untuk menemukan hambatan dalam rangkaian persetujuan. Dengan menganalisis durasi status ini, Anda dapat menemukan permintaan yang tertahan dan pemberi persetujuan yang kelebihan beban. Sumber data Disimpulkan dari kolom status pelepasan pada tabel EBAN (misalnya FRGZU) dan konfigurasi strategi pelepasan yang mendasarinya. Peristiwa dimulai saat kode pelepasan tertentu menjadi kode berikutnya yang harus diproses. Pengumpulan data Tentukan kapan permintaan pembelian memasuki status menunggu persetujuan untuk kode pelepasan tertentu berdasarkan log alur kerja atau kolom status. Jenis peristiwa inferred | |||
Panduan ekstraksi
Langkah
- Prasyarat: Pastikan Anda memiliki pengguna dengan otorisasi yang sesuai di SAP S/4HANA untuk mengakses CDS view yang diperlukan. Biasanya, ini mencakup izin untuk objek seperti S_TABU_NAM dan akses ke alat untuk menampilkan data.
- Tentukan metode akses sistem: Tentukan cara menghubungkan ke database SAP S/4HANA untuk menjalankan kueri SQL. Alat yang umum digunakan antara lain SAP HANA Studio, Eclipse IDE dengan ADT (ABAP Development Tools), atau klien SQL pihak ketiga seperti DBeaver yang dapat terhubung melalui klien database SAP HANA.
- Tinjau kueri SQL: Pelajari skrip SQL yang disediakan. Skrip ini menggunakan Common Table Expressions (CTE) untuk mengumpulkan data dari berbagai aktivitas, lalu menggabungkannya menjadi satu log peristiwa.
- Sesuaikan placeholder: Temukan dan ganti placeholder dalam kueri. Tetapkan rentang tanggal ekstraksi dengan format
[YYYY-MM-DD]dan masukkan kode perusahaan yang sesuai ([Your Company Code]). - Jalankan kueri: Jalankan kueri SQL lengkap yang sudah disesuaikan pada database SAP S/4HANA. Waktu eksekusi dapat bervariasi, tergantung volume data dan rentang tanggal yang dipilih.
- Tinjau data awal: Setelah kueri selesai, periksa beberapa baris pertama hasilnya. Pastikan semua kolom, seperti PurchaseRequisitionId, ActivityName, dan EventTime, terisi sesuai harapan dan format datanya benar.
- Periksa transformasi data: Kueri yang disediakan menghasilkan data dalam format yang siap digunakan untuk process mining. Fungsi
CASTdanCONCATmemastikan tipe data tetap konsisten. Anda tidak perlu melakukan transformasi besar setelah kueri dijalankan. - Ekspor log peristiwa: Ekspor seluruh hasil dari klien SQL ke file CSV. Pastikan pengodean file menggunakan UTF-8 agar karakter tidak bermasalah.
- Siapkan data untuk diunggah: Sebelum mengunggah file ke alat process mining, pastikan file CSV memiliki header yang benar (
PurchaseRequisitionId,ActivityName,EventTime, dan seterusnya) serta format tanggal dan waktu untukEventTimekonsisten dan didukung platform tujuan. - Unggah ke ProcessMind: Unggah file CSV akhir ke proyek ProcessMind Anda. Atur proyek dengan memetakan
PurchaseRequisitionIdsebagai Case ID,ActivityNamesebagai Activity, danEventTimesebagai Timestamp.
Konfigurasi
- CDS View utama: Ekstraksi terutama menggunakan
I_PurchaseRequisitionAPI01untuk data utama permintaan pembelian,I_ChangeDocumentdanI_ChangeDocumentItemuntuk melacak perubahan dan pembaruan status, sertaI_PurchaseOrderItemAPI01untuk menghubungkan data ke pesanan pembelian. - Otorisasi: Pengguna yang menjalankan kueri perlu memiliki akses baca ke CDS view tersebut. Hubungi tim keamanan SAP Anda untuk mendapatkan peran dan otorisasi yang diperlukan.
- Filter rentang tanggal: Terapkan filter rentang tanggal pada tanggal pembuatan permintaan pembelian (
CreationDate) untuk membatasi volume data. Untuk analisis awal, disarankan menggunakan data selama 3 hingga 6 bulan. - Filter organisasi: Filter data berdasarkan
CompanyCodeagar analisis mencakup entitas bisnis yang tepat. Anda juga dapat memfilter berdasarkanPurchaseRequisitionTypeuntuk berfokus pada proses pengadaan tertentu, misalnya barang standar atau jasa. - Konfigurasi dokumen perubahan: Pencatatan aktivitas seperti 'Permintaan pembelian diubah' dan berbagai tahap persetujuan bergantung pada pengaktifan pencatatan dokumen perubahan untuk kolom terkait di sistem SAP Anda. Jika peristiwa ini tidak muncul, periksa konfigurasi sistem untuk tabel EBAN.
- Kinerja: Pada sistem yang sangat besar dengan jutaan permintaan pembelian, menjalankan kueri untuk rentang waktu panjang dapat memengaruhi kinerja sistem. Pertimbangkan untuk menjalankannya di luar jam sibuk atau di lingkungan nonproduksi dengan data yang baru diperbarui.
Contoh kueri sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Langkah
- Pastikan akses baca langsung ke skema SAP HANA yang berisi EBAN dan EBKN tersedia. Identifikasi juga objek dokumen perubahan dan dokumen pembelian yang digunakan sistem Anda untuk perubahan permintaan, proses persetujuan, penetapan sumber, referensi pesanan pembelian, dan penutupan. Objek dan kolom dapat berbeda menurut versi dan konfigurasi, jadi ganti setiap placeholder dalam tanda kurung siku pada kueri dengan objek atau kolom yang sesuai di sistem Anda.
- Di SAP GUI, gunakan transaksi SE16H atau alat administrasi database yang disetujui untuk memeriksa EBAN dan EBKN. Verifikasi kolom kunci permintaan pembelian serta kolom tanggal, waktu, pengguna, status, penghapusan, persetujuan, penetapan akun, dan referensi dokumen pembelian yang tersedia. Gunakan SE11 atau kamus data SAP untuk memeriksa definisi kolom. Jangan tampilkan data produksi saat melakukan pengujian.
- Tentukan sumber dokumen perubahan yang dikonfigurasi untuk perubahan permintaan pembelian dan persetujuan. Kueri ini mengharapkan sumber perubahan yang dinormalisasi bernama [Your requisition change document source], dengan kolom nomor permintaan, nomor item, kolom yang diubah, nilai lama, nilai baru, tanggal perubahan, waktu perubahan, dan pengguna. Sebelum menjalankan kueri, petakan sumber ini ke tabel dokumen perubahan SAP atau CDS view yang relevan di sistem Anda.
- Tentukan sumber workflow atau persetujuan yang dikonfigurasi untuk pengajuan, pengaturan ulang persetujuan, awal tahap persetujuan, penyelesaian tahap persetujuan, persetujuan akhir, dan penolakan. Kueri ini mengharapkan [Your requisition approval event source], dengan satu baris untuk setiap perubahan status atau persetujuan serta kolom nomor permintaan, nomor item, jenis peristiwa, kode persetujuan atau grup persetujuan, pemberi persetujuan, tanggal peristiwa, waktu peristiwa, dan status. Petakan sumber ini ke penyimpanan data persetujuan atau workflow yang digunakan konfigurasi S/4HANA Anda.
- Tentukan sumber penetapan sumber, referensi pesanan pembelian, dan penutupan. Kueri ini mengharapkan [Your requisition source assignment source], [Your requisition purchase order reference source], dan [Your requisition closure source]. Petakan placeholder ini ke tabel atau view yang disetujui di sistem Anda. Pembuatan pesanan pembelian harus ditunjukkan oleh referensi eksplisit dari item pesanan pembelian ke item permintaan pembelian, bukan disimpulkan dari aktivitas pembelian lain yang tidak terkait.
- Tetapkan rentang ekstraksi menggunakan [Start date] dan [End date]. Untuk proses awal, disarankan menggunakan rentang tiga hingga enam bulan. Gunakan rentang yang lebih panjang hanya setelah memeriksa kinerja database dan volume peristiwa. Kueri memfilter tanggal pembuatan dan tanggal peristiwa, serta tetap menggunakan ID permintaan pembelian sebagai ID kasus.
- Jalankan kueri di klien SQL yang disetujui dan terhubung ke SAP HANA. Ganti hanya detail koneksi di luar kueri, parameter tanggal, filter khusus perusahaan, serta placeholder sumber dan kolom yang didokumentasikan secara eksplisit. Pertahankan nama kolom keluaran persis seperti berikut: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, dan RequisitionStatus.
- Periksa peristiwa duplikat, presisi stempel waktu, penanganan zona waktu, serta tingkat perincian item atau dokumen. Kueri menghasilkan ID kasus pada tingkat dokumen dan menyertakan konteks item secara internal. Jika beberapa item menghasilkan aktivitas dan stempel waktu yang sama, pertahankan baris terpisah kecuali rancangan ProcessMind Anda secara khusus mengharuskan deduplikasi.
- Pastikan setiap aktivitas yang diperlukan muncul sebagai nilai ActivityName, EventTime terisi dan urutannya masuk akal, serta ID kasus yang diperlukan tidak kosong. Cocokkan jumlahnya dengan laporan SAP atau ekstrak operasional yang disetujui untuk rentang tanggal yang sama.
- Ekspor hasilnya sebagai CSV UTF-8 atau format tabular lain yang didukung ProcessMind. Sertakan baris header, pertahankan stempel waktu yang kompatibel dengan ISO, biarkan nilai null kosong, lalu unggah file dengan PurchaseRequisitionId sebagai ID kasus, ActivityName sebagai kolom aktivitas, dan EventTime sebagai kolom stempel waktu.
Konfigurasi
- ID kasus: Gunakan nomor dokumen permintaan pembelian dari EBAN, yang direpresentasikan sebagai PurchaseRequisitionId. Jika proses dikonfigurasi pada tingkat item, gunakan kunci gabungan yang terdokumentasi, seperti nomor permintaan dan nomor item, lalu terapkan kunci yang sama pada setiap peristiwa.
- Sumber utama: EBAN digunakan untuk data item permintaan pembelian. EBKN digunakan untuk memperkaya data dengan penetapan akun serta departemen atau pusat biaya. Sebelum menjalankan kueri, pastikan nama kolom dan tipe datanya di kamus data SAP.
- Sumber peristiwa: Kueri menggunakan placeholder khusus untuk sumber perubahan, persetujuan, penetapan sumber, referensi pesanan pembelian, dan penutupan. Sumber-sumber ini bergantung pada versi S/4HANA, rancangan workflow, prosedur persetujuan, fungsi bisnis yang diaktifkan, dan ekstensi pelanggan.
- Rentang tanggal: Mulailah dengan tiga hingga enam bulan. Jika tersedia, batasi rentang pada kolom tanggal yang memiliki indeks atau mendukung pemangkasan partisi. Untuk pemuatan inkremental, tumpang tindihkan rentang ekstraksi secukupnya agar perubahan yang terlambat tercatat tetap terambil. Setelah itu, hapus duplikat berdasarkan kasus, aktivitas, stempel waktu, item, dan kunci peristiwa sumber.
- Filter bisnis: Konfigurasikan [Company code filter], [Document type filter], [Purchasing group filter], dan [Plant filter] hanya jika kolom tersebut tersedia dan makna bisnisnya sudah dipastikan. Hindari memfilter status jika tujuannya adalah mencatat seluruh siklus proses.
- Pemetaan status: Konfigurasikan nilai untuk Dalam persetujuan, disetujui akhir, ditolak, diatur ulang, kode persetujuan tertunda, dan ditutup sesuai strategi persetujuan atau konfigurasi workflow di sistem tujuan. Jangan menganggap satu kode status berlaku untuk semua klien SAP.
- Pemetaan perubahan: Sertakan perubahan pada kuantitas, harga, material, tanggal pengiriman, penetapan akun, dan kolom lain yang dianggap penting dalam proses Anda. Kueri ini mencakup kondisi eksplisit untuk kolom penting yang tercantum dan mengharuskan sumber menyediakan nama kolom yang diubah.
- Penanganan stempel waktu: Gabungkan tanggal dan waktu peristiwa menggunakan zona waktu database, lalu dokumentasikan setiap konversi ke UTC. Jika sumber hanya menyimpan tanggal, gunakan tengah malam hanya jika stempel waktu yang lebih tepat tidak tersedia, dan catat keterbatasan tersebut.
- Kinerja: Batasi ekstraksi awal berdasarkan tanggal dan cakupan bisnis, pilih hanya kolom yang diperlukan, hindari penggabungan tanpa batas ke riwayat perubahan atau workflow berukuran besar, dan periksa rencana eksekusi HANA. Jika ekstraksi perlu diulang, siapkan sumber peristiwa yang sudah dinormalisasi sebagai tabel sementara atau tabel perantara.
- Otorisasi dan prasyarat: Dapatkan otorisasi baca untuk EBAN, EBKN, sumber perubahan dan workflow yang dikonfigurasi, data penetapan sumber, data referensi pesanan pembelian, serta data penutupan. Pastikan akses database langsung disetujui, fungsi pengadaan dan workflow terkait aktif, serta lisensi database SAP HANA atau alat administrasi yang diperlukan tersedia.
- Keamanan: Terapkan akses dengan hak minimum, lindungi ID pengguna dan pemberi persetujuan, serta ikuti aturan organisasi untuk mengekstrak informasi pengadaan dan keuangan.
Contoh kueri sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Siap memulai?
Gunakan templat ini untuk menyiapkan data dengan yakin dan memanfaatkan process mining dalam proses Purchase to Pay - Requisition Anda. Mulai tingkatkan efisiensi hari ini!
Atasi keterlambatan permintaan pembelian P2P, optimalkan alur kerja Anda sekarang!
Sederhanakan proses, persingkat waktu tunggu, dan kurangi waktu siklus hingga 30%.
Tidak perlu kartu kredit, penyiapan hanya 5 menit.