Templat data entri jurnal untuk proses pencatatan hingga pelaporan
Templat data entri jurnal untuk proses pencatatan hingga pelaporan
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi untuk Microsoft Dynamics 365
Atribut Record to Report - Journal Entry
| Nama | Deskripsi | ||
|---|---|---|---|
|
Journal Entry ID
JournalEntryId
|
Pengenal unik untuk Journal Entry yang berfungsi sebagai ID kasus utama. | ||
|
Deskripsi
Journal Entry ID menghubungkan semua aktivitas dan titik data yang terkait dengan satu transaksi Journal Entry. ID ini memungkinkan Anda melacak seluruh siklus jurnal, mulai dari pembuatan dan peninjauan hingga posting akhir ke buku besar. Dalam analisis process mining, atribut ini menjadi dasar untuk menyusun kembali alur proses. Setiap Journal Entry ID unik mewakili satu kasus proses. Dengan begitu, Anda dapat memeriksa variasi proses, waktu siklus, dan kepatuhan untuk setiap transaksi keuangan secara terperinci.
Mengapa ini penting
Kunci penting untuk melacak Journal Entry dari awal hingga akhir dan menganalisis seluruh alur proses untuk setiap kasus.
Sumber data
Pengenal ini biasanya terdapat di tabel header jurnal, seperti LedgerJournalTable, sering kali pada kolom bernama JournalNum.
Contoh
JRN-0012345JV-2023-08-156GENJ0000891
|
|||
|
Nama aktivitas
ActivityName
|
Nama langkah atau peristiwa tertentu dalam proses bisnis yang terjadi. | ||
|
Deskripsi
Atribut ini menjelaskan satu peristiwa atau tugas dalam siklus Journal Entry, seperti 'Journal Entry dibuat', 'Jurnal diajukan untuk persetujuan', atau 'Journal Entry diposting'. Aktivitas ini menjadi simpul dalam peta proses yang ditemukan. Menganalisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini menunjukkan alur proses yang sebenarnya, membantu menemukan penyimpangan dari prosedur standar, dan menyoroti hambatan saat aktivitas memakan waktu lebih lama dari perkiraan atau harus diulang.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam proses. Langkah tersebut membentuk dasar peta proses dan memungkinkan analisis alur serta variasi proses.
Sumber data
Atribut konseptual ini berasal dari peristiwa sistem, perubahan status, atau log workflow di Microsoft Dynamics 365.
Contoh
Journal Entry dibuatJurnal diajukan untuk persetujuanJurnal disetujuiJournal Entry diposting
|
|||
|
Waktu peristiwa
EventTime
|
Stempel waktu yang menunjukkan secara tepat kapan aktivitas atau peristiwa terjadi. | ||
|
Deskripsi
Waktu peristiwa mencatat tanggal dan waktu saat aktivitas tertentu dalam proses Journal Entry berlangsung. Data kronologis ini penting untuk mengurutkan peristiwa dan menghitung jeda waktu di antaranya. Dalam analisis, stempel waktu ini digunakan untuk menyusun linimasa setiap kasus. Linimasa tersebut penting untuk menghitung semua metrik berbasis waktu, seperti waktu siklus, waktu pemrosesan, dan waktu tunggu. Data ini membantu menemukan keterlambatan antar langkah serta mendukung dashboard untuk menganalisis hambatan dan kepatuhan terhadap SLA.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menghitung semua KPI berbasis durasi, seperti waktu siklus dan keterlambatan pemrosesan.
Sumber data
Stempel waktu peristiwa biasanya terdapat di log riwayat workflow, tabel jejak audit seperti SysDatabaseLog, atau kolom waktu pembuatan dan perubahan pada data terkait, seperti LedgerJournalTable dan LedgerJournalTrans.
Contoh
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
|
|||
|
Alasan penolakan
RejectionReason
|
Alasan yang diberikan saat entri jurnal ditolak dalam proses persetujuan. | ||
|
Deskripsi
Saat entri jurnal ditolak, pemberi persetujuan biasanya menyertakan alasan. Atribut ini mencatat informasi tersebut, yang sangat berguna untuk analisis akar masalah. Atribut ini menjadi dasar dashboard 'Analisis tingkat penolakan entri jurnal'. Dengan mengelompokkan dan menganalisis alasan penolakan, organisasi dapat menemukan masalah yang sering terjadi, seperti dokumen pendukung yang tidak tepat, pelanggaran kebijakan, atau kesalahan entri data. Selanjutnya, organisasi dapat memberikan pelatihan yang sesuai atau memperbaiki proses.
Mengapa ini penting
Menjelaskan penyebab pengerjaan ulang dan memberi informasi langsung untuk mengurangi penolakan serta meningkatkan persetujuan yang benar sejak pengajuan pertama.
Sumber data
Informasi ini biasanya tersimpan dalam riwayat workflow atau bagian komentar pada langkah penolakan.
Contoh
Dokumen pendukung tidak memadaiAkun yang digunakan salahMelebihi batas persetujuanEntri duplikat
|
|||
|
Entitas hukum
LegalEntity
|
Entitas hukum atau kode perusahaan tempat entri jurnal dicatat. | ||
|
Deskripsi
Entitas hukum menunjukkan perusahaan atau unit bisnis tertentu dalam organisasi tempat transaksi keuangan dicatat. Ini merupakan dimensi organisasi yang mendasar dalam sistem keuangan. Dalam process mining, atribut ini memungkinkan Anda membandingkan proses entri jurnal di berbagai bagian organisasi. Anda dapat mengetahui apakah entitas hukum tertentu memiliki proses yang lebih efisien, tingkat penolakan lebih tinggi, atau waktu siklus lebih lama. Temuan ini membantu mengidentifikasi dan membagikan praktik terbaik.
Mengapa ini penting
Memungkinkan Anda membandingkan kinerja proses antarperusahaan atau unit bisnis, serta melihat perbedaan dan peluang perbaikan.
Sumber data
Kolom inti di Dynamics 365 ini biasanya tersedia di tabel transaksi seperti LedgerJournalTable dan umumnya terkait dengan DataAreaId.
Contoh
USMFDEMFGBSI
|
|||
|
Jenis jurnal
JournalType
|
Klasifikasi Journal Entry, seperti General Journal atau Accrual. | ||
|
Deskripsi
Jenis jurnal mengelompokkan entri berdasarkan tujuan bisnisnya, misalnya entri harian, akrual, alokasi, atau eliminasi. Pengelompokan ini penting untuk memahami perbedaan jalur dan perilaku proses. Atribut ini memungkinkan Anda memfilter dan membandingkan proses berdasarkan jenis jurnal. Atribut ini penting untuk dashboard 'Volume pemrosesan Journal Entry berdasarkan jenis', yang membantu menganalisis apakah jenis jurnal tertentu lebih sering mengalami keterlambatan, penolakan, atau pengerjaan ulang.
Mengapa ini penting
Memungkinkan Anda mengelompokkan analisis untuk membandingkan proses berdasarkan tujuan bisnis yang berbeda. Setiap tujuan mungkin memiliki jalur, waktu siklus, dan persyaratan persetujuan tersendiri.
Sumber data
Informasi ini biasanya tersimpan di tabel header jurnal LedgerJournalTable, pada kolom yang terkait dengan nama atau jenis jurnal, misalnya JournalName.
Contoh
Jurnal umumPenyesuaian akrualTransfer antarperusahaanPenggajian
|
|||
|
Nama pengguna
UserName
|
Nama pengguna yang menjalankan aktivitas. | ||
|
Deskripsi
Atribut ini menunjukkan karyawan atau pengguna sistem yang bertanggung jawab menjalankan aktivitas tertentu, seperti membuat, menyetujui, atau memposting Journal Entry. Atribut ini menghubungkan langkah proses dengan sumber daya manusia. Menganalisis kinerja berdasarkan pengguna merupakan kemampuan penting dalam process mining. Analisis ini membantu membuat dashboard 'Kinerja pengguna Journal Entry' untuk membandingkan durasi aktivitas dan jumlah pekerjaan yang diselesaikan oleh pengguna atau tim. Hasilnya dapat menunjukkan pengguna berkinerja tinggi, kebutuhan pelatihan, dan peluang untuk menyeimbangkan beban kerja.
Mengapa ini penting
Menghubungkan aktivitas proses dengan orang tertentu agar Anda dapat menganalisis kinerja pengguna, pembagian beban kerja, dan alokasi sumber daya.
Sumber data
Informasi pengguna biasanya terdapat di kolom createdBy atau modifiedBy pada tabel seperti LedgerJournalTable, atau di log riwayat workflow terkait.
Contoh
Alice SmithBob Johnsonsystem.batch
|
|||
|
Status jurnal
JournalStatus
|
Status jurnal saat ini atau status akhirnya. | ||
|
Deskripsi
Atribut ini menunjukkan status entri jurnal pada waktu tertentu, seperti 'Draf', 'Dalam peninjauan', 'Disetujui', 'Ditolak', atau 'Dibukukan'. Status ini menunjukkan posisi entri dalam siklusnya. Analisis status membantu Anda memahami hasil setiap kasus. Anda dapat memfilter jurnal yang ditolak atau melacak jumlah jurnal pada tahap tertentu. Atribut ini juga memberi konteks untuk analisis throughput dan status di berbagai dashboard.
Mengapa ini penting
Menunjukkan hasil setiap entri jurnal sehingga Anda dapat menganalisis tingkat keberhasilan, tingkat penolakan, dan volume pekerjaan pada tiap tahap.
Sumber data
Status biasanya tercatat di tabel header jurnal, LedgerJournalTable, atau diturunkan dari status workflow.
Contoh
DrafDiajukanDisetujuiDibukukanDitolak
|
|||
|
Total nilai jurnal
JournalTotalAmount
|
Nilai total entri jurnal, biasanya berupa jumlah debit. | ||
|
Deskripsi
Atribut ini menunjukkan nilai keuangan total entri jurnal. Anda dapat mengelompokkan entri berdasarkan rentang nilai, misalnya rendah, sedang, dan tinggi. Analisis proses berdasarkan nilai keuangan dapat mengungkap pola penting. Misalnya, entri jurnal bernilai tinggi mungkin memerlukan proses persetujuan yang lebih ketat, dengan lebih banyak langkah dan waktu siklus yang lebih lama. Atribut ini penting untuk analisis materialitas dan untuk memahami dampak keuangan dari inefisiensi proses.
Mengapa ini penting
Memungkinkan Anda mengelompokkan proses berdasarkan nilai keuangan, yang sering berkaitan dengan kompleksitas proses, risiko, dan alur persetujuan.
Sumber data
Nilai ini mungkin perlu dihitung dengan menjumlahkan nilai debit dari tabel baris jurnal, LedgerJournalTrans, untuk setiap entri jurnal.
Contoh
1500.75125000.0050.25
|
|||
|
Waktu akhir peristiwa
EventEndTime
|
Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa selesai. | ||
|
Deskripsi
Waktu akhir peristiwa menandai selesainya aktivitas tertentu. StartTime menunjukkan kapan peristiwa dimulai, sedangkan EndTime menunjukkan batas akhirnya. Keduanya memungkinkan penghitungan durasi tugas secara akurat. Dalam process mining, waktu mulai dan waktu akhir memungkinkan Anda menghitung waktu pemrosesan aktivitas, yang berbeda dari waktu tunggu. Informasi ini penting untuk dashboard yang menganalisis kinerja pengguna dan menemukan tugas tertentu yang paling banyak menyita waktu, bukan hanya jeda antar tugas.
Mengapa ini penting
Memungkinkan penghitungan durasi setiap aktivitas secara akurat. Informasi ini penting untuk menganalisis kinerja pengguna dan menemukan tugas yang paling banyak menyita sumber daya.
Sumber data
Data ini mungkin tersimpan secara eksplisit di log workflow atau perlu dihitung menggunakan StartTime aktivitas berikutnya dalam urutan.
Contoh
2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Benar sejak pengajuan pertama
IsFirstTimeRight
|
Penanda yang menunjukkan apakah jurnal disetujui tanpa pernah ditolak sebelumnya. | ||
|
Deskripsi
Atribut boolean pada tingkat kasus ini bernilai true jika entri jurnal beralih dari pengajuan ke persetujuan tanpa aktivitas 'Jurnal ditolak' atau 'Entri jurnal dikoreksi' di antaranya. Atribut ini menjadi ukuran penting kualitas proses. KPI 'Tingkat persetujuan benar sejak pengajuan pertama' dihitung langsung dari atribut ini. Tingkat yang tinggi menunjukkan proses yang efisien dan berkualitas. Tingkat yang rendah menandakan masalah sistemis pada kualitas data awal, kejelasan persyaratan, atau prosedur pengajuan.
Mengapa ini penting
Ukuran penting kualitas proses ini menunjukkan jumlah jurnal yang melewati proses persetujuan dengan lancar tanpa pengerjaan ulang.
Sumber data
Atribut ini dihitung pada tingkat kasus dengan menganalisis urutan aktivitas untuk setiap ID Entri Jurnal.
Contoh
truefalse
|
|||
|
Departemen
DepartmentName
|
Departemen atau pusat biaya yang terkait dengan entri jurnal. | ||
|
Deskripsi
Departemen atau pusat biaya menunjukkan unit bisnis internal yang bertanggung jawab atas atau terdampak oleh transaksi keuangan. Ini merupakan dimensi penting untuk pelaporan manajemen internal. Atribut ini memungkinkan Anda menganalisis proses entri jurnal berdasarkan departemen. Anda dapat menjawab pertanyaan seperti: Departemen mana yang paling banyak mengajukan jurnal? Apakah departemen tertentu memiliki tingkat penolakan lebih tinggi atau waktu persetujuan lebih lama? Informasi ini berguna untuk menentukan perbaikan proses yang tepat sasaran.
Mengapa ini penting
Memungkinkan analisis kinerja proses berdasarkan fungsi bisnis, sehingga Anda dapat menemukan hambatan khusus di departemen atau kebutuhan pelatihan.
Sumber data
Informasi ini biasanya tersedia pada tingkat baris jurnal (LedgerJournalTrans) sebagai dimensi keuangan.
Contoh
PenjualanKeuanganPemasaranOperasional
|
|||
|
Dibukukan otomatis
IsAutomatedPosting
|
Penanda yang menunjukkan apakah entri jurnal dibuat atau dibukukan secara otomatis. | ||
|
Deskripsi
Atribut boolean ini membedakan entri jurnal yang dibuat secara manual oleh pengguna dari entri yang dibuat otomatis oleh sistem atau subsistem, misalnya melalui integrasi sistem atau proses alokasi otomatis. Analisis atribut ini membantu membandingkan efisiensi dan tingkat kesalahan proses otomatis dengan proses manual. Anda dapat melihat peluang otomatisasi lebih lanjut, misalnya jika entri manual lebih sering mengalami kesalahan, pengerjaan ulang, atau keterlambatan.
Mengapa ini penting
Membedakan proses manual dan otomatis agar Anda dapat membandingkan efisiensi, akurasi, dan kepatuhannya.
Sumber data
Informasi ini dapat ditunjukkan oleh pengguna di kolom 'Created by' (misalnya pengguna sistem atau batch) atau penanda khusus pada header jurnal maupun konfigurasi jenis jurnal.
Contoh
truefalse
|
|||
|
Kode mata uang
CurrencyCode
|
Mata uang yang digunakan untuk nilai entri jurnal. | ||
|
Deskripsi
Atribut ini menunjukkan mata uang yang digunakan dalam entri jurnal, seperti USD, EUR, atau GBP. Informasi ini memberi konteks penting untuk total nilai jurnal. Mata uang mungkin tidak selalu digunakan untuk menganalisis alur proses, tetapi penting untuk pelaporan atau analisis keuangan berdasarkan nilai jurnal. Atribut ini membantu menjumlahkan dan membandingkan nilai dengan tepat, terutama di organisasi multinasional.
Mengapa ini penting
Memberi konteks yang diperlukan untuk analisis keuangan agar nilai uang ditafsirkan dengan benar, terutama saat menggunakan beberapa mata uang.
Sumber data
Kode mata uang biasanya tersedia di tabel baris jurnal, LedgerJournalTrans.
Contoh
USDEURGBPJPY
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu saat data terakhir diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini menunjukkan tanggal dan waktu ekstraksi data terbaru dari sistem sumber. Informasi ini memberi konteks tentang kebaruan analisis dan data yang disertakan. Dengan menampilkan informasi ini di dashboard, pengguna dapat mengetahui apakah data masih terkini dan memahami rentang waktu yang dicakup analisis proses saat ini. Ini adalah metadata penting dalam setiap proyek process mining.
Mengapa ini penting
Memberi konteks penting tentang kebaruan data agar pengguna memahami seberapa terkini analisis proses yang ditampilkan.
Sumber data
Stempel waktu ini dibuat dan disimpan selama proses ekstraksi, transformasi, dan pemuatan data (ETL).
Contoh
2023-10-27T02:00:00Z
|
|||
|
Pengerjaan ulang
IsRework
|
Penanda untuk mengidentifikasi aktivitas yang termasuk dalam siklus pengerjaan ulang atau koreksi. | ||
|
Deskripsi
Atribut boolean hasil perhitungan ini bernilai true untuk aktivitas yang terjadi setelah penolakan, seperti 'Entri jurnal dikoreksi' atau pengajuan ulang 'Jurnal diajukan untuk persetujuan'. Atribut ini membantu memisahkan dan mengukur pengerjaan ulang. Atribut ini penting untuk dashboard 'Siklus pengerjaan ulang dan koreksi entri jurnal' serta KPI 'Tingkat pengerjaan ulang'. Dengan menandai pengerjaan ulang, Anda dapat melihat dan mengukur frekuensi serta dampak siklus koreksi. Siklus ini merupakan salah satu sumber utama inefisiensi proses.
Mengapa ini penting
Menandai siklus pengerjaan ulang yang tidak efisien secara langsung, sehingga dampak penolakan dan koreksi terhadap waktu siklus dan biaya dapat diukur dengan mudah.
Sumber data
Atribut ini dihitung saat transformasi data dengan menganalisis urutan aktivitas dalam suatu kasus.
Contoh
truefalse
|
|||
|
Sistem sumber
SourceSystem
|
Sistem pencatatan asal data yang diekstrak. | ||
|
Deskripsi
Atribut ini menunjukkan aplikasi sumber tempat data Journal Entry berasal. Untuk proses ini, nilainya biasanya tetap, misalnya 'Microsoft Dynamics 365'. Dalam analisis yang lebih luas, terutama di lingkungan dengan beberapa ERP atau sistem terintegrasi, kolom ini membantu membedakan proses dan sumber data. Kolom ini memperjelas asal data serta penting untuk tata kelola dan validasi data.
Mengapa ini penting
Menunjukkan asal data. Informasi ini penting untuk tata kelola data dan analisis yang mencakup beberapa sistem perusahaan.
Sumber data
Nilai statis ini ditambahkan saat proses ekstraksi, transformasi, dan pemuatan data (ETL) untuk menandai asal kumpulan data.
Contoh
Microsoft Dynamics 365D365 F&O
|
|||
|
Status SLA persetujuan
ApprovalSlaState
|
Menunjukkan apakah persetujuan entri jurnal memenuhi service level agreement. | ||
|
Deskripsi
Atribut ini mengelompokkan siklus persetujuan setiap entri jurnal berdasarkan apakah proses selesai dalam batas waktu yang ditetapkan oleh Service Level Agreement (SLA). Nilai yang umum digunakan adalah 'Terpenuhi' atau 'Terlewati'. Atribut ini menjadi metrik utama untuk dashboard 'Kepatuhan SLA persetujuan entri jurnal'. Atribut ini menunjukkan kinerja terhadap target dalam istilah yang mudah dipahami bisnis. Anda dapat memantau ketepatan waktu proses persetujuan dan menentukan perbaikan saat SLA sering tidak tercapai.
Mengapa ini penting
Mengubah data waktu siklus menjadi hasil bisnis yang jelas, yaitu terpenuhi atau terlewati, sehingga kinerja terhadap target utama mudah dipantau.
Sumber data
Atribut ini dihitung dengan membandingkan KPI Waktu siklus persetujuan dengan target SLA yang telah ditentukan.
Contoh
TerpenuhiTerlewati
|
|||
|
Tanggal pembukuan
PostingDate
|
Tanggal entri jurnal dibukukan ke buku besar. | ||
|
Deskripsi
Tanggal pembukuan adalah tanggal resmi saat transaksi memengaruhi saldo buku besar. Tanggal ini penting untuk pelaporan keuangan dan penutupan periode. Atribut ini digunakan untuk menganalisis jeda antara persetujuan dan pembukuan, yang menjadi fokus KPI 'Waktu tunggu pembukuan entri jurnal'. Mengurangi jeda ini sering menjadi sasaran utama untuk mempercepat proses penutupan keuangan. Atribut ini juga dapat digunakan untuk menganalisis volume pembukuan dari waktu ke waktu.
Mengapa ini penting
Penting untuk menghitung KPI waktu tunggu pembukuan dan memahami keterlambatan antara persetujuan dan saat transaksi resmi tercatat di buku besar.
Sumber data
Tanggal ini biasanya tersimpan di tabel header jurnal (LedgerJournalTable) atau tabel transaksi terkait yang sudah dibukukan.
Contoh
2023-10-282023-11-012023-10-31
|
|||
|
Tingkat persetujuan
ApprovalLevel
|
Menunjukkan tahap saat ini atau tahap yang telah diselesaikan dalam workflow persetujuan bertingkat. | ||
|
Deskripsi
Untuk entri jurnal yang memerlukan beberapa persetujuan, atribut ini melacak tingkat yang telah dicapai, misalnya 'Persetujuan manajer' atau 'Persetujuan direktur'. Atribut ini membantu menganalisis hambatan persetujuan secara lebih terperinci. Anda dapat mengetahui apakah keterlambatan terus terjadi pada tingkat tertentu dalam rangkaian persetujuan. Temuan ini dapat menunjukkan perlunya merancang ulang proses atau mengalokasikan ulang sumber daya pada tahap tersebut.
Mengapa ini penting
Menunjukkan proses persetujuan bertahap dan membantu menemukan hambatan pada tingkat persetujuan tertentu.
Sumber data
Informasi ini dapat diturunkan dari log riwayat workflow yang mencatat penyelesaian setiap langkah persetujuan.
Contoh
Tingkat 1: ManajerTingkat 2: DirekturTingkat 3: Wakil presiden bidang keuangan
|
|||
Aktivitas Record to Report - Journal Entry
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Journal Entry dibuat
|
Aktivitas ini menandai dimulainya Journal Entry baru. Aktivitas tercatat saat pengguna membuat data header jurnal baru di sistem. Sistem lalu menetapkan Journal Entry ID unik sebagai ID kasus untuk analisis proses. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses. Mengukur waktu dari tahap ini hingga posting penting untuk menghitung waktu siklus dari awal hingga akhir dan menemukan keterlambatan saat memasukkan data.
Sumber data
Peristiwa ini diambil dari stempel waktu pembuatan header jurnal pada entitas GeneralJournalEntry atau LedgerJournalTable. Biasanya, peristiwa ini tercatat secara eksplisit saat data dibuat.
Pengumpulan data
Gunakan kolom 'createdDateTime' pada GeneralJournalEntry atau LedgerJournalTable.
Jenis peristiwa
explicit
|
|||
|
Journal Entry diposting
|
Aktivitas ini menandai keberhasilan posting Journal Entry ke buku besar, sehingga jurnal menjadi catatan keuangan resmi. Ini adalah peristiwa penting yang tercatat saat status header jurnal berubah menjadi 'Posted'. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir utama yang menandai keberhasilan proses. Peristiwa ini digunakan untuk menghitung waktu siklus dari awal hingga akhir dan waktu tunggu posting, yang menjadi indikator utama efisiensi tutup buku keuangan.
Sumber data
Diambil dari perubahan kolom status, misalnya JournalStatus berubah menjadi 'Posted' pada LedgerJournalTable, serta pembuatan data terkait di tabel GeneralJournalAccountEntry.
Pengumpulan data
Temukan stempel waktu saat status jurnal berubah menjadi 'Posted'.
Jenis peristiwa
inferred
|
|||
|
Jurnal diajukan untuk persetujuan
|
Menandai pengajuan resmi Journal Entry yang telah selesai ke alur kerja peninjauan dan persetujuan. Peristiwa ini biasanya disimpulkan dari perubahan status pada header jurnal, misalnya dari 'Draft' menjadi 'In Review' atau 'Submitted'. | ||
|
Mengapa ini penting
Ini adalah tahap penting yang memulai siklus persetujuan. Mengukur waktu dari pengajuan hingga persetujuan akhir penting untuk menemukan hambatan dalam proses peninjauan dan memantau kepatuhan terhadap SLA.
Sumber data
Disimpulkan dari perubahan kolom status, misalnya ApprovalStatus berubah menjadi 'InReview' pada LedgerJournalTable, atau dari log riwayat workflow yang terkait dengan jurnal.
Pengumpulan data
Temukan stempel waktu saat status jurnal berubah menjadi 'submitted' atau 'in review'.
Jenis peristiwa
inferred
|
|||
|
Jurnal disetujui
|
Pihak berwenang yang ditunjuk telah menyetujui Journal Entry, sehingga tahap akhir dalam alur kerja persetujuan selesai. Peristiwa ini biasanya tercatat saat status header jurnal berubah menjadi 'Approved'. | ||
|
Mengapa ini penting
Ini adalah tahap penting yang mengakhiri proses persetujuan dan memungkinkan jurnal diposting. Data ini diperlukan untuk menghitung waktu siklus persetujuan, waktu tunggu posting, dan tingkat benar sejak pertama kali.
Sumber data
Disimpulkan dari perubahan kolom status, misalnya ApprovalStatus berubah menjadi 'Approved' pada LedgerJournalTable, atau dari tabel riwayat workflow yang menunjukkan status persetujuan akhir.
Pengumpulan data
Temukan stempel waktu saat status jurnal berubah menjadi 'Approved'.
Jenis peristiwa
inferred
|
|||
|
Jurnal ditolak
|
Peninjau atau pemberi persetujuan menolak Journal Entry sehingga perlu diperbaiki. Peristiwa ini tercatat saat status jurnal berubah, misalnya menjadi 'Rejected' atau 'Needs Correction'. | ||
|
Mengapa ini penting
Melacak penolakan penting untuk menghitung tingkat penolakan dan menemukan penyebab utama pengerjaan ulang. Data ini dapat menunjukkan masalah kualitas data, kepatuhan, atau pelatihan pengguna.
Sumber data
Disimpulkan dari perubahan kolom status, misalnya ApprovalStatus berubah menjadi 'Rejected' pada LedgerJournalTable, atau dari log riwayat workflow.
Pengumpulan data
Temukan stempel waktu saat status jurnal berubah menjadi 'Rejected'.
Jenis peristiwa
inferred
|
|||
|
Baris jurnal ditambahkan
|
Peristiwa ini menandakan bahwa baris debit atau kredit telah ditambahkan ke Journal Entry. Peristiwa tercatat setiap kali baris transaksi baru dibuat dan dikaitkan dengan header jurnal. | ||
|
Mengapa ini penting
Melacak pembuatan setiap baris membantu memahami kerumitan dan upaya memasukkan data untuk berbagai jenis jurnal. Data ini juga dapat menunjukkan keterlambatan antara pembuatan header dan penyelesaian baris.
Sumber data
Diambil dari stempel waktu pembuatan data di entitas LedgerJournalTrans yang terhubung ke header jurnal. Pembuatan setiap baris tercatat sebagai peristiwa tersendiri.
Pengumpulan data
Gunakan kolom 'createdDateTime' untuk setiap data di tabel LedgerJournalTrans.
Jenis peristiwa
explicit
|
|||
|
Journal Entry dibalik
|
Menandai selesainya proses pembalikan Journal Entry, saat jurnal pembalik berhasil diposting. Peristiwa ini menjadi titik akhir alternatif dalam siklus jurnal yang keliru. | ||
|
Mengapa ini penting
Aktivitas ini menandai penyelesaian koreksi jurnal dan membantu menganalisis total upaya untuk penyesuaian setelah posting, yang memengaruhi efisiensi proses secara keseluruhan.
Sumber data
Tercatat saat jurnal pembalik baru berubah status menjadi 'Posted'. Jurnal asli tetap terhubung melalui kolom referensi.
Pengumpulan data
Temukan peristiwa status 'Posted' untuk Journal Entry pembalik yang terkait.
Jenis peristiwa
inferred
|
|||
|
Journal Entry diperbaiki
|
Aktivitas ini menunjukkan bahwa pengguna telah mengubah Journal Entry yang sebelumnya ditolak. Peristiwa ini biasanya disimpulkan dengan mendeteksi perubahan pada header atau baris jurnal setelah status 'Rejected' tercatat. | ||
|
Mengapa ini penting
Aktivitas ini menunjukkan pengerjaan ulang secara langsung. Menganalisis frekuensi dan durasi siklus koreksi membantu menyederhanakan proses dan mengurangi pekerjaan manual.
Sumber data
Disimpulkan dengan melacak kolom 'modifiedDateTime' dan 'modifiedBy' pada tabel LedgerJournalTable atau LedgerJournalTrans setelah peristiwa 'Journal Rejected' terjadi.
Pengumpulan data
Bandingkan stempel waktu perubahan status menjadi 'Rejected' dengan stempel waktu perubahan berikutnya oleh pembuat jurnal.
Jenis peristiwa
inferred
|
|||
|
Jurnal diajukan ulang untuk persetujuan
|
Journal Entry yang telah diperbaiki dikirim kembali ke alur kerja persetujuan untuk ditinjau ulang. Peristiwa ini disimpulkan dari perubahan status dari 'Rejected' atau 'Draft' kembali menjadi 'In Review' atau 'Submitted'. | ||
|
Mengapa ini penting
Aktivitas ini menandai dimulainya siklus pengerjaan ulang. Menghitung peristiwa ini membantu mengukur tingkat pengerjaan ulang dan rata-rata jumlah siklus persetujuan untuk setiap Journal Entry.
Sumber data
Disimpulkan dari riwayat workflow atau dengan melacak perubahan status pada LedgerJournalTable saat status berubah dari ditolak kembali menjadi diajukan.
Pengumpulan data
Temukan peristiwa status 'Submitted' yang terjadi setelah peristiwa status 'Rejected' untuk jurnal yang sama.
Jenis peristiwa
inferred
|
|||
|
Pembalikan Journal Entry dimulai
|
Peristiwa ini menandai dimulainya proses pembalikan Journal Entry yang sebelumnya telah diposting. Peristiwa tercatat saat pengguna memulai tindakan pembalikan di sistem. | ||
|
Mengapa ini penting
Melacak pembalikan membantu menemukan frekuensi dan alasan koreksi atas jurnal yang telah diposting. Data ini dapat menunjukkan masalah mendasar pada tahap awal pemasukan data atau persetujuan.
Sumber data
Biasanya, ini adalah tindakan pengguna yang tercatat secara eksplisit di jejak audit atau dapat diketahui dari pembuatan jurnal pembalik baru yang terhubung ke jurnal asli.
Pengumpulan data
Gunakan peristiwa pembuatan Journal Entry baru yang ditandai sebagai pembalik jurnal yang telah diposting.
Jenis peristiwa
explicit
|
|||
|
Peninjauan jurnal dimulai
|
Aktivitas ini menandai saat peninjau mulai menangani jurnal yang telah diajukan. Peristiwa dapat disimpulkan saat jurnal ditugaskan kepada peninjau atau saat peninjau pertama kali membuka data untuk diperiksa. | ||
|
Mengapa ini penting
Aktivitas ini membantu mengukur waktu serah terima kepada peninjau, yaitu jeda antara pengajuan dan dimulainya peninjauan. Data ini dapat mengungkap masalah alokasi sumber daya atau notifikasi.
Sumber data
Peristiwa ini sering kali tidak dicatat secara eksplisit. Peristiwa dapat disimpulkan dari log penugasan workflow atau dengan membandingkan stempel waktu pengajuan dengan stempel waktu perubahan pertama oleh pengguna yang bertindak sebagai peninjau.
Pengumpulan data
Perlu menganalisis log penugasan pengguna workflow atau log aktivitas pengguna, yang mungkin tidak tersedia secara standar.
Jenis peristiwa
inferred
|
|||
|
Posting jurnal dicoba
|
Aktivitas ini menandakan bahwa pengguna telah memulai proses posting untuk jurnal yang disetujui. Peristiwa ini mungkin tercatat secara eksplisit jika sistem mencatat dimulainya tugas posting. | ||
|
Mengapa ini penting
Membedakan upaya posting dari posting yang berhasil dapat membantu mendiagnosis masalah kinerja sistem atau keterlambatan tugas batch yang memengaruhi tutup buku keuangan.
Sumber data
Peristiwa ini mungkin tercatat secara eksplisit di tabel riwayat tugas batch atau disimpulkan dari perubahan status LedgerJournalTable menjadi 'Posting in progress'.
Pengumpulan data
Perlu menganalisis log tugas batch atau log sistem yang terkait dengan proses posting General Ledger.
Jenis peristiwa
explicit
|
|||
Panduan ekstraksi
Siap memulai?
Template ini menyediakan semua yang Anda perlukan untuk mulai meningkatkan proses Record to Report - Journal Entry. Manfaatkan data Anda untuk meningkatkan efisiensi dan mempercepat siklus pelaporan keuangan.
Tingkatkan proses Journal Entry di Dynamics 365 dan percepat pelaporan
Atasi hambatan dan kurangi waktu siklus Journal Entry R2R hingga 30%.
Tidak perlu kartu kredit. Mulai dalam hitungan menit.