Templat data pemrosesan faktur untuk proses pembelian hingga pembayaran
Templat data pemrosesan faktur untuk proses pembelian hingga pembayaran
- Atribut yang disarankan untuk analisis mendalam
- Aktivitas utama yang perlu dilacak selama siklus pemrosesan faktur
- Panduan mengekstrak data dari Microsoft Dynamics 365
Atribut pemrosesan faktur untuk proses pembelian hingga pembayaran
| Nama | Deskripsi | ||
|---|---|---|---|
|
Nama aktivitas
ActivityName
|
Nama peristiwa bisnis atau tugas tertentu yang terjadi pada waktu tertentu dalam proses pengolahan faktur. | ||
|
Deskripsi
Nama aktivitas menjelaskan langkah atau perubahan status tertentu dalam proses faktur, seperti 'Faktur didaftarkan', 'Faktur dikirim untuk persetujuan', atau 'Pembayaran dijalankan'. Data ini penting untuk menyusun peta proses dan memahami urutan peristiwa. Analisis atribut ini menunjukkan alur proses, jalur yang umum dilalui, serta penyimpangan atau hambatan. Atribut ini digunakan untuk menghitung waktu siklus antaraktivitas, seperti durasi dari persetujuan hingga pembukuan, dan mengukur frekuensi peristiwa tertentu, seperti penolakan atau pemblokiran pembayaran.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam peta proses, sehingga alur proses dapat divisualisasikan dan perpindahan antaraktivitas dapat dianalisis.
Sumber data
Atribut ini biasanya diperoleh dari gabungan kolom status, jenis transaksi, atau entri log perubahan di berbagai tabel Dynamics 365 yang terkait dengan pengolahan faktur.
Contoh
Faktur dikirim untuk persetujuanSelisih pencocokan ditemukanPembayaran dijalankan
|
|||
|
Nomor faktur
InvoiceNumber
|
Pengenal unik untuk setiap faktur pemasok, yang berfungsi sebagai ID kasus utama untuk melacak seluruh prosesnya. | ||
|
Deskripsi
Nomor faktur adalah kunci unik yang menghubungkan semua aktivitas terkait satu faktur pemasok. Nomor ini memungkinkan Anda melacak perjalanan faktur dari awal hingga akhir, mulai dari penerimaan dan pendaftaran hingga pencocokan, persetujuan, dan pembayaran. Dalam analisis process mining, atribut ini sangat penting karena menentukan kasus dan memungkinkan rekonstruksi alur setiap faktur. Dengan begitu, Anda dapat menghitung total waktu siklus, menemukan variasi proses, serta menganalisis karakteristik dan hasil setiap faktur.
Mengapa ini penting
Ini adalah ID kasus utama yang menghubungkan semua peristiwa terkait, sehingga seluruh proses setiap faktur dapat dianalisis.
Sumber data
Biasanya ditemukan di tabel utama faktur pemasok, seperti kolom Num pada VendInvoiceInfoTable.
Contoh
INV-10056773245-AUS-001-98432
|
|||
|
Waktu peristiwa
EventTime
|
Stempel waktu yang menunjukkan secara tepat kapan aktivitas atau peristiwa tertentu terjadi. | ||
|
Deskripsi
Waktu peristiwa, atau stempel waktu, mencatat tanggal dan waktu persis saat aktivitas berlangsung. Komponen penting dalam event log ini menyediakan urutan waktu untuk menyusun aktivitas dengan benar dan menghitung durasinya. Dalam analisis, stempel waktu menjadi dasar semua metrik terkait waktu. Data ini digunakan untuk menghitung durasi aktivitas, waktu siklus antarlangkah seperti waktu persetujuan, dan total waktu pengolahan setiap faktur dari awal hingga akhir. Data ini juga memungkinkan analisis tren dari waktu ke waktu.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa, menghitung semua waktu siklus dan durasi, serta menemukan hambatan proses.
Sumber data
Data ini bersumber dari berbagai kolom tanggal dan waktu di beberapa tabel, seperti kolom createdDateTime atau modifiedDateTime pada VendInvoiceInfoTable, VendTrans, atau tabel riwayat alur kerja.
Contoh
2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan terakhir kali data proses ini diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat kapan dataset terakhir kali diekstrak dan diperbarui dari Microsoft Dynamics 365. Biasanya, nilainya sama untuk semua catatan dalam satu pemuatan data. Informasi ini membantu pengguna mengetahui seberapa baru data yang sedang dianalisis. Informasi ini memberi konteks tentang kebaruan insight proses dan penting untuk mengelola jadwal pembaruan data serta memvalidasi alur data.
Mengapa ini penting
Memberi tahu pengguna seberapa baru data yang digunakan, kapan analisis terakhir diperbarui, dan kapan pembaruan data berikutnya diharapkan.
Sumber data
Stempel waktu ini dibuat dan ditambahkan ke dataset oleh proses ekstraksi data atau ETL saat dijalankan.
Contoh
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem pencatatan asal ekstraksi data peristiwa. | ||
|
Deskripsi
Atribut ini menunjukkan aplikasi sumber tempat data aktivitas berasal. Untuk proses ini, sumbernya biasanya 'Microsoft Dynamics 365'. Jika lingkungan Anda menggunakan beberapa sistem, seperti solusi OCR atau pencatatan eksternal, kolom ini membantu membedakan sistem tempat setiap langkah proses berlangsung. Dengan begitu, asal-usul data tetap jelas dan masalah ekstraksi data lebih mudah ditelusuri.
Mengapa ini penting
Atribut ini memberikan konteks penting tentang asal data, yang berguna untuk validasi data dan memahami lanskap sistem dalam proses.
Sumber data
Nilai statis 'Microsoft Dynamics 365' yang ditambahkan saat transformasi data untuk menandai asal dataset.
Contoh
Microsoft Dynamics 365
|
|||
|
Jumlah faktur
InvoiceAmount
|
Nilai total faktur. | ||
|
Deskripsi
Atribut ini menunjukkan total tagihan yang tercantum pada faktur vendor. Ini merupakan data keuangan dasar untuk setiap kasus. Jumlah faktur banyak digunakan untuk pengelompokan dan analisis. Atribut ini dapat menunjukkan apakah faktur bernilai tinggi melalui proses persetujuan yang berbeda dan lebih ketat, atau membutuhkan waktu pemrosesan lebih lama. Dasbor juga menggunakannya untuk menganalisis volume faktur berdasarkan nilai. Nilainya dapat dijumlahkan untuk mengetahui total pengeluaran yang dianalisis.
Mengapa ini penting
Memungkinkan analisis berdasarkan nilai keuangan, membantu memprioritaskan perbaikan proses untuk faktur bernilai tinggi dan memahami faktor penyebab biaya.
Sumber data
Terdapat di tabel header faktur, misalnya VendInvoiceInfoTable, pada kolom seperti InvoiceAmount atau Amount.
Contoh
1500.00250.7512500.50
|
|||
|
Nomor pemasok
VendorNumber
|
Pengenal unik vendor atau pemasok yang mengirimkan faktur. | ||
|
Deskripsi
Nomor Vendor adalah kode unik untuk mengidentifikasi pemasok dalam data induk. Kode ini menghubungkan transaksi faktur dengan vendor tertentu, sehingga analisis dapat dilakukan berdasarkan vendor. Atribut ini penting untuk mengelompokkan data proses menurut vendor. Anda dapat menggunakannya untuk menjawab pertanyaan seperti, “Vendor mana yang waktu persetujuannya paling lama?” atau “Apakah ketidaksesuaian pencocokan lebih sering terjadi pada vendor tertentu?” Analisis kinerja per vendor dapat menunjukkan peluang untuk bekerja sama dengan pemasok dan memperbaiki proses.
Mengapa ini penting
Memungkinkan penyaringan dan analisis akar masalah berdasarkan vendor, sehingga masalah kinerja atau pola yang terkait dengan pemasok tertentu dapat diketahui.
Sumber data
Biasanya terdapat di header tabel faktur vendor, seperti VendInvoiceInfoTable, yang terhubung ke data induk vendor utama di VendTable.
Contoh
V-1001V-2050V-8342
|
|||
|
Nomor pesanan pembelian
PurchaseOrderNumber
|
Pengenal Purchase Order (PO) yang terkait dengan faktur. | ||
|
Deskripsi
Nomor Purchase Order menghubungkan faktur dengan dokumen pengadaan aslinya. Nomor ini penting dalam proses pencocokan 2 arah atau 3 arah antara faktur, PO, dan penerimaan barang. Atribut ini memungkinkan analisis faktur dengan PO dan tanpa PO, yang sering mengikuti alur proses berbeda. Atribut ini juga penting untuk memahami efektivitas pencocokan, menyelidiki ketidaksesuaian, dan mengukur tingkat pemrosesan langsung untuk faktur yang didukung PO.
Mengapa ini penting
Membedakan faktur yang didukung PO dari faktur tanpa PO. Perbedaan ini menjadi penyebab utama variasi proses dan penting dalam analisis pencocokan.
Sumber data
Terdapat di tabel header faktur, seperti VendInvoiceInfoTable, biasanya pada kolom seperti PurchId.
Contoh
PO-001234PO-005678PO-009101
|
|||
|
Pengguna
User
|
ID pengguna atau nama orang yang melakukan aktivitas. | ||
|
Deskripsi
Atribut ini mengidentifikasi karyawan atau pengguna sistem yang bertanggung jawab menjalankan langkah proses tertentu. Untuk langkah otomatis, pengguna dapat berupa akun sistem atau akun layanan. Analisis proses berdasarkan pengguna membantu Anda memahami pembagian beban kerja, mengetahui kebutuhan pelatihan, dan membandingkan kinerja antarindividu atau tim. Atribut ini penting untuk menganalisis proses pengerjaan ulang, saat pekerjaan berpindah bolak-balik antar pengguna, serta memahami perbedaan cara pengguna menyelesaikan tugas yang sama.
Mengapa ini penting
Memungkinkan analisis kinerja dan beban kerja berdasarkan pengguna atau tim, serta membantu mengetahui tingkat otomatisasi dan sumber pengerjaan ulang.
Sumber data
Bersumber dari kolom ID pengguna di tabel transaksi atau riwayat workflow, seperti kolom createdby atau modifiedby. Informasi ini mungkin tersedia di tabel pelacakan workflow.
Contoh
j.doea.smithAX_Admin
|
|||
|
Status faktur
InvoiceStatus
|
Status faktur saat ini ketika data diekstrak. | ||
|
Deskripsi
Status faktur menunjukkan posisi faktur dalam siklus prosesnya, seperti “Menunggu persetujuan”, “Disetujui”, “Dibukukan”, atau “Dibayar”. Status ini memberikan gambaran kemajuan faktur saat ini. Atribut ini terutama digunakan untuk membuat dasbor operasional yang menampilkan beban kerja dan pekerjaan tertunda saat ini. Atribut ini membantu manajer mengetahui jumlah faktur di setiap tahap proses, sehingga mereka dapat mengalokasikan sumber daya dan memantau operasional. Atribut ini penting untuk dasbor “Volume pemrosesan dan status faktur”.
Mengapa ini penting
Menampilkan kondisi terkini semua faktur, yang penting untuk pemantauan operasional, pengelolaan beban kerja, dan mengetahui hambatan saat ini.
Sumber data
Biasanya ditentukan dari kolom status pada tabel faktur utama, seperti VendInvoiceInfoTable.
Contoh
Menunggu persetujuanDibukukanDibayar
|
|||
|
Tanggal jatuh tempo pembayaran
PaymentDueDate
|
Tanggal batas pembayaran faktur sesuai dengan ketentuan pembayaran yang disepakati. | ||
|
Deskripsi
Tanggal jatuh tempo pembayaran dihitung berdasarkan tanggal faktur dan ketentuan pembayaran vendor. Tanggal ini merupakan batas waktu pembayaran sesuai kontrak. Tanggal ini penting untuk mengukur kinerja keuangan dan mengelola hubungan dengan vendor. Tanggal ini menjadi acuan untuk menghitung KPI “Tingkat pembayaran tepat waktu” dengan membandingkannya dengan tanggal aktual “Pembayaran dilakukan”. Analisis ini membantu menemukan masalah sistemik yang menyebabkan keterlambatan pembayaran, yang dapat merusak hubungan dengan vendor atau membuat organisasi kehilangan diskon pembayaran lebih awal.
Mengapa ini penting
Menjadi acuan untuk mengukur ketepatan waktu pembayaran, KPI penting bagi kesehatan keuangan dan hubungan dengan vendor.
Sumber data
Tanggal ini sering dihitung oleh sistem dan disimpan di tabel transaksi vendor, seperti VendTrans, berdasarkan tanggal faktur dan ketentuan pembayaran.
Contoh
2023-05-152023-06-302023-07-20
|
|||
|
Waktu selesai
EndTime
|
Stempel waktu yang menunjukkan secara tepat kapan aktivitas atau peristiwa tertentu selesai. | ||
|
Deskripsi
Waktu selesai mencatat kapan suatu aktivitas berakhir. Jika digabungkan dengan waktu mulai (EventTime), data ini memungkinkan penghitungan durasi setiap langkah secara tepat. Atribut ini penting untuk menghitung “ProcessingTime” setiap aktivitas, metrik utama dalam analisis kinerja. Atribut ini membantu menemukan langkah proses yang paling banyak menyita waktu, sehingga perbaikan dapat diarahkan dengan tepat. Misalnya, durasi persis untuk langkah pengodean manual atau persetujuan dapat diukur.
Mengapa ini penting
Memungkinkan penghitungan langsung waktu pemrosesan aktivitas, yang menjadi dasar untuk menemukan langkah proses yang paling lama.
Sumber data
Seperti StartTime, data ini bersumber dari berbagai kolom tanggal dan waktu. Untuk beberapa aktivitas, data ini mungkin menggunakan StartTime aktivitas berikutnya. Dalam kasus lain, data ini dapat berasal dari stempel waktu khusus seperti “tanggal selesai”.
Contoh
2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
|
|||
|
Alasan pemblokiran pembayaran
PaymentBlockReason
|
Kode alasan yang menjelaskan mengapa pembayaran faktur diblokir. | ||
|
Deskripsi
Pemblokiran pembayaran mencegah faktur dibayar. Atribut ini mencatat alasan pemblokiran, yang biasanya berupa kode standar pilihan pengguna, seperti “Tagihan disengketakan” atau “Menunggu penerimaan barang”. Atribut ini penting untuk dasbor “Frekuensi dan durasi pemblokiran pembayaran”. Analisis alasan pemblokiran yang paling umum membantu menemukan masalah mendasar dalam proses P2P. Mengatasi akar masalah tersebut dapat mengurangi keterlambatan pembayaran secara signifikan dan memperbaiki hubungan dengan vendor.
Mengapa ini penting
Menjelaskan alasan pembayaran sengaja ditunda, sehingga masalah di tahap sebelumnya yang menyebabkan pemblokiran dapat diketahui dan diatasi.
Sumber data
Biasanya berupa kolom pada catatan transaksi vendor atau faktur, yang sering terkait dengan status pemblokiran pembayaran. Periksa tabel seperti VendTrans.
Contoh
Sengketa kualitasMenunggu nota kreditPemblokiran manual
|
|||
|
Alasan penolakan
RejectionReason
|
Alasan yang diberikan pemberi persetujuan saat menolak faktur. | ||
|
Deskripsi
Saat faktur ditolak dalam workflow persetujuan, pemberi persetujuan biasanya menyertakan alasan. Atribut ini mencatat penjelasan tersebut, yang dapat berupa kode pilihan atau teks bebas. Atribut ini penting untuk dasbor “Analisis penolakan faktur”. Informasi ini membantu memahami akar penyebab penolakan, seperti “Nomor PO salah”, “Faktur duplikat”, atau “Harga tidak sesuai”. Analisis alasan penolakan membantu menentukan tindakan untuk mengurangi tingkat penolakan.
Mengapa ini penting
Memberikan gambaran langsung tentang alasan faktur ditolak, sehingga tindakan yang tepat dapat mengurangi pengerjaan ulang dan meningkatkan tingkat penyelesaian yang benar sejak awal.
Sumber data
Biasanya terdapat di komentar atau log riwayat pada tabel pemrosesan workflow.
Contoh
Jumlah tidak sesuaiFaktur duplikatMelebihi batas persetujuan
|
|||
|
Departemen
Department
|
Pusat biaya atau departemen tempat biaya faktur dialokasikan. | ||
|
Deskripsi
Departemen menunjukkan unit bisnis atau pusat biaya yang bertanggung jawab atas pengeluaran pada faktur. Informasi ini biasanya ditentukan saat aktivitas pengodean faktur. Analisis proses berdasarkan departemen penting untuk memahami perbedaan pengeluaran, waktu persetujuan, dan kepatuhan antar departemen. Analisis ini membantu mengetahui departemen dengan pengecualian faktur terbanyak atau siklus persetujuan terlama, sehingga komunikasi dan pelatihan dapat diarahkan ke bagian yang tepat.
Mengapa ini penting
Memungkinkan analisis biaya dan proses berdasarkan departemen, serta menunjukkan perbedaan kinerja dan kepatuhan di seluruh organisasi.
Sumber data
Bersumber dari dimensi keuangan yang terkait dengan baris atau header faktur. Untuk mengambilnya, Anda perlu mengkueri struktur data terkait dimensi.
Contoh
PenjualanPemasaranOperasional TI
|
|||
|
Jenis ketidaksesuaian
MatchingDiscrepancyType
|
Mengelompokkan jenis ketidaksesuaian yang ditemukan saat mencocokkan faktur dengan PO. | ||
|
Deskripsi
Jika terjadi ketidaksesuaian saat pencocokan 2 arah atau 3 arah, atribut ini menunjukkan jenis masalahnya, misalnya “Harga tidak sesuai”, “Jumlah tidak sesuai”, atau “Penerimaan barang tidak ditemukan”. Data ini menjadi dasar dasbor “Waktu penyelesaian ketidaksesuaian pencocokan”. Dengan menganalisis frekuensi setiap jenis ketidaksesuaian, bisnis dapat menemukan akar penyebab kegagalan pencocokan. Misalnya, ketidaksesuaian harga yang sering terjadi dapat menunjukkan masalah pada data induk yang sudah usang, sedangkan ketidaksesuaian jumlah dapat mengindikasikan masalah pengiriman.
Mengapa ini penting
Mengelompokkan kegagalan pencocokan agar akar masalah dapat dianalisis, tingkat ketidaksesuaian dapat dikurangi, dan pemrosesan langsung dapat ditingkatkan.
Sumber data
Data ini mungkin disimpan di tabel khusus untuk pencocokan atau log pengecualian, atau perlu ditentukan dari pesan status maupun komentar workflow.
Contoh
Harga tidak sesuaiJumlah tidak sesuaiPenerimaan barang tidak ditemukan
|
|||
|
Ketentuan pembayaran
PaymentTerms
|
Ketentuan pembayaran yang disepakati dengan vendor, seperti “Net 30” atau “2% 10, Net 30”. | ||
|
Deskripsi
Ketentuan pembayaran menetapkan syarat yang disepakati untuk membayar vendor, termasuk jangka waktu dan kemungkinan diskon. Informasi ini biasanya bersumber dari data induk vendor atau pesanan pembelian. Atribut ini memberikan konteks penting untuk tanggal jatuh tempo pembayaran dan KPI tingkat pembayaran tepat waktu. Analisis hubungan antara ketentuan pembayaran tertentu dan keterlambatan pembayaran dapat menunjukkan tantangan operasional. Informasi ini juga membantu perencanaan keuangan dan pengelolaan modal kerja.
Mengapa ini penting
Memberikan konteks untuk tanggal jatuh tempo pembayaran dan membantu menganalisis dampak keuangan dari waktu pembayaran serta tingkat pemanfaatan diskon.
Sumber data
Informasi ini disimpan dalam data induk vendor (VendTable) dan disalin ke tabel transaksi seperti VendInvoiceInfoTable.
Contoh
Net 30Net 602% 10, Net 30
|
|||
|
Kode perusahaan
CompanyCode
|
Pengenal badan hukum atau perusahaan dalam organisasi yang memproses faktur. | ||
|
Deskripsi
Kode perusahaan menunjukkan badan hukum tertentu yang bertanggung jawab secara keuangan atas faktur. Dalam organisasi yang terdiri dari beberapa perusahaan, data ini penting untuk pengelompokan keuangan. Atribut ini memungkinkan analisis proses disaring atau dibandingkan berdasarkan badan hukum. Analisis dapat menunjukkan apakah kinerja proses, kebijakan, atau hambatan hanya terjadi pada perusahaan tertentu dalam grup, sehingga perbaikan proses dapat disesuaikan dengan kebutuhan masing-masing.
Mengapa ini penting
Memungkinkan analisis proses dikelompokkan berdasarkan badan hukum, yang penting bagi organisasi besar dengan banyak perusahaan.
Sumber data
Ini adalah kolom standar di sebagian besar tabel keuangan Dynamics 365, yang sering disebut DataAreaId.
Contoh
USMFDEMFGBSI
|
|||
|
Mata uang faktur
InvoiceCurrency
|
Kode mata uang untuk jumlah faktur, misalnya USD atau EUR. | ||
|
Deskripsi
Mata uang faktur menunjukkan mata uang yang digunakan untuk menyatakan jumlah faktur. Informasi ini penting bagi organisasi multinasional yang bekerja dengan pemasok dari berbagai negara. Atribut ini memberikan konteks yang diperlukan untuk memahami jumlah faktur. Atribut ini juga digunakan untuk penyaringan dan pelaporan, terutama dalam operasional global. Dengan begitu, nilai keuangan dapat ditafsirkan dengan benar dan dianalisis menurut mata uang atau dikonversi ke mata uang pelaporan standar.
Mengapa ini penting
Memberikan konteks penting untuk nilai keuangan, sehingga nilai faktur dari berbagai wilayah dapat ditafsirkan dan dianalisis dengan tepat.
Sumber data
Terdapat di tabel header faktur, bersama jumlah faktur, misalnya pada kolom CurrencyCode di VendInvoiceInfoTable.
Contoh
USDEURGBP
|
|||
|
Otomatis
IsAutomated
|
Penanda yang menunjukkan apakah aktivitas dilakukan otomatis oleh sistem atau oleh pengguna. | ||
|
Deskripsi
Atribut boolean ini (true/false) membedakan peristiwa yang dijalankan sistem dari tugas manual pengguna. Misalnya, pencocokan faktur mungkin otomatis, sedangkan penanganan ketidaksesuaian dilakukan secara manual. Analisis atribut ini penting untuk memahami tingkat otomatisasi proses. Atribut ini membantu mengukur keberhasilan inisiatif otomatisasi, menemukan hambatan manual yang masih ada, dan menunjukkan peluang otomatisasi lebih lanjut untuk meningkatkan efisiensi serta mengurangi kesalahan.
Mengapa ini penting
Membantu mengukur tingkat otomatisasi proses, menemukan hambatan manual, dan mengetahui peluang untuk meningkatkan efisiensi.
Sumber data
Biasanya ditentukan berdasarkan atribut “Pengguna”. Jika pengguna merupakan akun sistem atau layanan yang dikenal, penanda ini diatur ke true.
Contoh
truefalse
|
|||
|
Pembayaran tepat waktu
IsOnTimePayment
|
Penanda hasil perhitungan yang menunjukkan apakah faktur dibayar pada atau sebelum tanggal jatuh tempo. | ||
|
Deskripsi
Atribut boolean ini ditentukan dengan membandingkan stempel waktu aktivitas “Pembayaran dilakukan” dengan “Tanggal jatuh tempo pembayaran”. Jika tanggal pembayaran sama dengan atau lebih awal dari tanggal jatuh tempo, nilainya true. Jika tidak, nilainya false. Atribut ini mendukung KPI “Tingkat pembayaran tepat waktu” dan dasbor “Kepatuhan terhadap ketentuan pembayaran”. Atribut ini menyederhanakan analisis dengan memberikan hasil yang jelas untuk setiap faktur. Anda dapat dengan mudah menyaring pembayaran terlambat dan menyelidiki akar masalahnya berdasarkan vendor, departemen, atau negara.
Mengapa ini penting
Mengukur kepatuhan terhadap ketentuan pembayaran secara langsung, sehingga penghitungan KPI tingkat pembayaran tepat waktu dan analisis terkait menjadi lebih mudah.
Sumber data
Atribut ini dihitung pada lapisan transformasi data. Logikanya: (Stempel waktu aktivitas “Pembayaran dilakukan”) <= (Tanggal jatuh tempo pembayaran).
Contoh
truefalse
|
|||
|
Total waktu siklus
TotalCycleTime
|
Total durasi pemrosesan satu faktur dari awal hingga akhir, mulai dari penerimaan sampai pembayaran. | ||
|
Deskripsi
Total waktu siklus mengukur seluruh durasi faktur dalam proses. Nilainya dihitung dari selisih waktu antara aktivitas pertama, misalnya “Faktur didaftarkan”, dan aktivitas terakhir, misalnya “Pembayaran dilakukan”, untuk setiap nomor faktur. Ini adalah KPI utama untuk mengukur efisiensi proses secara keseluruhan. Metrik ini memberikan gambaran umum kinerja dan digunakan dalam dasbor “Waktu siklus faktur dari awal hingga akhir”. Analisis tren metrik ini dan pengelompokan berdasarkan atribut seperti vendor atau jumlah faktur dapat membantu menemukan peluang perbaikan yang lebih luas.
Mengapa ini penting
Menjadi KPI utama untuk mengukur kecepatan dan efisiensi proses secara keseluruhan, serta merangkum kinerja setiap faktur.
Sumber data
Nilai ini dihitung pada tingkat kasus di dalam alat process mining atau saat menyiapkan data. Nilainya adalah selisih waktu antara stempel waktu peristiwa pertama dan terakhir untuk setiap CaseId.
Contoh
P15DP22DT5H30MP7D
|
|||
Aktivitas pemrosesan faktur untuk proses pembelian hingga pembayaran
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Faktur cocok dengan pesanan pembelian
|
Menandai selesainya proses pencocokan, saat detail faktur sesuai dengan pesanan pembelian dan informasi penerimaan barang. Peristiwa ini disimpulkan saat status pencocokan faktur diperbarui menjadi 'Lulus'. | ||
|
Mengapa ini penting
Pencocokan yang berhasil menjadi tonggak penting bagi faktur yang terkait dengan PO. Ini memastikan keabsahan tagihan sebelum pembayaran dan penting untuk memantau efisiensi serta tingkat otomatisasi pencocokan.
Sumber data
Disimpulkan dari perubahan kolom status pencocokan pada header atau baris faktur pemasok, misalnya VendInvoiceInfoTable, menjadi 'Lulus' atau 'Berhasil dicocokkan'.
Pengumpulan data
Stempel waktu perubahan status menjadi 'Lulus' pada detail validasi pencocokan faktur.
Jenis peristiwa
inferred
|
|||
|
Faktur dibukukan
|
Ini adalah peristiwa akuntansi resmi saat faktur yang disetujui dicatat di General Ledger dan membentuk kewajiban. Peristiwa transaksi ini tercatat secara eksplisit di sistem. | ||
|
Mengapa ini penting
Pembukuan adalah langkah terakhir sebelum pembayaran dan menjadi titik kontrol keuangan yang penting. Waktu dari 'Faktur disetujui' hingga 'Faktur dibukukan' mengukur efisiensi langkah akuntansi terakhir.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat saat transaksi pemasok dibukukan di tabel seperti VendTrans, beserta catatan GeneralJournalEntry dan LedgerEntry terkait.
Pengumpulan data
Stempel waktu pembuatan catatan di tabel transaksi pemasok (VendTrans).
Jenis peristiwa
explicit
|
|||
|
Faktur didaftarkan
|
Ini adalah pencatatan awal faktur ke dalam sistem, yang membuat catatan sementara sebelum detail lengkapnya diproses. Aktivitas ini tercatat saat catatan baru dibuat di jurnal register faktur pemasok. | ||
|
Mengapa ini penting
Aktivitas ini menandai dimulainya proses pengolahan faktur secara resmi. Dengan menganalisis waktu sejak tahap ini, Anda dapat mengukur total durasi pengolahan dan menemukan keterlambatan pada tahap awal.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat saat catatan dibuat di register faktur pemasok, biasanya di VendInvoiceRegisterJournalTable atau tabel faktur tertunda yang serupa.
Pengumpulan data
Stempel waktu pembuatan catatan di Jurnal Register Faktur Pemasok.
Jenis peristiwa
explicit
|
|||
|
Faktur dikirim untuk persetujuan
|
Aktivitas ini menandai pengajuan resmi faktur ke alur kerja untuk ditinjau dan disetujui. Mesin alur kerja Dynamics 365 mencatat peristiwa pengajuan ini secara eksplisit. | ||
|
Mengapa ini penting
Ini menjadi titik awal untuk mengukur seluruh siklus persetujuan. Anda dapat mengetahui berapa lama faktur menunggu sebelum proses persetujuan dimulai dan menggunakannya sebagai pemicu KPI terkait persetujuan.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat di tabel riwayat alur kerja, misalnya WorkflowTrackingStatusTable, saat faktur diajukan ke alur kerja.
Pengumpulan data
Stempel waktu pembuatan catatan pengajuan alur kerja di riwayat alur kerja.
Jenis peristiwa
explicit
|
|||
|
Faktur disetujui
|
Menandai persetujuan akhir faktur dalam alur kerja, yang mengizinkan faktur dibukukan dan dibayar. Mesin alur kerja mencatat peristiwa ini secara eksplisit saat proses selesai. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang mengakhiri proses persetujuan. Waktu dari 'Faktur dikirim untuk persetujuan' hingga peristiwa ini menjadi ukuran utama efisiensi persetujuan dan membantu menemukan hambatan.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat di tabel riwayat alur kerja, misalnya WorkflowTrackingStatusTable, saat status alur kerja berubah menjadi 'Disetujui'.
Pengumpulan data
Stempel waktu entri status 'Disetujui' di riwayat alur kerja.
Jenis peristiwa
explicit
|
|||
|
Pembayaran dijalankan
|
Ini adalah aktivitas terakhir, yaitu pembukuan jurnal pembayaran yang membuat pembayaran dan melunasi faktur. Peristiwa transaksi ini tercatat secara eksplisit dan menutup proses faktur. | ||
|
Mengapa ini penting
Aktivitas ini menandai berakhirnya proses faktur hingga pembayaran. Data ini menjadi dasar untuk mengukur 'Tingkat pembayaran tepat waktu' dan total waktu siklus dari awal hingga akhir.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat saat jurnal pembayaran dibukukan. Informasi pelunasan dicatat di tabel seperti VendSettlement, yang menghubungkan pembayaran dengan faktur.
Pengumpulan data
Stempel waktu pembukuan jurnal pembayaran yang melunasi transaksi pemasok.
Jenis peristiwa
explicit
|
|||
|
Blokir pembayaran dilepas
|
Menandai pelepasan penahanan pembayaran sehingga faktur dapat dilanjutkan ke penjadwalan pembayaran. Aktivitas ini tercatat saat kolom blokir pembayaran dikosongkan atau diubah ke status tidak diblokir. | ||
|
Mengapa ini penting
Mengukur waktu yang dibutuhkan untuk menyelesaikan masalah penyebab penahanan pembayaran. Jeda yang lama antara penetapan dan pelepasan blokir menunjukkan proses penyelesaian masalah yang kurang efisien.
Sumber data
Disimpulkan dari perubahan yang mengosongkan kolom penahanan atau blokir pembayaran pada transaksi pemasok yang sudah dibukukan (VendTrans). Log perubahan dapat menunjukkan stempel waktunya.
Pengumpulan data
Stempel waktu pembaruan yang mengosongkan kolom blokir pembayaran pada transaksi pemasok.
Jenis peristiwa
inferred
|
|||
|
Blokir pembayaran ditetapkan
|
Aktivitas ini terjadi saat faktur ditahan sehingga tidak dapat dibayar. Perubahan ini tercatat pada kolom blokir pembayaran atau status penahanan di catatan faktur yang sudah dibukukan. | ||
|
Mengapa ini penting
Blokir pembayaran menjadi salah satu penyebab utama keterlambatan pembayaran. Menganalisis kapan dan mengapa blokir ditetapkan sangat penting untuk meningkatkan ketepatan waktu pembayaran dan hubungan dengan pemasok.
Sumber data
Disimpulkan dari perubahan kolom penahanan atau blokir pembayaran pada transaksi pemasok yang sudah dibukukan (VendTrans). Log perubahan dapat digunakan untuk mencatat stempel waktunya.
Pengumpulan data
Stempel waktu pembaruan yang menetapkan kolom blokir pembayaran pada transaksi pemasok.
Jenis peristiwa
inferred
|
|||
|
Data faktur dicatat
|
Menandai selesainya input data faktur, termasuk detail header dan baris, sebelum faktur diajukan untuk pencocokan atau persetujuan. Aktivitas ini sering disimpulkan saat status catatan faktur berubah dari 'baru' atau 'terdaftar' menjadi 'siap diproses'. | ||
|
Mengapa ini penting
Pelacakan aktivitas ini membantu mengukur efisiensi input data, baik yang dilakukan secara manual maupun otomatis dengan OCR. Keterlambatan pada tahap ini dapat berdampak pada seluruh proses.
Sumber data
Disimpulkan dari perubahan status pada catatan faktur pemasok tertunda, misalnya VendInvoiceInfoTable. Peristiwa ini terjadi saat semua kolom wajib terisi dan faktur siap melanjutkan ke tahap berikutnya.
Pengumpulan data
Deteksi perubahan status pada tabel faktur tertunda yang menandakan input data telah selesai.
Jenis peristiwa
inferred
|
|||
|
Faktur ditolak
|
Menandakan bahwa pemberi persetujuan menolak faktur, sehingga proses terhenti dan faktur biasanya dikembalikan untuk diperbaiki. Mesin alur kerja mencatat peristiwa penolakan ini secara eksplisit. | ||
|
Mengapa ini penting
Dengan melacak penolakan, Anda dapat mengukur pekerjaan ulang dan menemukan penyebab umum, seperti kode akun yang salah atau pelanggaran kebijakan. Data ini mendukung KPI 'Tingkat penolakan faktur'.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat di tabel riwayat alur kerja, misalnya WorkflowTrackingStatusTable, saat status alur kerja berubah menjadi 'Ditolak' atau 'Dibatalkan'.
Pengumpulan data
Stempel waktu entri status 'Ditolak' di riwayat alur kerja.
Jenis peristiwa
explicit
|
|||
|
Kode akun faktur ditetapkan
|
Aktivitas ini menandakan bahwa distribusi akun General Ledger telah ditetapkan ke baris faktur. Biasanya, aktivitas ini disimpulkan dari pembuatan atau finalisasi distribusi akun buku besar yang terkait dengan faktur. | ||
|
Mengapa ini penting
Pemberian kode akun merupakan langkah penting untuk menjaga akurasi keuangan. Dengan mengukur waktu yang dibutuhkan untuk memberi kode pada faktur, Anda dapat menemukan hambatan dalam proses peninjauan akuntansi dan memantau KPI 'Rata-rata waktu dari pencatatan data hingga pemberian kode'.
Sumber data
Disimpulkan dari pembuatan dan validasi catatan di tabel distribusi akuntansi, misalnya AccountingDistribution, yang terkait dengan faktur pemasok tertunda.
Pengumpulan data
Stempel waktu saat distribusi akuntansi untuk faktur disimpan dan divalidasi.
Jenis peristiwa
inferred
|
|||
|
Pembayaran dijadwalkan
|
Aktivitas ini terjadi saat faktur yang sudah dibukukan dimasukkan ke proposal pembayaran atau jurnal pembayaran, sebelum pembayaran dijalankan. Tindakan ini tercatat secara eksplisit saat baris jurnal pembayaran dibuat. | ||
|
Mengapa ini penting
Tahap ini menandai peralihan dari Utang Usaha ke operasional Treasury. Analisis tahap ini dapat mengungkap keterlambatan antara pembukuan faktur dan dimulainya pembayaran.
Sumber data
Ini adalah peristiwa eksplisit yang tercatat saat baris dibuat di jurnal pembayaran (LedgerJournalTrans) untuk melunasi transaksi pemasok yang sudah dibukukan.
Pengumpulan data
Stempel waktu pembuatan baris jurnal pembayaran yang merujuk pada faktur.
Jenis peristiwa
explicit
|
|||
|
Selisih pencocokan ditangani
|
Menandai penyelesaian selisih pencocokan yang ditemukan sebelumnya agar faktur dapat diproses lebih lanjut. Aktivitas ini disimpulkan saat faktur dengan status pencocokan 'Gagal' berhasil dicocokkan ulang atau statusnya diubah secara manual. | ||
|
Mengapa ini penting
Aktivitas ini mengakhiri subproses penyelesaian selisih. Waktu antara 'Selisih pencocokan ditemukan' dan peristiwa ini menjadi KPI penting untuk mengukur efisiensi penyelesaian.
Sumber data
Disimpulkan dari peristiwa pencocokan yang berhasil ('Faktur cocok dengan pesanan pembelian') setelah peristiwa 'Selisih pencocokan ditemukan' untuk faktur yang sama.
Pengumpulan data
Temukan stempel waktu status pencocokan 'Lulus' yang muncul setelah stempel waktu status 'Gagal'.
Jenis peristiwa
inferred
|
|||
|
Selisih pencocokan ditemukan
|
Aktivitas ini terjadi saat proses pencocokan faktur gagal karena detail faktur, pesanan pembelian, atau penerimaan barang tidak sesuai. Aktivitas ini tercatat saat status pencocokan faktur berubah menjadi 'Gagal' atau 'Selisih'. | ||
|
Mengapa ini penting
Mengetahui kapan dan mengapa selisih terjadi sangat penting untuk KPI 'Tingkat selisih pencocokan'. Aktivitas ini menandai dimulainya proses penyelesaian, yang sering menjadi sumber keterlambatan besar.
Sumber data
Disimpulkan dari perubahan kolom status pencocokan pada faktur pemasok, misalnya VendInvoiceInfoTable, menjadi 'Gagal'. Alasan kegagalan juga sering dicatat.
Pengumpulan data
Stempel waktu perubahan status menjadi 'Gagal' atau 'Selisih' saat pencocokan.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat ini untuk memulai process mining dan menemukan cara mempercepat serta meningkatkan akurasi pemrosesan faktur. Mulai tingkatkan operasional Anda hari ini.
Mulai optimalkan pemrosesan faktur untuk pembelian hingga pembayaran hari ini
Temukan inefisiensi dan pangkas waktu siklus faktur hingga 30% atau lebih.
Tidak perlu kartu kredit. Mulai dalam hitungan menit.