Templat Data Pengelolaan Kredit dan Penagihan
Templat Data Pengelolaan Kredit dan Penagihan
- Atribut yang disarankan untuk analisis menyeluruh
- Aktivitas utama untuk ditelusuri saat menemukan proses
- Panduan ekstraksi data langkah demi langkah
Atribut Pengelolaan Kredit dan Penagihan
| Nama | Deskripsi | ||
|---|---|---|---|
| Nama aktivitas ActivityName | Nama peristiwa bisnis atau tugas tertentu yang terjadi pada suatu waktu dalam proses manajemen kredit. | ||
| Deskripsi Atribut ini menjelaskan satu langkah dalam siklus hidup faktur, seperti 'Faktur dibuat', 'Prosedur penagihan dimulai', atau 'Pembayaran diterima'. Setiap aktivitas mewakili peristiwa tersendiri yang membawa kasus ke tahap berikutnya. Menganalisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu menemukan alur proses yang sebenarnya, mengidentifikasi hambatan saat kasus tersendat, mendeteksi pengulangan aktivitas, serta membandingkan proses aktual dengan proses yang dirancang atau diharapkan. Nama Aktivitas menjadi dasar untuk membuat peta proses dan menghitung waktu perpindahan antar langkah. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam peta proses, sehingga siklus hidup faktur dapat ditampilkan dan dianalisis dari awal hingga akhir. Sumber data Ini adalah kolom konseptual yang disusun dari berbagai peristiwa bisnis di Oracle Fusion Financials. Biasanya, kolom ini dibuat dengan memetakan status transaksi, tanggal peristiwa, atau tindakan tertentu dari modul seperti Receivables (AR) dan Advanced Collections. Contoh Faktur dibuatProsedur penagihan dimulaiPembayaran diterimaSengketa didaftarkan | |||
| Nomor faktur InvoiceNumber | Pengenal unik untuk setiap faktur pelanggan, yang digunakan sebagai ID kasus utama dalam proses manajemen kredit. | ||
| Deskripsi Nomor Faktur menjadi kunci utama yang menghubungkan semua peristiwa dan aktivitas terkait satu piutang, mulai dari pembuatan hingga pelunasan atau penghapusan. Dengan kunci ini, Anda dapat melihat seluruh siklus hidup faktur dari awal hingga akhir. Dalam analisis process mining, atribut ini digunakan untuk merekonstruksi perjalanan setiap faktur. Dengan mengelompokkan semua aktivitas terkait berdasarkan satu Nomor Faktur, analis dapat melihat alur proses, menemukan jalur yang umum maupun menyimpang, serta mengukur waktu siklus seluruh proses atau tahap tertentu, seperti penyelesaian sengketa atau pencatatan pembayaran. Mengapa ini penting Ini adalah ID Kasus utama yang menghubungkan semua langkah proses terkait. Dengan demikian, perjalanan setiap faktur dari penerbitan hingga penutupan dapat direkonstruksi dan dianalisis. Sumber data Pengenal ini biasanya terdapat di tabel RA_CUSTOMER_TRX_ALL sebagai TRX_NUMBER di Oracle Fusion Financials. Contoh INV-1005679884321AR-2023-04-112 | |||
| Waktu peristiwa EventTime | Tanggal dan waktu tepat saat aktivitas terjadi, yang menjadi cap waktu peristiwa tersebut. | ||
| Deskripsi Waktu Peristiwa, atau cap waktu, mencatat saat tepat suatu aktivitas berlangsung. Data ini penting untuk mengurutkan peristiwa secara kronologis dan menyusun alur proses yang akurat. Tanpa cap waktu yang akurat, urutan peristiwa tidak dapat ditentukan dengan benar. Dalam analisis, atribut ini digunakan untuk menghitung durasi dan waktu siklus antaraktivitas, yang penting untuk mengukur kinerja. Contohnya, atribut ini digunakan untuk menghitung KPI seperti Waktu Siklus Penyelesaian Sengketa atau Waktu Siklus Pembayaran Faktur. Atribut ini juga memungkinkan analisis tren kinerja proses dari waktu ke waktu. Mengapa ini penting Cap waktu ini penting untuk mengurutkan peristiwa, menghitung waktu siklus dan durasi, serta menganalisis kinerja proses dari waktu ke waktu. Sumber data Diambil dari berbagai kolom tanggal di tabel Oracle Fusion Financials, seperti TRX_DATE di RA_CUSTOMER_TRX_ALL untuk pembuatan faktur atau tanggal pembuatan tindakan penagihan. Contoh 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Pembaruan data terakhir LastDataUpdate | Cap waktu yang menunjukkan kapan data untuk peristiwa ini terakhir diperbarui atau diekstrak dari sistem sumber. | ||
| Deskripsi Atribut ini mencatat tanggal dan waktu ekstraksi data terbaru. Ini adalah kolom metadata, bukan bagian dari proses bisnis, tetapi penting untuk mengetahui seberapa baru data yang dianalisis. Analis menggunakan cap waktu ini untuk memastikan data yang digunakan sudah diperbarui dan mengetahui batas akhir data yang tersedia. Informasi ini penting untuk tata kelola data dan membantu pengguna memahami kebaruan data di dasbor dan laporan. Mengapa ini penting Menunjukkan kebaruan data agar analis dan pemangku kepentingan mengetahui seberapa mutakhir dan relevan data tersebut. Sumber data Nilai ini dibuat dan dicatat pada setiap baris selama proses ekstraksi dan pemuatan data (ETL). Contoh 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Sistem sumber SourceSystem | Sistem asal data. | ||
| Deskripsi Atribut ini menunjukkan aplikasi sumber tempat data peristiwa dicatat. Dalam lingkungan TI yang kompleks, satu proses dari awal hingga akhir dapat melibatkan beberapa sistem. Mencantumkan sistem sumber penting untuk tata kelola data, pemecahan masalah, dan memahami konteks data. Jika data dari berbagai sistem digabungkan dalam satu tampilan proses, atribut ini membantu membedakan asal setiap peristiwa dan memperjelas jejak datanya. Mengapa ini penting Menjelaskan asal data, yang penting untuk validasi dan tata kelola data serta pemahaman konteks teknologi proses. Sumber data Biasanya, nilai statis ini ditambahkan saat ekstraksi data untuk menunjukkan asal catatan. Contoh Oracle Fusion FinancialsOracle AROracle Collections | |||
| Nilai faktur InvoiceAmount | Total nilai uang pada faktur. | ||
| Deskripsi Nilai Faktur menunjukkan total nilai barang atau jasa yang ditagihkan kepada pelanggan. Atribut keuangan ini penting untuk memahami dampak finansial proses. Dalam analisis, Nilai Faktur digunakan untuk menentukan prioritas penagihan, terutama untuk faktur bernilai tinggi yang telah jatuh tempo. Atribut ini juga digunakan untuk menganalisis perilaku pembayaran berdasarkan nilai transaksi dan menghitung dampak finansial penghapusan piutang. Dasbor seperti Analisis Tingkat Penghapusan Faktur menggunakan nilai ini untuk menilai besarnya kerugian finansial. Mengapa ini penting Memberikan konteks keuangan pada proses, sehingga Anda dapat memprioritaskan faktur bernilai tinggi dan menganalisis dampak finansial dari inefisiensi proses. Sumber data Informasi ini dapat diambil dari tabel AR_PAYMENT_SCHEDULES_ALL, yang menyimpan jumlah tagihan untuk suatu faktur. Contoh 5000.001250.75250000.00 | |||
| Nomor pelanggan CustomerNumber | Pengenal unik untuk pelanggan yang terkait dengan faktur. | ||
| Deskripsi Nomor Pelanggan menghubungkan faktur dengan akun pelanggan tertentu. Dengan atribut ini, Anda dapat mengelompokkan dan menganalisis proses kredit dan penagihan berdasarkan karakteristik pelanggan. Dengan menyertakan Nomor Pelanggan, analis dapat menyelidiki apakah pelanggan tertentu sering terlambat membayar, lebih sering mengajukan sengketa, atau memerlukan lebih banyak upaya penagihan. Informasi ini penting untuk menyusun strategi penagihan khusus pelanggan, menyesuaikan persyaratan kredit, dan menemukan segmen pelanggan berisiko tinggi. Atribut ini mendukung analisis seperti Analisis Tingkat Penghapusan Faktur berdasarkan Segmen Pelanggan. Mengapa ini penting Memungkinkan proses dikelompokkan berdasarkan pelanggan untuk menemukan pola, risiko, dan peluang dalam menyusun strategi penagihan yang sesuai. Sumber data Biasanya terdapat di tabel RA_CUSTOMER_TRX_ALL sebagai BILL_TO_CUSTOMER_ID, yang ditautkan ke HZ_CUST_ACCOUNTS. Contoh CUST-0012389455ACME-CORP-US | |||
| Pengguna User | ID pengguna atau sistem yang melakukan aktivitas. | ||
| Deskripsi Atribut ini menunjukkan karyawan atau pengguna sistem tertentu yang bertanggung jawab menjalankan aktivitas, seperti menyetujui batas kredit, mencatat pembayaran, atau menyelesaikan sengketa. Analisis aktivitas berdasarkan pengguna penting untuk memahami pembagian beban kerja, kinerja individu, dan kepatuhan. Untuk aktivitas otomatis, atribut ini membantu melacak keterlibatan proses sistem. Atribut ini juga dapat digunakan untuk mengetahui kebutuhan pelatihan atau mendeteksi potensi kecurangan dengan memantau perilaku pengguna. Mengapa ini penting Mengaitkan aktivitas proses dengan individu atau sistem otomatis tertentu, sehingga kinerja dan beban kerja dapat dianalisis serta aktivitas dapat diaudit. Sumber data Bersumber dari kolom 'CREATED_BY' atau 'LAST_UPDATED_BY' di berbagai tabel transaksi dan riwayat dalam Oracle Fusion Financials. Contoh jsmithspesialis_piutang_1OTOMATISASI_SISTEM | |||
| Petugas penagihan Collector | Nama atau ID petugas penagihan yang ditugaskan menangani faktur. | ||
| Deskripsi Petugas Penagihan adalah individu atau tim yang bertanggung jawab menangani penagihan faktur yang telah jatuh tempo. Penugasan ini merupakan langkah penting dalam alur kerja penagihan. Atribut ini penting untuk mengelola kinerja dan alokasi sumber daya di bagian penagihan. Dengan menganalisis hasil tiap petugas, manajer dapat menilai efektivitas, mengetahui kebutuhan pelatihan, dan menyeimbangkan beban kerja. Dasbor Efektivitas Penugasan Petugas Penagihan menggunakan atribut ini untuk membandingkan tingkat keberhasilan dan waktu siklus antarpetugas. Mengapa ini penting Memungkinkan analisis kinerja petugas atau tim, sehingga alokasi sumber daya dapat dioptimalkan dan efisiensi penagihan secara keseluruhan meningkat. Sumber data Informasi ini biasanya disimpan dalam modul Oracle Advanced Collections, sering kali di tabel seperti IEX_CASES_ALL_B atau tabel penugasan terkait. Contoh John SmithJane DoeTim Penagihan A | |||
| Segmen pelanggan CustomerSegment | Pengelompokan pelanggan berdasarkan kategori tertentu, seperti ukuran, industri, atau kepentingan strategis. | ||
| Deskripsi Segmen Pelanggan adalah atribut kategori yang mengelompokkan pelanggan berdasarkan karakteristik yang sama. Segmen dapat ditentukan berdasarkan faktor seperti 'Strategis', 'UKM', 'Perusahaan besar', atau industri seperti 'Manufaktur' dan 'Ritel'. Atribut ini berguna untuk analisis perbandingan. Analis dapat membandingkan kinerja proses antarsegmen, misalnya untuk mengetahui apakah suatu segmen lebih sering mengajukan sengketa atau memiliki siklus pembayaran yang lebih panjang. Temuan ini membantu menyesuaikan kebijakan kredit dan strategi penagihan dengan kebutuhan serta risiko tiap segmen, sekaligus mendukung dasbor seperti Analisis Tingkat Penghapusan Faktur. Mengapa ini penting Memungkinkan analisis perbandingan untuk melihat perbedaan kinerja proses dan risiko di berbagai kelompok pelanggan. Sumber data Biasanya dikelola dalam data induk pelanggan (HZ_CUST_ACCOUNTS atau tabel terkait) atau ditentukan dari atribut pelanggan seperti pendapatan atau industri. Contoh Perusahaan besarUsaha kecil dan menengahPemerintahMitra strategis | |||
| Tanggal Jatuh Tempo DueDate | Tanggal batas pembayaran faktur. | ||
| Deskripsi Tanggal Jatuh Tempo adalah tanggal penting yang disepakati dalam kontrak sebagai batas pembayaran. Tanggal ini menjadi acuan untuk mengukur ketepatan waktu pembayaran. Atribut ini penting untuk mengidentifikasi faktur yang lewat jatuh tempo dan menghitung jumlah hari keterlambatannya. Atribut ini menjadi acuan utama untuk menentukan kapan prosedur penagihan perlu dimulai dan digunakan dalam perhitungan KPI seperti Days Sales Outstanding (DSO). Tanggal ini juga diperlukan untuk membuat laporan umur piutang yang mengelompokkan utang yang belum dibayar. Mengapa ini penting Menjadi acuan untuk menentukan apakah faktur telah lewat jatuh tempo, memulai aktivitas penagihan, dan menganalisis umur piutang. Sumber data Tersedia di tabel AR_PAYMENT_SCHEDULES_ALL sebagai DUE_DATE. Contoh 2023-05-302023-06-152023-07-01 | |||
| Tingkat Penagihan DunningLevel | Tahap atau tingkat prosedur penagihan yang diterapkan pada faktur. | ||
| Deskripsi Tingkat Penagihan menunjukkan seberapa intensif pengingat pembayaran dikirim, biasanya meningkat seiring waktu. Misalnya, Tingkat 1 bisa berupa pengingat ringan melalui email, sedangkan Tingkat 3 bisa berupa surat resmi atau panggilan telepon. Analisis proses berdasarkan Tingkat Penagihan membantu menilai efektivitas strategi penagihan. Dasbor Efektivitas Penagihan menggunakan atribut ini untuk menampilkan tingkat konversi dari setiap tahap penagihan hingga pembayaran. Dengan begitu, perusahaan dapat mengetahui tindakan penagihan yang paling efektif, lalu menyesuaikan waktu dan isi pengingat untuk memaksimalkan penerimaan pembayaran. Mengapa ini penting Mencatat tahap eskalasi upaya penagihan, yang penting untuk menilai efektivitas strategi penagihan. Sumber data Data ini dikelola di modul Oracle Advanced Collections. Data dapat ditemukan di tabel riwayat penagihan, seperti IEX_DUNNINGS. Contoh Tingkat 1: PengingatTingkat 2: PeringatanTingkat 3: Pemberitahuan terakhir | |||
| Alasan Sengketa DisputeReason | Alasan yang disampaikan pelanggan saat menyengketakan faktur. | ||
| Deskripsi Saat menyengketakan faktur, pelanggan biasanya menyampaikan alasan, seperti 'Harga Tidak Sesuai', 'Barang Rusak', atau 'Faktur Duplikat'. Atribut ini mencatat alasan tersebut. Analisis alasan sengketa penting untuk menemukan akar masalah. Analisis ini membantu mengidentifikasi masalah berulang dalam proses sebelumnya, seperti pengelolaan pesanan atau penagihan, yang menyebabkan keterlambatan pembayaran. Dengan mengelompokkan alasan sengketa dan memantau frekuensinya, perusahaan dapat mengambil tindakan terarah untuk mengatasi akar masalah. Hal ini membantu mempersingkat Waktu Penyelesaian Sengketa. Mengapa ini penting Membantu menemukan akar masalah sengketa faktur, sehingga perbaikan dapat dilakukan pada proses sebelumnya untuk mencegah sengketa serupa. Sumber data Informasi ini biasanya dicatat di modul Oracle Advanced Collections atau Oracle Channel Revenue Management jika pengelolaan sengketa sudah diformalkan. Data mungkin tersimpan di tabel seperti AR_DISPUTE_HISTORY. Contoh Jumlah Tidak SesuaiSelisih HargaBarang RusakLayanan Belum Diberikan | |||
| Jumlah Batas Kredit CreditLimitAmount | Jumlah kredit maksimum yang disetujui untuk pelanggan. | ||
| Deskripsi Jumlah Batas Kredit adalah total eksposur kredit yang bersedia diberikan perusahaan kepada pelanggan tertentu. Jumlah ini ditetapkan saat peninjauan kredit. Atribut ini penting untuk dasbor Dampak Keputusan Batas Kredit. Dengan menghubungkan batas kredit yang disetujui dengan perilaku pembayaran dan penghapusbukuan setelahnya, perusahaan dapat menilai efektivitas kebijakan risiko kredit. Analisis dapat menunjukkan apakah batas kredit yang terlalu tinggi meningkatkan utang macet, sehingga proses persetujuan kredit dapat disempurnakan. Mengapa ini penting Penting untuk menilai efektivitas kebijakan risiko kredit dengan menghubungkan batas kredit yang disetujui dengan hasil pembayaran dan penghapusbukuan. Sumber data Dikelola di Oracle Credit Management dan biasanya disimpan dalam tabel terkait profil kredit pelanggan, seperti HZ_CUST_PROFILE_AMTS. Contoh 10000.0050000.00250000.00 | |||
| Jumlah Hari Lewat Jatuh Tempo DaysOverdue | Jumlah hari sejak faktur melewati tanggal jatuh tempo. | ||
| Deskripsi Metrik hasil perhitungan ini menunjukkan berapa lama faktur yang belum dibayar mengalami keterlambatan. Nilainya dihitung dari selisih antara tanggal saat ini (untuk faktur terbuka) atau tanggal pembayaran (untuk faktur tertutup) dan tanggal jatuh tempo. Jumlah Hari Lewat Jatuh Tempo penting untuk analisis umur piutang dan menentukan prioritas penagihan. Metrik ini menjadi ukuran utama dalam dasbor Umur dan Status Faktur Lewat Jatuh Tempo. Di sana, faktur dikelompokkan berdasarkan lama keterlambatannya, misalnya 1-30 hari atau 31-60 hari. Dengan begitu, tim penagihan dapat berfokus pada utang yang paling lama tertunggak dan berisiko tinggi. Mengapa ini penting Mengukur lamanya keterlambatan pembayaran dan menjadi metrik utama untuk menentukan prioritas penagihan serta menganalisis umur piutang. Sumber data Ini adalah kolom hasil perhitungan. Logikanya: CurrentDate - DueDate untuk faktur terbuka, atau PaymentDate - DueDate untuk faktur tertutup. Contoh 1545920 | |||
| Mata uang faktur InvoiceCurrency | Mata uang yang digunakan untuk menyatakan nilai faktur. | ||
| Deskripsi Atribut ini menunjukkan mata uang faktur, seperti USD, EUR, atau GBP. Perusahaan multinasional sering menerbitkan faktur dalam berbagai mata uang. Analisis data dengan beberapa mata uang memerlukan penanganan yang cermat. Atribut ini memungkinkan Anda memfilter tampilan proses berdasarkan mata uang atau menerapkan nilai tukar yang tepat untuk laporan keuangan konsolidasi. Dengan begitu, nilai uang dapat ditafsirkan dengan benar dan jumlah dapat dibandingkan secara setara. Mengapa ini penting Penting untuk menafsirkan data keuangan dengan benar dalam lingkungan yang menggunakan berbagai mata uang dan memastikan analisis keuangan akurat. Sumber data Biasanya terdapat di tabel RA_CUSTOMER_TRX_ALL sebagai INVOICE_CURRENCY_CODE. Contoh USDEURGBPJPY | |||
| Status Faktur InvoiceStatus | Status faktur saat ini dalam siklusnya. | ||
| Deskripsi Status Faktur menunjukkan posisi faktur saat ini dalam proses. Status yang umum antara lain 'Terbuka', 'Lunas', 'Disengketakan', 'Lewat Jatuh Tempo', atau 'Dihapuskan'. Atribut ini memberikan gambaran umum tentang kondisi piutang. Dalam process mining, atribut ini berguna untuk memfilter kasus dan berfokus pada kelompok tertentu, misalnya semua faktur terbuka yang telah lewat jatuh tempo. Atribut ini menjadi dimensi utama dalam dasbor Umur dan Status Faktur Lewat Jatuh Tempo. Dasbor tersebut menampilkan kondisi terkini seluruh faktur dan membantu menentukan prioritas penagihan. Mengapa ini penting Memberikan gambaran singkat tentang kondisi faktur saat ini, sehingga faktur mudah difilter dan upaya penagihan dapat diprioritaskan. Sumber data Biasanya tersedia di tabel AR_PAYMENT_SCHEDULES_ALL, pada kolom bernama STATUS. Contoh TerbukaDitutupDisengketakanDalam Penagihan | |||
| Sudah Dihapuskan IsWrittenOff | Penanda boolean yang menunjukkan apakah faktur telah dihapuskan sebagai utang macet. | ||
| Deskripsi Penanda turunan ini mengidentifikasi faktur yang dinilai perusahaan tidak dapat ditagih dan telah dikeluarkan dari piutang aktif. Ini biasanya menjadi hasil akhir yang tidak diinginkan untuk sebuah faktur. Atribut ini penting untuk menghitung KPI Tingkat Penghapusbukuan Faktur dan mendukung analisis di dasbor terkait. Analis dapat memisahkan kasus penagihan yang gagal untuk menemukan karakteristik umum, seperti segmen pelanggan atau nilai faktur, yang mungkin berkaitan dengan risiko penghapusbukuan lebih tinggi. Temuan ini digunakan untuk menyempurnakan kebijakan kredit dan strategi penagihan. Mengapa ini penting Menandai kasus kegagalan penagihan dengan jelas, sehingga akar masalah utang macet dapat dianalisis dan tingkat penghapusbukuan dapat dihitung. Sumber data Ini adalah kolom hasil perhitungan. Nilainya ditentukan dengan memeriksa apakah terdapat aktivitas 'Invoice Written Off' pada kasus atau apakah status faktur adalah 'Written Off'. Contoh truefalse | |||
| Sudah Lewat Jatuh Tempo IsOverdue | Penanda boolean yang menunjukkan apakah faktur telah melewati tanggal jatuh tempo pembayaran. | ||
| Deskripsi Atribut turunan ini menunjukkan secara sederhana apakah faktur sudah lewat jatuh tempo. Nilainya biasanya dihitung dengan membandingkan tanggal saat ini (atau tanggal pembayaran) dengan tanggal jatuh tempo faktur. Penanda ini sangat berguna untuk memfilter dan mengelompokkan data dalam analisis. Analis dapat dengan cepat memilih faktur yang lewat jatuh tempo untuk mempelajari alur prosesnya, efektivitas aktivitas penagihan, dan karakteristik lainnya. Penanda ini juga memudahkan pembuatan dasbor dan KPI untuk mengelola utang yang lewat jatuh tempo, seperti dasbor Umur dan Status Faktur Lewat Jatuh Tempo. Mengapa ini penting Memberikan penanda yang jelas untuk mengidentifikasi dan menganalisis semua faktur yang lewat jatuh tempo, fokus utama proses penagihan. Sumber data Ini adalah kolom hasil perhitungan. Logikanya: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Contoh truefalse | |||
| Syarat Pembayaran PaymentTerms | Ketentuan yang disepakati untuk menentukan kapan pembayaran harus dilakukan. | ||
| Deskripsi Syarat Pembayaran menetapkan ketentuan pembayaran bagi pelanggan, misalnya 'Net 30' atau 'Net 60'. Ketentuan ini digunakan untuk menghitung tanggal jatuh tempo faktur. Analisis kinerja pembayaran berdasarkan syarat pembayaran dapat menunjukkan pola tertentu. Misalnya, pelanggan dengan jangka waktu pembayaran lebih singkat mungkin lebih sering terlambat membayar. Informasi ini dapat digunakan untuk meninjau dan menyempurnakan kebijakan kredit, serta mengelompokkan pelanggan untuk menerapkan strategi penagihan yang berbeda. Hasilnya memberi konteks untuk memahami penyebab faktur tertentu terlambat dibayar. Mengapa ini penting Memberikan konteks tentang jadwal pembayaran yang disepakati, sehingga perilaku pembayaran dapat dianalisis berdasarkan ketentuan kredit yang berbeda. Sumber data Data ini disimpan di tabel RA_TERMS dan ditautkan ke transaksi faktur. Contoh Net 30Net 60Jatuh Tempo Saat Diterima | |||
| Tanggal Janji Pembayaran PromiseToPayDate | Tanggal yang dijanjikan pelanggan untuk melakukan pembayaran. | ||
| Deskripsi Saat proses penagihan berlangsung, pelanggan mungkin berkomitmen untuk membayar pada tanggal tertentu di kemudian hari. 'Tanggal Janji Pembayaran' dicatat untuk memantau komitmen tersebut. Atribut ini penting untuk mengelola alur kerja penagihan dan menilai keandalan komitmen pelanggan. Dengan membandingkan Tanggal Janji Pembayaran dengan tanggal pembayaran diterima, petugas penagihan dapat menilai seberapa sering janji tersebut dipenuhi. Informasi ini membantu memperkirakan arus kas dengan lebih akurat dan menentukan kapan upaya penagihan perlu ditingkatkan jika janji tidak ditepati. Mengapa ini penting Mencatat komitmen pembayaran pelanggan, membantu memperkirakan penerimaan kas dan mengelola efektivitas negosiasi penagihan. Sumber data Disimpan di modul Oracle Advanced Collections, kemungkinan dalam tabel seperti IEX_PROMISES_T. Contoh 2023-06-102023-06-252023-07-05 | |||
| Unit Bisnis BusinessUnit | Unit bisnis atau entitas organisasi tertentu yang menerbitkan faktur. | ||
| Deskripsi Di organisasi besar, kegiatan operasional sering dibagi ke beberapa unit bisnis. Atribut ini menunjukkan unit bisnis yang terkait dengan faktur. Analisis proses berdasarkan Unit Bisnis memungkinkan perbandingan kinerja antarbagian organisasi. Analisis ini dapat menyoroti perbedaan penerapan kebijakan kredit dan penagihan, serta menunjukkan unit bisnis yang lebih efektif dalam mengelola piutang. Hasilnya membantu organisasi berbagi praktik yang baik dan menyeragamkan proses bila diperlukan. Mengapa ini penting Memungkinkan perbandingan kinerja antarunit organisasi, sehingga praktik yang baik dan area yang perlu diperbaiki dapat diketahui. Sumber data Tersedia di tabel RA_CUSTOMER_TRX_ALL melalui kolom ORG_ID, yang terhubung ke struktur organisasi. Contoh Unit Bisnis Amerika UtaraUnit Bisnis EMEADivisi Layanan Global | |||
| Waktu Selesai EndTime | Stempel waktu yang menunjukkan kapan aktivitas berdurasi selesai. | ||
| Deskripsi Untuk aktivitas yang memiliki waktu mulai dan selesai, atribut ini mencatat waktu penyelesaiannya. Banyak event dalam process mining terjadi seketika, tetapi beberapa aktivitas, seperti 'Investigasi Sengketa', dapat berlangsung selama jangka waktu tertentu. Waktu Selesai terpisah memungkinkan durasi pemrosesan aktivitas dihitung dengan tepat. Hasilnya lebih akurat daripada memperkirakan durasi dari waktu mulai aktivitas berikutnya, terutama jika ada waktu jeda. Atribut ini penting untuk menganalisis pemanfaatan sumber daya dan mengetahui langkah tertentu yang paling banyak menyita waktu dalam proses. Mengapa ini penting Memungkinkan penghitungan durasi aktivitas tertentu secara akurat, sehingga hambatan dan pemanfaatan sumber daya dapat dianalisis lebih mendalam. Sumber data Atribut ini sering kali bersifat konseptual. Sumbernya mungkin berupa stempel waktu 'terakhir diperbarui' atau kolom 'tanggal penutupan' tertentu di tabel sumber yang sesuai dengan aktivitas. Contoh 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
Aktivitas Pengelolaan Kredit dan Penagihan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Faktur dibuat | Menandai pembuatan catatan transaksi faktur di Oracle Fusion Financials. Peristiwa ini menjadi awal resmi siklus hidup faktur dalam modul piutang dan titik awal utama untuk analisis. | ||
| Mengapa ini penting Ini adalah peristiwa awal yang penting dalam perjalanan faktur. Semua perhitungan waktu siklus berikutnya, seperti Days Sales Outstanding (DSO) dan waktu siklus pembayaran faktur, bergantung pada cap waktu awal ini. Sumber data Peristiwa ini tercatat secara langsung pada kolom CREATION_DATE atau TRX_DATE di tabel RA_CUSTOMER_TRX_ALL untuk TRX_NUMBER (Nomor Faktur) tertentu. Pengumpulan data Waktu peristiwa menggunakan CREATION_DATE dari tabel RA_CUSTOMER_TRX_ALL. Jenis peristiwa explicit | |||
| Faktur dihapuskan | Menandai keputusan resmi untuk menghentikan upaya penagihan dan membukukan nilai faktur sebagai piutang tak tertagih. Ini adalah transaksi keuangan langsung yang menyesuaikan saldo faktur menjadi nol. | ||
| Mengapa ini penting Ini adalah titik akhir yang menandakan kegagalan dalam proses penagihan. Menganalisis penghapusan piutang berdasarkan segmen pelanggan, wilayah, atau batas kredit membantu menyempurnakan kebijakan kredit dan strategi penagihan untuk mengurangi kerugian. Sumber data Dicatat secara langsung saat penyesuaian dibuat di tabel AR_ADJUSTMENTS_ALL dengan RECEIVABLES_TRX_ID yang merujuk pada aktivitas piutang tak tertagih atau penghapusan piutang. Pengumpulan data Tanggal pembuatan catatan di AR_ADJUSTMENTS_ALL dengan jenis aktivitas penghapusan piutang. Jenis peristiwa explicit | |||
| Pembayaran dialokasikan | Menandai pengalokasian pembayaran yang diterima ke faktur tertentu sehingga saldo terutang faktur berkurang. Pada tahap inilah pembayaran secara resmi ditautkan ke faktur. | ||
| Mengapa ini penting Aktivitas ini penting untuk memastikan faktur tercatat telah dibayar. Inilah titik akhir yang sebenarnya untuk perhitungan Days Sales Outstanding (DSO) dan siklus pencatatan pembayaran. Sumber data Peristiwa ini tercatat secara langsung dari APPLY_DATE di tabel AR_RECEIVABLE_APPLICATIONS_ALL, yang menautkan penerimaan kas ke transaksi pelanggan (faktur). Pengumpulan data APPLY_DATE dari AR_RECEIVABLE_APPLICATIONS_ALL untuk faktur terkait. Jenis peristiwa explicit | |||
| Pembayaran diterima | Menandai penerimaan dana dari pelanggan, yang mungkin belum dialokasikan ke faktur tertentu. Peristiwa ini tercatat saat transaksi penerimaan kas dibuat di sistem. | ||
| Mengapa ini penting Ini adalah tonggak penting dalam proses penagihan yang menandakan kas telah diterima. Waktu antara peristiwa ini dan pengalokasian pembayaran mengukur efisiensi pemrosesan internal. Sumber data Dicatat secara langsung dari RECEIPT_DATE di tabel AR_CASH_RECEIPTS_ALL. Penerimaan kemudian dapat ditautkan ke faktur yang dibayar melalui AR_RECEIVABLE_APPLICATIONS_ALL. Pengumpulan data RECEIPT_DATE dari AR_CASH_RECEIPTS_ALL, ditautkan melalui tabel aplikasi. Jenis peristiwa explicit | |||
| Prosedur penagihan dimulai | Menandai dimulainya proses penagihan resmi untuk faktur yang telah jatuh tempo, biasanya dengan mengirim surat penagihan resmi pertama. Peristiwa ini umumnya tercatat saat proses batch penagihan berjalan dan menyertakan faktur tersebut. | ||
| Mengapa ini penting Melacak aktivitas ini penting untuk mengukur efektivitas penagihan dan kepatuhan terhadap kebijakan penagihan. Data ini menjadi acuan untuk mengukur waktu yang dibutuhkan hingga penagihan menghasilkan pembayaran. Sumber data Dicatat dalam modul Oracle Advanced Collections. Tanggal pembuatan catatan penagihan di tabel seperti IEX_DUNNINGS, yang ditautkan ke ID transaksi, menandai peristiwa ini. Pengumpulan data Tanggal pembuatan catatan di tabel IEX_DUNNINGS yang terkait dengan faktur. Jenis peristiwa explicit | |||
| Tanggal jatuh tempo pembayaran terlewati | Peristiwa terhitung yang terjadi ketika tanggal saat ini melewati tanggal jatuh tempo faktur dan faktur belum lunas. Peristiwa ini menandai perubahan status faktur dari 'belum jatuh tempo' menjadi 'terlambat'. | ||
| Mengapa ini penting Ini adalah tonggak penting yang memicu proses penagihan. Menganalisis jumlah dan nilai faktur yang melewati tanggal jatuh tempo penting untuk mengelola modal kerja dan menilai risiko kredit. Sumber data Peristiwa ini dihitung dengan membandingkan tanggal sistem saat ini dengan DUE_DATE di tabel AR_PAYMENT_SCHEDULES_ALL untuk faktur berstatus 'OP' (Terbuka). Pengumpulan data Peristiwa terhitung: terjadi ketika SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Jenis peristiwa calculated | |||
| Faktur dikirim ke pelanggan | Menunjukkan bahwa faktur telah disampaikan secara resmi kepada pelanggan, baik secara elektronik maupun dalam bentuk cetak. Peristiwa ini dapat dicatat langsung oleh modul pengiriman atau disimpulkan dari tanggal pencetakan faktur. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya masa pembayaran pelanggan. Dengan melacaknya, Anda dapat menghitung hari keterlambatan secara akurat dan menganalisis jeda antara pembuatan faktur dan pemberitahuan kepada pelanggan. Sumber data Data dapat diambil dari LAST_PRINTED_DATE di RA_CUSTOMER_TRX_ALL. Alternatifnya, peristiwa ini dapat disimpulkan dari log integrasi dengan sistem pengiriman email atau platform komunikasi lainnya. Pengumpulan data Gunakan LAST_PRINTED_DATE dari RA_CUSTOMER_TRX_ALL atau status dari log pengiriman. Jenis peristiwa inferred | |||
| Faktur ditutup | Terjadi saat saldo terutang faktur menjadi nol, baik melalui pembayaran, pengalokasian nota kredit, maupun penyesuaian. Ini menandai selesainya siklus hidup faktur. | ||
| Mengapa ini penting Peristiwa ini menjadi salah satu titik akhir utama yang menandakan proses berhasil. Memantau penutupan faktur penting untuk memahami kondisi keseluruhan portofolio piutang. Sumber data Disimpulkan dari perubahan status di tabel AR_PAYMENT_SCHEDULES_ALL, saat STATUS berubah menjadi 'CL' (Ditutup). Cap waktunya adalah LAST_UPDATE_DATE dari perubahan tersebut. Pengumpulan data Deteksi saat AR_PAYMENT_SCHEDULES_ALL.STATUS menjadi 'CL' untuk faktur tersebut. Jenis peristiwa inferred | |||
| Janji pembayaran dibuat | Menandai kesepakatan resmi yang dicatat dalam sistem, saat pelanggan berjanji akan membayar pada tanggal tertentu. Ini merupakan salah satu hasil penting dari aktivitas penagihan. | ||
| Mengapa ini penting Melacak janji pembayaran dan tingkat pemenuhannya merupakan indikator kinerja utama bagi petugas penagihan. Data ini membantu memperkirakan arus kas dari piutang yang telah jatuh tempo dan menilai efektivitas petugas. Sumber data Dibuat secara langsung di Oracle Advanced Collections. Tanggal pembuatan diambil dari tabel IEX_PROMISE_DETAILS. Pengumpulan data Tanggal pembuatan dari tabel IEX_PROMISE_DETAILS untuk faktur terkait. Jenis peristiwa explicit | |||
| Sengketa didaftarkan | Menunjukkan bahwa pelanggan secara resmi menyengketakan sebagian atau seluruh faktur. Peristiwa ini biasanya dicatat melalui perubahan status pada jadwal pembayaran faktur. | ||
| Mengapa ini penting Aktivitas ini menjadi awal proses penyelesaian sengketa. Menganalisis waktu dari pendaftaran hingga penyelesaian penting untuk menemukan hambatan yang menunda penerimaan kas. Sumber data Disimpulkan dari perubahan status di tabel AR_PAYMENT_SCHEDULES_ALL, saat kolom STATUS berubah menjadi 'DS' (Disengketakan). Cap waktu dapat diambil dari tabel audit atau tanggal pembaruan terakhir. Pengumpulan data Deteksi saat AR_PAYMENT_SCHEDULES_ALL.STATUS berubah menjadi 'DS' untuk faktur tersebut. Jenis peristiwa inferred | |||
| Sengketa diselesaikan | Menunjukkan bahwa sengketa yang terdaftar telah diselidiki dan diselesaikan. Peristiwa ini tercatat saat status sengketa pada faktur dihapus. | ||
| Mengapa ini penting Peristiwa ini menandai akhir siklus penyelesaian sengketa. Durasi antara 'Sengketa didaftarkan' dan peristiwa ini merupakan KPI penting untuk mengukur efisiensi operasional dan dampaknya terhadap arus kas. Sumber data Disimpulkan saat STATUS di AR_PAYMENT_SCHEDULES_ALL berubah dari 'DS' (Disengketakan) kembali menjadi 'OP' (Terbuka) atau 'CL' (Ditutup) setelah nota kredit atau penyesuaian. Pengumpulan data Deteksi saat AR_PAYMENT_SCHEDULES_ALL.STATUS berubah dari 'DS' ke status lain. Jenis peristiwa inferred | |||
| Strategi penagihan ditetapkan | Terjadi saat strategi penagihan otomatis ditetapkan untuk faktur atau pelanggan yang telah jatuh tempo. Strategi ini menentukan rangkaian langkah dan aktivitas yang akan dijalankan oleh sistem atau petugas penagihan. | ||
| Mengapa ini penting Peristiwa ini memberi gambaran tentang otomatisasi proses penagihan. Menganalisis strategi yang ditetapkan dan hasilnya membantu mengoptimalkan pendekatan penagihan untuk berbagai segmen pelanggan. Sumber data Dicatat dalam modul Oracle Advanced Collections. Biasanya, data ini dapat ditemukan dengan melihat tanggal pembuatan penetapan strategi di tabel seperti IEX_STRATEGIES atau objek terkait. Pengumpulan data Tanggal pembuatan item kerja strategi di tabel penagihan yang ditautkan ke pelanggan atau transaksi. Jenis peristiwa explicit | |||
| Tindakan petugas penagihan selesai | Menandai tindakan manual yang dilakukan petugas penagihan, seperti menelepon, mengirim email, atau mencatat interaksi. Tindakan ini dicatat sebagai 'aktivitas' atau 'interaksi' dalam modul penagihan. | ||
| Mengapa ini penting Memantau tindakan petugas penagihan membantu mengukur efisiensi dan efektivitas alur kerja penagihan manual. Anda dapat menganalisis frekuensi aktivitas dan kaitannya dengan keberhasilan pembayaran. Sumber data Diambil dari tabel riwayat interaksi atau aktivitas di Oracle Advanced Collections, seperti JTF_IH_ACTIVITIES, yang ditautkan ke pelanggan dan, jika tersedia, ke faktur tertentu. Pengumpulan data Cap waktu pembuatan catatan di JTF_IH_ACTIVITIES dengan hasil atau kode alasan yang relevan. Jenis peristiwa explicit | |||
| Tinjauan kredit selesai | Menandai selesainya penilaian kredit untuk pelanggan yang terkait dengan faktur. Peristiwa ini biasanya disimpulkan dengan menghubungkan tanggal pembuatan faktur ke tanggal penyelesaian tinjauan kredit terbaru untuk akun pelanggan tersebut. Data ini menjadi acuan awal untuk analisis terkait kredit. | ||
| Mengapa ini penting Menganalisis waktu antara tinjauan kredit dan penempatan pesanan membantu menemukan keterlambatan pada tahap awal siklus pesanan hingga pembayaran. Data ini menjadi dasar untuk mengukur KPI Waktu Siklus Persetujuan Kredit dan memahami dampak keputusan kredit. Sumber data Disimpulkan dengan mengambil HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE untuk pelanggan pada faktur (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Waktu peristiwa adalah LAST_CREDIT_REVIEW_DATE yang mendahului CREATION_DATE faktur. Pengumpulan data Hubungkan faktur dengan tanggal tinjauan kredit terbaru pelanggan sebelum faktur dibuat. Jenis peristiwa inferred | |||
Panduan Ekstraksi
Langkah
- Buka Oracle BI Publisher: Masuk ke lingkungan Oracle Fusion Financials Anda. Buka bagian Reports and Analytics dengan mengeklik ikon Navigator, lalu pilih Tools > Reports and Analytics.
- Buat Model Data Baru: Di panel Reports and Analytics, klik tombol 'Browse Catalog'. Di katalog, klik menu tarik-turun 'New', lalu pilih 'Data Model'.
- Tentukan Kumpulan Data SQL Query: Di editor Data Model, klik ikon '+' untuk menambahkan kumpulan data baru, lalu pilih 'SQL Query'.
- Atur Sumber Data: Di jendela kumpulan data baru, beri nama yang jelas, misalnya 'CreditCollectionsEventLog'. Pilih 'FSCM' atau basis data aplikasi Oracle Fusion yang sesuai sebagai Sumber Data. Atur Type of SQL ke 'Standard SQL'.
- Masukkan SQL Query: Salin seluruh SQL query yang tersedia di bagian 'query' dokumen ini, lalu tempelkan ke area teks SQL Query.
- Tentukan Parameter Query: Query menggunakan parameter seperti
:P_START_DATEdan:P_END_DATEuntuk memfilter rentang tanggal. BI Publisher akan mendeteksinya secara otomatis. Anda dapat mengaturnya sebagai prompt pengguna dan menetapkan tipe data 'Date'. - Simpan dan Uji Model Data: Simpan model data di folder bersama atau folder khusus. Untuk memastikan query berfungsi, buka tab 'Data', masukkan nilai parameter contoh, misalnya rentang tanggal terbaru, lalu klik 'View' untuk melihat contoh data keluaran. Pastikan semua kolom tampil dengan benar.
- Buat Laporan Baru: Kembali ke katalog, klik menu tarik-turun 'New', lalu pilih 'Report'. Di dialog 'Create Report', pilih 'Use Data Model', lalu cari model data yang baru saja Anda simpan.
- Atur Properti Laporan: Tata letak tabel sederhana sudah cukup untuk mengekstrak data. Tetapkan format keluaran default. Untuk process mining, format yang disarankan adalah CSV. Klik 'View a List', cari 'CSV' di daftar 'Output Formats', lalu centang kotaknya. Anda dapat menghapus centang pada format lain agar lebih mudah digunakan.
- Simpan Laporan: Simpan laporan di folder yang sama dengan model data.
- Jadwalkan Ekstraksi: Untuk mengotomatiskan ekstraksi, Anda dapat menjadwalkan laporan. Buka laporan, klik 'Actions', lalu pilih 'Schedule'. Atur frekuensi jadwal, misalnya harian, tentukan format keluaran CSV, lalu pilih tujuan pengiriman, seperti direktori content server atau server eksternal melalui FTP.
Konfigurasi
- Prasyarat: Pengguna yang membuat dan menjalankan laporan harus memiliki peran BI yang sesuai, misalnya 'BI Administrator' atau 'BI Author', serta hak akses keamanan data untuk mengakses tabel Financials terkait (AR, IEX, HZ, JTF).
- Sumber Data: Query harus dijalankan pada basis data aplikasi utama, yang biasanya bernama 'FSCM'.
- Parameter Rentang Tanggal: Gunakan parameter
:P_START_DATEdan:P_END_DATEuntuk membatasi volume data. Untuk pengujian awal, gunakan rentang pendek, misalnya satu bulan. Untuk penggunaan rutin, rentang bergulir 3 hingga 6 bulan biasanya sesuai. - Pemfilteran: Untuk organisasi besar, pertimbangkan menambahkan parameter
BU_NAME(Business Unit Name) ke klausaWHEREpada ekspresi tabel umuminvoices_base. Dengan begitu, data dapat diproses untuk satu unit bisnis setiap kali. - Pertimbangan Kinerja: Query menggabungkan beberapa tabel transaksi berukuran besar. Jika dijalankan untuk rentang tanggal yang luas tanpa filter, prosesnya bisa lama atau mengalami batas waktu di BI Publisher. Jadwalkan laporan di luar jam sibuk.
- Format Keluaran: Pastikan format keluaran default atau terjadwal adalah CSV. Format ini menghasilkan file dengan pemisah kolom yang mudah digunakan oleh alat process mining. Periksa properti keluaran CSV untuk memastikan pemisah dan pengodean karakter sudah benar.
Contoh kueri sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' Siap Memulai?
Gunakan templat ini untuk menyiapkan data sebelum dianalisis dan menemukan wawasan penting tentang proses pengelolaan kredit dan penagihan. Mulai tingkatkan proses Anda hari ini.
Mulai Optimalkan Pengelolaan Kredit dan Penagihan Hari Ini
Pangkas waktu siklus hingga 30% dan perkuat kondisi keuangan di Oracle Fusion.
Tidak perlu kartu kredit. Mulai dalam hitungan menit.