Templat data Purchase to Pay - Purchase Order Anda

Oracle Fusion Financials
Templat data Purchase to Pay - Purchase Order Anda

Templat data Purchase to Pay - Purchase Order Anda

Templat ini memandu Anda mengumpulkan data yang diperlukan untuk menganalisis proses Purchase to Pay - Purchase Order. Templat ini menjelaskan atribut data penting, aktivitas utama yang perlu dilacak, dan panduan praktis untuk mengekstrak informasi tersebut. Gunakan templat ini agar semua detail penting tercakup dalam analisis process mining.
  • Atribut yang disarankan untuk mengumpulkan data secara menyeluruh
  • Aktivitas proses utama yang perlu dilacak dan dianalisis
  • Panduan langkah demi langkah untuk mengekstrak data dari Oracle Fusion Financials
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut Purchase to Pay - Purchase Order

Berikut kolom data yang disarankan untuk disertakan dalam log peristiwa agar proses Purchase to Pay - Purchase Order dapat dianalisis secara menyeluruh.
3 Wajib 7 Disarankan 11 Opsional
Nama Deskripsi
Aktivitas
ActivityName
Nama peristiwa bisnis atau langkah tertentu yang terjadi dalam siklus pesanan pembelian.
Deskripsi

Atribut ini menjelaskan tugas atau perubahan status tertentu dalam proses, seperti 'Purchase Order Created' atau 'Goods Received'. Aktivitas-aktivitas ini membentuk urutan peristiwa dalam alur proses.

Analisis urutan dan waktu aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan peta proses, menemukan hambatan, mengungkap penyimpangan dari prosedur standar, dan mengukur durasi setiap langkah.

Mengapa ini penting

Aktivitas adalah bagian dasar dari peta proses. Pelacakannya membantu memvisualisasikan dan menganalisis alur proses, hambatan, serta penyimpangan.

Sumber data

Ditentukan dari perubahan status di tabel seperti PO_HEADERS_ALL dan PO_ACTION_HISTORY, atau dari tabel transaksi tertentu seperti RCV_TRANSACTIONS untuk penerimaan barang.

Contoh
Purchase Order CreatedPurchase Order ApprovedBarang diterima
Pesanan pembelian
PurchaseOrder
Pengenal unik dokumen pesanan pembelian yang berfungsi sebagai ID kasus utama untuk melacak siklus pengadaan.
Deskripsi

Nomor pesanan pembelian menjadi pengenal utama yang menghubungkan semua aktivitas terkait, dari pembuatan hingga penutupan. Nomor ini memungkinkan analisis menyeluruh untuk satu kasus pengadaan.

Dalam process mining, setiap nomor pesanan pembelian yang unik mewakili satu kejadian proses. Analisis data berdasarkan pengenal ini membantu memahami variasi proses, waktu siklus, dan kepatuhan untuk setiap pesanan.

Mengapa ini penting

Ini adalah ID kasus utama yang menghubungkan semua peristiwa terkait, sehingga seluruh siklus pesanan pembelian dapat direkonstruksi dan dianalisis.

Sumber data

Oracle Fusion Cloud SCM, modul Procurement, tabel PO_HEADERS_ALL, kolom SEGMENT1.

Contoh
100234510023461002347
Waktu mulai
EventTime
Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi.
Deskripsi

Atribut ini mencatat tanggal dan waktu setiap aktivitas dalam proses secara tepat. Data ini menjadi dasar untuk mengurutkan peristiwa secara kronologis dan melakukan semua analisis berbasis waktu.

Dalam process mining, waktu mulai digunakan untuk menyusun log peristiwa, menghitung waktu siklus antaraktivitas, mengukur waktu tunggu, dan menganalisis kinerja proses dalam berbagai periode. Data ini penting untuk dashboard waktu siklus dan kinerja.

Mengapa ini penting

Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menghitung semua metrik durasi, seperti waktu siklus dan hambatan.

Sumber data

Kolom stempel waktu seperti CREATION_DATE dan LAST_UPDATE_DATE dari berbagai tabel, termasuk PO_HEADERS_ALL, PO_ACTION_HISTORY, dan RCV_SHIPMENT_LINES.

Contoh
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
Departemen
DepartmentName
Nama departemen yang mengajukan atau bertanggung jawab atas pesanan pembelian.
Deskripsi

Atribut ini menunjukkan unit organisasi yang terkait dengan pembelian, seperti 'Keuangan', 'TI', atau 'Manufaktur'. Atribut ini digunakan untuk alokasi biaya dan pelaporan organisasi.

Dalam process mining, pengelompokan proses berdasarkan departemen penting untuk membandingkan kinerja, menemukan hambatan khusus departemen, dan memahami perbedaan pelaksanaan proses di seluruh organisasi. Atribut ini mendukung dashboard seperti 'Analisis waktu siklus persetujuan PO' dan 'Tren perubahan pesanan pembelian'.

Mengapa ini penting

Memungkinkan Anda memfilter dan membandingkan kinerja proses di berbagai unit bisnis, sehingga masalah khusus departemen atau praktik yang baik dapat terlihat.

Sumber data

Ditentukan dari informasi pusat biaya di tabel seperti PO_DISTRIBUTIONS_ALL, yang terhubung dengan data induk departemen.

Contoh
Operasional TIPemasaranRiset dan pengembangan
Nama pemasok
VendorName
Nama pemasok yang menyediakan barang atau jasa yang dibeli.
Deskripsi

Atribut ini menunjukkan pemasok eksternal untuk pesanan pembelian. Data induk penting ini terhubung dengan header PO.

Analisis pemasok merupakan bagian penting dari process mining P2P. Dengan memfilter atau mengelompokkan data berdasarkan pemasok, perusahaan dapat menganalisis 'Kinerja pengiriman pemasok', membandingkan tingkat ketepatan waktu pengiriman, dan menyelidiki 'Tingkat pengembalian barang' untuk menemukan pemasok dengan kinerja tinggi atau rendah. Data ini penting untuk mengelola hubungan dengan pemasok dan strategi pengadaan.

Mengapa ini penting

Penting untuk menganalisis kinerja pemasok, termasuk membandingkan waktu pengiriman, tingkat pengembalian, dan keandalan secara keseluruhan.

Sumber data

Terhubung dari PO_HEADERS_ALL.VENDOR_ID ke POZ_SUPPLIERS.VENDOR_NAME.

Contoh
Global Office SuppliesTech Solutions Inc.Advanced Logistics Co.
Nama pemberi persetujuan
ApproverName
Nama pengguna yang menyetujui atau menolak pesanan pembelian.
Deskripsi

Atribut ini mencatat orang yang bertanggung jawab atas tahap persetujuan dalam alur kerja. Informasi ini biasanya tersimpan di tabel riwayat tindakan atau log alur kerja yang terkait dengan pesanan pembelian.

Analisis berdasarkan pemberi persetujuan penting untuk dashboard 'Analisis waktu siklus persetujuan PO' dan 'Beban kerja sumber daya persetujuan'. Analisis ini membantu menemukan pemberi persetujuan atau kelompok yang menjadi hambatan, menilai pembagian beban kerja secara adil, serta mengidentifikasi peluang untuk mendelegasikan tugas atau merancang ulang proses.

Mengapa ini penting

Menunjukkan orang-orang dalam alur persetujuan, sehingga hambatan, beban kerja, dan waktu siklus persetujuan dapat dianalisis berdasarkan pemberi persetujuan.

Sumber data

Pengguna yang melakukan tindakan, tercatat di PO_ACTION_HISTORY.ACTION_PERFORMED_BY dan terhubung ke tabel pengguna untuk mendapatkan nama lengkap.

Contoh
susan.managerdavid.directoremily.finance
Pengguna
UserName
ID pengguna atau nama orang yang melakukan aktivitas.
Deskripsi

Atribut ini menunjukkan karyawan atau pengguna sistem yang bertanggung jawab atas suatu peristiwa, seperti membuat permintaan pembelian, menyetujui PO, atau mencatat penerimaan barang. Sumbernya biasanya kolom seperti 'Created By' atau 'Last Updated By'.

Analisis proses berdasarkan pengguna membantu memahami pembagian beban kerja dan kinerja individu, serta menemukan kebutuhan pelatihan. Atribut ini penting untuk dashboard 'Beban kerja sumber daya persetujuan' dan untuk menyelidiki masalah kepatuhan terkait tindakan pengguna.

Mengapa ini penting

Mengaitkan tindakan pengguna dengan individu tertentu, sehingga beban kerja dan kinerja dapat dianalisis serta kebutuhan pelatihan dapat diketahui.

Sumber data

Gabungkan dengan tabel pengguna berdasarkan ID di kolom seperti CREATED_BY atau LAST_UPDATED_BY pada tabel PO_HEADERS_ALL dan PO_ACTION_HISTORY.

Contoh
john.doejane.smithsystem.batch
Tanggal pengiriman yang diminta
RequestedDeliveryDate
Tanggal saat pemohon mengharapkan barang atau jasa dikirimkan.
Deskripsi

Tanggal ini tercantum pada baris pesanan pembelian dan memberi tahu pemasok kapan barang diharapkan tiba. Tanggal ini menjadi acuan untuk mengukur ketepatan waktu pengiriman.

Atribut ini penting untuk menghitung KPI 'Tingkat ketepatan waktu pengiriman'. Dengan membandingkan tanggal penerimaan barang yang sebenarnya dengan tanggal pengiriman yang diminta, organisasi dapat mengukur dan melacak keandalan pemasok serta menemukan keterlambatan berulang dalam rantai pasok.

Mengapa ini penting

Menjadi acuan untuk mengukur ketepatan waktu pengiriman, KPI penting untuk menilai keandalan pemasok dan efisiensi rantai pasok.

Sumber data

Terdapat di tingkat lokasi baris, pada tabel PO_LINE_LOCATIONS_ALL, kolom NEED_BY_DATE.

Contoh
2023-05-202023-06-152023-07-01
Total nilai PO
PurchaseOrderTotalAmount
Nilai total pesanan pembelian.
Deskripsi

Atribut ini menunjukkan total biaya semua barang dalam pesanan pembelian, dalam mata uang yang ditentukan. Ini adalah metrik keuangan penting untuk memahami nilai transaksi yang melewati proses.

Analisis total nilai PO membantu menentukan prioritas perbaikan proses. Misalnya, pesanan bernilai tinggi dapat melalui proses persetujuan yang lebih ketat. Atribut ini juga memungkinkan analisis dampak keuangan, seperti menghitung nilai PO yang sering diubah atau tertunda.

Mengapa ini penting

Memberikan konteks keuangan untuk proses, sehingga analisis dapat dilakukan berdasarkan nilai uang, misalnya dengan berfokus pada pesanan bernilai tinggi atau memahami dampak keuangan dari keterlambatan.

Sumber data

Dihitung dengan menjumlahkan nilai dari PO_LINES_ALL untuk header PO tertentu, atau diambil dari total tingkat header jika tersedia.

Contoh
5250.00120000.50750.99
Waktu selesai
EndTime
Stempel waktu saat aktivitas selesai. Untuk peristiwa yang terjadi seketika, nilainya sering sama dengan waktu mulai.
Deskripsi

Untuk aktivitas yang memiliki durasi, waktu ini menandai saat aktivitas selesai. Untuk peristiwa seketika, nilainya biasanya sama dengan waktu mulai. Data ini penting untuk menghitung waktu pemrosesan setiap aktivitas.

Waktu selesai yang terpisah memungkinkan analisis durasi aktivitas yang lebih akurat, yang bisa berbeda dari waktu tunggu antaraktivitas. Dengan begitu, waktu kerja aktif dapat dibedakan dari waktu menganggur untuk mendukung analisis beban kerja sumber daya dan efisiensi.

Mengapa ini penting

Memungkinkan penghitungan waktu pemrosesan aktivitas secara akurat, yang penting untuk menganalisis efisiensi sumber daya dan menemukan tugas yang memakan waktu.

Sumber data

Untuk peristiwa seketika, nilainya dapat sama dengan waktu mulai atau ditentukan dari stempel waktu peristiwa berikutnya. Beberapa aktivitas mungkin memiliki stempel waktu penyelesaian tersendiri.

Contoh
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
Apakah pengiriman terlambat
IsLateDelivery
Penanda yang menunjukkan apakah penerimaan barang terakhir terjadi setelah tanggal pengiriman yang diminta.
Deskripsi

Atribut boolean hasil perhitungan ini bernilai true jika stempel waktu aktivitas 'Goods Received' lebih lambat daripada nilai pada atribut 'Requested Delivery Date' untuk Purchase Order tertentu.

Penanda ini menjadi dasar KPI 'On-Time Delivery Rate'. Anda dapat dengan mudah mengelompokkan dan menganalisis pesanan yang terlambat maupun yang tepat waktu, lalu menyelidiki penyebab keterlambatan, baik yang terkait dengan vendor, lokasi, maupun kategori produk tertentu.

Mengapa ini penting

Mendukung KPI 'On-Time Delivery Rate' secara langsung, sehingga Anda dapat menganalisis kinerja vendor dan keandalan pengiriman dengan jelas.

Sumber data

Kolom hasil perhitungan. Bernilai 'true' jika stempel waktu aktivitas 'Goods Received' lebih lambat daripada atribut 'RequestedDeliveryDate'.

Contoh
truefalse
Apakah perlu dikerjakan ulang
IsRework
Penanda yang menunjukkan apakah Purchase Order diubah setelah pertama kali dibuat.
Deskripsi

Atribut boolean hasil perhitungan ini bernilai true jika kasus Purchase Order memuat aktivitas 'Purchase Order Changed'. Atribut ini membantu Anda mengenali dengan cepat pesanan yang perlu dikoreksi atau diubah.

Penanda ini menyederhanakan perhitungan KPI 'PO Modification Rate' dan memudahkan Anda memfilter serta menganalisis pesanan yang dikerjakan ulang. Dengan memahami ciri-ciri pesanan tersebut, seperti vendor atau departemen yang terlibat, Anda dapat menemukan penyebab utama ketidakakuratan data atau perubahan kebutuhan.

Mengapa ini penting

Mendukung KPI 'PO Modification Rate' secara langsung dan memudahkan analisis ketidakstabilan proses dengan menandai semua pesanan yang mengalami perubahan.

Sumber data

Kolom hasil perhitungan. Bernilai 'true' jika log peristiwa untuk suatu kasus memuat aktivitas 'Purchase Order Changed', dan 'false' jika tidak.

Contoh
truefalse
Apakah persetujuan sesuai ketentuan
IsApprovalCompliant
Penanda yang menunjukkan apakah PO disetujui sebelum dikirim ke vendor.
Deskripsi

Atribut boolean hasil perhitungan ini memeriksa kepatuhan terhadap kontrol internal utama: Purchase Order harus disetujui sebelum dikirim ke pemasok. Nilainya true jika aktivitas 'Purchase Order Approved' terjadi sebelum aktivitas 'Purchase Order Sent to Vendor'.

Atribut ini penting untuk dashboard 'PO Process Compliance Audit' dan KPI 'PO Approval Compliance Rate'. Atribut ini memudahkan Anda mengenali dan mengukur pelanggaran kepatuhan, membantu menegakkan kebijakan pengadaan, serta mengurangi risiko pengeluaran tanpa otorisasi.

Mengapa ini penting

Mengukur KPI 'PO Approval Compliance Rate' secara langsung dan menyoroti pelanggaran kontrol internal yang serius, yaitu pesanan dikirim ke vendor sebelum disetujui.

Sumber data

Kolom hasil perhitungan. Bernilai 'true' jika stempel waktu 'Purchase Order Approved' kurang dari atau sama dengan stempel waktu 'Purchase Order Sent to Vendor'.

Contoh
truefalse
Jenis PO
PurchaseOrderType
Jenis pesanan pembelian, seperti 'Standar', 'Payung', atau 'Kontrak'.
Deskripsi

Atribut ini mengelompokkan pesanan pembelian berdasarkan tujuan pengadaannya. Jenis PO yang berbeda sering mengikuti aturan dan siklus proses yang berbeda.

PO 'Standar' digunakan untuk pembelian satu kali, sedangkan PO 'Payung' merupakan perjanjian jangka panjang dengan pemasok. Analisis berdasarkan jenis PO memberikan gambaran kinerja proses yang lebih akurat. Membandingkan waktu siklus PO standar dengan perjanjian payung, misalnya, tidak akan memberikan perbandingan yang setara.

Mengapa ini penting

Membedakan berbagai skenario pengadaan, sehingga kinerja proses dapat dibandingkan secara akurat untuk jenis pesanan yang serupa.

Sumber data

Oracle Fusion Cloud SCM, tabel PO_HEADERS_ALL, kolom TYPE_LOOKUP_CODE.

Contoh
STANDARDBLANKETCONTRACT
Kategori pembelian
PurchaseCategory
Klasifikasi barang atau jasa yang dibeli, seperti 'Perangkat keras TI' atau 'Perlengkapan kantor'.
Deskripsi

Atribut ini mengelompokkan barang dalam pesanan pembelian ke dalam hierarki pengadaan. Klasifikasi ini digunakan untuk analisis belanja dan pengelolaan pemasok.

Dalam process mining, pengelompokan proses berdasarkan kategori pembelian dapat menunjukkan perbedaan alur atau kinerja. Misalnya, proses persetujuan belanja modal mungkin lebih lama daripada persetujuan perlengkapan operasional. Atribut ini juga mendukung dashboard 'Tingkat dan alasan pengembalian barang' dengan menunjukkan kategori yang paling sering dikembalikan.

Mengapa ini penting

Memungkinkan analisis proses berdasarkan jenis belanja, sehingga perbedaan alur proses, hambatan, atau tingkat pengembalian antarjenis barang dapat diketahui.

Sumber data

Terhubung dari PO_LINES_ALL.CATEGORY_ID ke tampilan EGP_CATEGORIES_VL.

Contoh
TI.Perangkat keras.LaptopKantor.Perlengkapan.Alat tulisJasa profesional.Konsultasi
Lokasi pengiriman
DeliveryLocation
Lokasi atau alamat fisik tempat barang harus dikirim.
Deskripsi

Atribut ini menentukan alamat tujuan pengiriman barang dalam pesanan pembelian. Ini adalah informasi logistik yang penting.

Dalam process mining, analisis berdasarkan lokasi pengiriman mendukung dashboard 'Efisiensi pemrosesan penerimaan barang'. Analisis ini membantu mengetahui apakah proses penerimaan di gudang atau lokasi tertentu lebih lambat, yang dapat menunjukkan masalah sumber daya atau proses di lokasi tersebut.

Mengapa ini penting

Memungkinkan analisis kinerja berdasarkan lokasi geografis, sehingga hambatan di wilayah atau lokasi tertentu dalam proses penerimaan barang dapat diketahui.

Sumber data

Terhubung dari PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID ke tampilan HR_LOCATIONS_ALL.

Contoh
Gudang utama - Dermaga AGedung 3 - ResepsionisKantor SF - Lantai 10
Pembaruan data terakhir
LastDataUpdate
Stempel waktu saat data terakhir diekstrak atau diperbarui dari sistem sumber.
Deskripsi

Atribut ini menunjukkan seberapa baru data yang dianalisis. Atribut ini mencatat tanggal dan waktu pengambilan data terbaru dari Oracle Fusion Financials.

Informasi ini membantu pengguna memahami kemutakhiran analisis dan dashboard. Dengan begitu, pengguna tahu seberapa baru wawasan proses yang tersedia dan dapat memahami apakah transaksi terbaru sudah tercakup.

Mengapa ini penting

Menunjukkan kemutakhiran data dengan jelas, sehingga pengguna memahami seberapa baru analisis proses yang tersedia.

Sumber data

Stempel waktu ini dibuat dan ditambahkan selama proses ekstraksi dan transformasi data (ETL).

Contoh
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Permintaan pembelian
PurchaseRequisitionNumber
Pengenal permintaan pembelian yang dibuat sebelum dan menjadi dasar persetujuan pesanan pembelian.
Deskripsi

Permintaan pembelian adalah dokumen internal untuk mengajukan pembelian barang atau jasa. Atribut ini menghubungkan pesanan pembelian dengan permintaan awalnya.

Nomor permintaan pembelian memungkinkan analisis proses pengadaan yang lebih luas, dimulai dari permintaan awal, bukan hanya dari PO. Data ini membantu menganalisis waktu siklus dari permintaan hingga pesanan dan memahami pengaruh detail permintaan terhadap proses PO berikutnya.

Mengapa ini penting

Menghubungkan PO dengan permintaan awal, sehingga proses dari permintaan hingga pembayaran dapat dianalisis secara menyeluruh.

Sumber data

Terhubung melalui tabel PO_DISTRIBUTIONS_ALL yang berisi REQ_DISTRIBUTION_ID dan dapat ditelusuri kembali ke tabel POR_REQUISITION_LINES_ALL.

Contoh
PR-2023-05-001PR-2023-05-002PR-2023-05-003
Sistem sumber
SourceSystem
Sistem informasi tempat data ini diekstrak.
Deskripsi

Atribut ini menunjukkan asal data, terutama berguna jika organisasi menggunakan beberapa sistem terintegrasi. Untuk proses ini, nilainya biasanya 'Oracle Fusion Financials'.

Nilainya sering kali tetap untuk satu set data, tetapi penting untuk tata kelola data, pemecahan masalah, dan memastikan asal-usul data dapat ditelusuri. Jika analisis menggabungkan beberapa sumber, atribut ini memungkinkan data difilter dan dikelompokkan berdasarkan sistem asal.

Mengapa ini penting

Menunjukkan asal data, yang penting untuk tata kelola data, konteks, dan integrasi dengan sistem lain.

Sumber data

Biasanya berupa nilai tetap yang ditentukan dan ditambahkan selama proses ekstraksi dan transformasi data (ETL).

Contoh
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
Status PO
PurchaseOrderStatus
Status terkini dokumen pesanan pembelian.
Deskripsi

Atribut ini menunjukkan posisi pesanan pembelian dalam siklusnya, seperti 'Open', 'Approved', 'Finally Closed', atau 'Canceled'. Atribut ini memberikan gambaran status PO saat ini.

Process mining berfokus pada urutan aktivitas, tetapi status saat ini berguna untuk memfilter kasus. Misalnya, analisis dapat difokuskan hanya pada PO yang masih terbuka untuk memahami antrean saat ini, atau pada PO yang sudah ditutup untuk menganalisis proses yang selesai. Atribut ini penting untuk dashboard 'Alur dan status pesanan pembelian'.

Mengapa ini penting

Memberikan gambaran status terkini pesanan pembelian, sehingga analisis dapat difilter untuk pesanan aktif, selesai, atau dibatalkan.

Sumber data

Oracle Fusion Cloud SCM, tabel PO_HEADERS_ALL, kolom AUTHORIZATION_STATUS atau DOCUMENT_STATUS.

Contoh
OPENAPPROVEDFINALLY_CLOSEDCANCELED
Unit bisnis
BusinessUnitName
Unit bisnis tertentu dalam organisasi yang melakukan pembelian.
Deskripsi

Unit bisnis adalah entitas bisnis tersendiri dalam perusahaan, sering kali dengan buku besar dan pelaporan keuangannya sendiri. Di Oracle Fusion, unit bisnis menjadi mekanisme utama untuk memisahkan data.

Analisis kinerja proses berdasarkan unit bisnis penting bagi perusahaan besar dan multinasional. Analisis ini memungkinkan perbandingan efisiensi pengadaan, kepatuhan, dan biaya di berbagai bagian organisasi, sekaligus menunjukkan praktik yang baik dan area yang perlu diperbaiki.

Mengapa ini penting

Penting bagi organisasi besar untuk membandingkan efisiensi proses dan kepatuhan di berbagai divisi operasional.

Sumber data

Informasi unit bisnis biasanya terdapat di header PO, PO_HEADERS_ALL.PRC_BU_ID, yang terhubung ke tampilan FUN_ALL_BUSINESS_UNITS_V.

Contoh
Unit bisnis ASEMEA VisionAPAC Services
Wajib Disarankan Opsional

Aktivitas Purchase to Pay - Purchase Order

Berikut langkah dan tonggak proses utama yang perlu dicatat dalam log peristiwa agar proses Purchase to Pay - Purchase Order dapat ditemukan dengan akurat.
6 Disarankan 10 Opsional
Aktivitas Deskripsi
Barang diterima
Barang telah diterima secara fisik, dihitung, dan dicatat terhadap pesanan pembelian. Peristiwa transaksi ini memperbarui persediaan dan status PO.
Mengapa ini penting

Tahap ini menjadi tonggak penting untuk mengukur ketepatan waktu pengiriman pemasok dan total waktu tunggu. Tahap ini juga memicu aktivitas berikutnya, seperti pemeriksaan kualitas dan pencocokan faktur.

Sumber data

Peristiwa ini tercatat secara eksplisit di tabel RCV_TRANSACTIONS. Transaksi dapat dikenali dari nilai TRANSACTION_TYPE 'RECEIVE'.

Pengumpulan data

Gunakan TRANSACTION_DATE dari RCV_TRANSACTIONS dengan TRANSACTION_TYPE 'RECEIVE'.

Jenis peristiwa explicit
Pesanan pembelian dibatalkan
Pesanan pembelian dibatalkan secara permanen dan tidak ada transaksi lanjutan yang diharapkan. Tindakan ini mengubah status akhir dokumen secara eksplisit.
Mengapa ini penting

Aktivitas ini menandai kondisi akhir yang tidak diharapkan dalam proses. Analisis pembatalan dapat mengungkap masalah seperti pesanan ganda, perubahan anggaran, atau perubahan kebutuhan proyek.

Sumber data

Tindakan ini tercatat di tabel PO_ACTION_HISTORY dengan ACTION_CODE 'CANCEL'. Status PO di PO_HEADERS_ALL juga diperbarui.

Pengumpulan data

Filter PO_ACTION_HISTORY dengan ACTION_CODE = 'CANCEL'.

Jenis peristiwa explicit
Pesanan pembelian ditutup sepenuhnya
Pesanan pembelian dianggap selesai, artinya seluruh barang telah diterima dan/atau faktur telah diproses, tanpa aktivitas lanjutan yang diharapkan. Tindakan ini secara eksplisit menetapkan status akhir pada PO.
Mengapa ini penting

Aktivitas ini menandai penyelesaian siklus pesanan pembelian. Ini adalah kondisi akhir positif utama. Pelacakannya penting untuk mengukur throughput proses secara keseluruhan dan tingkat penyelesaian.

Sumber data

Peristiwa ini tercatat di tabel PO_ACTION_HISTORY dengan ACTION_CODE 'FINALLY CLOSE'. Status PO di PO_HEADERS_ALL juga diperbarui menjadi 'Finally Closed'.

Pengumpulan data

Filter PO_ACTION_HISTORY dengan ACTION_CODE = 'FINALLY CLOSE'.

Jenis peristiwa explicit
Purchase Order Approved
Purchase order telah menerima semua persetujuan yang diperlukan dan kini boleh dikirim kepada pemasok. Tahap penting ini tercatat secara eksplisit dalam riwayat tindakan dokumen.
Mengapa ini penting

Tahap penting ini menentukan apakah PO boleh dikirim kepada pemasok. Data ini penting untuk mengukur waktu siklus persetujuan dan memastikan kepatuhan terhadap kebijakan belanja.

Sumber data

Kejadian ini tercatat di tabel PO_ACTION_HISTORY, biasanya dengan ACTION_CODE 'APPROVE', atau saat status dokumen di PO_HEADERS_ALL berubah menjadi status disetujui.

Pengumpulan data

Filter PO_ACTION_HISTORY untuk tindakan 'APPROVE' terakhir.

Jenis peristiwa explicit
Purchase Order Created
Ini adalah awal resmi siklus purchase order, saat dokumen PO dibuat dengan status draf atau belum lengkap. Sistem mencatat kejadian ini melalui stempel waktu pembuatan catatan header PO yang baru.
Mengapa ini penting

Sebagai kejadian awal utama untuk kasus PO, aktivitas ini menjadi dasar semua perhitungan waktu siklus. Aktivitas ini digunakan untuk mengukur efisiensi tahap berikutnya, seperti persetujuan dan komunikasi dengan pemasok.

Sumber data

Kejadian ini tercatat secara eksplisit berdasarkan kolom CREATION_DATE di tabel PO_HEADERS_ALL untuk ID Purchase Order (PO_HEADER_ID) tertentu.

Pengumpulan data

Gunakan stempel waktu pembuatan dari tabel PO_HEADERS_ALL.

Jenis peristiwa explicit
Purchase Order Sent to Vendor
Purchase order yang telah disetujui dikirim secara resmi kepada pemasok, misalnya melalui email atau EDI. Kejadian ini sering disimpulkan dari perubahan status atau stempel waktu pada catatan komunikasi PO.
Mengapa ini penting

Tahap ini menandai dimulainya waktu tunggu pemasok. Ini menjadi titik penting untuk mengukur kinerja pemasok, dari konfirmasi hingga pengiriman akhir.

Sumber data

Kejadian ini dapat disimpulkan saat status dokumen PO berubah menjadi 'Open' dan tanggal komunikasi terisi. Kolom yang digunakan biasanya PO_HEADERS_ALL.communicated_date atau status terkait.

Pengumpulan data

Simpulkan kejadian ini dari stempel waktu saat status komunikasi PO diperbarui menjadi 'Communicated'.

Jenis peristiwa inferred
Barang dikembalikan ke pemasok
Barang yang sebelumnya diterima dikirim kembali ke pemasok, biasanya karena cacat, rusak, atau kiriman tidak sesuai. Pengembalian ini dicatat sebagai transaksi khusus di modul penerimaan.
Mengapa ini penting

Pelacakan pengembalian penting untuk menilai kualitas pemasok dan ketepatan pesanan. Tingkat pengembalian yang tinggi dari pemasok dapat menandakan masalah berulang yang perlu ditangani.

Sumber data

Peristiwa ini tercatat secara eksplisit di tabel RCV_TRANSACTIONS dengan TRANSACTION_TYPE 'RETURN TO VENDOR'.

Pengumpulan data

Gunakan TRANSACTION_DATE dari RCV_TRANSACTIONS dengan TRANSACTION_TYPE 'RETURN TO VENDOR'.

Jenis peristiwa explicit
Dokumen penerimaan barang dibuat
Dokumen penerimaan dibuat di sistem sebagai persiapan kedatangan barang secara fisik. Aktivitas ini menandai dimulainya proses penerimaan internal.
Mengapa ini penting

Tahap ini menandai peralihan dari pengadaan ke logistik. Analisis waktu sejak tahap ini hingga penerimaan barang dicatat membantu menemukan inefisiensi di gudang atau bagian penerimaan.

Sumber data

Peristiwa ini tercatat secara eksplisit melalui waktu pembuatan rekaman baru di tabel RCV_SHIPMENT_HEADERS yang terhubung dengan pesanan pembelian.

Pengumpulan data

Gunakan tanggal pembuatan rekaman terkait di RCV_SHIPMENT_HEADERS.

Jenis peristiwa explicit
Konfirmasi layanan telah diberikan
Untuk pesanan pembelian jasa, aktivitas ini menandai konfirmasi bahwa layanan telah diberikan sesuai kesepakatan. Konfirmasi biasanya dicatat secara manual atau melalui lembar pencatatan layanan.
Mengapa ini penting

Tahap ini setara dengan penerimaan barang untuk pembelian jasa dan harus dilakukan sebelum faktur dapat dibayar. Keterlambatan konfirmasi layanan dapat menyebabkan pembayaran terlambat dan merenggangkan hubungan dengan pemasok.

Sumber data

Aktivitas ini biasanya dicatat sebagai penerimaan untuk baris jasa pada PO. Pencatatannya dapat menggunakan kolom khusus atau transaksi penerimaan kompleks untuk melacak kemajuan atau penyelesaian layanan.

Pengumpulan data

Identifikasi transaksi penerimaan (RCV_TRANSACTIONS) yang terhubung dengan baris PO untuk jasa.

Jenis peristiwa explicit
Pemeriksaan kualitas dilakukan
Barang yang memerlukan pemeriksaan kualitas telah diperiksa, lalu diterima atau ditolak. Aktivitas ini berlangsung setelah penerimaan awal dan dicatat sebagai transaksi tersendiri.
Mengapa ini penting

Aktivitas ini penting untuk pengelolaan kualitas. Analisis durasi pemeriksaan membantu menyederhanakan proses kontrol kualitas dan mengurangi keterlambatan sebelum barang siap digunakan.

Sumber data

Aktivitas ini tercatat di tabel RCV_TRANSACTIONS. Aktivitas dikenali dari transaksi dengan TRANSACTION_TYPE 'ACCEPT' atau 'REJECT' yang terjadi setelah transaksi penerimaan.

Pengumpulan data

Gunakan TRANSACTION_DATE dari RCV_TRANSACTIONS dengan TRANSACTION_TYPE 'ACCEPT' atau 'REJECT'.

Jenis peristiwa explicit
Purchase Order Acknowledged
Pemasok telah mengonfirmasi penerimaan dan persetujuan atas ketentuan purchase order. Staf pengadaan biasanya mencatat kejadian ini secara manual berdasarkan komunikasi dengan pemasok atau melalui konfirmasi elektronik.
Mengapa ini penting

Konfirmasi pemasok memastikan pesanan telah diterima dan sedang diproses. Dengan melacaknya, Anda dapat mengelola komunikasi dengan pemasok dan lebih awal menemukan potensi masalah pemenuhan pesanan.

Sumber data

Kejadian ini biasanya disimpulkan dari perubahan kolom status konfirmasi pada header atau baris PO, misalnya saat PO_HEADERS_ALL.acceptance_status berubah menjadi 'Accepted'.

Pengumpulan data

Simpulkan kejadian ini dari pembaruan kolom status konfirmasi PO.

Jenis peristiwa inferred
Purchase Order Changed
Pesanan pembelian diubah setelah persetujuan awal, misalnya jumlah, harga, atau tanggal pengiriman. Oracle Fusion mencatat perubahan ini dengan membuat revisi dokumen baru.
Mengapa ini penting

Perubahan PO menunjukkan adanya pengerjaan ulang dan dapat menandakan masalah pada ketepatan pesanan awal atau perubahan kebutuhan bisnis. Analisis frekuensi dan jenis perubahan membantu menemukan peluang untuk meningkatkan efisiensi proses.

Sumber data

Peristiwa ini tercatat secara eksplisit saat revisi dokumen baru dibuat. Perubahan dapat diketahui dari kenaikan nilai pada kolom REVISION_NUM di tabel PO_HEADERS_ALL.

Pengumpulan data

Identifikasi setiap kejadian saat nilai REVISION_NUM untuk PO_HEADER_ID bertambah.

Jenis peristiwa explicit
Purchase Order Rejected
Pemberi persetujuan menolak purchase order dan mengembalikannya kepada pembuat untuk diperbaiki. Kejadian ini tercatat secara eksplisit dalam riwayat tindakan dan menandakan penyimpangan dari alur proses standar.
Mengapa ini penting

Penolakan menambah pekerjaan ulang dan keterlambatan. Dengan melacak aktivitas ini, Anda dapat menemukan alasan penolakan yang umum, kebutuhan pelatihan, atau persyaratan persetujuan yang kurang jelas.

Sumber data

Tindakan ini tercatat di tabel PO_ACTION_HISTORY dengan ACTION_CODE 'REJECT' untuk PO_HEADER_ID terkait.

Pengumpulan data

Filter PO_ACTION_HISTORY berdasarkan ACTION_CODE = 'REJECT'.

Jenis peristiwa explicit
Purchase Order Submitted
Purchase order yang telah dibuat diajukan ke alur kerja persetujuan. Oracle Fusion mencatat tindakan ini secara eksplisit, termasuk pengguna dan stempel waktu pengajuan.
Mengapa ini penting

Aktivitas ini menandai dimulainya siklus persetujuan. Menganalisis waktu antara pengajuan dan persetujuan penting untuk menemukan hambatan dalam proses persetujuan internal.

Sumber data

Tindakan ini tercatat di tabel PO_ACTION_HISTORY dengan ACTION_CODE 'SUBMIT' untuk PO_HEADER_ID terkait.

Pengumpulan data

Filter PO_ACTION_HISTORY berdasarkan ACTION_CODE = 'SUBMIT'.

Jenis peristiwa explicit
Purchase Requisition Approved
Pihak yang berwenang telah menyetujui purchase requisition, sehingga bagian pengadaan dapat membuat purchase order. Kejadian ini tercatat secara eksplisit dalam riwayat tindakan permintaan di sistem.
Mengapa ini penting

Tahap ini menandai berakhirnya proses persetujuan internal atas permintaan. Keterlambatan pada tahap ini dapat berdampak langsung pada seluruh jadwal pengadaan, sehingga durasinya penting untuk dipantau.

Sumber data

Kejadian ini tercatat dalam riwayat tindakan yang terkait dengan permintaan, biasanya melalui tabel alur kerja atau kolom status persetujuan tertentu pada dokumen permintaan.

Pengumpulan data

Tercatat sebagai tindakan persetujuan dalam riwayat alur kerja untuk dokumen permintaan terkait.

Jenis peristiwa explicit
Purchase Requisition Created
Aktivitas ini menandai pembuatan purchase requisition, yaitu permintaan resmi atas barang atau jasa yang dibuat sebelum purchase order. Aktivitas ini tercatat saat entri baru dibuat pada tabel header permintaan di Oracle Fusion.
Mengapa ini penting

Analisis aktivitas ini membantu memahami tahap awal munculnya permintaan. Dengan melacak waktu dari pembuatan permintaan hingga purchase order, Anda dapat menemukan keterlambatan dalam mengubah kebutuhan internal menjadi pesanan pengadaan.

Sumber data

Kejadian ini tercatat secara eksplisit saat permintaan baru disimpan. Anda dapat menemukannya dengan melacak stempel waktu pembuatan di tabel POR_REQUISITION_HEADERS_ALL.

Pengumpulan data

Kejadian ini didasarkan pada tanggal pembuatan catatan di tabel POR_REQUISITION_HEADERS_ALL.

Jenis peristiwa explicit
Disarankan Opsional

Panduan ekstraksi

Cara mengambil data dari Oracle Fusion Financials

Siap memulai?

Gunakan templat ini untuk menyederhanakan pengumpulan data dan mulai menemukan wawasan tentang proses Purchase to Pay - Purchase Order. Mulai optimalkan operasional Anda hari ini.

Optimalkan proses Purchase to Pay - Purchase Order Anda sekarang

Temukan hambatan yang merugikan dan kurangi waktu siklus hingga 30% dengan mudah.

Mulai uji coba gratis

Tidak perlu kartu kredit. Mulai optimalkan proses Anda hari ini.