Templat Data Pemrosesan Pembayaran Utang Usaha
Templat Data Pemrosesan Pembayaran Utang Usaha
- Atribut yang disarankan untuk analisis mendalam
- Tahapan penting proses yang perlu dilacak
- Panduan ekstraksi khusus NetSuite
Atribut Pemrosesan Pembayaran Utang Usaha
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
Activity
|
Nama langkah proses atau peristiwa yang terjadi. | ||
|
Deskripsi
Atribut ini mencatat tindakan atau perubahan status tertentu yang terjadi pada waktu tertentu. Contohnya: 'Faktur Dibuat', 'Status Persetujuan Berubah', atau 'Pembayaran Diproses'. Data ini penting untuk merekonstruksi peta alur proses. Dengan mengurutkan aktivitas secara kronologis untuk setiap Nomor Faktur, alat process mining menampilkan alur kerja aktual dan menemukan pengulangan, pekerjaan ulang, serta penyimpangan dari jalur yang diharapkan.
Mengapa ini penting
Menentukan langkah-langkah dalam peta proses dan wajib ada untuk analisis process mining.
Sumber data
System Notes atau log Workflow History
Contoh
Faktur dibuatFaktur disetujuiPembayaran dijadwalkanPembayaran telah dicairkan
|
|||
|
Nomor faktur
InvoiceNumber
|
ID unik untuk faktur vendor. | ||
|
Deskripsi
Atribut ini menunjukkan nomor referensi unik yang diberikan kepada tagihan vendor di NetSuite. Nomor ini menjadi ID kasus utama untuk proses Utang Usaha dan mengelompokkan semua aktivitas yang terkait dengan kewajiban pembayaran tertentu. Dalam analisis, kolom ini menjadi kunci utama untuk setiap instans proses. Analis dapat menelusuri seluruh siklus kewajiban, mulai dari faktur diterima dan dicatat hingga pembayaran akhirnya dicairkan. Variasi proses dikelompokkan berdasarkan ID ini untuk menemukan jalur proses yang umum.
Mengapa ini penting
ID Kasus wajib yang menghubungkan semua peristiwa menjadi satu kasus proses.
Sumber data
Tabel transaksi, kolom 'tranid' untuk jenis 'Vendor Bill'
Contoh
INV-2023-001VB-99822ACME-10299982311
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Waktu saat data diekstrak atau diperbarui. | ||
|
Deskripsi
Menunjukkan kapan data terakhir diambil dari sistem sumber ke platform process mining. Informasi ini membantu pengguna mengetahui seberapa baru analisis yang ditampilkan. Data ini digunakan untuk memastikan apakah informasi di dashboard menunjukkan kondisi terkini atau rekam data dari periode sebelumnya. Hal ini penting agar perhitungan 'Hari keterlambatan' dapat dipercaya.
Mengapa ini penting
Wajib untuk mengetahui kebaruan data dan status sinkronisasi.
Sumber data
Stempel waktu ETL
Contoh
2023-11-01T00:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Nama sistem asal data. | ||
|
Deskripsi
Menunjukkan aplikasi perangkat lunak tempat data peristiwa diambil. Dalam konteks ini, nilainya biasanya tetap, misalnya 'NetSuite'. Atribut ini berguna untuk melacak asal-usul data di lingkungan dengan banyak sistem. Meskipun tampilan ini berfokus pada NetSuite, kolom ini tetap mendukung penggunaan model data di seluruh perusahaan.
Mengapa ini penting
Wajib untuk melacak asal-usul data dan membedakan data di lingkungan dengan beberapa sistem.
Sumber data
Ditetapkan langsung saat ekstraksi
Contoh
NetSuiteNetSuite OneWorld
|
|||
|
Waktu peristiwa
EventTime
|
Stempel waktu saat aktivitas terjadi. | ||
|
Deskripsi
Tanggal dan waktu tepat saat suatu aktivitas berlangsung. Data ini digunakan untuk mengurutkan peristiwa dan menghitung durasi antar langkah. Stempel waktu yang akurat penting untuk menemukan hambatan. Data ini memungkinkan penghitungan waktu siklus, seperti waktu yang dibutuhkan untuk persetujuan atau lamanya faktur berada dalam status diblokir.
Mengapa ini penting
Wajib untuk mengurutkan peristiwa dan menghitung semua KPI berbasis waktu.
Sumber data
Kolom 'date' di System Notes
Contoh
2023-10-01T14:30:00Z2023-10-02T09:15:00Z
|
|||
|
Anak perusahaan
Subsidiary
|
Anak perusahaan atau badan hukum yang menerima faktur. | ||
|
Deskripsi
Di lingkungan NetSuite OneWorld, atribut ini menunjukkan badan hukum (Subsidiary) yang terkait dengan faktur. Informasi ini memungkinkan perbandingan antarbagian organisasi. Atribut ini digunakan dalam dashboard 'Waktu siklus pembayaran dari awal hingga akhir' untuk membandingkan efisiensi antarunit bisnis. Anda dapat mengetahui apakah kinerja wilayah atau entitas tertentu tertinggal.
Mengapa ini penting
Penting bagi organisasi dengan beberapa entitas untuk membandingkan kinerja antarunit bisnis.
Sumber data
Kolom 'subsidiary' pada transaksi
Contoh
AS TimurKantor pusat EMEAPenjualan APAC
|
|||
|
Departemen
Department
|
Departemen internal yang terkait dengan faktur. | ||
|
Deskripsi
Mengelompokkan faktur berdasarkan pusat biaya atau departemen internal (misalnya, TI atau Pemasaran) yang menanggung pengeluaran. Atribut ini memungkinkan perbandingan waktu siklus antar-departemen. Anda dapat mengetahui apakah departemen tertentu lebih lambat dalam mencatat atau menyetujui faktur, lalu menentukan perbaikan proses yang sesuai.
Mengapa ini penting
Mendukung analisis efisiensi proses di seluruh organisasi.
Sumber data
Kolom 'department' pada transaksi
Contoh
TIPemasaranManufaktur
|
|||
|
Jumlah faktur
InvoiceAmount
|
Nilai total faktur. | ||
|
Deskripsi
Jumlah total tagihan vendor, biasanya dalam mata uang dasar atau mata uang transaksi. Metrik ini membantu menganalisis dampak keuangan. Dashboard 'Pelacakan keterlambatan pembayaran dan denda' menggunakan data ini untuk mengukur risiko arus kas akibat pembayaran terlambat. Data ini juga membantu menentukan faktur bernilai tinggi yang perlu ditangani secara manual terlebih dahulu.
Mengapa ini penting
Diperlukan untuk mengukur dampak keuangan dari ketidakefisienan proses.
Sumber data
Kolom 'usertotal' atau 'foreignamount' pada transaksi
Contoh
1500.00250.5010000.00
|
|||
|
Nama vendor
VendorName
|
Nama pemasok yang menerbitkan faktur. | ||
|
Deskripsi
Atribut ini berisi nama entitas yang terkait dengan tagihan vendor. Data ini penting untuk menganalisis kinerja di seluruh rantai pasok. Dalam analisis, kolom ini mendukung dashboard 'Variasi siklus pembayaran vendor'. Analis dapat mengelompokkan kasus berdasarkan vendor untuk menemukan pemasok tertentu yang berulang kali menyebabkan ketidaksesuaian pencocokan atau menerapkan syarat pembayaran yang tidak standar.
Mengapa ini penting
Penting untuk mengelompokkan analisis berdasarkan pemasok dan menemukan hambatan yang terkait dengan vendor tertentu.
Sumber data
Kolom 'entity' pada transaksi yang digabungkan dengan data Vendor
Contoh
Office DepotOracleFedEx
|
|||
|
Nomor pesanan pembelian
PurchaseOrderNumber
|
Nomor referensi pesanan pembelian terkait. | ||
|
Deskripsi
Menghubungkan tagihan vendor dengan pesanan pembelian (PO) asalnya. Jika kolom ini kosong, faktur dianggap sebagai faktur tanpa PO. Atribut ini penting untuk dashboard 'Kecepatan pemrosesan faktur tanpa PO'. Analisis dapat memisahkan variasi alur antara faktur dengan PO dan faktur tanpa PO (FI), lalu membandingkan efisiensi dan kepatuhannya.
Mengapa ini penting
Diperlukan untuk membedakan pemrosesan faktur berbasis PO dan tanpa PO.
Sumber data
Kolom 'createdfrom' pada transaksi
Contoh
PO-8821PO-1002null
|
|||
|
Pengguna
User
|
Pegawai yang melakukan aktivitas. | ||
|
Deskripsi
Menunjukkan orang yang bertanggung jawab atas suatu peristiwa, misalnya menyetujui faktur atau membuka blokir pembayaran. Monitor 'Hambatan alur kerja persetujuan' menggunakan data ini untuk menemukan keterlambatan yang terkait dengan sumber daya tertentu. Manajemen dapat menyeimbangkan beban kerja dan mengetahui anggota tim yang memerlukan pelatihan.
Mengapa ini penting
Diperlukan untuk menganalisis sumber daya dan menemukan hambatan pada tingkat pengguna.
Sumber data
'name' pada System Notes atau 'employee' pada Transaction
Contoh
John DoeAdmin keuanganSistem
|
|||
|
Status persetujuan
ApprovalStatus
|
Status persetujuan faktur saat ini dalam alur kerja. | ||
|
Deskripsi
Menunjukkan apakah faktur menunggu persetujuan, disetujui, atau ditolak. Status ini menentukan perpindahan dalam alur kerja. Kolom ini menjadi dasar 'Audit kepatuhan alur kerja persetujuan'. Perubahan status menghasilkan peristiwa aktivitas, sedangkan status akhir menentukan apakah faktur siap dibayar.
Mengapa ini penting
Melacak perkembangan faktur melalui tahap persetujuan.
Sumber data
Kolom 'approvalstatus' pada transaksi
Contoh
Menunggu persetujuanDisetujuiDitolak
|
|||
|
Tanggal jatuh tempo
DueDate
|
Tanggal batas pembayaran kepada vendor. | ||
|
Deskripsi
Atribut ini menunjukkan batas waktu pembayaran sesuai kesepakatan pada faktur. Tanggal ini menjadi acuan untuk menghitung pembayaran tepat waktu. Kolom ini menjadi dasar KPI 'Tingkat pembayaran tepat waktu'. Sistem membandingkan tanggal 'Pembayaran dilakukan' dengan tanggal ini untuk menandai pembayaran terlambat dan memperkirakan potensi denda.
Mengapa ini penting
Dasar untuk menghitung tingkat pembayaran tepat waktu dan menemukan kewajiban yang terlambat dibayar.
Sumber data
Kolom 'duedate' pada transaksi
Contoh
2023-11-152023-12-01
|
|||
|
Tanggal pembayaran
PaymentDate
|
Tanggal pembayaran dilakukan. | ||
|
Deskripsi
Tanggal yang tercatat pada transaksi Vendor Payment yang terhubung dengan tagihan. Tanggal ini menandai selesainya siklus utang usaha. Data ini digunakan untuk menghitung 'Waktu siklus pembayaran dari awal hingga akhir'. Bandingkan tanggal ini dengan 'InvoiceDate' untuk mengetahui total durasi proses.
Mengapa ini penting
Stempel waktu akhir untuk siklus proses utama.
Sumber data
Tanggal transaksi Vendor Payment yang terhubung
Contoh
2023-11-202023-12-05
|
|||
|
Tanpa PO
IsNonPO
|
Penanda yang menunjukkan apakah faktur tidak terhubung dengan pesanan pembelian. | ||
|
Deskripsi
Atribut boolean yang diturunkan dari tidak adanya pesanan pembelian terkait. Atribut ini membagi proses menjadi faktur dengan PO dan faktur FI langsung. Dashboard 'Kecepatan pemrosesan faktur tanpa PO' menggunakan data ini untuk menunjukkan ketidakefisienan pemrosesan faktur manual dibandingkan proses pencocokan tiga arah.
Mengapa ini penting
Pengelompokan utama untuk menganalisis variasi proses.
Sumber data
Ditentukan dari nilai null pada 'PurchaseOrderNumber'
Contoh
truefalse
|
|||
|
Diskon tersedia
DiscountAvailable
|
Potensi nilai diskon untuk pembayaran lebih awal. | ||
|
Deskripsi
Nilai uang dari diskon pembayaran lebih awal, dihitung berdasarkan jumlah faktur dan syarat pembayaran. Nilai ini menunjukkan potensi penghematan. Atribut ini menjadi dasar dashboard 'Tingkat pemanfaatan diskon pembayaran lebih awal'. Analis dapat menjumlahkan nilainya untuk pembayaran terlambat guna menghitung total penghematan yang terlewat.
Mengapa ini penting
Mengukur peluang penghematan biaya jika proses dipercepat.
Sumber data
Dihitung dari Terms dan InvoiceAmount
Contoh
30.000.0015.50
|
|||
|
Hari keterlambatan
DaysOverdue
|
Jumlah hari pembayaran dilakukan setelah tanggal jatuh tempo. | ||
|
Deskripsi
Metrik hasil perhitungan yang mengukur keterlambatan pembayaran dibandingkan tanggal jatuh tempo. Nilai negatif menunjukkan pembayaran lebih awal. Atribut ini digunakan dalam dashboard 'Pelacakan keterlambatan pembayaran dan denda'. Data ini penting untuk mengukur tingkat keterlambatan dan menemukan pola keterlambatan yang berulang.
Mengapa ini penting
Metrik utama untuk menganalisis kepatuhan pembayaran dan risiko denda.
Sumber data
Dihitung: PaymentDate - DueDate
Contoh
50-2
|
|||
|
Mata uang
Currency
|
Mata uang yang digunakan untuk menerbitkan faktur. | ||
|
Deskripsi
Kode ISO yang menunjukkan mata uang transaksi. Informasi ini penting bagi organisasi multinasional. Data ini digunakan untuk menyetarakan nilai keuangan dalam analisis 'Jumlah faktur'. Data ini juga membantu mengetahui apakah proses valuta asing menambah waktu pada aktivitas 'Pembayaran diselesaikan'.
Mengapa ini penting
Diperlukan untuk menjumlahkan nilai keuangan dengan benar dan menganalisis valuta asing.
Sumber data
Kolom 'currency' pada transaksi
Contoh
USDEURGBP
|
|||
|
Penahanan pembayaran
PaymentHold
|
Menunjukkan apakah pembayaran faktur sedang diblokir. | ||
|
Deskripsi
Penanda atau status yang menunjukkan bahwa pembayaran faktur ditahan sehingga faktur tidak dapat disertakan dalam proses pembayaran. Atribut ini mendukung dashboard 'Analisis dampak blokir pembayaran'. Dengan menganalisis berapa lama kolom ini bernilai 'true', Anda dapat menemukan keterlambatan pemrosesan akibat sengketa atau informasi yang belum lengkap.
Mengapa ini penting
Penting untuk menganalisis penyebab faktur tertahan atau terlambat.
Sumber data
Kolom 'paymenthold' pada transaksi
Contoh
truefalse
|
|||
|
Syarat pembayaran
PaymentTerms
|
Kesepakatan yang mengatur waktu pembayaran dan diskon. | ||
|
Deskripsi
Menentukan ketentuan pembayaran, seperti 'Net 30' atau '2% 10 Net 30'. Informasi ini membantu menjelaskan 'Tanggal jatuh tempo' dan peluang memperoleh diskon pembayaran lebih awal. Dashboard 'Tingkat pemanfaatan diskon pembayaran lebih awal' menggunakan atribut ini untuk menemukan faktur yang memenuhi syarat diskon dan mengaitkan diskon yang terlewat dengan ketentuan tertentu yang membatasi.
Mengapa ini penting
Memberi konteks pada tanggal jatuh tempo dan menunjukkan peluang diskon.
Sumber data
Kolom 'terms' pada transaksi
Contoh
Net 302% 10 Net 30Jatuh tempo saat diterima
|
|||
|
Tanggal faktur
InvoiceDate
|
Tanggal yang tercetak pada faktur vendor. | ||
|
Deskripsi
Tanggal dokumen yang diberikan vendor. Tanggal ini sering menjadi titik awal perhitungan umur faktur. Data ini digunakan untuk menghitung 'Waktu siklus pemrosesan dari awal hingga akhir'. Selisih antara tanggal ini dan tanggal pembuatan di NetSuite dapat menunjukkan keterlambatan pemindaian atau penanganan surat.
Mengapa ini penting
Menandai awal resmi periode vendor.
Sumber data
Kolom 'trandate' pada transaksi
Contoh
2023-10-012023-10-05
|
|||
Aktivitas Pemrosesan Pembayaran Utang Usaha
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Faktur dibuat
|
Pembuatan awal catatan Tagihan Vendor di NetSuite. Ini menandai awal proses dan menunjukkan bahwa faktur telah dimasukkan ke ERP. | ||
|
Mengapa ini penting
Menetapkan stempel waktu awal untuk seluruh siklus Utang Usaha dan perhitungan umur faktur.
Sumber data
Tabel transaksi. Filter jenis catatan Vendor Bill. Ambil kolom datecreated atau trandate.
Pengumpulan data
Dicatat saat transaksi Vendor Bill dijalankan
Jenis peristiwa
explicit
|
|||
|
Faktur dicocokkan dengan PO
|
Menunjukkan bahwa Tagihan Vendor dibuat dari atau ditautkan ke Pesanan Pembelian yang sudah ada. Ini membedakan faktur dengan PO dari faktur tanpa PO. | ||
|
Mengapa ini penting
Penting untuk menganalisis kepatuhan terhadap kebijakan pengadaan dan membandingkan waktu siklus faktur dengan PO dan tanpa PO.
Sumber data
Tabel transaksi. Periksa kolom 'createdfrom' pada catatan Vendor Bill. Jika berisi ID Pesanan Pembelian, aktivitas ini terjadi.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Faktur disetujui
|
Status Tagihan Vendor berubah menjadi Open. Artinya, tagihan telah disetujui untuk dibayar dan berdampak pada buku besar (GL). Ini merupakan tahap penting sebelum pembayaran. | ||
|
Mengapa ini penting
Mengakhiri siklus persetujuan dan membuat faktur siap dijadwalkan untuk pembayaran. Penting untuk mengukur efisiensi persetujuan.
Sumber data
System Notes. Cari perubahan kolom 'approvalstatus' menjadi '2' (Approved) atau status menjadi 'Open'.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Pembayaran diproses
|
Catatan Bill Payment berhasil dibukukan. Faktur ditandai sebagai Paid in Full atau Partially Paid, dan kewajiban di buku besar (GL) berkurang. | ||
|
Mengapa ini penting
Tahap utama yang menandai selesainya proses pembayaran. Digunakan untuk menghitung 'Waktu Siklus Pemrosesan dari Awal hingga Akhir'.
Sumber data
Tabel transaksi. Cari pembuatan catatan 'Bill Payment' atau perubahan status menjadi 'Deposited' (untuk cek) atau 'Paid'.
Pengumpulan data
Dicatat saat transaksi Bill Payment dijalankan
Jenis peristiwa
explicit
|
|||
|
Pembayaran telah dicairkan
|
Bill Payment ditandai telah dicairkan saat rekonsiliasi bank. Ini memastikan dana sudah keluar dari rekening bank. | ||
|
Mengapa ini penting
Memberikan tanggal akhir keuangan yang sebenarnya untuk analisis arus kas, berbeda dari tanggal pembayaran dalam akuntansi.
Sumber data
Transaction Line. Penanda 'cleared' pada baris transaksi Bill Payment diatur ke True.
Pengumpulan data
Dicatat saat transaksi X dijalankan
Jenis peristiwa
explicit
|
|||
|
Akun faktur diubah
|
Akun beban buku besar (GL) pada baris faktur diubah. Ini menunjukkan koreksi kesalahan pengodean atau reklasifikasi. | ||
|
Mengapa ini penting
Mengukur langsung KPI 'Tingkat Pekerjaan Ulang Pengodean Faktur' dan menunjukkan penurunan efisiensi pada tahap pengodean akuntansi.
Sumber data
System Notes. Cari perubahan kolom 'account' pada subdaftar Transaction Line.
Pengumpulan data
Dicatat saat transaksi X dijalankan
Jenis peristiwa
explicit
|
|||
|
Faktur ditolak
|
Tagihan Vendor dikembalikan kepada pengaju untuk diperbaiki atau ditolak. Ini menandai pengulangan atau penghentian dalam alur kerja persetujuan. | ||
|
Mengapa ini penting
Tingkat penolakan yang tinggi menunjukkan adanya kendala proses, masalah pelatihan, atau masalah kualitas data pada tahap sebelumnya.
Sumber data
System Notes. Cari perubahan kolom 'approvalstatus' menjadi '3' (Rejected).
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Jumlah faktur diubah
|
Jumlah total Tagihan Vendor diubah setelah pertama kali dibuat. Ini dapat menandakan pekerjaan ulang, kesalahan entri data, atau penyelesaian selisih. | ||
|
Mengapa ini penting
Menunjukkan adanya campur tangan manual dan pekerjaan ulang, yang menurunkan tingkat pemrosesan otomatis tanpa intervensi.
Sumber data
System Notes. Cari perubahan kolom 'total' atau 'usertotal' pada catatan Vendor Bill.
Pengumpulan data
Dicatat saat transaksi X dijalankan
Jenis peristiwa
explicit
|
|||
|
Kredit vendor diterapkan
|
Kredit Tagihan (Kredit Vendor) diterapkan pada Tagihan Vendor sehingga jumlah yang harus dibayar berkurang. Ini menjadi alternatif pembayaran tunai. | ||
|
Mengapa ini penting
Menjelaskan perbedaan antara jumlah pembayaran dan jumlah faktur, serta memastikan kewajiban ditutup dengan benar.
Sumber data
Transaction Links. Cari transaksi jenis 'Vendor Credit' yang ditautkan ke Tagihan Vendor.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Pembayaran dibatalkan
|
Bill Payment yang sebelumnya diproses dibatalkan, sehingga Tagihan Vendor dibuka kembali. Ini merupakan pengecualian besar dan kegagalan proses. | ||
|
Mengapa ini penting
Penting untuk kepatuhan audit dan menemukan penyebab pembayaran gagal, misalnya kesalahan pencetakan cek atau penolakan bank.
Sumber data
System Notes pada Bill Payment. Status berubah menjadi 'Voided'.
Pengumpulan data
Dicatat saat transaksi X dijalankan
Jenis peristiwa
explicit
|
|||
|
Pembayaran dijadwalkan
|
Catatan Bill Payment dibuat dengan status 'Pending Approval'. Ini sering terjadi saat batch Electronic Bank Payment (EFT) dibuat. | ||
|
Mengapa ini penting
Membedakan rencana pembayaran dari pencairan dana yang sebenarnya dan menunjukkan keterlambatan otorisasi pembayaran.
Sumber data
Tabel transaksi. Pembuatan catatan 'Bill Payment' yang ditautkan ke Bill, dengan status 'Pending Approval'.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Pemblokiran pembayaran dicabut
|
Kotak centang Payment Hold diatur ke False, sehingga faktur dapat diproses untuk pembayaran. Ini menandai berakhirnya periode pemblokiran. | ||
|
Mengapa ini penting
Digunakan untuk menghitung KPI 'Durasi Pemblokiran Pembayaran' dan memahami waktu penyelesaian faktur yang disengketakan.
Sumber data
System Notes. Cari perubahan kolom 'paymenthold' dari 'T' menjadi 'F'.
Pengumpulan data
Dicatat saat transaksi X dijalankan
Jenis peristiwa
explicit
|
|||
|
Pemblokiran pembayaran diterapkan
|
Kotak centang Payment Hold pada Tagihan Vendor diatur ke True. Ini mencegah faktur dipilih untuk batch pembayaran. | ||
|
Mengapa ini penting
Menunjukkan hambatan saat faktur tertahan karena sengketa atau keputusan pengelolaan arus kas.
Sumber data
System Notes. Cari perubahan kolom 'paymenthold' dari 'F' menjadi 'T'.
Pengumpulan data
Dicatat saat transaksi X dijalankan
Jenis peristiwa
explicit
|
|||
|
Persetujuan faktur diminta
|
Status Tagihan Vendor berubah menjadi Pending Approval. Ini menunjukkan bahwa faktur telah masuk ke alur kerja untuk mendapatkan persetujuan. | ||
|
Mengapa ini penting
Menandai awal waktu siklus persetujuan dan membantu menemukan hambatan dalam rantai otorisasi.
Sumber data
System Notes. Cari perubahan kolom 'approvalstatus' menjadi '1' (Pending Approval).
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
Panduan Ekstraksi
Siap memulai?
Mulai gunakan process mining hari ini dengan menerapkan templat ini di lingkungan NetSuite Anda. Temukan peluang efisiensi dan optimalkan alur kerja pembayaran tanpa menunda.
Optimalkan pemrosesan pembayaran utang usaha Anda sekarang
Temukan hambatan dan kurangi waktu siklus hingga 30 persen.
Tidak perlu kartu kredit. Penyiapan hanya perlu beberapa menit.