Templat data Purchase to Pay - Purchase Order Anda
Templat data Purchase to Pay - Purchase Order Anda
- 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
Atribut Purchase to Pay - Purchase Order
| 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
|
|||
Aktivitas Purchase to Pay - Purchase Order
| 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
|
|||
Panduan ekstraksi
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.
Tidak perlu kartu kredit. Mulai optimalkan proses Anda hari ini.