Templat data Order to Cash - Penagihan dan Faktur

Oracle Fusion Financials
Templat data Order to Cash - Penagihan dan Faktur

Templat data Order to Cash - Penagihan dan Faktur

Templat ini memandu Anda menyiapkan data untuk menganalisis proses Order to Cash - Penagihan dan Faktur. Templat ini menjelaskan atribut penting yang perlu dikumpulkan, aktivitas utama yang perlu dilacak, serta cara mengekstrak data. Ikuti panduan ini untuk menyiapkan kumpulan data yang sesuai bagi process mining dan perbaikan proses.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama yang perlu dilacak
  • Panduan ekstraksi untuk Oracle Fusion Financials
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut Order to Cash - Penagihan dan Faktur

Berikut kolom data yang disarankan untuk disertakan dalam log peristiwa agar analisis Order to Cash - Penagihan dan Faktur berjalan menyeluruh.
3 Wajib 5 Disarankan 14 Opsional
Nama Deskripsi
Nomor faktur
InvoiceNumber
Nomor unik untuk setiap faktur penagihan. Nomor ini menjadi ID kasus utama untuk melacak semua aktivitas terkait.
Deskripsi

Nomor Faktur menjadi dasar analisis proses penagihan. Nomor ini berfungsi sebagai ID kasus yang mengelompokkan semua peristiwa, mulai dari pembuatan faktur hingga pembayaran dan penutupan. Dengan begitu, Anda dapat melihat seluruh siklus satu dokumen penagihan dari awal hingga akhir.

Dalam process mining, analisis berdasarkan Nomor Faktur membantu memetakan variasi proses, menghitung waktu siklus setiap faktur, serta menemukan hambatan atau pekerjaan ulang pada transaksi tertentu. Atribut ini penting untuk dashboard seperti 'Waktu siklus faktur dari awal hingga akhir' dan untuk menghitung KPI utama, seperti Days Sales Outstanding (DSO), per faktur.

Mengapa ini penting

Atribut ini menghubungkan semua aktivitas penagihan dan pembayaran terkait ke dalam satu kasus, sehingga siklus faktur dapat dianalisis secara lengkap dan akurat.

Sumber data

Biasanya berupa Transaction Number (TRX_NUMBER) dari tabel RA_CUSTOMER_TRX_ALL di Oracle Fusion Financials.

Contoh
INV-1002345983451CM-55432
Waktu mulai
EventTimestamp
Tanggal dan waktu tepat saat aktivitas atau peristiwa tertentu terjadi.
Deskripsi

Stempel waktu peristiwa mencatat waktu persis saat suatu aktivitas terjadi. Data ini menunjukkan urutan kronologis peristiwa untuk setiap faktur, yang diperlukan untuk menyusun alur proses dan melakukan analisis berbasis waktu.

Atribut ini menjadi dasar semua perhitungan durasi dan kinerja. Anda dapat menggunakannya untuk mengukur jeda antaraktivitas, menghitung waktu siklus dari awal hingga akhir, mengetahui apakah pembayaran tepat waktu, dan menganalisis tren dari waktu ke waktu. KPI seperti 'Rata-rata waktu persetujuan faktur' dan 'Waktu siklus faktur dari awal hingga akhir' dihitung langsung dari stempel waktu ini.

Mengapa ini penting

Stempel waktu diperlukan untuk menghitung semua metrik kinerja, termasuk waktu siklus, keterlambatan, dan ketepatan tenggat. Data ini menjadi dasar analisis proses secara kuantitatif.

Sumber data

Data ini diambil dari berbagai kolom tanggal di tabel Oracle Fusion Financials, seperti CREATION_DATE di RA_CUSTOMER_TRX_ALL atau stempel waktu pembaruan status di tabel workflow.

Contoh
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-20T11:25:10Z
Nama aktivitas
ActivityName
Nama peristiwa bisnis atau tugas tertentu yang terjadi pada suatu waktu dalam siklus faktur.
Deskripsi

Nama Aktivitas menjelaskan langkah dalam proses penagihan, seperti 'Faktur dibuat', 'Faktur disetujui', atau 'Pembayaran pelanggan diterima'. Rangkaian peristiwa ini membentuk alur proses untuk setiap faktur.

Atribut ini menjadi dasar penemuan proses. Dengan atribut ini, alat process mining dapat menyusun peta visual tentang cara faktur diproses sebenarnya. Atribut ini juga digunakan untuk menganalisis variasi proses, menemukan pekerjaan ulang seperti persetujuan berulang, serta mengukur frekuensi dan durasi setiap tahap. Semua dashboard dan KPI mengandalkan atribut ini untuk memahami alur proses.

Mengapa ini penting

Atribut ini menentukan langkah-langkah dalam peta proses, sehingga alur kerja faktur dapat divisualisasikan dan dianalisis, serta ketidakefisienan dapat ditemukan.

Sumber data

Informasi ini diperoleh dari berbagai tabel dan perubahan status di Oracle Fusion Financials, seperti tabel riwayat workflow, misalnya untuk persetujuan, serta kolom status transaksi.

Contoh
Faktur dibuatFaktur disetujuiPembayaran pelanggan diterimaFaktur ditutup
Nama pelanggan
CustomerName
Nama pelanggan atau entitas yang ditagih.
Deskripsi

Atribut ini menunjukkan pelanggan yang terkait dengan faktur. Atribut ini menjadi dimensi utama untuk mengelompokkan dan memfilter data proses.

Analisis berdasarkan Nama Pelanggan membantu Anda mengetahui pelanggan dengan siklus pembayaran terlama, pelanggan yang paling sering menyengketakan faktur, dan pelanggan yang selalu membayar tepat waktu. Informasi ini penting untuk dashboard Tren DSO dan untuk menyesuaikan strategi penagihan dengan perilaku setiap pelanggan.

Mengapa ini penting

Memungkinkan proses dikelompokkan berdasarkan pelanggan, sehingga perbedaan perilaku, pola pembayaran, dan potensi masalah hubungan yang memengaruhi arus kas dapat terlihat.

Sumber data

Diperoleh dengan menggabungkan tabel transaksi (RA_CUSTOMER_TRX_ALL) dengan tabel data induk pelanggan seperti HZ_PARTIES.

Contoh
Global Tech Inc.Innovate Solutions LLCApex Manufacturing
Nilai faktur
InvoiceAmount
Total nilai uang pada faktur.
Deskripsi

Atribut ini menunjukkan total tagihan yang harus dibayar pada faktur. Nilainya penting untuk memahami nilai uang yang mengalir dalam proses penagihan.

Dalam analisis, Nilai Faktur digunakan untuk memprioritaskan transaksi bernilai tinggi, menghitung total piutang yang belum dibayar, dan memberi bobot pada KPI seperti Days Sales Outstanding (DSO). Atribut ini juga membantu mengelompokkan proses berdasarkan dampak finansial. Misalnya, Anda dapat menganalisis apakah faktur bernilai tinggi mengikuti jalur persetujuan yang berbeda atau membutuhkan waktu lebih lama untuk dibayar.

Mengapa ini penting

Memberi konteks finansial untuk setiap kasus, sehingga Anda dapat menganalisis berdasarkan nilai, memprioritaskan faktur bernilai tinggi, dan menghitung KPI finansial utama.

Sumber data

Tersedia di tabel RA_CUSTOMER_TRX_ALL, kemungkinan pada kolom seperti INVOICE_AMOUNT atau kolom terkait yang menunjukkan total transaksi.

Contoh
5000.001250.75250000.00
Status faktur
InvoiceStatus
Status faktur saat ini dalam siklusnya, seperti 'Open', 'Closed', atau 'Disputed'.
Deskripsi

Status Faktur menunjukkan posisi faktur dalam proses. Status yang umum antara lain terbuka (belum dibayar), ditutup (sudah dibayar), disengketakan, atau dibatalkan.

Atribut ini berguna untuk pemantauan tingkat tinggi dan pemfilteran. Misalnya, dashboard Prakiraan Arus Kas Real-Time menggunakan status ini untuk mengelompokkan jumlah yang belum dibayar. Status ini membantu Anda menemukan dengan cepat faktur yang terlambat, disengketakan, atau sudah dilunasi.

Mengapa ini penting

Memberi gambaran cepat tentang kondisi faktur saat ini, sehingga faktur dapat difilter dan dikelompokkan dengan mudah untuk pelaporan keuangan dan pengelolaan operasional.

Sumber data

Diperoleh dari kolom status di tabel seperti RA_CUSTOMER_TRX_ALL atau AR_PAYMENT_SCHEDULES_ALL, misalnya kolom STATUS.

Contoh
TerbukaDitutupDisengketakanMenunggu persetujuan
Tanggal jatuh tempo
DueDate
Tanggal batas pembayaran faktur.
Deskripsi

Tanggal Jatuh Tempo adalah atribut tanggal penting yang menetapkan batas pembayaran faktur sesuai ketentuan pembayaran.

Atribut ini diperlukan untuk memantau penagihan dan kondisi keuangan. Tanggal ini menjadi acuan untuk menghitung KPI Tingkat Pembayaran Tepat Waktu dan membuat laporan umur piutang. Dalam dashboard, tanggal ini digunakan untuk memperkirakan arus kas berdasarkan waktu pembayaran yang diharapkan dan menemukan faktur terlambat yang perlu ditindaklanjuti.

Mengapa ini penting

Menjadi acuan utama untuk mengukur ketepatan waktu pembayaran, menghitung DSO, dan memantau umur piutang.

Sumber data

Tersedia di tabel AR_PAYMENT_SCHEDULES_ALL, biasanya pada kolom DUE_DATE.

Contoh
2023-05-302023-06-152023-07-01
Unit bisnis
BusinessUnit
Unit bisnis tertentu dalam organisasi yang menerbitkan faktur.
Deskripsi

Unit Bisnis menunjukkan entitas organisasi yang bertanggung jawab atas transaksi. Elemen data ini penting untuk pengelompokan dan pelaporan keuangan di perusahaan besar.

Atribut ini memungkinkan Anda membandingkan kinerja proses di berbagai bagian perusahaan. Misalnya, Anda dapat menganalisis apakah DSO berbeda jauh antarunit bisnis atau apakah satu unit memiliki tingkat pekerjaan ulang penagihan yang jauh lebih tinggi. Hasilnya membantu Anda menentukan bagian yang paling membutuhkan perbaikan.

Mengapa ini penting

Memungkinkan perbandingan kinerja antarunit organisasi, sehingga praktik yang baik dan bagian yang perlu diperbaiki dapat diketahui secara lebih terperinci.

Sumber data

Tersedia di tabel transaksi seperti RA_CUSTOMER_TRX_ALL, sering kali sebagai ORG_ID yang terhubung ke definisi unit bisnis.

Contoh
Konsultasi ASManufaktur EMEALayanan APAC
Alasan sengketa
DisputeReason
Alasan yang disampaikan pelanggan saat menyengketakan faktur.
Deskripsi

Saat pelanggan menyengketakan faktur, alasan sengketa dicatat. Alasannya bisa terkait harga, jumlah, kualitas layanan, atau masalah lainnya.

Analisis alasan sengketa membantu menemukan akar masalah. Dengan mengetahui penyebab sengketa yang paling umum, perusahaan dapat mengatasi masalah mendasar terkait harga, pemenuhan pesanan, atau kualitas data. Langkah ini membantu mengurangi Rata-rata Waktu Penyelesaian Sengketa Faktur dan meningkatkan kepuasan pelanggan.

Mengapa ini penting

Memberi gambaran langsung tentang penyebab keterlambatan pembayaran dan ketidakpuasan pelanggan, sehingga perusahaan dapat mengatasi masalah yang terjadi berulang.

Sumber data

Informasi ini mungkin tersimpan di Oracle Collections atau modul pengelolaan sengketa terkait. Data dapat berada di tabel sengketa khusus atau sebagai kode alasan pada transaksi.

Contoh
Harga tidak sesuaiJumlah tidak sesuaiBarang rusakFaktur duplikat
Days Sales Outstanding
DaysSalesOutstanding
Jumlah hari antara tanggal faktur dan tanggal pembayaran diterima.
Deskripsi

Days Sales Outstanding (DSO) adalah metrik keuangan penting yang mengukur rata-rata waktu yang dibutuhkan untuk menerima pembayaran setelah faktur diterbitkan. Atribut ini menghitung DSO untuk setiap faktur.

DSO keseluruhan merupakan KPI utama, tetapi perhitungan pada tingkat faktur memungkinkan analisis yang lebih terperinci. Data ini dapat digunakan untuk membuat dashboard tren, menemukan karakteristik faktur dengan DSO tinggi, dan mengukur dampak finansial dari keterlambatan proses. Perhitungan terperinci ini membantu Anda memahami faktor yang memengaruhi KPI DSO secara keseluruhan.

Mengapa ini penting

Menghitung metrik arus kas penting untuk setiap faktur, sehingga faktor yang memengaruhi waktu penagihan dan kinerja keuangan dapat dianalisis secara terperinci.

Sumber data

Dihitung dengan mencari selisih antara stempel waktu aktivitas 'Pembayaran pelanggan diterima' dan atribut 'Tanggal Faktur'.

Contoh
356228
Departemen penagihan
BillingDepartment
Departemen atau tim internal yang bertanggung jawab membuat dan mengelola faktur.
Deskripsi

Atribut ini menunjukkan tim atau departemen tertentu dalam organisasi yang menangani proses penagihan. Atribut ini memberikan konteks organisasi tambahan untuk analisis.

Dengan mengelompokkan proses berdasarkan Departemen Penagihan, perusahaan dapat membandingkan efisiensi dan ketepatan kerja setiap tim. Analisis ini membantu menemukan departemen dengan tingkat pekerjaan ulang lebih tinggi, siklus persetujuan lebih lama, atau kontribusi lebih besar terhadap DSO yang tinggi. Hasilnya dapat menunjukkan peluang pelatihan terarah atau standardisasi proses.

Mengapa ini penting

Memungkinkan perbandingan kinerja antar tim internal, sehingga praktik yang baik, kebutuhan sumber daya, dan bagian yang perlu diperbaiki dapat diketahui.

Sumber data

Informasi ini mungkin diperoleh dari pengguna yang membuat faktur dengan mencocokkan pengguna tersebut ke departemen yang tercatat di sistem SDM, misalnya melalui PER_ALL_ASSIGNMENTS_F.

Contoh
Penagihan korporatTim penagihan layananPenagihan penjualan produk
Dibayar tepat waktu
IsPaidOnTime
Penanda boolean yang menunjukkan apakah faktur dibayar pada atau sebelum tanggal jatuh tempo.
Deskripsi

Atribut hasil perhitungan ini memberikan indikator sederhana, benar atau salah, untuk menunjukkan ketepatan waktu pembayaran. Nilainya diperoleh dengan membandingkan tanggal aktivitas 'Pembayaran pelanggan diterima' dengan atribut 'Tanggal Jatuh Tempo' faktur.

Penanda ini memudahkan analisis dan pelaporan KPI Tingkat Pembayaran Tepat Waktu. Anda dapat memfilter dan mengelompokkan data untuk mengetahui faktor yang berkaitan dengan keterlambatan pembayaran, seperti pelanggan, wilayah, atau nilai faktur. Metrik ini penting untuk menilai efektivitas penagihan.

Mengapa ini penting

Memudahkan pengukuran kinerja penagihan dan analisis faktor yang menyebabkan pembayaran tepat waktu atau terlambat.

Sumber data

Dihitung dengan membandingkan stempel waktu aktivitas pembayaran terakhir dengan atribut DueDate. Logikanya: PaymentTimestamp <= DueDate.

Contoh
truefalse
Ketentuan pembayaran
PaymentTerms
Ketentuan pembayaran faktur yang disepakati, seperti 'Net 30' atau '2% 10, Net 30'.
Deskripsi

Ketentuan Pembayaran menetapkan aturan waktu dan cara pembayaran faktur, termasuk kemungkinan diskon untuk pembayaran lebih awal. Informasi ini penting untuk mengelola piutang dan arus kas.

Atribut ini diperlukan untuk menghitung tanggal jatuh tempo yang tepat dan menemukan peluang diskon pembayaran awal. KPI Tingkat Pemanfaatan Diskon Pembayaran Awal bergantung langsung pada data ini untuk menentukan faktur yang memenuhi syarat diskon.

Mengapa ini penting

Menetapkan aturan pembayaran faktur, yang langsung memengaruhi perhitungan tanggal jatuh tempo dan kemampuan melacak serta meningkatkan pemanfaatan diskon pembayaran awal.

Sumber data

Tersedia di tabel RA_TERMS dan terhubung ke transaksi melalui term_id di RA_CUSTOMER_TRX_ALL.

Contoh
Net 30Net 602% 10, Net 30
Merupakan pekerjaan ulang
IsRework
Penanda boolean yang menunjukkan apakah suatu aktivitas dianggap sebagai pekerjaan ulang, misalnya persetujuan atau koreksi yang diulang.
Deskripsi

Atribut hasil perhitungan ini menandai aktivitas yang menunjukkan pekerjaan tidak perlu atau berulang. Contohnya, faktur ditolak lalu diajukan kembali untuk persetujuan, atau dikoreksi setelah pertama kali dibuat.

Penanda pekerjaan ulang memudahkan Anda mengukur dampaknya terhadap proses. KPI Tingkat Pekerjaan Ulang Penagihan dihitung langsung dari atribut ini. Dashboard dapat menampilkan frekuensi pekerjaan ulang dan mengukur tambahan waktu siklus yang ditimbulkannya, sehingga sumber ketidakefisienan dan kesalahan dapat ditemukan.

Mengapa ini penting

Mengukur ketidakefisienan proses secara langsung dengan menandai pekerjaan yang tidak perlu atau berulang, sehingga dampak masalah kualitas terhadap biaya dan waktu dapat diketahui.

Sumber data

Dihitung saat transformasi data berdasarkan urutan aktivitas. Misalnya, jika aktivitas 'Faktur disetujui' didahului aktivitas 'Faktur ditolak' untuk kasus yang sama, aktivitas tersebut ditandai sebagai pekerjaan ulang.

Contoh
truefalse
Metode pembayaran
PaymentMethod
Cara yang digunakan pelanggan untuk membayar, seperti transfer bank atau kartu kredit.
Deskripsi

Atribut ini menunjukkan cara pelanggan membayar faktur. Informasi ini berguna untuk menganalisis tren dan biaya pembayaran.

Setiap metode pembayaran dapat memiliki waktu pemrosesan dan biaya transaksi yang berbeda. Analisis berdasarkan metode pembayaran membantu mengetahui apakah metode tertentu lebih sering menimbulkan kesalahan rekonsiliasi atau keterlambatan. Informasi ini juga dapat digunakan untuk mendorong pelanggan memilih saluran pembayaran yang lebih efisien.

Mengapa ini penting

Membantu menganalisis efisiensi pemrosesan pembayaran, biaya transaksi, dan tingkat kesalahan rekonsiliasi pada berbagai saluran pembayaran.

Sumber data

Tersedia di tabel penerimaan kas, seperti AR_CASH_RECEIPTS_ALL, yang memuat kolom untuk menunjukkan metode pembayaran.

Contoh
ACHTransfer bankKartu kreditCek
Pembaruan data terakhir
LastDataUpdate
Stempel waktu yang menunjukkan kapan data untuk peristiwa ini terakhir diperbarui atau diekstrak dari sistem sumber.
Deskripsi

Atribut ini mencatat waktu ekstraksi data terbaru. Sebagai kolom metadata, atribut ini membantu Anda mengetahui seberapa baru data yang dianalisis.

Analis menggunakan informasi ini untuk memastikan data yang mereka gunakan masih mutakhir dan mengetahui kapan data tersebut terakhir diperbarui. Informasi ini sangat penting untuk dashboard yang menyatakan datanya 'real-time' atau mendekati real-time, karena menunjukkan kemungkinan jeda pembaruan data.

Mengapa ini penting

Memberi tahu pengguna seberapa baru data yang tersedia, sehingga analisis dan kesimpulan didasarkan pada informasi yang tingkat kemutakhirannya diketahui dan dapat diterima.

Sumber data

Kolom metadata ini dibuat selama proses ekstraksi, transformasi, dan pemuatan data (ETL). Biasanya, nilainya menunjukkan waktu eksekusi pipeline data.

Contoh
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Pengguna
User
Karyawan atau pengguna sistem yang melakukan aktivitas tertentu.
Deskripsi

Atribut Pengguna menunjukkan orang atau agen otomatis yang bertanggung jawab menjalankan langkah proses. Pengguna tersebut bisa saja orang yang membuat faktur, manajer yang menyetujuinya, atau petugas penagihan yang mengirim pengingat.

Analisis berdasarkan pengguna membantu menemukan kebutuhan pelatihan, melihat pembagian beban kerja, dan membandingkan kinerja antarindividu atau tim. Analisis ini dapat menunjukkan pengguna yang sering terkait dengan tingkat kesalahan tinggi atau pemberi persetujuan tertentu yang kerap menjadi hambatan.

Mengapa ini penting

Menetapkan penanggung jawab untuk setiap langkah proses, sehingga kinerja pengguna dan pembagian beban kerja dapat dianalisis serta kebutuhan pelatihan dapat diketahui.

Sumber data

Diambil dari kolom ID pengguna seperti CREATED_BY atau LAST_UPDATED_BY di berbagai tabel transaksi dan workflow. ID ini kemudian dicocokkan dengan tabel direktori pengguna, misalnya PER_ALL_PEOPLE_F, untuk mendapatkan nama pengguna.

Contoh
john.smithjane.doeCollectionsBot
Sistem sumber
SourceSystem
Sistem pencatatan asal tempat data peristiwa diekstrak.
Deskripsi

Atribut ini menunjukkan aplikasi sumber asal data. Untuk proses ini, biasanya sumbernya Oracle Fusion Financials, tetapi bisa juga modul tertentu di dalamnya, seperti Oracle Receivables (AR).

Jika lingkungan kerja menggunakan beberapa sistem yang terintegrasi, kolom ini membantu membedakan sumber data dan mendukung validasi serta tata kelola data. Dengan begitu, analisis menggunakan kumpulan data yang tepat dan sesuai tujuan.

Mengapa ini penting

Menunjukkan asal data. Informasi ini penting untuk tata kelola data, pemecahan masalah, dan memastikan analisis menggunakan sistem pencatatan yang tepat.

Sumber data

Biasanya berupa nilai tetap ('Oracle Fusion Financials') yang ditambahkan saat proses ekstraksi dan transformasi data.

Contoh
Oracle Fusion FinancialsOracle AR CloudFusion Apps
Tanggal faktur
InvoiceDate
Tanggal resmi penerbitan faktur.
Deskripsi

Tanggal Faktur, yang juga dikenal sebagai tanggal transaksi, adalah tanggal yang tercantum pada dokumen faktur. Tanggal ini menjadi titik awal perhitungan ketentuan pembayaran.

Tanggal ini penting untuk menghitung Days Sales Outstanding (DSO), yang mengukur waktu sejak Tanggal Faktur hingga pembayaran diterima. Tanggal ini berbeda dari tanggal pembuatan faktur di sistem dan menandai awal resmi siklus pembayaran dari sudut pandang pelanggan.

Mengapa ini penting

Menjadi tanggal resmi dimulainya siklus faktur dan acuan untuk menghitung KPI Days Sales Outstanding (DSO).

Sumber data

Tersedia di tabel RA_CUSTOMER_TRX_ALL, pada kolom TRX_DATE.

Contoh
2023-04-142023-05-182023-06-25
Waktu selesai
EventEndTime
Tanggal dan waktu tepat saat aktivitas atau peristiwa tertentu selesai.
Deskripsi

Waktu Selesai Peristiwa mencatat saat suatu aktivitas berakhir. Banyak peristiwa terjadi seketika, tetapi aktivitas seperti 'Persetujuan faktur' dapat berlangsung selama beberapa waktu, mulai dari pengajuan hingga keputusan dibuat.

Waktu selesai memungkinkan perhitungan durasi pemrosesan aktivitas secara tepat. Data ini berguna untuk menganalisis waktu yang dihabiskan pengguna pada tugas tertentu. Analisis hambatan juga menjadi lebih akurat karena waktu tunggu dapat dibedakan dari waktu pemrosesan sebenarnya.

Mengapa ini penting

Memungkinkan durasi pemrosesan aktivitas dihitung secara tepat dan membedakan waktu kerja aktif dari waktu tunggu, yang penting untuk analisis hambatan secara terperinci.

Sumber data

Sering kali diperoleh dari Waktu Mulai aktivitas berikutnya dalam proses. Untuk beberapa aktivitas, kolom waktu selesai khusus mungkin tersedia di log workflow.

Contoh
2023-04-15T09:05:12Z2023-04-18T15:00:00Z2023-05-20T11:25:45Z
Waktu siklus faktur
InvoiceCycleTime
Total waktu sejak faktur pertama kali dibuat hingga ditutup.
Deskripsi

Atribut ini mengukur durasi seluruh siklus faktur dari awal hingga akhir untuk satu kasus. Nilainya dihitung dari selisih waktu antara aktivitas pertama, biasanya 'Faktur dibuat', dan aktivitas terakhir, 'Faktur ditutup'.

Metrik ini memberikan gambaran umum tentang efisiensi proses. Metrik ini menjadi ukuran utama untuk dashboard 'Waktu Siklus Faktur dari Awal hingga Akhir'. Dengan menganalisis atribut ini berdasarkan dimensi seperti pelanggan atau unit bisnis, organisasi dapat mengetahui jenis faktur yang paling lama diproses dan menyelidiki penyebabnya.

Mengapa ini penting

Memberikan satu ukuran penting untuk melihat kecepatan proses secara keseluruhan, sehingga faktur yang paling lama diselesaikan dari awal hingga akhir dapat segera diketahui.

Sumber data

Metrik ini dihitung dengan mencari selisih antara EventTimestamp maksimum dan minimum untuk setiap InvoiceNumber unik.

Contoh
45 hari 8 jam32 hari 2 jam90 hari 12 jam
Wilayah
Region
Wilayah geografis yang terkait dengan pelanggan atau transaksi.
Deskripsi

Wilayah memberikan konteks geografis untuk faktur, biasanya berdasarkan lokasi pelanggan. Dengan atribut ini, kinerja proses dapat dianalisis menurut wilayah.

Analisis per wilayah dapat mengungkap perbedaan akibat peraturan setempat, kondisi pasar, atau kinerja tim regional. Anda dapat mengelompokkan dashboard Tren DSO dan Waktu Siklus Faktur dari Awal hingga Akhir berdasarkan wilayah untuk mengetahui apakah ada wilayah tertentu yang menghadapi kendala dalam menerima pembayaran faktur.

Mengapa ini penting

Memungkinkan proses dikelompokkan berdasarkan wilayah geografis, sehingga perbedaan kinerja, perilaku pelanggan, atau kepatuhan antarwilayah dapat terlihat.

Sumber data

Biasanya diperoleh dari informasi alamat pelanggan yang tersimpan di TCA (HZ_LOCATIONS, HZ_PARTY_SITES). Data ini bukan kolom langsung pada faktur.

Contoh
Amerika UtaraEropaAsia-Pasifik
Wajib Disarankan Opsional

Aktivitas Order to Cash - Penagihan dan Faktur

Berikut langkah proses dan tonggak utama yang perlu dicatat dalam log peristiwa agar proses dapat ditemukan dengan akurat.
6 Disarankan 7 Opsional
Aktivitas Deskripsi
Faktur dibuat
Pembuatan awal transaksi faktur di sistem, biasanya dengan status draf atau belum lengkap. Peristiwa ini dicatat secara eksplisit saat pengguna pertama kali menyimpan data faktur baru di modul Accounts Receivable.
Mengapa ini penting

Peristiwa ini menandai awal proses penagihan. Analisis waktu dari pembuatan hingga penyelesaian membantu menemukan keterlambatan entri data di tahap awal atau masalah kinerja sistem.

Sumber data

Peristiwa ini diambil dari tanggal pembuatan catatan transaksi di tabel RA_CUSTOMER_TRX_ALL. Status awalnya biasanya 'Incomplete'.

Pengumpulan data

Gunakan creation_date dari tabel RA_CUSTOMER_TRX_ALL untuk nomor faktur terkait.

Jenis peristiwa explicit
Faktur dikirim kepada pelanggan
Faktur telah dikirim kepada pelanggan melalui metode yang mereka pilih, seperti email atau surat cetak. Sistem biasanya mencatat stempel waktu saat pengiriman dilakukan.
Mengapa ini penting

Aktivitas ini secara resmi memulai masa pembayaran. Mengukur waktu dari persetujuan hingga pengiriman penting untuk memahami efisiensi proses distribusi faktur.

Sumber data

Peristiwa ini dapat disimpulkan dari kolom 'last_printed_date' di RA_CUSTOMER_TRX_ALL atau dari log Oracle Business Intelligence Publisher jika faktur dikirim secara elektronik.

Pengumpulan data

Gunakan stempel waktu dari log pengiriman atau pencetakan yang terkait dengan faktur.

Jenis peristiwa inferred
Faktur disetujui
Faktur telah menerima semua persetujuan yang diperlukan dan siap dikirim kepada pelanggan. Peristiwa ini dicatat saat alur kerja persetujuan berhasil diselesaikan dan status faktur diperbarui.
Mengapa ini penting

Ini adalah tonggak penting yang menentukan kapan faktur dapat dikirim kepada pelanggan. Keterlambatan pada tahap ini langsung menunda dimulainya masa pembayaran dan memengaruhi Days Sales Outstanding (DSO).

Sumber data

Disimpulkan dari pembaruan status persetujuan akhir pada catatan transaksi faktur atau stempel waktu penyelesaian tugas BPM terkait.

Pengumpulan data

Catat stempel waktu saat status persetujuan faktur berubah menjadi 'Approved'.

Jenis peristiwa inferred
Faktur ditutup
Faktur telah dibayar lunas dan direkonsiliasi, sehingga siklusnya selesai. Peristiwa ini biasanya disimpulkan saat saldo terutang pada faktur menjadi nol dan statusnya diperbarui.
Mengapa ini penting

Ini adalah penyelesaian akhir faktur sekaligus menandai berakhirnya proses. Total waktu hingga mencapai tahap ini disebut waktu siklus menyeluruh, salah satu KPI utama proses penagihan.

Sumber data

Disimpulkan dari tabel AR_PAYMENT_SCHEDULES_ALL saat status diperbarui menjadi 'CLOSED' dan nilai amount_due_remaining menjadi nol. Kolom 'gl_date_closed' menunjukkan tanggal penutupan.

Pengumpulan data

Gunakan gl_date_closed dari AR_PAYMENT_SCHEDULES_ALL untuk faktur terkait.

Jenis peristiwa inferred
Pembayaran dialokasikan ke faktur
Pembayaran pelanggan yang diterima berhasil dicocokkan dan dialokasikan ke faktur tertentu, sehingga saldo terutang berkurang. Peristiwa ini dicatat sebagai transaksi tersendiri.
Mengapa ini penting

Aktivitas ini memastikan kas telah dialokasikan dengan benar, yang penting untuk keakuratan laporan umur piutang dan laporan keuangan. Ini adalah langkah terakhir untuk mencatat pembayaran terhadap piutang.

Sumber data

Dicatat secara eksplisit di tabel AR_RECEIVABLE_APPLICATIONS_ALL. Kolom apply_date dan gl_date menunjukkan kapan pembayaran dialokasikan.

Pengumpulan data

Gunakan apply_date dari tabel AR_RECEIVABLE_APPLICATIONS_ALL yang menghubungkan penerimaan kas dengan faktur.

Jenis peristiwa explicit
Pembayaran pelanggan diterima
Pembayaran dari pelanggan telah dimasukkan ke sistem sebagai penerimaan kas. Pada tahap ini, pembayaran mungkin belum dialokasikan ke faktur tertentu.
Mengapa ini penting

Tonggak ini menandai masuknya kas. Jeda waktu antara penerimaan pembayaran dan pengalokasiannya ke faktur menjadi indikator penting efisiensi pengelolaan kas.

Sumber data

Dicatat secara eksplisit saat catatan dibuat di tabel AR_CASH_RECEIPTS_ALL. Kolom receipt_date menunjukkan kapan pembayaran diproses.

Pengumpulan data

Gunakan creation_date atau receipt_date dari tabel AR_CASH_RECEIPTS_ALL.

Jenis peristiwa explicit
Faktur diajukan untuk persetujuan
Faktur secara resmi diajukan ke alur kerja persetujuan, jika alur tersebut telah dikonfigurasi. Peristiwa ini dicatat saat status faktur berubah menjadi menunggu persetujuan dan pemberitahuan dikirim kepada pemberi persetujuan yang ditunjuk.
Mengapa ini penting

Menandai awal siklus persetujuan. Aktivitas ini perlu dilacak untuk mengukur dan menganalisis waktu persetujuan berikutnya, yang menjadi bagian penting dari keseluruhan waktu siklus faktur.

Sumber data

Disimpulkan dari perubahan status transaksi faktur atau diambil dari tabel workflow Oracle Business Process Management (BPM) yang mencatat dimulainya tugas persetujuan.

Pengumpulan data

Temukan stempel waktu saat status persetujuan faktur berubah menjadi 'Pending' atau status serupa.

Jenis peristiwa inferred
Faktur disesuaikan
Perubahan, seperti penghapusbukuan atau pemberian kredit, telah dilakukan pada jumlah faktur. Transaksi ini secara eksplisit mengubah saldo terutang faktur.
Mengapa ini penting

Penyesuaian sering menandakan adanya sengketa, konsesi, atau koreksi. Analisis frekuensi dan nilai penyesuaian dapat mengungkap masalah mendasar dalam proses order-to-cash.

Sumber data

Dicatat secara eksplisit di tabel AR_ADJUSTMENTS_ALL. creation_date pada catatan penyesuaian menandai waktu terjadinya peristiwa.

Pengumpulan data

Gunakan creation_date dari tabel AR_ADJUSTMENTS_ALL untuk faktur terkait.

Jenis peristiwa explicit
Faktur ditolak
Pemberi persetujuan menolak faktur, biasanya karena kesalahan data seperti harga atau jumlah. Peristiwa ini mengembalikan faktur untuk diperbaiki dan memulai siklus pengerjaan ulang.
Mengapa ini penting

Pelacakan penolakan membantu menemukan masalah akurasi penagihan dan pengendalian internal. Analisis frekuensi dan alasan penolakan dapat menunjukkan bagian yang perlu diperbaiki atau memerlukan pelatihan.

Sumber data

Disimpulkan dari pembaruan status pada catatan transaksi faktur atau hasil 'Rejected' pada tugas workflow BPM.

Pengumpulan data

Catat stempel waktu saat status persetujuan faktur berubah menjadi 'Rejected'.

Jenis peristiwa inferred
Faktur selesai
Menandai saat entri data faktur selesai dan transaksi siap divalidasi serta dicatat dalam pembukuan. Peristiwa ini biasanya diketahui dari perubahan status faktur dari 'Incomplete' menjadi 'Complete'.
Mengapa ini penting

Tonggak ini menandai akhir tahap entri data. Waktu antara pembuatan dan penyelesaian dapat menunjukkan efisiensi proses entri data dan peninjauan di bagian penagihan.

Sumber data

Disimpulkan dari perubahan status catatan transaksi faktur di tabel RA_CUSTOMER_TRX_ALL. Cari stempel waktu yang terkait dengan pembaruan status menjadi 'Complete'.

Pengumpulan data

Lacak riwayat status transaksi di RA_CUSTOMER_TRX_ALL atau tabel workflow terkait.

Jenis peristiwa inferred
Pengingat pembayaran dikirim
Surat penagihan atau pemberitahuan pengingat telah dikirim kepada pelanggan untuk faktur yang terlambat dibayar. Modul penagihan mencatat tindakan ini secara eksplisit.
Mengapa ini penting

Pelacakan pengingat membantu mengukur efektivitas proses penagihan dan menganalisis strategi pengingat yang mendorong pembayaran lebih cepat.

Sumber data

Dicatat secara eksplisit di modul Oracle Advanced Collections. Tabel riwayat penagihan seperti IEX_DUNNINGS mencatat tanggal dan tingkat pengingat yang dikirim.

Pengumpulan data

Ambil data dari tabel riwayat penagihan, lalu hubungkan transaksi penagihan dengan faktur.

Jenis peristiwa explicit
Sengketa dimulai
Pelanggan secara resmi menyengketakan faktur dan kasus sengketa dibuat di sistem. Biasanya, hal ini dicatat dengan mengubah penanda status pada jadwal pembayaran faktur.
Mengapa ini penting

Sengketa menghentikan proses pembayaran dan memerlukan upaya manual untuk diselesaikan. Analisis frekuensi sengketa dan waktu penyelesaiannya membantu menemukan penyebab utama, seperti kesalahan harga atau pengiriman.

Sumber data

Peristiwa ini dapat disimpulkan saat kolom status di tabel AR_PAYMENT_SCHEDULES_ALL menunjukkan status sengketa, atau dari catatan pembuatan kasus di AR_DISPUTE_HISTORY.

Pengumpulan data

Temukan waktu saat penanda atau status sengketa diaktifkan pada jadwal pembayaran faktur.

Jenis peristiwa inferred
Tanggal jatuh tempo pembayaran tercapai
Tanggal pembayaran faktur sesuai kontrak telah lewat. Ini bukan peristiwa transaksi, melainkan dihitung berdasarkan ketentuan faktur dan tanggal saat ini.
Mengapa ini penting

Peristiwa hasil perhitungan ini penting untuk analisis umur piutang dan penghitungan DSO. Peristiwa ini membedakan faktur yang dibayar tepat waktu dari yang terlambat, sehingga aktivitas penagihan dapat lebih terarah.

Sumber data

Peristiwa ini dihitung. Peristiwa terjadi saat tanggal saat ini melewati nilai kolom due_date di tabel AR_PAYMENT_SCHEDULES_ALL untuk faktur tertentu.

Pengumpulan data

Hitung dengan membandingkan tanggal saat ini dengan kolom due_date di AR_PAYMENT_SCHEDULES_ALL.

Jenis peristiwa calculated
Disarankan Opsional

Panduan ekstraksi

Cara mengambil data dari Oracle Fusion Financials

Siap memulai?

Gunakan templat ini untuk menyiapkan data, menyederhanakan proses Order to Cash - Penagihan dan Faktur, serta mempercepat konversi kas. Temukan wawasan dan tingkatkan efisiensi operasional Oracle Fusion Financials Anda.

Mulai optimalkan penagihan dan pembuatan faktur Oracle sekarang

Pangkas waktu siklus penagihan hingga 30% dan tingkatkan arus kas dengan solusi kami.

Mulai uji coba gratis

Tidak perlu kartu kredit. Siapkan dalam hitungan menit.