Templat data permintaan pembelian hingga pembayaran
Templat data permintaan pembelian hingga pembayaran
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi untuk Oracle Fusion Financials
Atribut permintaan pembelian hingga pembayaran
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama peristiwa bisnis yang terjadi pada tahap tertentu dalam proses permintaan. | ||
|
Deskripsi
Aktivitas menunjukkan langkah atau tonggak tertentu dalam siklus proses permintaan pembelian. Contohnya, 'Permintaan Dibuat', 'Tahap Persetujuan Disetujui', atau 'Pesanan Pembelian Dibuat'. Aktivitas ini berasal dari perubahan status, tindakan pengguna, atau peristiwa sistem yang tercatat dalam log audit atau tabel transaksi sistem sumber. Atribut ini diperlukan untuk menyusun peta proses yang menggambarkan alur permintaan secara visual. Dengan menganalisis urutan dan frekuensi aktivitas, Anda dapat menemukan jalur proses yang umum, hambatan, pengulangan pekerjaan, dan penyimpangan dari prosedur standar.
Mengapa ini penting
Atribut ini menjadi dasar peta proses untuk memvisualisasikan dan menganalisis alur kerja permintaan.
Sumber data
Diambil dari catatan perubahan status pada tabel seperti POR_REQUISITION_HEADERS_ALL, riwayat transaksi, atau jejak audit alur kerja seperti FA_FUSION_SOAINFRA.WFTASK.
Contoh
Permintaan pembelian dibuatLangkah persetujuan disetujuiPermintaan pembelian ditolakPurchase order dibuat
|
|||
|
ID Purchase Requisition
PurchaseRequisitionId
|
Pengenal unik untuk permintaan pembelian yang berfungsi sebagai ID kasus dalam proses. | ||
|
Deskripsi
ID Permintaan Pembelian adalah pengenal utama yang menghubungkan semua aktivitas terkait permintaan barang atau jasa tertentu. Setiap permintaan mendapat ID unik saat dibuat, dan ID ini tetap sama sepanjang siklus prosesnya. Dalam process mining, atribut ini digunakan untuk mengelompokkan semua peristiwa terkait, seperti pembuatan, pengajuan, tahapan persetujuan, dan penutupan, ke dalam satu kasus. Dengan begitu, perjalanan permintaan dapat dianalisis dari awal hingga akhir. Anda dapat melihat peta proses, menghitung waktu siklus, dan menganalisis variasi untuk setiap permintaan.
Mengapa ini penting
Atribut ini menjadi dasar untuk melacak siklus proses permintaan dari awal hingga akhir, serta mendukung analisis di tingkat kasus dan perhitungan KPI.
Sumber data
Biasanya, atribut ini menjadi kunci utama pada tabel header permintaan, seperti POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID di Oracle Fusion Financials.
Contoh
100234810023491002350
|
|||
|
Waktu peristiwa
EventTime
|
Stempel waktu yang menunjukkan kapan aktivitas terjadi. | ||
|
Deskripsi
Waktu peristiwa mencatat tanggal dan waktu persis saat aktivitas tertentu berlangsung. Stempel waktu ini menjadi dasar untuk mengurutkan peristiwa secara kronologis dalam satu kasus. Sumbernya dapat berupa tanggal pembuatan, tanggal pembaruan terakhir, atau stempel waktu tindakan tertentu di sistem. Dalam analisis, waktu peristiwa digunakan untuk menghitung semua metrik durasi, seperti waktu siklus antaraktivitas, waktu tunggu, dan durasi keseluruhan kasus. Atribut ini penting untuk menemukan hambatan, mengukur kinerja terhadap SLA, dan memahami dinamika waktu dalam proses permintaan.
Mengapa ini penting
Atribut ini diperlukan untuk menghitung KPI terkait waktu, mengurutkan peristiwa dengan benar, serta menganalisis kinerja proses dan hambatan.
Sumber data
Biasanya, atribut ini bersumber dari kolom 'LAST_UPDATE_DATE' atau 'CREATION_DATE' yang terkait dengan transaksi atau perubahan status. Kolom tersebut sering ditemukan di tabel seperti POR_REQUISITION_HEADERS_ALL atau tabel riwayat alur kerja.
Contoh
2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu saat data terakhir diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini menunjukkan tanggal dan waktu terakhir data diekstrak dari Oracle Fusion Financials. Nilainya berlaku untuk seluruh dataset, bukan untuk setiap peristiwa. Analis menggunakan informasi ini untuk mengetahui seberapa baru data yang tersedia dan memastikan kapan transaksi terbaru disertakan. Metadata ini penting untuk pelaporan dasbor dan memastikan analisis menggunakan informasi terkini.
Mengapa ini penting
Memberi tahu pengguna seberapa baru data yang tersedia, sehingga analisis tetap relevan dan menggunakan informasi terbaru.
Sumber data
Stempel waktu ini dibuat dan disimpan selama proses ekstraksi data, biasanya oleh alat ETL atau pipeline data.
Contoh
2023-10-27T02:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem informasi tempat data ini diambil. | ||
|
Deskripsi
Atribut ini menunjukkan asal data proses. Dalam model data ini, nilainya selalu 'Oracle Fusion Financials'. Jika organisasi menggunakan beberapa ERP atau sistem terintegrasi, kolom ini penting untuk menelusuri asal data, memecahkan masalah, dan menjaga kualitas data. Kolom ini memberi konteks tentang sumber tepercaya bagi peristiwa proses yang dianalisis.
Mengapa ini penting
Memberi konteks penting tentang asal data, yang diperlukan untuk tata kelola data dan integrasi data dari beberapa sistem.
Sumber data
Nilai statis ini ditambahkan saat proses ekstraksi dan transformasi data untuk menandai asal dataset.
Contoh
Oracle Fusion Financials
|
|||
|
Alasan penolakan
RejectionReason
|
Alasan yang diberikan pemberi persetujuan saat menolak permintaan atau tahap persetujuan. | ||
|
Deskripsi
Saat menolak permintaan, pemberi persetujuan biasanya menyertakan alasan dengan memilih dari daftar yang tersedia atau menulis keterangan sendiri. Atribut ini mencatat alasan tersebut. Atribut ini penting untuk menganalisis akar penyebab kegagalan proses. Atribut ini mendukung dasbor 'Tren Perubahan dan Penolakan' dengan menjelaskan alasan di balik penolakan. Analisis alasan penolakan dapat menemukan masalah umum, seperti kode yang salah, anggaran terlampaui, atau pelanggaran kebijakan. Masalah tersebut kemudian dapat ditangani melalui pelatihan atau kontrol sistem.
Mengapa ini penting
Menunjukkan alasan permintaan ditolak, sehingga perbaikan dapat diarahkan untuk mengurangi pekerjaan ulang dan meningkatkan tingkat pemrosesan langsung.
Sumber data
Bersumber dari komentar alur kerja atau kolom kode alasan penolakan pada jejak audit alur kerja, misalnya di tabel terkait FA_FUSION_SOAINFRA.WFTASK atau penyimpanan komentar terkait.
Contoh
Akun GL tidak tepatMelebihi anggaran pusat biayaPemasok yang dipilih bukan pemasok pilihanPermintaan duplikat
|
|||
|
Departemen
DepartmentName
|
Departemen tempat pemohon bekerja. | ||
|
Deskripsi
Atribut ini menunjukkan unit organisasi orang yang membuat permintaan, seperti 'Keuangan', 'TI', atau 'Pemasaran'. Biasanya, informasi ini diambil dari profil pemohon di sistem SDM. Analisis berdasarkan departemen merupakan cara umum untuk mengelompokkan data proses. Cara ini membantu menemukan pola khusus departemen, seperti tingkat penolakan yang lebih tinggi atau waktu siklus yang lebih lama. Temuan tersebut dapat menjadi dasar perbaikan proses yang lebih terarah. Atribut ini juga menjadi dimensi penting dalam dasbor 'Metrik Kinerja Pemohon'.
Mengapa ini penting
Memungkinkan analisis proses berdasarkan unit bisnis untuk menemukan pola, kinerja, dan masalah kepatuhan yang spesifik pada tiap departemen.
Sumber data
Biasanya, informasi ini diambil dari profil pemohon. Anda mungkin perlu menggabungkan tabel permintaan dengan tabel SDM atau direktori pengguna yang memuat informasi departemen.
Contoh
Teknologi InformasiKeuanganOperasionalPemasaran
|
|||
|
Nama pemohon
RequesterName
|
Nama karyawan yang membuat dan mengajukan permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan orang yang mengajukan permintaan barang atau jasa. Informasi ini biasanya dicatat saat permintaan pertama kali dibuat. Analisis kinerja proses berdasarkan pemohon penting untuk dasbor 'Metrik Kinerja Pemohon'. Analisis ini membantu menemukan pengguna atau kelompok yang mungkin memerlukan pelatihan tambahan, misalnya karena permintaannya sering diubah atau ditolak, atau memiliki waktu siklus yang panjang. Atribut ini memberi gambaran proses dari sisi orang yang terlibat.
Mengapa ini penting
Mendukung analisis kinerja berdasarkan pemohon, membantu menemukan kebutuhan pelatihan serta pengguna atau departemen yang bekerja secara efisien.
Sumber data
Bersumber dari data header permintaan. Biasanya, ID pemohon dicocokkan dengan tabel data induk karyawan atau pengguna. Cari kolom terkait 'PREPARER_ID' di POR_REQUISITION_HEADERS_ALL, lalu gabungkan dengan PER_ALL_PEOPLE_F.
Contoh
John SmithJane DoeEmily Jones
|
|||
|
Status permintaan
RequisitionStatus
|
Status permintaan pembelian saat ini atau status akhirnya. | ||
|
Deskripsi
Atribut ini menunjukkan keadaan permintaan secara keseluruhan pada waktu tertentu atau hasil akhirnya, seperti 'Disetujui', 'Ditolak', 'Sedang Diproses', atau 'Ditutup'. Status ini sering menjadi sumber untuk menghasilkan berbagai aktivitas dalam log peristiwa. Atribut ini penting untuk dasbor 'Ringkasan Status Permintaan', yang menampilkan gambaran beban kerja dan tunggakan saat ini. Atribut ini juga digunakan untuk menghitung KPI berdasarkan hasil, seperti Tingkat Penolakan Permintaan, dengan memfilter kasus yang berakhir pada status tertentu.
Mengapa ini penting
Memberi gambaran status permintaan saat ini dan membantu menentukan hasil akhir untuk perhitungan KPI.
Sumber data
Tersedia di tabel header permintaan, biasanya pada kolom seperti 'DOCUMENT_STATUS' atau 'APPROVAL_STATUS' di POR_REQUISITION_HEADERS_ALL.
Contoh
DISETUJUISEDANG DIPROSESDITOLAKDIBATALKAN
|
|||
|
Tanggal dibutuhkan
RequiredByDate
|
Tanggal saat pemohon membutuhkan barang atau jasa. | ||
|
Deskripsi
Pemohon menetapkan tanggal ini sebagai batas waktu penerimaan barang yang diminta. Tanggal ini menjadi target perjanjian tingkat layanan (SLA) internal untuk proses pengadaan. Atribut ini menjadi dasar dasbor 'Kinerja terhadap Tanggal Dibutuhkan' dan KPI 'Tingkat Pemenuhan Tanggal Dibutuhkan'. Dengan membandingkan tanggal ini dengan tanggal pembuatan Pesanan Pembelian atau tanggal penerimaan barang, analisis dapat menunjukkan seberapa baik proses pengadaan memenuhi kebutuhan pelanggan internal dan menemukan keterlambatan yang terjadi secara sistematis.
Mengapa ini penting
Penting untuk mengukur kinerja proses terhadap tenggat internal dan mengetahui apakah proses pengadaan memenuhi kebutuhan bisnis tepat waktu.
Sumber data
Biasanya, informasi ini disimpan pada tingkat baris item permintaan, di tabel seperti POR_REQUISITION_LINES_ALL pada kolom seperti 'NEED_BY_DATE'.
Contoh
2023-11-012023-12-152024-01-31
|
|||
|
Total nilai permintaan
RequisitionTotalAmount
|
Nilai total uang dari permintaan pembelian. | ||
|
Deskripsi
Atribut ini menunjukkan jumlah nilai semua baris item dalam satu permintaan pembelian. Informasi ini penting untuk memahami nilai finansial setiap permintaan. Dalam process mining, total nilai digunakan untuk berbagai analisis. Anda dapat memfilter permintaan bernilai tinggi, yang sering kali memiliki jalur persetujuan berbeda atau memerlukan pemeriksaan lebih ketat. Dasbor juga dapat menggunakan atribut ini untuk menganalisis hubungan antara metrik proses, seperti waktu siklus atau tingkat penolakan, dan nilai permintaan.
Mengapa ini penting
Memberi konteks finansial untuk analisis berdasarkan nilai, membantu menentukan prioritas perbaikan proses dan memahami pengaruh nilai permintaan terhadap perilaku proses.
Sumber data
Tersedia di header permintaan, biasanya pada kolom seperti REQUISITION_TOTAL di POR_REQUISITION_HEADERS_ALL. Nilainya juga dapat dihitung dengan menjumlahkan nilai item dari POR_REQUISITION_LINES_ALL.
Contoh
550.0012500.7599.99
|
|||
|
Unit bisnis
BusinessUnit
|
Unit bisnis tertentu dalam organisasi yang terkait dengan permintaan. | ||
|
Deskripsi
Unit bisnis adalah entitas hukum atau fungsional tersendiri dalam perusahaan yang mengajukan permintaan. Tingkatnya lebih tinggi daripada departemen dalam struktur organisasi. Analisis berdasarkan unit bisnis memungkinkan perbandingan kinerja tingkat tinggi antarbagian organisasi. Manajemen senior dapat mengetahui apakah ketidakefisienan proses hanya terjadi di bagian tertentu atau tersebar luas, serta menentukan fokus perbaikan. Atribut ini menjadi dimensi penting untuk memfilter hampir semua dasbor dan KPI.
Mengapa ini penting
Memberi konteks organisasi tingkat tinggi untuk membandingkan kinerja dan mendukung analisis strategis di berbagai bagian perusahaan.
Sumber data
Ini adalah kolom organisasi utama di Oracle Fusion dan biasanya tersedia pada header permintaan di tabel seperti POR_REQUISITION_HEADERS_ALL.
Contoh
Unit bisnis Amerika UtaraUnit bisnis EropaKantor pusat perusahaan
|
|||
|
Deskripsi item
ItemDescription
|
Deskripsi produk atau jasa yang diminta pada baris permintaan. | ||
|
Deskripsi
Atribut ini berisi deskripsi teks tentang item yang akan dibeli. Deskripsi tersebut memberikan rincian khusus tentang barang atau jasa yang diminta. Meski sering kali tidak terstruktur, deskripsi item memberi konteks yang berguna untuk analisis. Anda dapat menggunakannya sebagai filter untuk menemukan permintaan jenis pembelian tertentu yang tidak tercakup dalam jenis permintaan. Misalnya, analis dapat mencari semua permintaan yang memuat 'Lisensi Perangkat Lunak' untuk memahami alur proses dan waktu siklusnya.
Mengapa ini penting
Memberi rincian tentang barang atau jasa yang dibeli, sehingga Anda dapat memfilter dan menganalisis jenis pembelian tertentu dengan lebih terperinci.
Sumber data
Tersedia di tabel baris item permintaan, POR_REQUISITION_LINES_ALL, pada kolom seperti ITEM_DESCRIPTION.
Contoh
Laptop 15 inci, RAM 16 GBJasa konsultasi, proyek kuartal 4Perpanjangan pemeliharaan perangkat lunak tahunan
|
|||
|
Dilakukan otomatis
IsAutomated
|
Penanda yang menunjukkan apakah aktivitas dilakukan secara otomatis oleh sistem. | ||
|
Deskripsi
Atribut ini menunjukkan peristiwa proses yang dilakukan oleh pengguna sistem atau agen otomatis, bukan oleh manusia. Contohnya mencakup perubahan status yang dipicu sistem atau tahapan persetujuan otomatis untuk item bernilai rendah. Analisis atribut ini membantu mengukur tingkat otomatisasi proses. Anda dapat membandingkan kecepatan dan efisiensi langkah otomatis dengan langkah manual, serta menemukan peluang untuk menambah otomatisasi.
Mengapa ini penting
Membantu mengukur tingkat otomatisasi proses dan menemukan peluang untuk mengotomatiskan tugas manual.
Sumber data
Ditentukan dengan memeriksa apakah pengguna yang terkait dengan aktivitas merupakan akun sistem atau akun layanan. Untuk itu, diperlukan daftar ID pengguna sistem yang diketahui.
Contoh
truefalse
|
|||
|
Diproses langsung
IsStraightThrough
|
Penanda yang menunjukkan apakah permintaan disetujui tanpa perubahan atau penolakan. | ||
|
Deskripsi
Penanda hasil perhitungan ini menunjukkan permintaan yang melewati proses dari pengajuan hingga persetujuan tanpa pengulangan pekerjaan, seperti perubahan atau penolakan. Artinya, proses untuk satu kasus berjalan tanpa hambatan. Atribut ini menjadi dasar KPI 'Tingkat Permintaan yang Diproses Langsung'. Analisis karakteristik permintaan yang diproses langsung, seperti departemen, pemohon, atau jenis permintaan yang umum, dapat mengungkap praktik baik dan peluang otomatisasi. Sebaliknya, analisis permintaan yang tidak diproses langsung dapat membantu menemukan penyebab utama ketidakefisienan.
Mengapa ini penting
Mengukur efisiensi proses secara langsung dan menjadi dasar KPI Tingkat Permintaan yang Diproses Langsung, sekaligus membantu menemukan penyebab pekerjaan ulang.
Sumber data
Atribut ini dihitung saat transformasi data. Kasus diberi nilai benar jika tidak memiliki aktivitas 'Permintaan Diubah' atau 'Tahap Persetujuan Ditolak'.
Contoh
truefalse
|
|||
|
Jalur alur kerja persetujuan
ApprovalWorkflowPath
|
Urutan pemberi persetujuan atau kelompok persetujuan yang telah ditetapkan untuk permintaan. | ||
|
Deskripsi
Atribut ini menentukan proses persetujuan standar yang diharapkan untuk suatu permintaan berdasarkan kebijakan perusahaan, dengan mempertimbangkan faktor seperti nilai permintaan, jenis, dan departemen. Atribut ini menggambarkan model proses yang diharapkan. Jalur alur kerja persetujuan menjadi dasar analisis kepatuhan dan kesesuaian. Atribut ini mendukung dasbor 'Analisis Kepatuhan dan Penyimpangan' serta KPI 'Indeks Kesesuaian Permintaan' dengan membandingkan tahapan persetujuan yang benar-benar dilalui dengan jalur yang ditetapkan. Penyimpangan dapat menunjukkan pelanggaran kebijakan atau proses yang tidak efisien.
Mengapa ini penting
Mendukung pemeriksaan kesesuaian dengan membandingkan alur proses aktual dengan hierarki persetujuan yang diwajibkan, sehingga permintaan yang tidak patuh dapat ditemukan.
Sumber data
Informasi ini dikonfigurasi di Oracle Fusion BPM Worklist atau Approval Management Engine (AMX). Mengambil jalur yang ditetapkan untuk setiap permintaan bisa jadi rumit dan mungkin memerlukan kueri ke tabel konfigurasi.
Contoh
Manajer > Direktur > VP KeuanganPemilik Pusat Biaya > Keamanan TIManajer > Kepala Departemen
|
|||
|
Jenis permintaan
RequisitionType
|
Kategori permintaan, misalnya permintaan barang atau jasa. | ||
|
Deskripsi
Atribut ini mengelompokkan permintaan berdasarkan barang atau jasa yang diminta. Jenis yang umum mencakup barang, jasa, atau belanja modal. Jenis permintaan dapat memengaruhi alur kerja persetujuan dan strategi pengadaan. Dalam analisis, jenis permintaan menjadi dimensi untuk memfilter dan membandingkan data. Misalnya, Anda dapat menganalisis apakah permintaan jasa memerlukan waktu persetujuan lebih lama daripada permintaan barang. Atribut ini membantu memahami perbedaan perilaku proses dan hambatan pada tiap jenis permintaan.
Mengapa ini penting
Memungkinkan analisis berdasarkan jenis pembelian, misalnya untuk memahami perbedaan proses permintaan barang dan jasa.
Sumber data
Jenis ini sering ditentukan oleh jenis atau kategori item yang dipilih saat permintaan dibuat. Informasinya mungkin disimpan di tabel baris permintaan, POR_REQUISITION_LINES_ALL.
Contoh
BarangJasaBelanja modal
|
|||
|
Mata uang
CurrencyCode
|
Kode mata uang untuk nilai permintaan, seperti USD atau EUR. | ||
|
Deskripsi
Atribut ini menunjukkan mata uang yang digunakan untuk menyatakan total nilai permintaan. Organisasi global dapat membuat permintaan dalam berbagai mata uang. Informasi ini diperlukan untuk menafsirkan dan menjumlahkan data finansial dengan benar. Dalam analisis yang melibatkan nilai uang, gunakan kode mata uang agar nilai dapat dibandingkan secara akurat. Anda dapat memfilter satu mata uang atau mengonversi semua nilai ke mata uang yang sama.
Mengapa ini penting
Menjaga akurasi analisis dan pelaporan finansial, terutama di organisasi multinasional yang menggunakan beberapa mata uang.
Sumber data
Biasanya, informasi ini tersedia di tabel header permintaan bersama kolom nilai, misalnya di POR_REQUISITION_HEADERS_ALL.
Contoh
USDEURGBPJPY
|
|||
|
Nama pemasok
SupplierName
|
Nama pemasok yang disarankan atau dipilih sebelumnya untuk barang atau jasa. | ||
|
Deskripsi
Atribut ini menunjukkan pemasok tempat barang atau jasa akan dibeli. Pemohon dapat menyarankan pemasok, atau sistem dapat menentukannya berdasarkan katalog atau perjanjian sebelumnya. Analisis berdasarkan pemasok dapat mengungkap pola pengadaan yang penting. Misalnya, analisis dapat menunjukkan apakah permintaan untuk pemasok tertentu memerlukan waktu persetujuan lebih lama atau lebih sering ditolak. Informasi ini berguna untuk mengelola hubungan dengan pemasok dan menyusun strategi pengadaan.
Mengapa ini penting
Memungkinkan analisis kinerja proses berdasarkan pemasok, yang dapat membantu menyusun strategi pengadaan dan mengelola hubungan dengan pemasok.
Sumber data
Tersedia di tabel baris item permintaan, POR_REQUISITION_LINES_ALL. Biasanya, informasi ini dihubungkan melalui VENDOR_ID ke tabel data induk pemasok seperti POZ_SUPPLIERS.
Contoh
Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
|
|||
|
Nama pengguna
UserName
|
Nama pengguna yang melakukan aktivitas tertentu, misalnya pemberi persetujuan atau penyunting. | ||
|
Deskripsi
Nama pemohon menunjukkan orang yang mengajukan permintaan, sedangkan nama pengguna menunjukkan orang yang melakukan peristiwa tertentu, seperti menyetujui atau menolak permintaan. Atribut ini sangat penting dalam alur kerja persetujuan bertahap yang melibatkan beberapa orang. Atribut ini membantu menganalisis hambatan persetujuan dan mengukur kinerja pemberi persetujuan atau tim tertentu. Atribut ini mendukung dasbor 'Hambatan Alur Kerja Persetujuan' dengan memungkinkan analisis waktu pemrosesan setiap pengguna dalam rangkaian persetujuan.
Mengapa ini penting
Menunjukkan pelaku setiap peristiwa, yang penting untuk menganalisis waktu serah terima, kinerja pemberi persetujuan, dan alokasi sumber daya.
Sumber data
Bersumber dari riwayat alur kerja atau tabel jejak audit, seperti FA_FUSION_SOAINFRA.WFTASK, yang mencatat pengguna terkait dengan penyelesaian setiap tugas.
Contoh
David LeeSusan ChenMichael Brown
|
|||
|
Nomor pesanan pembelian
PurchaseOrderNumber
|
Pengenal pesanan pembelian yang dibuat dari permintaan yang telah disetujui. | ||
|
Deskripsi
Atribut ini menghubungkan permintaan pembelian dengan pesanan pembelian yang dihasilkan. Setelah permintaan disetujui sepenuhnya, permintaan biasanya diubah menjadi satu atau beberapa pesanan pembelian untuk dikirim ke pemasok. Dalam analisis, ID ini penting untuk melacak proses setelah tahap permintaan. ID ini memungkinkan penghitungan KPI 'Waktu Tunggu Permintaan ke PO' dan mendukung dasbor 'Waktu Siklus Permintaan ke PO'. Anda juga dapat menggabungkan data proses permintaan dengan proses PO dan faktur berikutnya untuk menganalisis proses Purchase-to-Pay dari awal hingga akhir.
Mengapa ini penting
Menghubungkan permintaan dengan pesanan pembelian berikutnya, sehingga waktu siklus permintaan ke PO dapat diukur dan proses dianalisis dari awal hingga akhir.
Sumber data
Informasi ini tersedia setelah PO dibuat. Biasanya, informasi ini ditemukan melalui referensi permintaan pada tabel distribusi PO, seperti PO_DISTRIBUTIONS_ALL, yang terhubung kembali ke baris permintaan.
Contoh
PO-2023-5832PO-2023-5833PO-2023-5834
|
|||
|
Pernah diubah
IsAmendedFlag
|
Penanda bernilai benar jika permintaan pernah diubah setidaknya satu kali. | ||
|
Deskripsi
Atribut hasil perhitungan ini menunjukkan apakah permintaan pernah diubah setelah pertama kali diajukan. Nilainya ditentukan dengan memeriksa apakah terdapat aktivitas 'Permintaan Diubah' dalam riwayat kasus. Penanda ini mempermudah analisis dan penghitungan KPI. Penanda ini digunakan untuk menghitung KPI 'Tingkat Perubahan Permintaan' dan menemukan kasus yang tidak diproses langsung. Anda dapat memfilter dan membandingkan metrik proses untuk permintaan yang diubah dan yang tidak diubah.
Mengapa ini penting
Mempermudah penghitungan tingkat perubahan dan perbandingan permintaan yang diubah dengan yang tidak diubah.
Sumber data
Atribut ini tidak tersedia di sistem sumber. Nilainya dihitung saat transformasi data berdasarkan aktivitas terkait perubahan dalam log peristiwa.
Contoh
truefalse
|
|||
Aktivitas permintaan pembelian hingga pembayaran
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Permintaan pembelian diajukan
|
Menandai tindakan pengguna yang mengajukan permintaan lengkap ke alur kerja persetujuan. Peristiwa ini tercatat saat status permintaan berubah dari 'Incomplete' atau 'Draft' menjadi status yang menunjukkan bahwa persetujuan sedang menunggu. | ||
|
Mengapa ini penting
Aktivitas ini memulai siklus persetujuan. Ini menjadi tonggak penting untuk mengukur Waktu Siklus Persetujuan Permintaan dan keseluruhan waktu tunggu.
Sumber data
Disimpulkan dari perubahan status di tabel POR_REQUISITION_HEADERS_ALL, misalnya saat status berubah menjadi 'PENDING APPROVAL'. Tanggal pengajuan juga sering disimpan secara eksplisit.
Pengumpulan data
Temukan stempel waktu saat kolom status dokumen pertama kali berubah menjadi 'Pending Approval'.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian dibuat
|
Menandai dimulainya proses pengadaan, saat pengguna menyimpan permintaan pembelian baru untuk pertama kalinya. Peristiwa ini biasanya tercatat sebagai pembuatan data secara eksplisit dengan stempel waktu terkait di sistem. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses permintaan pembelian. Analisis waktu dari pembuatan hingga pengajuan dapat menunjukkan keterlambatan dalam meresmikan permintaan.
Sumber data
Peristiwa ini tercatat di tabel POR_REQUISITION_HEADERS_ALL, berdasarkan kolom creation_date saat Requisition ID baru dibuat.
Pengumpulan data
Gunakan stempel waktu pembuatan pada data header permintaan.
Jenis peristiwa
explicit
|
|||
|
Permintaan pembelian disetujui
|
Menandai persetujuan akhir atas permintaan pembelian setelah berhasil melewati semua langkah dalam alur kerja. Peristiwa ini disimpulkan dari perubahan status keseluruhan permintaan menjadi 'Approved'. | ||
|
Mengapa ini penting
Tonggak ini menunjukkan bahwa permintaan siap ditindaklanjuti oleh bagian pengadaan. Ini menjadi titik akhir untuk mengukur total waktu siklus persetujuan permintaan.
Sumber data
Disimpulkan dari perubahan kolom status dokumen di tabel POR_REQUISITION_HEADERS_ALL menjadi 'APPROVED'. Tanggal perubahan status tersebut menjadi waktu peristiwa.
Pengumpulan data
Temukan stempel waktu saat status dokumen pertama kali ditetapkan menjadi 'Approved'.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian ditolak
|
Menandai penolakan akhir atas permintaan yang menghentikan proses untuk permintaan tersebut. Peristiwa ini disimpulkan saat status keseluruhan permintaan berubah menjadi 'Rejected'. | ||
|
Mengapa ini penting
Aktivitas ini menjadi titik akhir bagi permintaan yang tidak berhasil. Analisis kasus ini penting untuk memahami KPI Tingkat Penolakan Permintaan dan penyebab kegagalan.
Sumber data
Disimpulkan dari perubahan status dokumen di tabel POR_REQUISITION_HEADERS_ALL menjadi 'REJECTED'.
Pengumpulan data
Temukan stempel waktu saat status dokumen pertama kali ditetapkan menjadi 'Rejected'.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian ditutup
|
Menandai penutupan akhir siklus permintaan, yang berarti semua barisnya telah dipenuhi, misalnya dikonversi menjadi PO, atau dibatalkan. Peristiwa ini disimpulkan dari pembaruan status akhir. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir utama yang menandakan proses berhasil. Peristiwa ini memastikan permintaan telah diproses sepenuhnya dan tidak memerlukan tindakan lanjutan.
Sumber data
Disimpulkan dari perubahan status header permintaan di POR_REQUISITION_HEADERS_ALL menjadi 'CLOSED'.
Pengumpulan data
Temukan stempel waktu saat status dokumen permintaan berubah menjadi 'Closed'.
Jenis peristiwa
inferred
|
|||
|
Purchase order dibuat
|
Peristiwa ini terjadi saat baris permintaan yang telah disetujui digunakan untuk membuat purchase order. Peristiwa ini menghubungkan proses permintaan dengan proses pengadaan berikutnya. | ||
|
Mengapa ini penting
Tonggak ini penting untuk mengukur Waktu Tunggu dari Permintaan ke PO. Keterlambatan pada tahap ini menunjukkan hambatan dalam serah terima dari persetujuan ke pembelian.
Sumber data
Peristiwa ini tercatat secara eksplisit. Hubungan antara permintaan dan purchase order disimpan di tabel seperti PO_LINE_LOCATIONS_ALL, yang memuat referensi ke ID baris permintaan sumber.
Pengumpulan data
Temukan tanggal pembuatan Purchase Order yang merujuk pada Requisition ID terkait.
Jenis peristiwa
explicit
|
|||
|
Langkah persetujuan dikembalikan
|
Pemberi persetujuan mengembalikan permintaan kepada penyusun untuk meminta informasi tambahan atau perbaikan kecil, tanpa menolaknya secara resmi. Biasanya, tindakan ini tercatat secara eksplisit di sistem alur kerja. | ||
|
Mengapa ini penting
Peristiwa ini menunjukkan perlunya klarifikasi dan memicu pekerjaan ulang yang memperpanjang waktu siklus. Membedakan pengembalian dari penolakan memberi gambaran lebih jelas tentang kendala dalam proses.
Sumber data
Diambil dari riwayat tindakan persetujuan permintaan. Sistem alur kerja mencatat tindakan 'RETURN' atau tindakan serupa beserta stempel waktunya.
Pengumpulan data
Gunakan stempel waktu tindakan 'RETURN' atau 'Request for Information' dari riwayat alur kerja.
Jenis peristiwa
explicit
|
|||
|
Langkah persetujuan dimulai
|
Menandai saat permintaan ditugaskan kepada pemberi persetujuan atau kelompok persetujuan tertentu dalam alur kerja. Informasi ini diambil dari log transaksi mesin alur kerja. | ||
|
Mengapa ini penting
Aktivitas ini penting untuk menghitung waktu tunggu pada setiap langkah persetujuan. Aktivitas ini membantu menemukan hambatan yang disebabkan oleh pemberi persetujuan atau tingkat persetujuan tertentu.
Sumber data
Diambil dari tabel alur kerja Oracle Fusion yang mencatat tugas yang diberikan kepada pengguna. Stempel waktu penugasan tugas persetujuan digunakan.
Pengumpulan data
Gunakan stempel waktu pembuatan tugas dalam riwayat alur kerja untuk permintaan terkait.
Jenis peristiwa
explicit
|
|||
|
Langkah persetujuan disetujui
|
Menandai tindakan pemberi persetujuan yang menyetujui permintaan pada langkah yang menjadi tanggung jawabnya dalam alur kerja. Peristiwa ini tercatat secara eksplisit dalam riwayat persetujuan. | ||
|
Mengapa ini penting
Melacak setiap langkah persetujuan membantu memetakan jalur persetujuan yang sebenarnya dan mengukur waktu pemrosesan di setiap tingkat hierarki.
Sumber data
Diambil dari riwayat tindakan persetujuan permintaan. Data ini biasanya tersimpan di tabel workflow (WF) atau Human Capital Management (HCM) yang mengelola hierarki persetujuan.
Pengumpulan data
Gunakan stempel waktu tindakan 'APPROVE' dari log riwayat tindakan alur kerja.
Jenis peristiwa
explicit
|
|||
|
Langkah persetujuan ditolak
|
Pemberi persetujuan menolak permintaan. Biasanya, permintaan dikembalikan kepada penyusun untuk diperbaiki atau prosesnya dihentikan. Tindakan ini tercatat secara eksplisit dalam riwayat alur kerja. | ||
|
Mengapa ini penting
Aktivitas ini menjadi penyebab utama pekerjaan ulang dan keterlambatan. Analisis penolakan membantu menemukan masalah kepatuhan, anggaran, atau alasan permintaan yang kurang jelas.
Sumber data
Diambil dari riwayat tindakan persetujuan permintaan. Sistem alur kerja mencatat tindakan 'REJECT' beserta stempel waktunya.
Pengumpulan data
Gunakan stempel waktu tindakan 'REJECT' dari log riwayat tindakan alur kerja.
Jenis peristiwa
explicit
|
|||
|
Permintaan pembelian ditarik
|
Terjadi saat pemohon membatalkan atau menarik permintaan yang telah diajukan sebelum persetujuan penuh diberikan. Biasanya, tindakan pengguna ini tercatat secara eksplisit sebagai perubahan status. | ||
|
Mengapa ini penting
Melacak penarikan membantu menemukan alasan proses dihentikan lebih awal, seperti perubahan kebutuhan bisnis atau pengguna yang memperbaiki kesalahan setelah pengajuan.
Sumber data
Disimpulkan dari perubahan status menjadi 'WITHDRAWN' di tabel POR_REQUISITION_HEADERS_ALL. Tindakan ini tercatat dalam riwayat tindakan permintaan.
Pengumpulan data
Deteksi stempel waktu saat status permintaan berubah menjadi 'Withdrawn'.
Jenis peristiwa
inferred
|
|||
|
Permintaan pembelian diubah
|
Peristiwa ini menandakan pengguna mengubah permintaan setelah pengajuan awal. Perubahan tersebut sering kali mengharuskan proses persetujuan dimulai kembali. Peristiwa ini disimpulkan dengan mendeteksi perubahan pada kolom data utama atau pembuatan versi permintaan yang baru. | ||
|
Mengapa ini penting
Perubahan yang sering terjadi menunjukkan masalah kualitas data atau persyaratan yang terus berubah, sehingga menimbulkan pekerjaan ulang dan keterlambatan proses. Peristiwa ini mendukung KPI 'Tingkat Perubahan Permintaan' secara langsung.
Sumber data
Disimpulkan dengan melacak nomor versi permintaan atau mendeteksi perubahan status kembali menjadi 'Incomplete' setelah pengajuan. Log perubahan atau tabel jejak audit juga dapat mencatat perubahan ini.
Pengumpulan data
Temukan stempel waktu pembuatan versi baru untuk Requisition ID yang sama setelah permintaan diajukan.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat ini untuk mulai mengoptimalkan proses permintaan pembelian hingga pembayaran dan meningkatkan efisiensi. Bersiaplah untuk meningkatkan kinerja operasional pengadaan Anda.
Percepat proses permintaan pembelian hingga pembayaran sebesar 30%
Sederhanakan proses permintaan P2P Oracle dan kurangi waktu siklus hingga 30%.
Tidak perlu kartu kredit. Siapkan dalam hitungan menit.