Templat data Order to Cash - Penagihan dan Faktur
Templat data Order to Cash - Penagihan dan Faktur
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data dari Microsoft Dynamics 365
Atribut Order to Cash - Penagihan dan Faktur
| Nama | Deskripsi | ||
|---|---|---|---|
|
Nomor Faktur
InvoiceNumber
|
Nomor unik untuk setiap faktur pelanggan, yang berfungsi sebagai ID kasus utama dalam proses penagihan. | ||
|
Deskripsi
Nomor Faktur menjadi kunci utama untuk mengelompokkan semua aktivitas yang terkait dengan satu dokumen penagihan. Nomor ini memungkinkan analisis menyeluruh atas siklus faktur, mulai dari pembuatan dan persetujuan hingga pembayaran pelanggan dan penutupan. Dengan menggunakannya sebagai ID Kasus, setiap catatan log peristiwa terkait dengan faktur tertentu. Anda pun dapat menganalisis variasi proses secara terperinci, menghitung waktu siklus, dan memantau kinerja setiap transaksi penagihan.
Mengapa ini penting
Atribut ini penting untuk melacak seluruh siklus faktur dan menganalisis efisiensi proses, hambatan, serta penyimpangan pada setiap dokumen penagihan.
Sumber data
Biasanya tersedia di modul Sales and marketing, dalam tabel seperti CustInvoiceJour (kolom InvoiceId) atau melalui entitas data seperti SalesInvoiceHeaderV2.
Contoh
CIV-001254INV-2023-9876US-004321
|
|||
|
Nama Aktivitas
ActivityName
|
Nama aktivitas bisnis atau kejadian yang berlangsung pada tahap tertentu dalam siklus faktur. | ||
|
Deskripsi
Atribut ini menjelaskan langkah atau tonggak tertentu dalam proses penagihan, seperti 'Faktur Dibuat', 'Faktur Disetujui', atau 'Pembayaran Pelanggan Diterima'. Urutan aktivitas ini membentuk alur proses. Analisis aktivitas merupakan dasar process mining karena membantu menemukan model proses dan variasinya, serta mengukur kinerja di antara berbagai langkah.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam proses, sehingga Anda dapat memvisualisasikan peta proses, menganalisis variasi, dan menemukan hambatan atau penyimpangan dari prosedur standar.
Sumber data
Atribut ini biasanya diperoleh dari beberapa sumber, seperti kolom perubahan status (misalnya DocumentState), kolom tanggal tertentu yang terisi, atau log riwayat alur kerja di Microsoft Dynamics 365.
Contoh
Faktur dibuatFaktur disetujuiPembayaran pelanggan diterimaNota kredit diterbitkan
|
|||
|
Waktu Kejadian
EventTime
|
Stempel waktu yang menunjukkan secara tepat kapan aktivitas atau kejadian tertentu berlangsung. | ||
|
Deskripsi
Waktu Kejadian, yang juga dikenal sebagai stempel waktu, mencatat tanggal dan waktu tepat untuk setiap aktivitas dalam proses. Data ini penting untuk semua analisis process mining berbasis waktu. Data tersebut digunakan untuk menghitung waktu siklus antaraktivitas, mengukur durasi total kasus, dan memahami kinerja proses dari waktu ke waktu. Stempel waktu yang akurat dan andal menjadi dasar KPI seperti Days Sales Outstanding dan Waktu Pembuatan Faktur.
Mengapa ini penting
Atribut ini menjadi dasar untuk semua analisis kinerja dan waktu. Dengan atribut ini, Anda dapat menghitung waktu siklus, durasi, dan kapasitas pemrosesan untuk mengukur efisiensi proses.
Sumber data
Stempel waktu diambil dari berbagai kolom tanggal dan waktu di sejumlah tabel Dynamics 365, seperti CreatedDateTime di tabel CustInvoiceJour untuk pembuatan faktur, atau stempel waktu khusus di riwayat alur kerja.
Contoh
2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
|
|||
|
Departemen
Department
|
Departemen bisnis yang terkait dengan pengguna atau aktivitas. | ||
|
Deskripsi
Atribut ini mengaitkan aktivitas atau pengguna dengan departemen tertentu, seperti 'Piutang usaha' atau 'Penjualan'. Dengan atribut ini, Anda dapat melihat kinerja proses pada tingkat departemen, bukan hanya individu. Analisis per departemen membantu memahami perpindahan pekerjaan antar fungsi, membandingkan efisiensi tim, dan menemukan hambatan di tingkat departemen, sesuai kebutuhan dasbor 'Beban aktivitas departemen penagihan'.
Mengapa ini penting
Atribut ini memungkinkan analisis kinerja di tingkat organisasi, perbandingan efisiensi antar tim, dan pemahaman tentang dampak perpindahan pekerjaan antar departemen terhadap proses.
Sumber data
Biasanya, informasi ini tidak tersedia langsung pada transaksi faktur. Data diperoleh dengan menggabungkan ID UserResponsible dengan direktori karyawan atau pengguna yang memuat informasi departemen.
Contoh
Piutang usahaKeuanganOperasional penagihan
|
|||
|
Jumlah faktur
InvoiceAmount
|
Total nilai uang pada faktur. | ||
|
Deskripsi
Atribut ini menunjukkan total tagihan pada faktur. Nilai ini penting untuk analisis keuangan dan membantu mengelompokkan faktur berdasarkan jumlahnya. Misalnya, analis dapat meninjau faktur bernilai tinggi untuk memahami pola pembayarannya atau mengetahui apakah faktur tersebut membutuhkan waktu lebih lama untuk disetujui. Nilai ini juga menjadi dasar untuk menghitung total nilai faktur yang belum dibayar dan DSO.
Mengapa ini penting
Atribut ini membantu menganalisis dampak keuangan. Anda dapat memfilter dan mengelompokkan proses berdasarkan nilai uang untuk memprioritaskan faktur bernilai tinggi dan memahami pola prosesnya.
Sumber data
Biasanya tersedia di tabel CustInvoiceJour, pada kolom seperti InvoiceAmount. Nilai ini juga tersedia di tabel transaksi terkait.
Contoh
5430.5012500.00750.25
|
|||
|
Nama pelanggan
CustomerName
|
Nama pelanggan yang menerima faktur. | ||
|
Deskripsi
Nama pelanggan memudahkan Anda mengenali bisnis atau orang yang ditagih. Dalam analisis process mining, Anda dapat mengelompokkan proses penagihan berdasarkan pelanggan. Hasilnya dapat menunjukkan pelanggan yang selalu membayar tepat waktu, pelanggan yang sering terlambat, atau kelompok pelanggan yang mengalami variasi maupun keterlambatan proses tertentu. Atribut ini penting untuk dasbor perilaku pembayaran pelanggan dan analisis Days Sales Outstanding.
Mengapa ini penting
Atribut ini memungkinkan analisis proses dikelompokkan berdasarkan pelanggan, sehingga Anda dapat mengenali pola perilaku, kebiasaan pembayaran, atau masalah proses pada pelanggan tertentu.
Sumber data
Informasi ini diperoleh dengan menggabungkan data faktur dan tabel data induk pelanggan, biasanya CustTable, berdasarkan nomor akun pelanggan.
Contoh
Contoso Ltd.Fabrikam, Inc.Northwind Traders
|
|||
|
Pengguna yang bertanggung jawab
UserResponsible
|
Pengguna atau karyawan yang bertanggung jawab menjalankan aktivitas tertentu. | ||
|
Deskripsi
Atribut ini menunjukkan orang yang menjalankan tugas tertentu dalam proses penagihan, seperti menyetujui faktur atau mencatat pembayaran. Informasi ini penting untuk menganalisis beban kerja, membandingkan kinerja, dan mengetahui kebutuhan pelatihan. Misalnya, dasbor 'Beban aktivitas departemen penagihan' menggunakan atribut ini untuk melihat apakah pekerjaan terbagi merata atau menumpuk pada pengguna tertentu. Atribut ini juga membantu memahami alokasi sumber daya dan efisiensi.
Mengapa ini penting
Atribut ini memungkinkan analisis berdasarkan sumber daya, membantu menemukan hambatan, mengukur kinerja individu atau tim, dan menganalisis pembagian beban kerja di departemen penagihan.
Sumber data
Sumber data dapat berupa log riwayat workflow, misalnya WorkflowTrackingStatusTable, atau kolom kepemilikan seperti Owner atau ModifiedBy pada tabel terkait.
Contoh
John SmithAlicia BakerAdministrator sistem
|
|||
|
Status faktur
InvoiceStatus
|
Status faktur saat ini dalam siklusnya, misalnya terbuka, lunas, atau dibatalkan. | ||
|
Deskripsi
Atribut ini menunjukkan posisi faktur saat ini. Anda dapat mengetahui apakah faktur masih menunggu pembayaran, sudah lunas, telah jatuh tempo, atau dibatalkan dengan nota kredit. Informasi ini berguna untuk memfilter kasus dan hanya menganalisis faktur yang masih terbuka, atau memastikan hasil akhir faktur yang sudah ditutup. Atribut ini juga membantu memahami beban kerja saat ini dan kondisi keuangan piutang.
Mengapa ini penting
Atribut ini memberi gambaran singkat tentang kondisi faktur saat ini. Anda dapat menggunakannya untuk memfilter kasus dan memahami hasil dari berbagai variasi proses.
Sumber data
Status ini dapat ditentukan dari status pembayaran faktur, misalnya dengan memeriksa apakah saldo pada catatan CustTrans terkait bernilai nol. Tidak selalu ada satu kolom khusus untuk 'status'.
Contoh
TerbukaLunasTerlambatDibatalkan
|
|||
|
Tanggal jatuh tempo pembayaran
PaymentDueDate
|
Tanggal batas pembayaran faktur oleh pelanggan. | ||
|
Deskripsi
Tanggal jatuh tempo pembayaran adalah tanggal penting yang dihitung berdasarkan tanggal faktur dan ketentuan pembayaran pelanggan. Tanggal ini menjadi acuan untuk mengukur ketepatan waktu pembayaran. Atribut ini diperlukan untuk dasbor 'Analisis kepatuhan terhadap ketentuan pembayaran' dan penghitungan KPI seperti 'Tingkat pembayaran tepat waktu' dan 'Days Sales Outstanding'. Dengan membandingkan tanggal ini dengan tanggal pembayaran sebenarnya, Anda dapat memahami perilaku pembayaran pelanggan dan efektivitas proses penagihan.
Mengapa ini penting
Tanggal ini menjadi acuan untuk mengukur kinerja pembayaran. Atribut ini penting untuk menghitung tingkat pembayaran tepat waktu dan menganalisis kepatuhan terhadap ketentuan pembayaran pelanggan.
Sumber data
Biasanya tersedia di tabel CustInvoiceJour, pada kolom seperti DueDate.
Contoh
2023-05-152023-06-302023-07-01
|
|||
|
Days Sales Outstanding
DaysSalesOutstanding
|
Jumlah hari antara pembuatan faktur dan penerimaan pembayaran pelanggan. | ||
|
Deskripsi
Days Sales Outstanding (DSO) adalah metrik keuangan penting yang mengukur rata-rata waktu yang dibutuhkan perusahaan untuk menerima pembayaran setelah penjualan. Atribut hasil perhitungan ini menghitung durasi tersebut untuk setiap faktur. DSO menjadi metrik utama pada dasbor 'Analisis tren Days Sales Outstanding' dan KPI 'DSO'. Analisis DSO membantu mengelola arus kas dan menilai efisiensi fungsi kredit dan penagihan.
Mengapa ini penting
KPI ini penting untuk mengukur kondisi arus kas perusahaan dan efisiensi proses penagihan. DSO menunjukkan seberapa cepat pendapatan berubah menjadi kas.
Sumber data
Atribut ini tidak tersedia di sistem sumber. Nilainya dihitung dari durasi antara aktivitas 'Faktur dibuat' dan 'Pembayaran pelanggan diterima'.
Contoh
284592
|
|||
|
Ketentuan pembayaran
PaymentTerms
|
Kesepakatan tentang batas waktu pembayaran faktur, misalnya Net 30 atau Net 60. | ||
|
Deskripsi
Ketentuan pembayaran menetapkan batas waktu bagi pelanggan untuk membayar faktur. Atribut ini digunakan untuk menghitung tanggal jatuh tempo pembayaran dan menjadi dimensi penting dalam analisis perilaku pembayaran. Dasbor 'Analisis kepatuhan terhadap ketentuan pembayaran' menggunakan atribut ini untuk mengelompokkan pelanggan dan faktur, lalu melihat apakah ketentuan tertentu lebih efektif atau berkaitan dengan tingkat keterlambatan pembayaran yang lebih tinggi.
Mengapa ini penting
Atribut ini menjelaskan alasan faktur jatuh tempo pada tanggal tertentu. Anda juga dapat mengelompokkan analisis untuk melihat apakah ketentuan pembayaran tertentu berkaitan dengan keterlambatan pembayaran.
Sumber data
Biasanya tersimpan di data induk pelanggan, lalu disalin ke header faktur. Cari kolom Payment atau PaymTermId di tabel CustInvoiceJour.
Contoh
Net 30Net 60Jatuh tempo saat diterima
|
|||
|
Mata uang
Currency
|
Kode mata uang untuk jumlah faktur, misalnya USD atau EUR. | ||
|
Deskripsi
Atribut ini menunjukkan mata uang yang digunakan untuk menyatakan jumlah faktur. Informasi ini penting bagi organisasi multinasional yang bertransaksi dalam berbagai mata uang. Tanpa konteks ini, penjumlahan atau perbandingan jumlah faktur tidak akan bermakna. Atribut ini memungkinkan konversi mata uang yang tepat serta pelaporan dan analisis keuangan yang akurat di berbagai wilayah.
Mengapa ini penting
Atribut ini memberi konteks penting untuk metrik keuangan seperti Jumlah faktur. Dengan begitu, penjumlahan yang keliru dapat dihindari dan analisis tetap akurat di lingkungan dengan berbagai mata uang.
Sumber data
Biasanya tersedia di tabel CustInvoiceJour, pada kolom seperti CurrencyCode.
Contoh
USDEURGBP
|
|||
|
Memerlukan intervensi manual
RequiresManualIntervention
|
Penanda yang menunjukkan apakah pembayaran memerlukan penyesuaian manual saat pencatatan pembayaran. | ||
|
Deskripsi
Atribut boolean ini menandai pembayaran yang memerlukan intervensi atau koreksi manual saat pencatatan pembayaran. Atribut ini penting untuk KPI 'Tingkat selisih pencatatan pembayaran' karena membantu mengukur akurasi dan tingkat otomatisasi pencatatan pembayaran. Dengan mengetahui penyebab intervensi manual, seperti informasi pengiriman pembayaran yang tidak lengkap atau selisih pembayaran, Anda dapat memperbaiki proses dan meningkatkan tingkat pemrosesan otomatis dari awal hingga akhir.
Mengapa ini penting
Atribut ini membantu menemukan kendala dan ketidakakuratan pada tahap pencatatan pembayaran. Informasi ini penting untuk meningkatkan otomatisasi dan mengurangi pekerjaan manual.
Sumber data
Informasi ini dapat diperkirakan dari pengguna yang mencatat pembayaran, jika bukan pengguna sistem, atau dari kode alasan tertentu yang digunakan saat rekonsiliasi pembayaran. Lihat dokumentasi Microsoft Dynamics 365.
Contoh
truefalse
|
|||
|
Mengalami pengerjaan ulang
IsRework
|
Penanda yang menunjukkan apakah proses faktur mengalami pengerjaan ulang, misalnya beberapa kali persetujuan. | ||
|
Deskripsi
Atribut boolean hasil perhitungan ini menandai faktur yang mengalami pengerjaan ulang. Pengerjaan ulang dapat ditentukan dari beberapa event 'Faktur disetujui' atau pembatalan pembayaran. Atribut ini dirancang untuk mendukung dasbor 'Analisis pengerjaan ulang faktur' dan KPI 'Tingkat pengerjaan ulang faktur'. Dengan memisahkan kasus-kasus ini, analis dapat menyelidiki akar penyebab pengerjaan ulang, yang sering kali berkaitan dengan proses yang tidak efisien, masalah kualitas data, atau kurangnya pelatihan.
Mengapa ini penting
Penanda ini mengukur ketidakefisienan proses dengan menunjukkan kasus yang melibatkan tindakan berulang atau koreksi. Dengan begitu, Anda dapat menemukan akar pemborosan dan keterlambatan.
Sumber data
Atribut ini tidak tersedia di sistem sumber. Atribut dihitung pada lapisan transformasi data dengan memeriksa aktivitas berulang atau pola pengerjaan ulang tertentu dalam suatu kasus.
Contoh
truefalse
|
|||
|
Nomor pesanan penjualan
SalesOrderNumber
|
ID pesanan penjualan yang menjadi asal faktur. | ||
|
Deskripsi
Nomor pesanan penjualan menghubungkan proses penagihan dengan proses penjualan sebelumnya. Hubungan ini sangat berguna untuk analisis Order-to-Cash dari awal hingga akhir. Analis dapat menyelidiki dampak masalah dalam proses penjualan dan pemenuhan pesanan, seperti perubahan pesanan atau keterlambatan pengiriman, terhadap siklus penagihan. Misalnya, Anda dapat mencari tahu apakah faktur dari pesanan penjualan yang rumit membutuhkan waktu lebih lama untuk dibayar.
Mengapa ini penting
Atribut ini menghubungkan proses penagihan dengan proses penjualan sebelumnya. Dengan begitu, Anda dapat menganalisis Order-to-Cash dari awal hingga akhir dan mencari akar masalah penagihan.
Sumber data
Tersedia di header atau detail baris faktur dan terhubung ke pesanan penjualan. Cari kolom seperti SalesId di tabel CustInvoiceJour.
Contoh
SO-009876SO-010234US-SO-00543
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Waktu terakhir data untuk event ini diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat waktu terakhir data diekstrak atau diperbarui dari Microsoft Dynamics 365. Kolom metadata ini penting untuk mengetahui seberapa baru data yang dianalisis. Analis dan pengguna bisnis dapat memastikan apakah informasi yang mereka lihat sudah terbaru. Informasi ini juga membantu mengatur jadwal pembaruan data dan menjaga keandalan analisis.
Mengapa ini penting
Atribut ini membantu pengguna mengetahui kebaruan data. Informasi tersebut penting untuk tata kelola data, pengelolaan pembaruan dasbor, dan memastikan wawasan yang dihasilkan tepat waktu.
Sumber data
Atribut ini dibuat dan dicantumkan pada dataset selama proses ekstraksi, transformasi, dan pemuatan data (ETL).
Contoh
2023-06-20T05:00:00Z2023-06-21T05:00:00Z
|
|||
|
Pembayaran tepat waktu
IsOnTimePayment
|
Penanda yang menunjukkan apakah pembayaran pelanggan diterima pada atau sebelum tanggal jatuh tempo. | ||
|
Deskripsi
Atribut boolean hasil perhitungan ini membandingkan waktu event 'Pembayaran pelanggan diterima' dengan 'Tanggal jatuh tempo pembayaran'. Atribut ini menandai setiap faktur sebagai dibayar tepat waktu atau terlambat. Nilai ini menjadi dasar penghitungan KPI 'Tingkat pembayaran tepat waktu' dan banyak digunakan dalam dasbor 'Analisis kepatuhan terhadap ketentuan pembayaran'. Hasilnya jelas, yaitu tepat waktu atau terlambat, sehingga analisis dan pelaporan lebih mudah.
Mengapa ini penting
Atribut ini mengukur kepatuhan pelanggan terhadap ketentuan pembayaran dan menjadi dasar KPI Tingkat pembayaran tepat waktu. Hasilnya menyederhanakan analisis efektivitas penagihan.
Sumber data
Atribut ini tidak tersedia di sistem sumber. Atribut dihitung saat transformasi data dengan membandingkan tanggal pembayaran dan PaymentDueDate.
Contoh
truefalse
|
|||
|
Sistem Sumber
SourceSystem
|
Sistem tempat data diekstrak. | ||
|
Deskripsi
Atribut ini menunjukkan asal data proses. Dalam konteks ini, data berasal dari Microsoft Dynamics 365. Informasi ini penting di lingkungan yang menggunakan beberapa sistem agar sumber data dapat dibedakan dan asal-usul data tetap jelas. Dengan begitu, validasi data dan penelusuran masalah menjadi lebih mudah.
Mengapa ini penting
Informasi ini memberi konteks penting tentang asal data. Konteks tersebut diperlukan untuk tata kelola dan validasi data, serta saat menggabungkan data dari beberapa sistem perusahaan.
Sumber data
Nilai tetap ini ditambahkan saat proses ekstraksi dan transformasi data untuk menandai asal dataset.
Contoh
Microsoft Dynamics 365 FinanceD365 F&O
|
|||
Aktivitas Order to Cash - Penagihan dan Faktur
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Faktur dibuat
|
Menunjukkan pembuatan dan pencatatan dokumen faktur penjualan di sistem. Ini adalah transaksi eksplisit di Dynamics 365 yang membuat dokumen legal dan entri keuangan di subbuku besar piutang. | ||
|
Mengapa ini penting
Ini menandai awal resmi siklus penagihan faktur. Kejadian ini penting untuk melacak Days Sales Outstanding (DSO) dan durasi proses secara keseluruhan.
Sumber data
Diambil dari stempel waktu pembuatan catatan faktur penjualan yang sudah dicatat di tabel CustInvoiceJour. Saat faktur dicatat, transaksi keuangan terkait dibuat di tabel GeneralJournalEntry dan LedgerEntry.
Pengumpulan data
Gunakan kolom CreatedDateTime dari tabel CustInvoiceJour untuk faktur yang sudah dicatat.
Jenis peristiwa
explicit
|
|||
|
Faktur dikirim ke pelanggan
|
Aktivitas ini menandai saat faktur dikirim kepada pelanggan, secara elektronik atau fisik. Di Dynamics 365, kejadian ini dapat dicatat secara eksplisit jika faktur dikirim melalui email sistem. Jika pelacakan khusus tidak diaktifkan, waktunya dapat disimpulkan dari waktu pencatatan faktur. | ||
|
Mengapa ini penting
Mengukur efisiensi proses pengiriman faktur. Keterlambatan antara persetujuan dan pengiriman faktur memperpanjang siklus pembayaran.
Sumber data
Dapat dicatat secara eksplisit dari log email seperti SysOutgoingEmailTable jika Anda menggunakan fitur email D365. Jika tidak, waktunya sering disimpulkan sama dengan waktu pencatatan faktur di CustInvoiceJour.
Pengumpulan data
Gunakan stempel waktu di log email jika tersedia. Jika tidak, gunakan stempel waktu pencatatan faktur.
Jenis peristiwa
inferred
|
|||
|
Faktur disetujui
|
Menandai selesainya proses peninjauan internal, saat faktur resmi disetujui. Kejadian ini dicatat oleh sistem alur kerja Dynamics 365 dan menandakan bahwa faktur siap dikirim kepada pelanggan. | ||
|
Mengapa ini penting
Ini adalah tonggak penting untuk mengukur waktu siklus persetujuan. Keterlambatan pada tahap ini dapat langsung memperpanjang waktu hingga pelanggan membayar.
Sumber data
Dicatat di tabel riwayat alur kerja, seperti WorkflowTrackingStatusTable, sebagai langkah penyelesaian atau persetujuan untuk instans alur kerja faktur tertentu.
Pengumpulan data
Ekstrak log peristiwa alur kerja dengan status 'Disetujui' atau 'Selesai'.
Jenis peristiwa
explicit
|
|||
|
Faktur ditutup
|
Aktivitas ini menandai status akhir faktur, saat saldonya nol karena sudah dibayar lunas atau diselesaikan dengan nota kredit. Ini bukan transaksi langsung, melainkan status yang disimpulkan dari kondisi keuangan faktur. | ||
|
Mengapa ini penting
Kejadian ini menandai selesainya siklus Order to Cash untuk satu faktur. Waktu yang dibutuhkan hingga tahap ini menjadi ukuran utama efisiensi proses secara keseluruhan.
Sumber data
Disimpulkan dengan memeriksa apakah saldo transaksi faktur di tabel CustTrans sudah nol. Caranya, bandingkan jumlah faktur dengan total jumlah yang telah diselesaikan.
Pengumpulan data
Simpulkan dari catatan CustTrans saat AmountCur sama dengan SettleAmountCur. Gunakan tanggal penyelesaian terakhir sebagai stempel waktu.
Jenis peristiwa
inferred
|
|||
|
Pembayaran dialokasikan ke faktur
|
Menunjukkan penyelesaian pembayaran pelanggan terhadap faktur tertentu, sehingga saldo terutang faktur berkurang. Di Dynamics 365, ini merupakan langkah tersendiri yang menghubungkan transaksi pembayaran dengan transaksi faktur. | ||
|
Mengapa ini penting
Ini adalah tonggak penting untuk menghitung DSO secara akurat dan memahami efisiensi tim pencatatan pembayaran. Tahap ini menandai saat pembayaran sudah direkonsiliasi sepenuhnya dengan tagihan.
Sumber data
Dicatat di tabel CustSettlement. Kolom tanggal penyelesaian pada tabel ini memberikan stempel waktu saat pembayaran tertentu dialokasikan ke transaksi faktur tertentu.
Pengumpulan data
Gunakan TransDate atau CreatedDateTime dari tabel CustSettlement.
Jenis peristiwa
explicit
|
|||
|
Pembayaran pelanggan diterima
|
Aktivitas ini menandai pembuatan entri jurnal untuk mencatat pembayaran yang diterima dari pelanggan. Artinya, dana sudah diterima, tetapi belum dialokasikan ke faktur tertentu. | ||
|
Mengapa ini penting
Ini menjadi titik awal untuk mengukur waktu yang dibutuhkan dalam pencatatan pembayaran. Dengan demikian, Anda dapat membedakan waktu penerimaan dana dari waktu rekonsiliasinya dengan faktur yang belum lunas.
Sumber data
Diambil dari pembuatan atau pencatatan jurnal pembayaran pelanggan. Data ini dicatat di tabel seperti LedgerJournalTrans, lalu saat jurnal dicatat, transaksi pelanggan dibuat di CustTrans.
Pengumpulan data
Gunakan stempel waktu pencatatan jurnal pembayaran pelanggan dari LedgerJournalTable.
Jenis peristiwa
explicit
|
|||
|
Tanggal jatuh tempo pembayaran tercapai
|
Kejadian hasil perhitungan yang terjadi saat tanggal jatuh tempo faktur tiba dan pembayaran belum dilunasi sepenuhnya. Aktivitas ini bukan transaksi di sistem, melainkan disimpulkan dari data yang tersedia. | ||
|
Mengapa ini penting
Kejadian ini penting untuk menganalisis tingkat pembayaran tepat waktu dan menemukan faktur yang mulai menunggak. Kejadian ini menjadi pemicu aktivitas penagihan dan pengiriman surat penagihan.
Sumber data
Kejadian ini tidak dicatat secara langsung. Waktunya dihitung menggunakan kolom DueDate dari tabel CustInvoiceJour. Stempel waktu kejadian adalah tanggal jatuh tempo itu sendiri.
Pengumpulan data
Buat kejadian dengan stempel waktu yang diambil dari nilai kolom CustInvoiceJour.DueDate.
Jenis peristiwa
calculated
|
|||
|
Faktur diajukan untuk persetujuan
|
Aktivitas ini menunjukkan bahwa faktur yang sudah dibuat telah diajukan ke alur kerja persetujuan resmi. Proses ini umum di organisasi yang mewajibkan peninjauan oleh manajemen sebelum faktur dikirim kepada pelanggan. Langkah ini dicatat secara khusus di mesin alur kerja D365. | ||
|
Mengapa ini penting
Dengan melacak pengajuan persetujuan, Anda dapat membedakan waktu pembuatan faktur dari waktu tunggu persetujuan. Ini merupakan langkah pertama untuk menganalisis efisiensi proses peninjauan dan pengendalian internal.
Sumber data
Diambil dari tabel riwayat alur kerja, seperti WorkflowTrackingStatusTable, dengan memfilter kejadian pengajuan yang terkait dengan dokumen faktur.
Pengumpulan data
Ekstrak log peristiwa alur kerja dengan status 'Diajukan'.
Jenis peristiwa
explicit
|
|||
|
Nota kredit diterbitkan
|
Menunjukkan pembuatan nota kredit atau memo kredit, biasanya untuk memperbaiki kesalahan penagihan, memberikan penyesuaian harga, atau mencatat barang yang dikembalikan. Nota kredit pada dasarnya adalah faktur bernilai negatif. | ||
|
Mengapa ini penting
Nota kredit yang sering diterbitkan dapat menunjukkan masalah sistemis dalam proses pemenuhan pesanan atau penagihan. Menganalisis alasan penerbitannya penting untuk memperbaiki proses dan mengurangi kebocoran pendapatan.
Sumber data
Ini adalah transaksi eksplisit yang dicatat sebagai faktur baru dengan nilai negatif di tabel CustInvoiceJour. Nota kredit sering dihubungkan ke faktur asli melalui kolom referensi.
Pengumpulan data
Temukan catatan di CustInvoiceJour dengan jumlah total negatif, lalu hubungkan dengan faktur asli.
Jenis peristiwa
explicit
|
|||
|
Pembayaran dibatalkan
|
Aktivitas ini menandai pembatalan pembayaran pelanggan yang sebelumnya sudah dicatat. Hal ini dapat terjadi karena kesalahan pencatatan, dana tidak mencukupi, atau masalah pembayaran lainnya. | ||
|
Mengapa ini penting
Pembatalan pembayaran dapat menunjukkan kesalahan operasional atau masalah pembayaran pelanggan. Dengan menganalisis frekuensinya, Anda dapat menemukan akar penyebab dan meningkatkan akurasi proses pencatatan pembayaran.
Sumber data
Dicatat sebagai pembalikan transaksi di buku besar. Jurnal yang dibalik dapat ditemukan di GeneralJournalEntry, biasanya melalui penanda khusus atau kaitannya dengan transaksi asli.
Pengumpulan data
Temukan entri jurnal dengan penanda pembalikan atau referensi ke transaksi yang dibalik.
Jenis peristiwa
explicit
|
|||
|
Pengingat pembayaran dikirim
|
Menunjukkan pengiriman surat penagihan atau pemberitahuan penagihan kepada pelanggan terkait faktur yang telah jatuh tempo. Dynamics 365 memiliki proses penagihan resmi yang membuat dan mencatat komunikasi ini. | ||
|
Mengapa ini penting
Dengan melacak pengingat, Anda dapat menilai efektivitas proses penagihan dan menganalisis jumlah pengingat yang diperlukan sebelum pembayaran diterima.
Sumber data
Kejadian ini dicatat secara eksplisit berdasarkan tanggal pembuatan jurnal surat penagihan di tabel CustCollectionLetterJour, yang terhubung dengan transaksi faktur yang telah jatuh tempo.
Pengumpulan data
Gunakan stempel waktu pembuatan dari tabel CustCollectionLetterJour.
Jenis peristiwa
explicit
|
|||
|
Pesanan penjualan dipenuhi
|
Aktivitas ini menandai saat barang untuk pesanan penjualan dikirim atau layanan diberikan, sehingga proses penagihan dapat dimulai. Di Microsoft Dynamics 365, aktivitas ini biasanya disimpulkan dari pencatatan slip pengepakan atau nota pengiriman, yang mengubah status baris pesanan penjualan terkait. | ||
|
Mengapa ini penting
Kejadian ini menjadi titik awal untuk mengukur waktu siklus pembuatan faktur. Dengan memahami jeda antara pemenuhan pesanan dan pembuatan faktur, Anda dapat menemukan hambatan administratif yang berdampak pada arus kas.
Sumber data
Disimpulkan dari tanggal pembuatan entri jurnal slip pengepakan yang terkait dengan pesanan penjualan. Data ini melibatkan tabel seperti CustPackingSlipJour dan CustPackingSlipTrans, yang terhubung dengan pesanan penjualan yang menjadi dasar faktur.
Pengumpulan data
Temukan tanggal pencatatan slip pengepakan terbaru untuk pesanan penjualan yang terkait dengan faktur.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi data
Siap memulai?
Gunakan templat ini untuk mulai mengoptimalkan penagihan dan pembuatan faktur. Bekali tim Anda dengan wawasan yang dibutuhkan untuk meningkatkan efisiensi dan memperbaiki arus kas.
Atasi keterlambatan penagihan: optimalkan Order to Cash dan pembuatan faktur sekarang
Pangkas waktu siklus penagihan hingga 30% dan dapatkan gambaran keuangan yang lebih jelas dengan lebih cepat.
Tidak perlu kartu kredit. Uji coba gratis selama 14 hari.