Templat data pemrosesan pesanan penjualan hingga pembayaran
Templat data pemrosesan pesanan penjualan hingga pembayaran
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan praktis ekstraksi data
Atribut pemrosesan pesanan penjualan hingga pembayaran
| Nama | Deskripsi | ||
|---|---|---|---|
| Pesanan Penjualan SalesOrder | Pengenal unik untuk pesanan penjualan, yang menjadi kasus utama dalam proses Order to Cash. | ||
| Deskripsi Nomor Pesanan Penjualan menjadi pengenal unik untuk setiap pesanan pelanggan sepanjang siklusnya. Nomor ini menghubungkan semua aktivitas terkait, mulai dari pembuatan dan konfirmasi hingga pemenuhan, pembuatan faktur, dan pembayaran akhir. Dalam process mining, atribut ini penting untuk mengelompokkan semua peristiwa terkait ke dalam satu kasus. Analisis berdasarkan Pesanan Penjualan memberikan gambaran proses dari awal hingga akhir. Anda dapat menghitung waktu siklus total, menemukan variasi proses pada setiap pesanan, dan melacak perjalanan pesanan di berbagai departemen dan sistem. Mengapa ini penting Ini adalah ID Kasus. ID ini menghubungkan semua peristiwa proses sehingga Anda dapat menelusuri perjalanan satu pesanan pelanggan dari awal hingga akhir. Sumber data Pengenal ini biasanya terdapat di tabel header pesanan penjualan Oracle Fusion, seperti DOO_HEADERS_ALL. Lihat dokumentasi Oracle Fusion Financials. Contoh SO-100567SO-100568SO-100569 | |||
| Nama Aktivitas ActivityName | Nama peristiwa bisnis atau tugas tertentu yang terjadi dalam proses pesanan penjualan. | ||
| Deskripsi Atribut ini menjelaskan langkah yang dijalankan pada waktu tertentu dalam proses pesanan penjualan, seperti 'Pesanan Penjualan Dibuat', 'Barang Dikirim', atau 'Pembayaran Diterima'. Urutan aktivitas ini membentuk alur proses untuk setiap kasus. Analisis ActivityName merupakan dasar process mining. Atribut ini membantu memvisualisasikan peta proses, menemukan variasi proses, dan mengidentifikasi hambatan tempat kasus menumpuk. Atribut ini juga menjadi dasar untuk menghitung waktu antar langkah dan memahami urutan operasional proses Order to Cash. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam peta proses sehingga alur proses dapat divisualisasikan dan dianalisis. Sumber data Atribut ini diturunkan dengan memetakan status transaksi atau jenis peristiwa dari berbagai tabel Oracle Fusion, misalnya status pesanan, pengiriman, dan faktur, ke daftar nama aktivitas yang telah distandardisasi. Contoh Pesanan penjualan dibuatBarang dikirimFaktur dibuatPembayaran Diterima | |||
| Waktu Peristiwa EventTime | Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi pada pesanan penjualan. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu setiap aktivitas dalam proses, sehingga urutan peristiwa dapat diketahui. Data ini menjadi dasar waktu untuk analisis proses dan mencatat kapan setiap langkah berlangsung. Dalam process mining, EventTime penting untuk menghitung waktu siklus, durasi antaraktivitas, dan waktu penyelesaian keseluruhan kasus. Data ini mendukung analisis kinerja, deteksi hambatan berdasarkan waktu tunggu, serta pemantauan kepatuhan terhadap perjanjian tingkat layanan (SLA) terkait ketepatan waktu. Semua KPI dan dashboard berbasis waktu bergantung pada keakuratan atribut ini. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis dan menghitung semua metrik berbasis waktu, seperti waktu siklus dan durasi. Sumber data Atribut ini diturunkan dari berbagai kolom stempel waktu di tabel Oracle Fusion, seperti tanggal pembuatan pesanan, pengiriman, faktur, dan pembayaran. Contoh 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Diotomatisasi IsAutomated | Penanda yang menunjukkan apakah aktivitas dijalankan otomatis oleh sistem atau secara manual oleh pengguna. | ||
| Deskripsi Atribut boolean ini membedakan peristiwa yang dijalankan sistem, seperti pemeriksaan kredit otomatis atau faktur yang dibuat sistem, dari tindakan manual pengguna. Biasanya, atribut ini diturunkan dari nama pengguna yang terkait dengan aktivitas. ID sistem umum menandakan otomatisasi. Analisis atribut ini membantu mengukur tingkat otomatisasi proses dan menjadi masukan langsung untuk KPI 'Persentase Pesanan yang Dikerjakan Ulang Secara Manual'. Atribut ini dapat menunjukkan peluang otomatisasi lebih lanjut dengan mengungkap langkah manual yang paling memakan waktu atau rentan terhadap kesalahan. Mengapa ini penting Membantu mengukur tingkat otomatisasi proses dan menemukan peluang untuk mengurangi intervensi manual yang mahal. Sumber data Kolom ini diturunkan, biasanya berdasarkan aturan yang diterapkan pada atribut UserName. Contohnya, jika penggunanya 'SYSTEM' atau 'BATCH', penanda ini diatur ke true. Contoh truefalse | |||
| Nama Pelanggan CustomerName | Nama pelanggan yang membuat pesanan penjualan. | ||
| Deskripsi Atribut ini menunjukkan nama resmi akun pelanggan yang terkait dengan pesanan penjualan. Atribut ini menjadi dimensi penting untuk mengelompokkan dan menganalisis proses dari sudut pandang pelanggan. Analisis berdasarkan pelanggan membantu menemukan pelanggan yang mengalami waktu siklus lebih lama, lebih banyak pengerjaan ulang, atau penyimpangan proses tertentu. Temuan ini dapat digunakan untuk meningkatkan layanan pelanggan, menyesuaikan proses bagi pelanggan utama, dan menyelidiki masalah yang memengaruhi kepuasan pelanggan. Mengapa ini penting Mendukung analisis yang berfokus pada pelanggan untuk menemukan masalah proses yang memengaruhi pelanggan tertentu dan meningkatkan kepuasan mereka. Sumber data Diambil dari tabel data induk pelanggan, seperti HZ_PARTIES, lalu ditautkan ke pesanan penjualan melalui ID pelanggan. Contoh Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Nama Pengguna UserName | Nama atau ID pengguna yang menjalankan aktivitas. | ||
| Deskripsi Atribut ini mengidentifikasi karyawan atau pengguna sistem yang bertanggung jawab menjalankan langkah proses tertentu. Atribut ini dapat digunakan untuk menganalisis kinerja pengguna, pembagian beban kerja, dan kepatuhan terhadap prosedur standar. Analisis berdasarkan pengguna membantu menemukan kebutuhan pelatihan, mengenali individu atau tim berkinerja tinggi, dan menyelidiki penyimpangan yang disebabkan oleh pengguna tertentu. Informasi ini juga berguna untuk kepatuhan dan audit karena mencatat siapa yang melakukan setiap tindakan. Mengapa ini penting Mendukung analisis kinerja per pengguna dan pembagian beban kerja, serta membantu menemukan pola pengerjaan ulang manual yang terkait dengan individu. Sumber data Biasanya diambil dari kolom seperti CREATED_BY atau LAST_UPDATED_BY di tabel transaksi Oracle Fusion, yang sering ditautkan ke tabel induk pengguna seperti FND_USER. Contoh john.smithjane.doesystem_batch_user | |||
| Saluran Penjualan SalesChannel | Saluran yang digunakan untuk menerima pesanan penjualan. | ||
| Deskripsi Atribut ini mengelompokkan asal pesanan penjualan, seperti 'Web', 'Penjualan Langsung', 'Mitra', atau 'EDI'. Informasi ini menunjukkan bagaimana pesanan masuk ke organisasi. Pengelompokan proses berdasarkan saluran penjualan penting untuk dashboard 'Ringkasan Kinerja Saluran Penjualan'. Anda dapat membandingkan efisiensi, waktu siklus, dan tingkat kesalahan tiap saluran untuk mengetahui saluran yang paling efektif dan saluran yang mungkin perlu diperbaiki atau diotomatisasi lebih lanjut. Mengapa ini penting Mendukung analisis kinerja per saluran dan membantu menemukan saluran yang paling efisien maupun yang paling tidak efisien dalam memproses pesanan. Sumber data Informasi ini mungkin tersimpan di kolom khusus pada header pesanan penjualan. Lihat dokumentasi Oracle Fusion Financials. Contoh Penjualan LangsungPortal WebEDIPenjual Kembali | |||
| Tanggal Jatuh Tempo Pembayaran PaymentDueDate | Tanggal batas pelanggan harus membayar faktur. | ||
| Deskripsi Tanggal Jatuh Tempo Pembayaran dihitung berdasarkan tanggal faktur dan ketentuan pembayaran yang disepakati dengan pelanggan. Tanggal ini menjadi batas waktu penagihan pembayaran. Atribut ini penting untuk KPI 'Tingkat Penagihan Pembayaran Tepat Waktu'. Dengan membandingkan PaymentDueDate dengan tanggal pembayaran diterima, sistem dapat menentukan apakah pembayaran tepat waktu atau terlambat. Informasi ini membantu memantau kinerja piutang dan mengelola arus kas. Mengapa ini penting Menjadi batas waktu untuk menghitung tingkat pembayaran tepat waktu, yang merupakan ukuran penting efisiensi arus kas. Sumber data Terdapat di tabel piutang atau faktur Oracle Fusion, seperti AR_PAYMENT_SCHEDULES_ALL. Contoh 2023-06-192023-07-012023-06-25 | |||
| Tanggal Pengantaran Aktual ActualDeliveryDate | Tanggal barang benar-benar diantarkan kepada pelanggan. | ||
| Deskripsi Atribut ini mencatat tanggal pengantaran akhir, yang menandai selesainya tahap pemenuhan dalam proses. Tanggal ini menunjukkan hasil aktual yang dibandingkan dengan tanggal rencana atau permintaan. Tanggal ini dibandingkan dengan RequestedDeliveryDate untuk menghitung kinerja pengantaran tepat waktu. Data ini penting untuk KPI 'Tingkat Pengantaran Tepat Waktu' dan dashboard 'SLA Pengantaran', serta memberikan ukuran yang jelas tentang efektivitas logistik dan rantai pasok. Mengapa ini penting Tanggal hasil aktual ini digunakan untuk menghitung tingkat pengantaran tepat waktu dan menilai kinerja pemenuhan berdasarkan permintaan pelanggan. Sumber data Diambil dari tabel transaksi pengiriman dan pengantaran Oracle Fusion. Lihat dokumentasi Oracle Fusion Financials. Contoh 2023-05-202023-06-032023-05-25 | |||
| Tanggal Pengantaran yang Diminta RequestedDeliveryDate | Tanggal pengantaran pesanan yang diminta pelanggan. | ||
| Deskripsi Atribut ini mencatat tanggal pelanggan ingin menerima barang. Tanggal ini menjadi target kinerja utama untuk tahap pemenuhan dalam proses Order to Cash. Tanggal ini penting untuk menghitung KPI 'Tingkat Pengantaran Tepat Waktu' dan mendukung dashboard 'Perjanjian Tingkat Layanan Pengantaran (SLA)'. Dengan membandingkannya dengan ActualDeliveryDate, organisasi dapat mengukur kemampuannya memenuhi harapan pelanggan dan menemukan akar penyebab keterlambatan pengantaran. Mengapa ini penting Menjadi acuan untuk mengukur kinerja pengantaran tepat waktu dan kepatuhan terhadap perjanjian tingkat layanan (SLA) pelanggan. Sumber data Biasanya terdapat di tabel baris pesanan penjualan Oracle Fusion. Lihat dokumentasi Oracle Fusion Financials. Contoh 2023-05-202023-06-012023-05-25 | |||
| Total Nilai Pesanan Penjualan SalesOrderTotalAmount | Nilai total pesanan penjualan. | ||
| Deskripsi Atribut ini menunjukkan jumlah total yang ditagihkan kepada pelanggan untuk seluruh pesanan penjualan. Nilainya mencakup semua baris barang, pajak, dan biaya lainnya sebelum diskon diterapkan. Dalam analisis proses, atribut ini penting untuk process mining berbasis nilai. Anda dapat mengelompokkan pesanan berdasarkan nilai, misalnya pesanan bernilai tinggi dan rendah, untuk melihat apakah alur proses atau waktu siklusnya berbeda. Atribut ini juga membantu memprioritaskan perbaikan proses pada kasus yang berdampak finansial paling besar. Mengapa ini penting Mendukung analisis dampak finansial, membantu memprioritaskan perbaikan proses pada pesanan bernilai tinggi dan memahami faktor pemicu biaya. Sumber data Biasanya terdapat di tabel header pesanan penjualan Oracle Fusion. Lihat dokumentasi Oracle Fusion Financials. Contoh 5250.00125000.75980.50 | |||
| Apakah faktur dikoreksi IsInvoiceCorrected | Penanda yang menunjukkan apakah faktur dikoreksi atau direvisi setelah pertama kali dibuat. | ||
| Deskripsi Atribut boolean ini bernilai true jika faktur mengalami siklus koreksi, yang ditandai dengan adanya aktivitas 'Faktur Dikoreksi'. Penanda ini menunjukkan kasus yang memerlukan pengerjaan ulang pada tahap pembuatan faktur. Atribut ini menjadi masukan utama untuk dasbor 'Analisis Akurasi dan Pengerjaan Ulang Faktur' serta KPI 'Tingkat Pengerjaan Ulang Faktur'. Atribut ini membantu mengukur besarnya kesalahan faktur dan menganalisis penyebab koreksi, sehingga pekerjaan manual dan keterlambatan pembayaran dapat dikurangi. Mengapa ini penting Mengidentifikasi pengerjaan ulang faktur, yang menjadi indikator penting ketidakefisienan proses, masalah kualitas data, dan potensi keterlambatan pembayaran. Sumber data Ini adalah kolom hasil perhitungan. Biasanya, nilainya true untuk suatu kasus jika log peristiwa memuat aktivitas 'Faktur Dikoreksi'. Contoh falsetrue | |||
| Jenis Pesanan OrderType | Klasifikasi pesanan penjualan, seperti 'Pesanan Standar' atau 'Pesanan Retur'. | ||
| Deskripsi Jenis Pesanan digunakan untuk mengelompokkan pesanan penjualan berdasarkan tujuan bisnisnya. Jenis yang umum mencakup penjualan standar, pesanan layanan, otorisasi retur barang (RMA), dan pesanan internal. Analisis proses berdasarkan jenis pesanan penting karena tiap jenis biasanya memiliki alur proses dan target kinerja yang berbeda. Pengelompokan ini membantu memahami variasi proses yang memang disengaja dan diharapkan, sehingga tidak keliru dianggap sebagai penyimpangan. Mengapa ini penting Mendukung pengelompokan alur proses yang berbeda dan sah, seperti pesanan standar dan retur, agar analisis tetap adil dan akurat. Sumber data Biasanya tersedia sebagai kolom di tabel header pesanan penjualan Oracle Fusion. Lihat dokumentasi Oracle Fusion Financials. Contoh Pesanan Penjualan StandarOtorisasi ReturPesanan Layanan | |||
| Ketentuan Pembayaran PaymentTerms | Ketentuan pembayaran yang disepakati dengan pelanggan. | ||
| Deskripsi Atribut ini menentukan kapan pelanggan diharapkan membayar faktur, misalnya 'Net 30' atau 'Net 60'. Ketentuan ini menjadi dasar untuk menghitung PaymentDueDate. Pengelompokan berdasarkan ketentuan pembayaran dapat membantu menjelaskan perbedaan waktu siklus pembayaran. Informasi ini memberi konteks untuk KPI 'Tingkat Pembayaran Tepat Waktu', karena ketentuan yang berbeda secara alami menghasilkan perilaku pembayaran yang berbeda. Temuan ini dapat menjadi masukan bagi kebijakan kredit dan perkiraan arus kas. Mengapa ini penting Memberikan konteks penting untuk menganalisis perilaku pembayaran dan membantu menjelaskan perbedaan waktu siklus dari faktur hingga pembayaran. Sumber data Tersedia pada tingkat pesanan penjualan atau akun pelanggan di Oracle Fusion. Lihat dokumentasi Oracle Fusion Financials. Contoh Net 30Net 60Jatuh Tempo Saat Diterima | |||
| Metode Pengiriman ShippingMethod | Metode atau jasa pengangkut yang digunakan untuk mengirim barang kepada pelanggan. | ||
| Deskripsi Atribut ini menjelaskan jasa pengangkut atau tingkat layanan yang digunakan untuk pengantaran, seperti 'Angkutan Darat', 'Ekspres Udara', atau 'Kurir Lokal'. Informasi ini penting untuk dashboard 'Kepatuhan Pengantaran berdasarkan Metode Pengiriman'. Anda dapat membandingkan kinerja pengantaran tepat waktu dan biaya pengiriman untuk berbagai metode dan jasa pengangkut. Hasilnya membantu mengoptimalkan strategi logistik dan pemilihan vendor. Mengapa ini penting Mendukung analisis logistik dengan membandingkan kinerja berbagai jasa pengangkut dan metode pengiriman. Sumber data Tersedia di tabel pengiriman dan pemenuhan Oracle Fusion. Lihat dokumentasi Oracle Fusion Financials. Contoh FedEx GroundUPS Next Day AirDHL International | |||
| Nama Produk ProductName | Nama produk atau layanan yang dijual. | ||
| Deskripsi Atribut ini menunjukkan barang pada baris pesanan penjualan. Jika pesanan memiliki beberapa baris, kasus dapat dianalisis pada tingkat baris barang, atau atribut ini dapat digabungkan pada tingkat header. Analisis berdasarkan produk membantu mengetahui apakah produk tertentu berkaitan dengan alur proses yang lebih rumit atau bermasalah, misalnya sering terlambat dikirim atau mengalami masalah pembayaran. Temuan ini dapat menjadi masukan bagi strategi pengelolaan produk dan rantai pasok. Mengapa ini penting Mendukung analisis kinerja proses untuk berbagai produk dan menyoroti barang yang mungkin memiliki alur pemenuhan atau penagihan yang rumit. Sumber data Diambil dari tabel baris pesanan penjualan dan digabungkan dengan tabel induk produk. Lihat dokumentasi Oracle Fusion Financials. Contoh Standard Widget X1Paket Layanan PremiumKomponen Y2-B | |||
| Negara Pelanggan CustomerCountry | Negara tempat pelanggan berada. | ||
| Deskripsi Atribut ini menunjukkan negara berdasarkan alamat pengiriman atau penagihan pelanggan. Atribut ini menjadi dimensi penting untuk analisis geografis. Pengelompokan proses berdasarkan negara dapat mengungkap perbedaan kinerja proses, waktu siklus, atau perilaku pembayaran di tiap wilayah. Informasi ini berguna untuk memahami dampak peraturan setempat, tantangan logistik, dan kondisi pasar terhadap proses Order to Cash. Mengapa ini penting Mendukung analisis geografis untuk menemukan perbedaan efisiensi proses, kepatuhan, dan perilaku pelanggan di tiap wilayah. Sumber data Diambil dari tabel data induk pelanggan, seperti HZ_LOCATIONS dan HZ_PARTY_SITES, yang ditautkan ke pesanan penjualan. Contoh USAJermanJepang | |||
| Nomor Faktur InvoiceNumber | Pengenal unik untuk faktur pelanggan. | ||
| Deskripsi Atribut ini adalah nomor unik yang diberikan pada faktur dari pesanan penjualan. Nomor ini menghubungkan aktivitas penjualan dan pemenuhan dengan tahap penyelesaian keuangan dalam proses. Pesanan Penjualan menjadi ID kasus utama, sedangkan Nomor Faktur penting untuk menganalisis subproses pembuatan faktur dan pembayaran. Nomor ini diperlukan untuk melacak koreksi faktur, sengketa, dan status pembayaran, serta mendukung dashboard seperti 'Analisis Akurasi dan Pengerjaan Ulang Faktur'. Mengapa ini penting Menghubungkan proses dengan piutang dan diperlukan untuk menganalisis pengerjaan ulang faktur serta siklus pembayaran. Sumber data Tersedia di tabel transaksi piutang Oracle Fusion, seperti RA_CUSTOMER_TRX_ALL. Contoh INV-93485INV-93486INV-93487 | |||
| Pembaruan Data Terakhir LastUpdateDate | Stempel waktu yang menunjukkan kapan terakhir kali data peristiwa ini diperbarui dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat kapan data terakhir diekstrak atau diperbarui dalam dataset process mining. Dengan begitu, Anda dapat mengetahui seberapa baru data yang dianalisis. Informasi ini membantu pengguna memahami seberapa mutakhir analisis proses. Informasi ini juga membantu mengatur ekspektasi tentang kebaruan data serta menyusun dan memantau jadwal pembaruan data. Mengapa ini penting Menunjukkan kebaruan data agar pengguna mengetahui seberapa mutakhir analisis proses. Sumber data Nilai ini dibuat dan dicantumkan pada dataset setiap kali siklus ekstraksi dan transformasi data berlangsung. Contoh 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Pembayaran Terlambat IsLatePayment | Penanda hasil perhitungan yang bernilai true jika pembayaran diterima setelah tanggal jatuh tempo. | ||
| Deskripsi Atribut boolean ini diturunkan dengan membandingkan tanggal pembayaran diterima dengan PaymentDueDate. Atribut ini menunjukkan dengan jelas apakah faktur dibayar tepat waktu. Atribut ini digunakan untuk menghitung KPI 'Tingkat Pembayaran Tepat Waktu'. Anda dapat mengelompokkan pembayaran yang tepat waktu dan terlambat untuk menganalisis karakteristik pelanggan yang terlambat membayar, penyebab keterlambatan yang umum, dan dampak finansialnya terhadap modal kerja. Mengapa ini penting Mengukur langsung efektivitas penagihan pembayaran dan memudahkan analisis pembayaran yang menunggak. Sumber data Ini adalah kolom hasil perhitungan. Logikanya: PaymentReceivedDate > PaymentDueDate. Contoh falsetrue | |||
| Pengantaran Tepat Waktu IsOnTimeDelivery | Penanda hasil perhitungan yang bernilai true jika barang diantarkan pada atau sebelum tanggal pengantaran yang diminta. | ||
| Deskripsi Atribut boolean ini diturunkan dengan membandingkan ActualDeliveryDate dengan RequestedDeliveryDate. Atribut ini memberikan indikator kinerja pengantaran yang sederhana untuk setiap kasus. Penanda ini menjadi dasar untuk menghitung KPI agregat 'Tingkat Pengantaran Tepat Waktu'. Penanda ini memudahkan pemfilteran dan analisis, sehingga pengguna dapat dengan cepat menemukan semua pesanan yang terlambat dan menganalisis faktor penyebabnya. Mengapa ini penting Mengukur langsung kinerja pemenuhan berdasarkan harapan pelanggan dan memudahkan analisis pesanan yang terlambat. Sumber data Kolom ini dihitung dengan logika: ActualDeliveryDate <= RequestedDeliveryDate. Contoh truefalse | |||
| Sistem Sumber SourceSystemIdentifier | Menunjukkan sistem sumber tempat data peristiwa diekstrak. | ||
| Deskripsi Atribut ini menunjukkan asal data. Informasi ini berguna terutama jika proses Order to Cash melibatkan beberapa sistem. Misalnya, data pesanan mungkin berasal dari Oracle Fusion, sedangkan data pengiriman berasal dari sistem logistik pihak ketiga. Dalam analisis, atribut ini membantu memahami asal-usul data dan memfilter tampilan proses berdasarkan sistem tertentu. Atribut ini juga penting untuk memvalidasi data dan menemukan proses yang tersebar di berbagai sistem TI. Mengapa ini penting Memberikan konteks tentang asal data. Informasi ini penting untuk tata kelola data dan pemecahan masalah di lingkungan yang menggunakan banyak sistem. Sumber data Biasanya berupa nilai tetap yang ditambahkan saat data diekstrak dan ditransformasikan untuk menandai asal dataset. Contoh Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Unit Bisnis BusinessUnitName | Nama unit bisnis internal yang bertanggung jawab atas pesanan penjualan. | ||
| Deskripsi Atribut ini menunjukkan divisi atau unit operasional tertentu di perusahaan yang memiliki transaksi tersebut. Atribut ini memungkinkan perbandingan kinerja antarbagian organisasi. Pengelompokan proses berdasarkan unit bisnis membantu menemukan perbedaan efisiensi, biaya, dan kepatuhan di seluruh perusahaan. Analisis ini dapat mengungkap praktik baik dari unit berkinerja tinggi untuk dibagikan, atau menunjukkan unit berkinerja rendah yang memerlukan perbaikan proses terarah. Mengapa ini penting Mendukung perbandingan kinerja dan analisis konsistensi proses di berbagai unit organisasi. Sumber data Biasanya tersedia di header pesanan penjualan dan ditautkan ke struktur organisasi yang ditetapkan di Oracle Fusion. Contoh BU-Amerika UtaraBU-EMEALayanan Global | |||
Aktivitas pemrosesan pesanan penjualan hingga pembayaran
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Barang dikirim | Aktivitas ini menandai saat barang meninggalkan gudang dan mulai dikirim ke pelanggan. Aktivitas ini tercatat saat transaksi konfirmasi pengiriman diproses di Oracle Shipping. | ||
| Mengapa ini penting Pencapaian penting ini menandai selesainya tahap pemenuhan dalam proses dan memicu pembuatan faktur. Data ini penting untuk mengukur ketepatan waktu pengiriman dan waktu tunggu pengiriman. Sumber data Peristiwa ini tercatat secara eksplisit di Oracle Shipping Execution. Transaksi konfirmasi pengiriman membuat data di tabel pengiriman seperti WSH_DELIVERY_DETAILS, beserta tanggal pengiriman. Pengumpulan data Diambil dari stempel waktu 'tanggal pengiriman aktual' pada data detail pengiriman yang terkait dengan baris pesanan. Jenis peristiwa explicit | |||
| Faktur dibuat | Aktivitas ini menunjukkan pembuatan faktur pelanggan di modul Accounts Receivable, yang biasanya dipicu oleh peristiwa konfirmasi pengiriman. Data faktur dibuat dengan nomor unik dan tanggal pembuatan. | ||
| Mengapa ini penting Menandai awal resmi siklus penagihan pembayaran. Aktivitas ini menjadi dasar untuk mengukur 'Waktu dari Faktur hingga Pembayaran' dan efisiensi arus kas secara keseluruhan. Sumber data Peristiwa ini tercatat secara eksplisit di Oracle Accounts Receivable (AR). Data faktur dibuat di tabel RA_CUSTOMER_TRX_ALL dengan tanggal transaksi. Pengumpulan data Diambil dari tanggal pembuatan transaksi faktur di modul AR. Jenis peristiwa explicit | |||
| Pembayaran Diterima | Aktivitas ini menandakan bahwa pembayaran pelanggan telah diterima dan dibukukan ke faktur di Accounts Receivable. Aktivitas ini tercatat saat penerimaan kas dibukukan. | ||
| Mengapa ini penting Ini adalah tonggak penting untuk mengukur 'Waktu Siklus Order to Cash Keseluruhan' dan 'Tingkat Pembayaran Tepat Waktu'. Tahap ini menandai perubahan penjualan menjadi kas. Sumber data Ini adalah peristiwa eksplisit di Oracle Accounts Receivable. Peristiwa ini dicatat di tabel penerimaan kas seperti AR_RECEIVABLE_APPLICATIONS_ALL saat pembayaran diterapkan ke faktur. Pengumpulan data Diambil dari stempel waktu 'apply date' pada catatan penerapan penerimaan kas di AR. Jenis peristiwa explicit | |||
| Pesanan dikonfirmasi | Pencapaian penting ini menandakan bahwa pesanan penjualan telah melewati semua pemeriksaan awal, termasuk persetujuan kredit, dan siap dipenuhi. Biasanya, hal ini disimpulkan saat status pesanan berubah menjadi status seperti 'Menunggu Pengiriman' atau 'Terjadwal'. | ||
| Mengapa ini penting Aktivitas ini menjadi pencapaian penting untuk menghitung 'Rata-rata Waktu Konfirmasi Pesanan' dan menandai peralihan dari pencatatan pesanan ke proses pemenuhan. Sumber data Disimpulkan dari perubahan status header atau baris pesanan penjualan ke nilai yang menunjukkan pesanan siap dipenuhi, misalnya 'Menunggu Pengiriman'. Periksa kolom status di DOO_HEADERS_ALL atau DOO_FULFILL_LINES_ALL. Pengumpulan data Diambil dari stempel waktu saat status pesanan berubah menjadi terkonfirmasi atau terjadwal. Jenis peristiwa inferred | |||
| Pesanan Ditutup | Aktivitas terakhir dalam proses. Semua baris pada pesanan penjualan telah dipenuhi, difakturkan, dan ditutup. Status header pesanan diperbarui menjadi 'Closed'. | ||
| Mengapa ini penting Aktivitas ini menandai berakhirnya siklus hidup pesanan penjualan. Data ini penting untuk menghitung durasi proses dari awal hingga akhir dan menemukan pesanan yang tidak kunjung ditutup. Sumber data Disimpulkan dari perubahan status header pesanan penjualan menjadi 'Closed' di tabel DOO_HEADERS_ALL. Stempel waktu perubahan status terakhir ini menjadi waktu peristiwa. Pengumpulan data Ditentukan dari stempel waktu perubahan status header pesanan penjualan menjadi 'Closed'. Jenis peristiwa inferred | |||
| Pesanan penjualan dibuat | Aktivitas ini menandai awal proses pesanan penjualan, yaitu saat pesanan baru dimasukkan ke Oracle Fusion. Biasanya, peristiwa ini tercatat secara eksplisit saat pengguna menyimpan data pesanan baru di modul Order Management. | ||
| Mengapa ini penting Sebagai awal proses, aktivitas ini penting untuk mengukur waktu siklus Order to Cash secara keseluruhan dan menganalisis volume pesanan yang masuk. Sumber data Tercatat secara eksplisit saat data pesanan penjualan dibuat di Order Management Cloud. Cari stempel waktu pembuatan di tabel DOO_HEADERS_ALL. Pengumpulan data Diambil dari stempel waktu pembuatan data header pesanan penjualan. Jenis peristiwa explicit | |||
| Barang diambil | Menunjukkan pengambilan barang secara fisik dari gudang untuk memenuhi pesanan. Ini merupakan langkah penting dalam proses logistik dan biasanya tercatat di modul manajemen gudang atau pengiriman. | ||
| Mengapa ini penting Aktivitas ini memberikan visibilitas terhadap operasional gudang. Keterlambatan antara pencadangan inventaris dan pengambilan barang dapat menunjukkan hambatan sumber daya atau proses di gudang. Sumber data Tercatat di modul Oracle Fusion Cloud SCM (Supply Chain Management). Peristiwa ini dapat disimpulkan dari perubahan status gelombang pengambilan atau slip pengambilan yang terkait dengan baris pesanan penjualan. Pengumpulan data Disimpulkan dari stempel waktu penyelesaian transaksi pengambilan di modul SCM. Jenis peristiwa inferred | |||
| Barang diterima | Menunjukkan bahwa pelanggan telah menerima kiriman. Informasi ini sering berasal dari perusahaan pengangkut dan diperbarui di Oracle Fusion. Informasi tersebut juga dapat disimpulkan berdasarkan waktu transit standar sejak tanggal pengiriman. | ||
| Mengapa ini penting Aktivitas ini penting untuk menghitung KPI 'Tingkat Pengiriman Tepat Waktu' dan mengukur tingkat layanan pelanggan secara akurat. Sumber data Peristiwa ini biasanya tidak tersedia secara bawaan di Oracle. Data dapat diambil jika integrasi dengan perusahaan pengangkut sudah tersedia, atau dihitung dengan menambahkan waktu transit standar ke tanggal 'Barang Dikirim'. Perlu analisis sistem. Pengumpulan data Disimpulkan dari umpan data perusahaan pengangkut atau dihitung berdasarkan tanggal pengiriman ditambah rata-rata waktu transit. Jenis peristiwa inferred | |||
| Baris Pesanan Ditutup | Menandai penutupan akhir satu baris pesanan penjualan. Barang telah dikirim sepenuhnya, faktur telah dibuat, dan tidak ada transaksi lanjutan yang diharapkan. Status baris diperbarui menjadi 'Closed'. | ||
| Mengapa ini penting Penutupan baris pesanan menandakan bahwa semua kewajiban kontraktual untuk barang tersebut telah dipenuhi. Analisis ini membantu menemukan pesanan yang masih terbuka lama setelah pemenuhan dan pembayaran selesai. Sumber data Disimpulkan dari perubahan status baris pemenuhan menjadi 'Closed' di tabel DOO_FULFILL_LINES_ALL. Stempel waktu perubahan status menandai waktu peristiwa. Pengumpulan data Ditentukan dari stempel waktu perubahan status baris pemenuhan menjadi 'Closed'. Jenis peristiwa inferred | |||
| Faktur dikoreksi | Terjadi saat faktur yang sudah dibuat diubah, diterbitkan ulang, atau dikreditkan karena kesalahan atau sengketa dengan pelanggan. Biasanya, hal ini dicatat dengan membuat nota kredit atau versi faktur yang baru. | ||
| Mengapa ini penting Melacak koreksi faktur penting untuk KPI 'Tingkat Pengerjaan Ulang Faktur'. KPI ini menyoroti masalah dalam proses penagihan yang dapat menunda pembayaran dan menambah biaya administrasi. Sumber data Disimpulkan dari pembuatan nota kredit yang ditautkan ke faktur asli atau versi berikutnya dari faktur yang sama di tabel RA_CUSTOMER_TRX_ALL. Pengumpulan data Ditentukan dengan mengidentifikasi nota kredit atau faktur yang merujuk pada transaksi faktur sebelumnya. Jenis peristiwa inferred | |||
| Inventaris dicadangkan | Aktivitas ini menunjukkan alokasi atau pencadangan inventaris fisik untuk memenuhi baris pesanan penjualan. Sistem menetapkan stok tertentu agar tersedia saat pesanan siap diambil. | ||
| Mengapa ini penting Pelacakan aktivitas ini membantu menganalisis KPI 'Waktu Tunggu Alokasi Inventaris' dan menemukan keterlambatan antara konfirmasi pesanan dan ketersediaan barang. Sumber data Peristiwa ini sering tercatat di modul inventaris atau pelaksanaan rantai pasok. Peristiwa ini dapat disimpulkan dari pembaruan status pada baris pemenuhan yang menunjukkan inventaris telah dirinci atau dicadangkan. Pengumpulan data Disimpulkan dari perubahan status baris pemenuhan yang terkait dengan pencadangan atau penjadwalan inventaris. Jenis peristiwa inferred | |||
| Pemeriksaan kredit dilakukan | Menunjukkan pemeriksaan kredit pada akun pelanggan untuk menilai kelayakan kredit. Langkah ini sering dilakukan secara otomatis atau manual dalam alur kerja pemrosesan pesanan. Penyelesaiannya biasanya tercatat sebagai pembaruan status atau tugas yang telah selesai. | ||
| Mengapa ini penting Menganalisis waktu yang dibutuhkan untuk pemeriksaan kredit membantu menemukan hambatan dalam persetujuan pesanan. Data ini penting untuk KPI 'Waktu dari Pemeriksaan Kredit hingga Konfirmasi'. Sumber data Dapat disimpulkan dari perubahan status pesanan penjualan, misalnya saat status berubah menjadi 'Menunggu Persetujuan Kredit', atau dari log peristiwa eksplisit di fitur manajemen kredit. Pengumpulan data Disimpulkan dari perubahan status pesanan atau stempel waktu yang terkait dengan tugas peninjauan kredit. Jenis peristiwa inferred | |||
| Penahanan kredit diterapkan | Aktivitas ini terjadi saat pesanan penjualan ditahan secara otomatis atau manual karena pemeriksaan kredit gagal atau ada masalah terkait kredit lainnya. Biasanya, hal ini tercatat sebagai perubahan status penahanan pesanan di sistem. | ||
| Mengapa ini penting Melacak penahanan kredit penting untuk mengetahui penyebab keterlambatan pemrosesan pesanan dan mengukur efisiensi proses pelepasan penahanan kredit. Sumber data Disimpulkan dari penerapan penahanan pada pesanan penjualan. Biasanya, hal ini tercatat di tabel terkait penahanan, seperti DOO_HOLDS_ALL, yang terhubung dengan pesanan penjualan. Pengumpulan data Disimpulkan dari pembuatan data di tabel penahanan pesanan dengan jenis penahanan 'Kredit'. Jenis peristiwa inferred | |||
| Pesanan Dibatalkan | Menandai pembatalan pesanan penjualan sebelum seluruh barang dikirim. Pembatalan dapat terjadi karena berbagai alasan dan menghasilkan status akhir 'Cancelled'. | ||
| Mengapa ini penting Ini adalah jalur pengecualian yang penting. Analisis pesanan yang dibatalkan membantu menemukan akar masalah, seperti stok habis, masalah harga, atau perubahan keputusan pelanggan. Temuan ini dapat menjadi dasar perbaikan proses. Sumber data Disimpulkan dari perubahan status header atau baris pesanan penjualan menjadi 'Cancelled'. Stempel waktu perubahan status digunakan untuk mencatat peristiwa. Pengumpulan data Ditentukan dari stempel waktu perubahan status header atau baris pesanan menjadi 'Cancelled'. Jenis peristiwa inferred | |||
Panduan ekstraksi
Langkah
- Buka Oracle BI Publisher: Masuk ke lingkungan Oracle Fusion dengan pengguna yang memiliki hak istimewa BI Administrator atau BI Author. Buka menu Navigator, lalu pilih Tools > Reports and Analytics. Klik tombol 'Browse Catalog' untuk membuka Business Intelligence Catalog.
- Buat model data baru: Di BI Catalog, buka folder yang sesuai, misalnya Shared Folders > Custom. Klik menu tarik-turun 'New', lalu pilih 'Data Model'.
- Tentukan himpunan data kueri SQL: Di editor Data Model, klik ikon '+' untuk membuat himpunan data baru, lalu pilih 'SQL Query'. Kotak dialog akan muncul. Beri nama himpunan data, misalnya 'OrderToCash_EventLog', pilih 'Oracle BI EE' sebagai Sumber Data, lalu pilih 'Standard SQL' sebagai jenis SQL.
- Masukkan kueri SQL: Salin seluruh kueri SQL dari bagian 'query' dokumen ini, lalu tempelkan ke area teks SQL Query. Kueri ini menyertakan parameter tanggal mulai dan akhir (:p_start_date dan :p_end_date), yang akan dikenali secara otomatis oleh BI Publisher.
- Atur properti model data: Setelah menempelkan kueri, klik 'OK'. Buka bagian 'Properties' di panel kiri editor model data. Pastikan 'Include Parameter Tags' dicentang. Jika perlu, Anda juga dapat menetapkan nilai default untuk parameter tanggal.
- Lihat dan simpan model data: Klik tab 'Data'. Anda mungkin diminta memasukkan nilai untuk parameter tanggal. Masukkan rentang tanggal pendek untuk pengujian. Klik 'View' untuk melihat contoh data. Jika data tampil dengan benar, simpan model data dengan mengeklik ikon simpan dan memberinya nama yang jelas, misalnya 'OrderToCash_EventLog_DM'.
- Buat laporan dari model data: Setelah model data disimpan, klik tombol 'Create Report' di pojok kanan atas. Wizard pembuatan laporan akan terbuka.
- Atur laporan: Di wizard, pilih opsi 'Use Data Model'. Wizard akan memandu Anda mengatur tata letak. Untuk ekspor CSV sederhana, pilih tata letak 'Table'. Seret semua kolom ke dalam tabel. Klik 'Next', lalu hapus centang 'Show Grand Totals Row'. Klik 'Finish' untuk menyimpan laporan. Beri nama, misalnya 'OrderToCash_EventLog_Report'.
- Jalankan laporan: Buka laporan yang baru dibuat. Anda akan diminta memasukkan tanggal mulai dan akhir untuk ekstraksi. Masukkan rentang tanggal yang diinginkan.
- Ekspor data: Setelah laporan dijalankan, klik menu tarik-turun 'View' dan pilih opsi tampilan lain, seperti 'View Report'. Lalu, cari tautan atau ikon 'Export' dan pilih 'CSV' sebagai format ekspor. File log peristiwa akan diunduh.
- Siapkan data untuk diunggah: Buka file CSV yang diunduh. Pastikan judul kolom sesuai dengan atribut yang diperlukan: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate, dan IsAutomated. File siap diunggah ke alat process mining.
Konfigurasi
- Hak istimewa pengguna: Anda harus memiliki peran yang memberi hak untuk membuat model data dan laporan BI Publisher, seperti 'BI Administrator' atau 'BI Author'.
- Sumber data: Kueri ini dirancang untuk sumber data aplikasi standar 'Oracle BI EE', yang terhubung ke basis data transaksi (Fusion Apps). Biasanya, konfigurasi khusus tidak diperlukan.
- Parameter rentang tanggal: Kueri menggunakan dua parameter, :p_start_date dan :p_end_date, untuk memfilter data. Sebaiknya ekstrak data dalam kelompok yang mudah dikelola, misalnya setiap 3 hingga 6 bulan, untuk menghindari laporan kehabisan waktu atau mengalami masalah kinerja.
- Filter unit bisnis: Untuk membatasi cakupan ekstraksi, Anda dapat menambahkan klausa WHERE ke CTE BaseOrders dalam kueri untuk memfilter berdasarkan ID Unit Bisnis tertentu, misalnya AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filter jenis pesanan: Anda juga dapat memfilter jenis pesanan penjualan tertentu dengan menambahkan kondisi pada dhead.SOURCE_ORDER_TYPE_CODE di CTE BaseOrders.
- Kinerja: Untuk himpunan data sangat besar yang mencakup beberapa tahun, pendekatan satu kueri ini mungkin lambat. Jalankan di luar jam sibuk atau bagi ekstraksi menjadi kelompok bulanan yang lebih kecil. Pastikan properti 'Enable SQL Pruning' tidak dipilih di Data Model karena dapat mengganggu kueri UNION yang kompleks.
Contoh kueri sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' Langkah
- Buka konsol BICC: Masuk ke instans Oracle Fusion Applications dengan pengguna yang memiliki peran BICC_ADMINISTRATOR. Buka Tools, lalu pilih Business Intelligence Cloud Connector dari menu.
- Buat penawaran baru: Di konsol BICC, klik Configure External Storage untuk menyiapkan tujuan penyimpanan, yaitu Oracle Universal Content Management (UCM) atau bucket OCI Object Storage. Pastikan detail koneksi dan kredensial sudah benar.
- Mulai tugas ekstraksi baru: Buka bagian Manage Extract Jobs. Klik ikon + untuk membuat tugas baru. Beri nama yang jelas, misalnya ProcessMind_O2C_SalesOrder_Extract.
- Pilih penyimpanan data (PVO): Di konfigurasi tugas, cari dan tambahkan Public View Objects (PVO) yang diperlukan untuk merekam siklus pesanan penjualan. Anda perlu menambahkan beberapa PVO, termasuk FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice, dan FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Atur kolom untuk setiap PVO: Untuk setiap PVO yang dipilih, klik menu Actions, lalu pilih Select Columns. Pilih dengan cermat kolom yang diperlukan untuk membuat log peristiwa, seperti HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate, dan pengenal pengguna. Lihat manifes kueri untuk daftar lengkap kolom yang diperlukan dari setiap PVO.
- Terapkan filter untuk pemuatan inkremental: Untuk mengelola volume data, terapkan filter pada setiap PVO berdasarkan kolom LastUpdateDate. Untuk proses pertama, Anda dapat memilih rentang tanggal yang luas. Untuk proses terjadwal berikutnya, atur filter agar hanya mengekstrak catatan yang diperbarui sejak tugas terakhir dijalankan.
- Jadwalkan tugas ekstraksi: Buka bagian Manage Schedule. Buat jadwal baru untuk tugas Anda. Sebaiknya jalankan tugas di luar jam sibuk, misalnya setiap malam, untuk mengurangi dampak pada kinerja sistem.
- Kirim dan pantau tugas: Setelah konfigurasi selesai, kirim tugas. Pantau kemajuannya dari layar Manage Extract Jobs. Setelah berhasil, file data dalam format CSV terkompresi akan tersedia di lokasi penyimpanan cloud yang Anda konfigurasi.
- Ubah data mentah menjadi log peristiwa: Unduh file CSV hasil ekstraksi. BICC menyediakan data tabel mentah, bukan log peristiwa yang sudah diformat. Anda perlu memakai alat eksternal, seperti Python, skrip basis data, atau platform ETL, untuk memproses file tersebut. Langkahnya meliputi:
- Menggabungkan data dari berbagai file, misalnya menghubungkan data faktur dengan header pesanan penjualan.
- Mengubah kolom tanggal menjadi baris aktivitas terpisah. Contohnya, dari file FscmTopModelAM.DooTopAM.Header, buat satu baris untuk Pesanan Penjualan Dibuat menggunakan CreationDate dan baris lain untuk Pesanan Ditutup menggunakan ClosedDate.
- Memetakan kode status atau penanda ke aktivitas tertentu, seperti Pesanan Dikonfirmasi atau Pesanan Dibatalkan.
- Menggabungkan semua data yang sudah diubah ke dalam satu file dengan kolom yang diperlukan: SalesOrder, ActivityName, dan EventTime.
- Siapkan format untuk diunggah: Pastikan file akhir berupa satu file CSV dengan kolom yang sesuai dengan atribut wajib dan yang disarankan. File siap diunggah ke ProcessMind.
Konfigurasi
- Pemilihan PVO: Keakuratan log peristiwa sepenuhnya bergantung pada pemilihan PVO yang tepat. PVO utama mencakup FscmTopModelAM.DooTopAM.Header (untuk pembuatan dan penutupan pesanan), FscmTopModelAM.ScmTopAM.ShipmentLine (untuk peristiwa pengiriman), dan FscmTopModelAM.ArTopAM.ReceivableInvoice (untuk pembuatan faktur).
- Ekstraksi inkremental: Selalu gunakan filter LastUpdateDate untuk ekstraksi berulang. Filter ini penting untuk kinerja dan mencegah ekstraksi berulang atas himpunan data berukuran beberapa gigabita. Pemuatan penuh pertama menjadi data dasar, sedangkan proses berikutnya hanya mengambil perubahan.
- Rentang tanggal: Untuk pemuatan data historis pertama, ekstrak periode yang mewakili, misalnya data 3 hingga 6 bulan terakhir. Dengan begitu, data tetap cukup lengkap dan volumenya mudah dikelola. Proses berikutnya dilakukan secara inkremental.
- Konfigurasi penyimpanan: BICC dapat mengekspor data ke UCM Oracle atau OCI Object Storage. OCI Object Storage umumnya disarankan untuk data massal dan integrasi yang lebih mudah dengan alat ETL lanjutan.
- Penjadwalan tugas: Jadwalkan ekstraksi di luar jam kerja untuk menghindari kemungkinan penurunan kinerja sistem transaksi Oracle Fusion Financials.
- Prasyarat: Pengguna yang mengonfigurasi tugas memerlukan peran BICC_ADMINISTRATOR. Anda juga perlu menyiapkan kredensial penyimpanan cloud terlebih dahulu dan memahami logika transformasi data yang diperlukan setelah ekstraksi.
Contoh kueri config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering Siap memulai?
Gunakan templat ini untuk mempermudah pengumpulan data dan memulai process mining. Mulai optimalkan pemrosesan pesanan penjualan hingga pembayaran sekarang.
Optimalkan pemrosesan pesanan penjualan hingga pembayaran sekarang
Temukan hambatan dan kurangi waktu siklus pesanan hingga pembayaran sebesar 30% dengan mudah.
Tidak perlu kartu kredit. Uji coba gratis selama 14 hari.