> Perbaikan proses berkelanjutan > Pencatatan hingga pelaporan, entri jurnal > Workiva > Templat data

Templat Data Record to Report - Entri Jurnal Anda

Workiva

Atribut Record to Report - Entri Jurnal(18) Aktivitas Record to Report - Entri Jurnal(14) Panduan Ekstraksi(1)

Templat Data Record to Report - Entri Jurnal Anda

Templat ini memandu Anda mengumpulkan data yang diperlukan untuk menganalisis proses Record to Report - Entri Jurnal. Templat ini menjelaskan kolom data penting, langkah proses yang perlu dilacak, serta cara praktis mengambil data tersebut dari Workiva. Gunakan templat ini untuk menyiapkan data yang dibutuhkan dalam analisis process mining.

Atribut yang disarankan untuk dikumpulkan
Aktivitas utama yang perlu dilacak
Panduan praktis untuk mengekstrak data

Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Unduh template

Atribut Record to Report - Entri Jurnal

Berikut kolom data yang disarankan untuk disertakan dalam log peristiwa agar proses Record to Report - Entri Jurnal dapat dianalisis dengan baik.

5 Wajib 5 Disarankan 8 Opsional

	Nama	Deskripsi
	Aktivitas ActivityName	Nama langkah proses atau peristiwa tertentu yang terjadi pada entri jurnal.
Deskripsi Atribut ini menjelaskan aktivitas yang dilakukan pada tahap tertentu dalam siklus hidup entri jurnal. Atribut ini mencatat tonggak penting, seperti 'Journal Entry Created', 'Journal Entry Submitted for Review', 'Journal Entry Approved', dan 'Journal Entry Posted to GL'. Analisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan alur proses, menemukan jalur yang umum maupun jarang terjadi (variasi), serta menunjukkan hambatan yang membuat entri menghabiskan waktu paling lama. Atribut ini juga digunakan untuk menentukan titik awal dan akhir dalam penghitungan KPI, seperti waktu siklus persetujuan. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam proses, sehingga alur kerja entri jurnal dapat divisualisasikan dan dianalisis serta hambatan dapat ditemukan. Sumber data Biasanya diperoleh dari log peristiwa atau catatan perubahan status di Workiva. Anda mungkin perlu memetakan kolom yang tepat dari kode status atau deskripsi peristiwa di sistem. Contoh Journal Entry dibuatJournal Entry diajukan untuk ditinjauEntri jurnal disetujuiEntri jurnal dibukukan ke GL
	ID Entri Jurnal JournalEntryId	Pengenal unik untuk satu entri jurnal, yang digunakan sebagai pengenal kasus utama dalam analisis proses.
Deskripsi ID Entri Jurnal melacak semua aktivitas dan peristiwa yang terkait dengan rangkaian transaksi keuangan tertentu, mulai dari pembuatan hingga pembukuan dan rekonsiliasi akhir. ID ini menghubungkan setiap tahap, seperti pembuatan, pengajuan, peninjauan, persetujuan, dan pembukuan, menjadi satu rangkaian proses. Dalam process mining, atribut ini menjadi dasar untuk merekonstruksi perjalanan setiap entri jurnal dari awal hingga akhir. Anda dapat menganalisis variasi proses, waktu siklus, dan proses pengerjaan ulang untuk setiap entri, serta melihat dengan jelas alur masing-masing entri di dalam sistem. Mengapa ini penting Kunci utama untuk melacak seluruh siklus hidup entri jurnal dan menganalisis alur, durasi, serta variasi proses. Sumber data Ini adalah kunci utama untuk catatan entri jurnal di Workiva. Lihat dokumentasi Workiva untuk mengetahui tabel atau endpoint API yang tepat. Contoh JE-2023-08-1001JE-2023-08-1002JE-2023-09-1003
	Waktu mulai EventTime	Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi.
Deskripsi Waktu Peristiwa adalah stempel waktu yang mencatat tanggal dan waktu tepat saat aktivitas terjadi. Data ini penting untuk mengurutkan peristiwa dengan benar dan melakukan semua analisis berbasis waktu. Dalam process mining, atribut ini digunakan untuk menghitung durasi antaraktivitas, waktu siklus keseluruhan kasus, dan waktu tunggu. Atribut ini penting untuk dashboard yang menganalisis waktu siklus, seperti 'Journal Entry Approval Cycle Time' dan 'Document Attachment Lag Time', serta menjadi dasar untuk menemukan keterlambatan dan ketidakefisienan proses. Mengapa ini penting Stempel waktu ini penting untuk menghitung semua durasi, mengurutkan peristiwa dengan benar, dan menganalisis kinerja proses dari waktu ke waktu. Sumber data Informasi ini biasanya disimpan bersama setiap peristiwa atau perubahan status di tabel transaksi atau log Workiva. Contoh 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Pembaruan data terakhir LastDataUpdate	Stempel waktu yang menunjukkan kapan data terakhir kali diperbarui dari sistem sumber.
Deskripsi Atribut ini mencatat tanggal dan waktu ekstraksi data terbaru dari Workiva. Informasi ini menunjukkan seberapa baru data yang dianalisis. Dalam dashboard analisis proses, informasi ini membantu pengguna memahami seberapa mutakhir insight yang ditampilkan. Pengguna dapat mengetahui apakah data yang dilihat bersifat real-time atau merupakan rekam data dari waktu tertentu. Hal ini penting untuk mengambil keputusan operasional berdasarkan informasi yang tepat. Mengapa ini penting Memberi tahu pengguna seberapa mutakhir data, sehingga mereka dapat memahami apakah analisis mencerminkan kondisi proses terkini. Sumber data Stempel waktu ini dibuat dan disimpan selama proses ekstraksi, transformasi, dan pemuatan data (ETL). Contoh 2023-10-27T02:00:00Z
	Sistem sumber SourceSystem	Sistem pencatatan asal tempat data entri jurnal diekstrak.
Deskripsi Atribut ini menunjukkan aplikasi sumber tempat data proses berasal. Untuk analisis ini, nilainya selalu 'Workiva'. Meski nilainya mungkin tetap saat analisis hanya mencakup satu sistem, metadata ini penting untuk tata kelola dan pelacakan data. Di perusahaan besar, proses sering melibatkan beberapa sistem. Kolom ini membantu memahami asal-usul data secara menyeluruh dan mengintegrasikan data dari berbagai sumber dengan akurat. Mengapa ini penting Memberikan informasi penting tentang asal-usul dan konteks data, terutama saat proses melibatkan beberapa sistem. Sumber data Biasanya berupa nilai tetap yang ditambahkan saat proses ekstraksi dan transformasi data untuk menandai asal data. Contoh Workiva
	Departemen Department	Departemen bisnis atau pusat biaya yang mengajukan entri jurnal.
Deskripsi Atribut ini menunjukkan unit organisasi, seperti Finance, Sales, atau Marketing, yang terkait dengan entri jurnal. Unit ini biasanya ditentukan berdasarkan pusat biaya atau pengguna yang membuat entri. Analisis proses berdasarkan departemen memungkinkan perbandingan kinerja antarbagian organisasi. Analisis ini dapat menunjukkan departemen dengan proses paling efisien, tingkat pengerjaan ulang tertinggi, atau waktu persetujuan terlama. Hasilnya dapat digunakan untuk berbagi praktik yang baik atau memberikan dukungan yang lebih terarah. Mengapa ini penting Memungkinkan perbandingan kinerja antarunit bisnis untuk menemukan masalah atau praktik baik yang spesifik pada departemen tertentu. Sumber data Informasi ini kemungkinan tersedia di data header entri jurnal, mungkin ditautkan dari profil pengguna pembuat entri atau dicatat sebagai pusat biaya. Contoh KeuanganPenjualan Amerika UtaraOperasional Uni Eropa
	Jenis entri jurnal JournalEntryType	Klasifikasi entri jurnal, seperti standar, akrual, atau koreksi.
Deskripsi Atribut ini mengelompokkan entri jurnal berdasarkan tujuan bisnisnya. Jenis yang umum mencakup entri standar untuk transaksi rutin, akrual untuk mengakui pendapatan dan beban, entri reklasifikasi, serta entri koreksi. Dimensi ini penting untuk analisis perbandingan. Anda dapat mengelompokkan proses untuk melihat apakah jenis entri tertentu memerlukan waktu lebih lama, lebih sering ditolak, atau mengikuti jalur berbeda. Contohnya, dashboard 'Journal Entry Reversal Rate Trend' menggunakan atribut ini untuk menganalisis pembalikan berdasarkan jenis entri dan menemukan masalah yang terkait dengan praktik akuntansi tertentu. Mengapa ini penting Memungkinkan Anda mengelompokkan proses untuk mengetahui apakah jenis entri tertentu lebih sering menyebabkan keterlambatan, pengerjaan ulang, atau penyimpangan. Sumber data Kemungkinan berupa kolom standar pada header entri jurnal di Workiva. Contoh StandarAkrualReklasifikasiKoreksi
	Nilai entri jurnal JournalEntryAmount	Total nilai uang entri jurnal, biasanya jumlah debit atau kredit.
Deskripsi Atribut ini menunjukkan nilai keuangan utama yang terkait dengan entri jurnal. Nilainya dapat berupa total debit, yang seharusnya sama dengan total kredit. Analisis proses berdasarkan nilai keuangan dapat mengungkap pola penting. Misalnya, entri jurnal bernilai tinggi mungkin ditinjau lebih ketat dan mengikuti jalur persetujuan yang berbeda. Anda dapat menggunakan atribut ini untuk memfilter dashboard dan menganalisis hubungan antara nilai entri dengan waktu pemrosesan, tingkat pengerjaan ulang, atau keterlambatan persetujuan. Mengapa ini penting Memungkinkan analisis berdasarkan dampak keuangan untuk mengetahui apakah entri bernilai tinggi diproses secara berbeda atau lebih sering mengalami keterlambatan. Sumber data Ini adalah kolom dasar dalam data header entri jurnal di Workiva. Contoh 15000.00250.50125000.75
	Pengguna User	ID pengguna atau nama orang yang melakukan aktivitas.
Deskripsi Atribut ini menunjukkan orang yang bertanggung jawab atas suatu aktivitas, seperti pembuat, peninjau, atau pemberi persetujuan entri jurnal. Nilainya dapat berupa ID pengguna unik, nama, atau alamat email. Analisis berdasarkan pengguna penting untuk memahami pembagian beban kerja, kinerja, dan kepatuhan. Atribut ini mendukung dashboard seperti 'Journal Entry Workload Distribution' dan 'Journal Entry Rejection Analysis' dengan merinci aktivitas berdasarkan pengguna. Hasilnya dapat menunjukkan kebutuhan pelatihan atau ketimpangan sumber daya. Mengapa ini penting Atribut ini penting untuk menganalisis pembagian beban kerja, mengenali pengguna dengan kinerja terbaik, serta memahami pola kerja atau hambatan yang terkait dengan pengguna tertentu. Sumber data Informasi ini biasanya tersedia di log peristiwa atau transaksi Workiva dan dikaitkan dengan setiap aktivitas yang tercatat. Contoh asmithbjonescchen
	Status entri jurnal JournalEntryStatus	Status terkini entri jurnal dalam siklus hidupnya.
Deskripsi Atribut ini menunjukkan kondisi terkini entri jurnal, seperti 'Draft', 'Submitted for Approval', 'Approved', 'Posted', atau 'Rejected'. Nilainya menggambarkan posisi entri saat data diekstrak. Informasi ini penting untuk pemantauan operasional dan mendukung dashboard 'Current Journal Entry Status Overview'. Manajemen dapat melihat beban kerja dan tumpukan pekerjaan di setiap tahap proses, lalu mengatur sumber daya dan prioritas. Mengapa ini penting Memberikan gambaran terkini tentang posisi entri jurnal dalam proses. Informasi ini penting untuk pemantauan operasional dan pengelolaan tumpukan pekerjaan. Sumber data Ini adalah kolom standar pada header entri jurnal di Workiva yang menunjukkan status terkini. Contoh DrafMenunggu persetujuanDibukukanDitolak
	Alasan penolakan RejectionReason	Kode atau teks yang menjelaskan alasan entri jurnal ditolak selama proses peninjauan atau persetujuan.
Deskripsi Saat entri jurnal ditolak, atribut ini mencatat alasan yang diberikan peninjau atau pemberi persetujuan. Alasannya dapat berupa 'Incorrect GL Account', 'Missing Documentation', 'Calculation Error', atau 'Policy Violation'. Informasi ini sangat berguna untuk mencari akar penyebab pengerjaan ulang. Dengan menganalisis alasan penolakan yang paling sering muncul, organisasi dapat menemukan area yang perlu diperbaiki, seperti pelatihan khusus bagi pengguna, instruksi yang lebih jelas, atau peningkatan kontrol sistem. Atribut ini penting untuk dashboard 'Journal Entry Rework Analysis' dan 'Journal Entry Rejection Analysis'. Mengapa ini penting Menunjukkan akar penyebab pengerjaan ulang secara langsung, sehingga pelatihan, dokumentasi, dan kontrol proses dapat diperbaiki secara terarah. Sumber data Data ini mungkin disimpan di kolom khusus atau kolom komentar/catatan yang terkait dengan aktivitas 'Journal Entry Rejected' di Workiva. Contoh Dokumen pendukung tidak lengkapAkun GL yang digunakan salahNilai melebihi ambang batas
	Dilakukan otomatis IsAutomated	Penanda yang menunjukkan apakah aktivitas dilakukan oleh sistem atau pengguna.
Deskripsi Atribut boolean ini membedakan aktivitas yang dilakukan otomatis oleh sistem, seperti 'Automated Validation Run', dari aktivitas yang dilakukan pengguna secara manual, seperti 'Journal Entry Reviewed'. Pembedaan ini penting untuk mengukur efisiensi proses dan potensi otomatisasi secara akurat. Analis dapat memisahkan hambatan yang terkait dengan pekerjaan manusia dari hambatan sistem, serta menghitung upaya manual yang benar-benar diperlukan dalam proses. Atribut ini penting bagi inisiatif yang bertujuan meningkatkan otomatisasi dan mengurangi langkah manual. Mengapa ini penting Membantu membedakan aktivitas sistem dan manusia, yang penting untuk menganalisis tingkat otomatisasi dan menemukan hambatan dalam pekerjaan manual. Sumber data Atribut ini sering kali diturunkan dari data lain. Nilainya dapat ditentukan dengan memeriksa apakah 'User' untuk suatu aktivitas adalah akun sistem atau layanan, atau apakah nama aktivitas menunjukkan otomatisasi. Contoh truefalse
	Kode perusahaan CompanyCode	Pengenal badan hukum tertentu yang menjadi tempat pencatatan entri jurnal.
Deskripsi Kode Perusahaan menunjukkan badan hukum tersendiri dalam suatu grup perusahaan. Transaksi keuangan dicatat pada tingkat ini untuk pelaporan hukum dan konsolidasi. Di organisasi dengan beberapa badan hukum, analisis proses entri jurnal berdasarkan Kode Perusahaan sangat penting. Analisis ini dapat menunjukkan perbedaan kinerja proses, kepatuhan, dan efisiensi antarentitas hukum atau wilayah geografis. Hasilnya membantu organisasi menentukan inisiatif perbaikan proses yang lebih terarah. Mengapa ini penting Penting untuk menganalisis dan membandingkan kinerja proses antarentitas hukum dalam organisasi. Sumber data Ini adalah kolom dasar yang wajib diisi pada data header entri jurnal di sistem akuntansi perusahaan, termasuk Workiva. Contoh 1000US01DE01
	Memiliki dokumentasi HasSupportingDocumentation	Penanda yang menunjukkan apakah dokumen pendukung dilampirkan sebelum entri diajukan untuk ditinjau.
Deskripsi Atribut boolean ini memeriksa apakah aktivitas 'Supporting Documentation Attached' terjadi sebelum aktivitas 'Journal Entry Submitted for Review' untuk entri jurnal tertentu. Atribut ini mendukung dashboard 'Journal Entry Documentation Compliance' dan KPI 'JE Documentation Attachment Rate'. Atribut ini penting untuk kepatuhan dan auditabilitas karena entri tanpa dokumentasi yang memadai dapat menyebabkan penolakan, keterlambatan, dan temuan audit. Analisis ini membantu menegakkan kebijakan dan memperlancar proses peninjauan. Mengapa ini penting Mengukur kepatuhan terhadap kebijakan dokumentasi secara langsung, sehingga pengerjaan ulang dan keterlambatan akibat informasi yang kurang dapat dikurangi. Sumber data Atribut ini diturunkan dari data dengan memeriksa urutan aktivitas dalam data proses untuk setiap kasus. Contoh truefalse
	Perlu dikerjakan ulang IsRework	Penanda yang menunjukkan apakah entri jurnal pernah ditolak atau diperbaiki selama siklus hidupnya.
Deskripsi Atribut boolean ini dihitung untuk setiap kasus. Nilainya menjadi 'true' jika urutan aktivitas entri jurnal mencakup peristiwa seperti 'Journal Entry Rejected' atau 'Journal Entry Corrected'. Atribut ini menyederhanakan analisis pengerjaan ulang dengan menyediakan penanda biner yang jelas untuk pemfilteran dan agregasi. Atribut ini menjadi dasar untuk menghitung KPI 'Journal Entry Rework Rate' dan mendukung dashboard 'Journal Entry Rework Analysis'. Dengan begitu, kasus yang menyimpang dari jalur normal dan memerlukan upaya tambahan dapat segera ditemukan. Mengapa ini penting Memberikan penanda sederhana untuk menemukan dan menganalisis semua entri jurnal yang perlu diperbaiki. Informasi ini penting untuk mengukur kualitas proses dan tingkat penyelesaian yang benar sejak awal. Sumber data Atribut ini diturunkan dari data dengan memeriksa apakah terdapat aktivitas terkait pengerjaan ulang, seperti 'Journal Entry Rejected', di log peristiwa setiap kasus. Contoh truefalse
	Tanggal pembukuan PostingDate	Tanggal saat entri jurnal resmi dicatat di General Ledger.
Deskripsi Tanggal Pembukuan adalah tanggal efektif transaksi untuk keperluan pelaporan keuangan. Tanggal ini menentukan periode fiskal tempat entri dicatat dalam laporan keuangan. Tanggal ini dapat berbeda dari tanggal pembuatan atau persetujuan entri. Atribut ini penting untuk analisis keuangan dan kepatuhan. Atribut ini membantu menilai ketepatan waktu pembukuan jurnal menjelang penutupan periode fiskal. Jeda antara persetujuan dan pembukuan dapat menunjukkan hambatan sistem atau proses yang mungkin memengaruhi penutupan keuangan. Mengapa ini penting Tanggal ini penting untuk pelaporan keuangan dan membantu menganalisis ketepatan waktu pembukuan serta dampaknya pada siklus penutupan keuangan. Sumber data Ini adalah kolom tanggal standar pada data header entri jurnal di Workiva. Contoh 2023-10-312023-11-302023-12-31
	Waktu selesai EndTime	Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu selesai.
Deskripsi Waktu Selesai mencatat saat tepat suatu aktivitas berakhir. Banyak peristiwa proses terjadi seketika dan hanya memiliki Waktu Mulai. Namun, beberapa aktivitas memiliki durasi yang dapat diukur, seperti peninjauan yang dimulai saat pengguna membuka tugas dan berakhir saat tugas diajukan. Atribut ini terutama digunakan untuk menghitung waktu pemrosesan atau waktu kerja aktif suatu aktivitas, terpisah dari waktu menganggur atau waktu tunggu. Atribut ini membantu analisis untuk mengetahui berapa lama pengguna benar-benar mengerjakan tugas tertentu, seperti 'Journal Entry Reviewed'. Mengapa ini penting Atribut ini membantu menghitung waktu pemrosesan aktivitas yang sebenarnya, memisahkan durasi kerja aktif dari waktu tunggu agar analisis efisiensi lebih akurat. Sumber data Lihat dokumentasi Workiva. Nilai ini mungkin perlu diperoleh dengan mencatat peristiwa mulai dan selesai untuk satu aktivitas. Contoh 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T14:10:00Z
	Waktu siklus persetujuan ApprovalCycleTime	Total waktu sejak entri jurnal diajukan untuk ditinjau hingga akhirnya disetujui.
Deskripsi Metrik terhitung ini mengukur durasi seluruh tahap persetujuan. Biasanya, metrik dihitung dari selisih waktu antara peristiwa pertama 'Journal Entry Submitted for Review' dan peristiwa terakhir 'Journal Entry Approved' untuk setiap entri jurnal. Metrik ini mengukur langsung efisiensi alur kerja peninjauan dan persetujuan, serta menjadi KPI utama bagi banyak departemen keuangan. Metrik ini mendukung dashboard 'Journal Entry Approval Cycle Time' untuk menemukan hambatan dan memantau dampak inisiatif perbaikan proses yang bertujuan mempercepat persetujuan. Mengapa ini penting KPI ini mengukur efisiensi proses persetujuan secara langsung dan membantu menemukan keterlambatan. Sumber data Metrik ini dihitung dari stempel waktu aktivitas 'Journal Entry Submitted for Review' dan 'Journal Entry Approved' di log peristiwa. Contoh 25920086400604800

Wajib Disarankan Opsional

Aktivitas Record to Report - Entri Jurnal

Catat langkah proses dan tonggak utama ini dalam log peristiwa agar alur kerja entri jurnal dapat ditemukan dan dianalisis secara akurat.

6 Disarankan 8 Opsional

	Aktivitas	Deskripsi
	Entri jurnal dibukukan ke GL	Aktivitas ini menandakan bahwa entri jurnal yang disetujui telah resmi dibukukan ke General Ledger. Ini menandai selesainya alur proses utama dan biasanya tercatat sebagai perubahan status akhir atau di log transaksi pembukuan.
Mengapa ini penting Sebagai peristiwa 'akhir' utama bagi sebagian besar entri jurnal, aktivitas ini penting untuk menghitung waktu siklus dari awal hingga akhir dan throughput. Pada tahap ini, entri mulai memengaruhi laporan keuangan. Sumber data Informasi ini dapat ditemukan di log transaksi pembukuan GL atau sebagai perubahan status entri jurnal menjadi 'Posted'. Kolom tanggal pembukuan biasanya diisi pada saat ini. Pengumpulan data Diambil dari tabel pembukuan GL yang mencatat stempel waktu dan referensi ke ID Entri Jurnal, atau dari perubahan status menjadi 'Posted'. Jenis peristiwa explicit
	Entri jurnal disetujui	Aktivitas ini menandai persetujuan akhir entri jurnal oleh pengguna yang berwenang, sehingga entri siap dibukukan. Ini adalah tonggak penting yang biasanya tercatat di Workiva sebagai perubahan status menjadi 'Approved'.
Mengapa ini penting Menandai selesainya seluruh proses peninjauan dan persetujuan. Peristiwa ini penting untuk mengukur waktu siklus persetujuan dan tingkat persetujuan pada pengajuan pertama, yang berdampak langsung pada efisiensi proses. Sumber data Diambil dari log riwayat status entri jurnal. Kolom status catatan diperbarui menjadi 'Approved', lalu perubahan ini dicatat bersama stempel waktu dan ID pengguna pemberi persetujuan. Pengumpulan data Stempel waktu saat kolom status entri jurnal diperbarui menjadi 'Approved'. Jenis peristiwa inferred
	Entri jurnal ditolak	Peninjau atau pemberi persetujuan menolak entri jurnal karena kesalahan, informasi yang kurang, atau pelanggaran kebijakan. Entri dikembalikan kepada pembuatnya untuk diperbaiki. Penolakan ini tercatat sebagai perubahan status menjadi 'Rejected' atau 'Needs Rework'.
Mengapa ini penting Aktivitas ini menjadi pemicu utama proses pengerjaan ulang, yang sering kali mengurangi efisiensi proses. Analisis penolakan membantu menemukan kebutuhan pelatihan, kesalahan yang sering terjadi, dan panduan proses yang kurang jelas. Sumber data Disimpulkan dari perubahan status di log riwayat entri jurnal. Status diperbarui menjadi 'Rejected', lalu peristiwa ini dicatat bersama stempel waktu dan pengguna yang melakukan tindakan. Pengumpulan data Stempel waktu saat kolom status diperbarui menjadi 'Rejected' atau 'Sent Back'. Jenis peristiwa inferred
	Journal Entry diajukan untuk ditinjau	Aktivitas ini menandai saat pengguna mengajukan draf entri jurnal beserta dokumentasinya ke alur kerja peninjauan dan persetujuan resmi. Biasanya, aktivitas ini tercatat sebagai perubahan status di platform Workiva, dari 'Draft' atau 'New' menjadi 'In Review'.
Mengapa ini penting Aktivitas ini merupakan tonggak penting yang memulai siklus persetujuan. Mengukur waktu dari tahap ini hingga persetujuan akhir membantu menemukan hambatan dalam proses peninjauan dan menghitung waktu siklus persetujuan. Sumber data Disimpulkan dari perubahan status pada catatan entri jurnal, misalnya dari 'Draft' menjadi 'Submitted for Review'. Perubahan dan stempel waktunya dicatat dalam riwayat perubahan atau tabel log status. Pengumpulan data Ditentukan dengan melacak perubahan kolom status entri jurnal menjadi 'Submitted' atau nilai serupa, menggunakan stempel waktu perubahan tersebut. Jenis peristiwa inferred
	Journal Entry dibuat	Aktivitas ini menandai dimulainya entri jurnal baru di Workiva. Aktivitas tercatat saat pengguna membuat catatan entri jurnal baru. Sistem kemudian membuat Journal Entry ID unik yang berfungsi sebagai ID kasus dalam proses.
Mengapa ini penting Sebagai titik awal proses, peristiwa ini penting untuk mengukur waktu siklus setiap entri jurnal dari awal hingga akhir. Analisis aktivitas ini membantu Anda memahami awal beban kerja dan merencanakan sumber daya. Sumber data Biasanya, peristiwa ini diambil dari log audit atau tabel transaksi Workiva yang mencatat pembuatan objek entri jurnal baru, beserta stempel waktu pembuatan dan ID pengguna. Pengumpulan data Dicatat dalam jejak audit atau tabel saat catatan entri jurnal baru dibuat, dengan stempel waktu 'Created On'. Jenis peristiwa explicit
	Pembalikan entri jurnal diproses	Entri jurnal yang sudah dibukukan dibalik dengan membuat entri baru yang meniadakan nilai entri asli. Jenis transaksi khusus ini tercatat secara eksplisit di sistem.
Mengapa ini penting Aktivitas ini merupakan indikator kuat adanya kesalahan pada entri yang sudah dibukukan. Tingkat pembalikan yang tinggi dapat menunjukkan masalah pada proses peninjauan dan persetujuan awal, sehingga mengurangi akurasi keuangan dan menambah pekerjaan. Sumber data Diambil dari data transaksi yang memiliki jenis transaksi atau penanda khusus untuk menunjukkan pembalikan. Entri pembalik biasanya merujuk ke ID Entri Jurnal asli. Pengumpulan data Catatan entri jurnal baru dibuat dengan jenis 'Reversal' dan tautan ke ID entri asli. Jenis peristiwa explicit
	Dokumen pendukung dilampirkan	Aktivitas ini terjadi saat pengguna melampirkan satu atau beberapa dokumen pendukung, seperti faktur atau kontrak, ke catatan entri jurnal. Biasanya, aktivitas ini dilacak melalui fitur pengelolaan dokumen atau lampiran di Workiva.
Mengapa ini penting Melacak aktivitas ini penting untuk memantau kepatuhan dan menemukan keterlambatan. Jeda antara pembuatan entri dan pelampiran dokumen dapat menjadi hambatan besar yang memengaruhi siklus peninjauan dan persetujuan. Sumber data Data diambil dari log yang terkait dengan fitur pengelolaan dokumen Workiva, yang mencatat waktu file ditautkan ke Journal Entry ID tertentu. Informasi ini dapat berasal dari log peristiwa khusus atau disimpulkan dari tanggal pembuatan tautan lampiran. Pengumpulan data Peristiwa dicatat saat pengguna berhasil mengunggah atau menautkan dokumen ke entri jurnal. Jenis peristiwa explicit
	Entri jurnal dikirim untuk persetujuan	Setelah peninjauan awal berhasil, entri jurnal diteruskan secara resmi kepada pemberi persetujuan atau kelompok persetujuan yang ditunjuk. Perubahan ini tercatat sebagai perubahan status, misalnya dari 'Reviewed' menjadi 'Pending Approval'.
Mengapa ini penting Aktivitas ini membedakan tahap peninjauan awal dari persetujuan akhir, yang mungkin dilakukan oleh peran berbeda. Dengan begitu, keterlambatan pada tahap persetujuan tingkat lanjut dapat dianalisis secara terpisah. Sumber data Disimpulkan dari perubahan status pada catatan entri jurnal yang tercatat di tabel riwayat perubahan. Status berubah dari tahap peninjauan ke tahap persetujuan. Pengumpulan data Diperoleh dengan melacak perubahan kolom status menjadi 'Pending Approval' atau nilai serupa, beserta stempel waktunya. Jenis peristiwa inferred
	Entri jurnal diperbaiki	Setelah penolakan, pembuat entri atau pengguna lain mengubah entri jurnal untuk mengatasi masalah yang ditemukan. Peristiwa ini biasanya tidak tercatat secara eksplisit. Peristiwa ini disimpulkan dengan mendeteksi perubahan data pada catatan setelah status 'Rejected'.
Mengapa ini penting Aktivitas ini merupakan bagian penting dari proses pengerjaan ulang. Mengukur waktu yang dibutuhkan untuk memperbaiki entri dapat menunjukkan seberapa cepat kesalahan ditangani dan apakah perbaikan untuk pengguna atau jenis entri tertentu memerlukan waktu lebih lama. Sumber data Aktivitas ini disimpulkan dari analisis log jejak audit. Aktivitas dikenali dari peristiwa perubahan kolom pada entri jurnal antara status 'Rejected' dan pengajuan ulang berikutnya. Pengumpulan data Dikenali dari log perubahan atau jejak audit yang menunjukkan perubahan data entri jurnal setelah stempel waktu peristiwa 'Rejected'. Jenis peristiwa inferred
	Entri jurnal direkonsiliasi	Aktivitas setelah pembukuan ini terjadi saat entri jurnal dicocokkan dan diselesaikan dalam proses rekonsiliasi. Aktivitas ini tercatat di fitur rekonsiliasi atau sertifikasi akun Workiva.
Mengapa ini penting Menganalisis waktu dari pembukuan hingga rekonsiliasi penting untuk memahami efisiensi proses penutupan keuangan. Keterlambatan pada tahap ini dapat memengaruhi ketepatan waktu dan akurasi pelaporan keuangan. Sumber data Data ini kemungkinan berasal dari modul atau tabel rekonsiliasi terpisah di Workiva, yang menghubungkan item yang direkonsiliasi dengan ID Entri Jurnal sumbernya. Stempel waktu perubahan status rekonsiliasi digunakan. Pengumpulan data Stempel waktu peristiwa atau perubahan status di modul rekonsiliasi yang menandai entri jurnal sebagai 'Reconciled'. Jenis peristiwa explicit
	Journal Entry selesai ditinjau	Peristiwa ini menandakan peninjau telah menyelesaikan pemeriksaan entri jurnal dan mengambil tindakan, seperti meneruskannya untuk persetujuan atau menolaknya. Biasanya, peristiwa ini disimpulkan dari perubahan status berikutnya.
Mengapa ini penting Menandai selesainya pemeriksaan kualitas penting. Dengan menganalisis durasi tahap peninjauan, Anda dapat mengatur beban kerja tim dan menemukan peluang untuk melatih peninjau atau menyederhanakan proses. Sumber data Waktu ini disimpulkan dari stempel waktu saat status entri jurnal berubah dari 'In Review' ke status berikutnya, seperti 'Pending Approval' atau 'Rejected'. Pengumpulan data Stempel waktu saat status berubah dari 'Review' ke status berikutnya. Jenis peristiwa inferred
	Peninjauan Journal Entry dimulai	Aktivitas ini menandai saat peninjau mulai memeriksa entri jurnal yang diajukan. Aktivitas ini dapat disimpulkan saat peninjau membuka atau mengambil tugas peninjauan dari daftar tugas Workiva.
Mengapa ini penting Aktivitas ini membantu membedakan waktu entri menunggu dalam antrean dengan waktu yang digunakan untuk peninjauan aktif. Informasi ini penting untuk mengukur beban kerja peninjau secara akurat dan menemukan hambatan antrean. Sumber data Peristiwa ini sering kali tidak dicatat secara langsung. Waktunya dapat disimpulkan saat sistem menetapkan tugas kepada pengguna tertentu atau saat pengguna pertama kali membuka catatan entri jurnal setelah pengajuan. Pengumpulan data Disimpulkan dari perubahan status tugas menjadi 'In Progress' atau saat peninjau yang ditugaskan pertama kali membuka catatan setelah pengajuan. Jenis peristiwa inferred
	Validasi otomatis dijalankan	Setelah entri jurnal diajukan, sistem menjalankan pemeriksaan otomatis untuk memvalidasi kolom, total, atau aturan kepatuhan. Sistem biasanya mencatat proses otomatis yang berjalan di latar belakang ini.
Mengapa ini penting Aktivitas ini membantu menemukan masalah kualitas data lebih awal dan mengurangi pengerjaan ulang manual di tahap berikutnya. Analisis kegagalan dapat menunjukkan kesalahan pengguna yang umum atau bagian yang perlu diperjelas dalam panduan sistem. Sumber data Peristiwa ini dapat ditemukan dalam log sistem atau log transaksi khusus yang terkait dengan alur kerja entri jurnal. Log tersebut mencatat pelaksanaan aturan validasi. Pengumpulan data Dicatat oleh sistem saat mesin validasi memeriksa data entri jurnal. Jenis peristiwa explicit
	Validasi otomatis gagal	Pemeriksaan validasi otomatis sistem menemukan kesalahan sehingga entri jurnal tidak dapat melanjutkan alur kerja. Status entri otomatis berubah menjadi gagal atau perlu dikerjakan ulang.
Mengapa ini penting Aktivitas ini menunjukkan kontrol kualitas otomatis yang berjalan. Jika kegagalan sering terjadi, mungkin ada masalah sistematis dalam entri data atau aturan validasi yang memicu pengerjaan ulang yang sebenarnya bisa dihindari. Sumber data Informasi ini dapat diambil dari log sistem atau perubahan status yang dipicu proses validasi otomatis. Status entri mungkin berubah menjadi 'Validation Error' atau nilai serupa. Pengumpulan data Peristiwa yang dicatat sistem atau perubahan status otomatis ke kondisi kesalahan saat aturan validasi gagal. Jenis peristiwa explicit

Disarankan Opsional

Panduan Ekstraksi

Cara mengambil data dari Workiva

Langkah

Buat klien API di Workiva: Buka konsol Admin Workiva. Di bagian Pengaturan organisasi, buka 'API Clients' dan buat klien OAuth2 baru. Berikan cakupan akses yang diperlukan, seperti journals:read dan audittrail:read. Simpan Client ID dan Client Secret yang dihasilkan di tempat yang aman.
Siapkan lingkungan Python: Pastikan Python 3.6 atau versi yang lebih baru sudah terpasang. Pasang pustaka untuk mengirim permintaan API dan mengolah data dengan menjalankan pip install requests pandas di terminal.
Buat skrip autentikasi: Di skrip Python, buat fungsi untuk menangani autentikasi OAuth2. Fungsi ini harus menggunakan Client ID dan Client Secret Anda untuk mengirim permintaan POST ke endpoint token Workiva, misalnya https://[YourWorkivaDomain].workiva.com/oauth2/v2/token, lalu mengambil token akses.
Temukan endpoint API: Tentukan endpoint REST API khusus untuk mengambil entri jurnal dan riwayat terperincinya. Endpoint utama mungkin serupa dengan https://[YourWorkivaDomain].workiva.com/api/v1/journals, sedangkan endpoint riwayat dapat menggunakan struktur seperti .../api/v1/journals/{journal_id}/history.
Ambil daftar entri jurnal: Tulis bagian skrip yang memanggil endpoint utama entri jurnal. Gunakan parameter kueri untuk menyaring rentang tanggal dan kriteria lain yang relevan. Panggilan ini akan menghasilkan daftar objek entri jurnal, masing-masing dengan ID unik.
Ambil riwayat setiap entri: Ulangi proses untuk setiap entri jurnal yang diperoleh pada langkah sebelumnya. Untuk setiap JournalEntryId, kirim panggilan API terpisah ke endpoint riwayat atau jejak auditnya untuk mengambil rangkaian peristiwa yang terkait.
Petakan peristiwa mentah ke aktivitas: Olah data riwayat mentah dari respons API. Buat logika pemetaan untuk mengubah nama peristiwa internal atau perubahan status Workiva menjadi nama aktivitas yang diperlukan. Misalnya, perubahan status dari 'Draft' menjadi 'In Review' dipetakan ke aktivitas 'Journal Entry Submitted for Review'.
Buat baris log peristiwa: Untuk setiap peristiwa yang dipetakan, buat kamus atau objek yang mewakili satu baris dalam log peristiwa akhir. Isi semua atribut wajib seperti JournalEntryId, ActivityName, EventTime, dan Pengguna, serta atribut yang disarankan seperti JournalEntryAmount dan Departemen dari data jurnal induk.
Tangani paginasi API: Terapkan logika untuk menangani respons API berpaginasi. Periksa tautan 'next' atau token halaman di header atau isi respons, lalu kirim permintaan berikutnya sampai semua data untuk periode yang ditentukan berhasil diambil.
Gabungkan dan format data: Satukan semua baris log peristiwa yang dihasilkan ke dalam satu daftar. Ubah daftar ini menjadi pandas DataFrame untuk pemrosesan akhir.
Tambahkan kolom metadata: Tambahkan kolom SourceSystem dan LastDataUpdate ke DataFrame. Isi SourceSystem dengan nilai tetap seperti 'Workiva', dan isi LastDataUpdate dengan stempel waktu saat skrip dijalankan.
Ekspor ke CSV: Simpan DataFrame akhir ke file CSV. Pastikan file menggunakan encoding UTF-8 dan mengikuti struktur yang diperlukan untuk diunggah ke alat process mining.

Konfigurasi

Kredensial API: Skrip harus dikonfigurasi dengan CLIENT_ID dan CLIENT_SECRET yang valid dari konsol Admin Workiva. Keduanya diperlukan untuk autentikasi OAuth2.
Endpoint API: Skrip memerlukan URL dasar instans Workiva Anda, misalnya https://[YourWorkivaDomain].workiva.com, serta jalur khusus untuk endpoint token, daftar jurnal, dan riwayat jurnal.
Rentang Tanggal: Tentukan START_DATE dan END_DATE untuk membatasi cakupan ekstraksi. Untuk analisis awal, rentang 3 hingga 6 bulan biasanya cukup untuk menyeimbangkan volume data dan insight.
Parameter Filter: Skrip dapat menggunakan parameter query API untuk memfilter entri jurnal. Filter yang umum mencakup journalEntryType atau department untuk membatasi ekstraksi ke area bisnis atau proses tertentu.
Pemetaan Status: Skrip menggunakan dictionary STATUS_TO_ACTIVITY_MAP untuk mengubah nilai status mentah dari Workiva API menjadi nama aktivitas standar dalam log peristiwa. Anda mungkin perlu menyesuaikannya jika organisasi menggunakan status khusus.
Prasyarat: Anda memerlukan akses ke akun Workiva dengan hak administratif untuk membuat klien API. Lingkungan Python harus memiliki pustaka requests dan pandas.

Contoh kueri python

import requests
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Workiva instance details and credentials
WORKIVA_DOMAIN = class="hl-string">"https://[YourWorkivaDomain].workiva.com"
CLIENT_ID = class="hl-string">"[Your-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Client-Secret]"

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
class=class="hl-string">"hl-comment"># Define the date range for the journal entry extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- API Endpoint Definitions ---
class=class="hl-string">"hl-comment"># Use the correct API version and paths for your instance
TOKEN_URL = fclass="hl-string">"{WORKIVA_DOMAIN}/oauth2/v2/token"
JOURNALS_API_ENDPOINT = fclass="hl-string">"{WORKIVA_DOMAIN}/api/v1/journals"

class=class="hl-string">"hl-comment"># Mapping from Workiva status changes to standardized activity names
class=class="hl-string">"hl-comment"># This may need adjustment based on your specific Workiva workflow configuration.
STATUS_TO_ACTIVITY_MAP = {
    (class="hl-string">'Draft', class="hl-string">'In Review'): class="hl-string">'Journal Entry Submitted for Review',
    (class="hl-string">'In Review', class="hl-string">'Pending Approval'): class="hl-string">'Journal Entry Sent For Approval',
    (class="hl-string">'Pending Approval', class="hl-string">'Approved'): class="hl-string">'Journal Entry Approved',
    (class="hl-string">'Approved', class="hl-string">'Posted'): class="hl-string">'Journal Entry Posted to GL',
    (class="hl-string">'Posted', class="hl-string">'Reconciled'): class="hl-string">'Journal Entry Reconciled',
    (class="hl-string">'In Review', class="hl-string">'Rejected'): class="hl-string">'Journal Entry Rejected',
    (class="hl-string">'Pending Approval', class="hl-string">'Rejected'): class="hl-string">'Journal Entry Rejected'
}

def get_access_token():
    class="hl-string">"""Authenticates with Workiva and retrieves an OAuth2 access token."""
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET
    }
    response = requests.post(TOKEN_URL, data=payload)
    response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
    return response.json()[class="hl-string">'access_token']

def fetch_paginated_data(url, headers, params):
    class="hl-string">"""Fetches data from a paginated API endpoint."""
    all_data = []
    while url:
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status()
        data = response.json()
        all_data.extend(data.get(class="hl-string">'data', []))
        url = data.get(class="hl-string">'metadata', {}).get(class="hl-string">'nextPageUrl') class=class="hl-string">"hl-comment"># Adjust based on actual API response structure
        params = {} class=class="hl-string">"hl-comment"># Subsequent requests use the full URL from nextPageUrl
        time.sleep(0.5) class=class="hl-string">"hl-comment"># Respect rate limits
    return all_data

def map_history_to_activity(event, previous_event, journal_details):
    class="hl-string">"""Maps a single history event to a structured activity record."""
    activity_record = {
        class="hl-string">'JournalEntryId': journal_details.get(class="hl-string">'id'),
        class="hl-string">'EventTime': event.get(class="hl-string">'timestamp'),
        class="hl-string">'User': event.get(class="hl-string">'user', {}).get(class="hl-string">'name', class="hl-string">'System'),
        class="hl-string">'JournalEntryType': journal_details.get(class="hl-string">'type'),
        class="hl-string">'JournalEntryAmount': journal_details.get(class="hl-string">'amount'),
        class="hl-string">'JournalEntryStatus': event.get(class="hl-string">'details', {}).get(class="hl-string">'newValue'),
        class="hl-string">'Department': journal_details.get(class="hl-string">'department')
    }

    event_type = event.get(class="hl-string">'eventType')

    if event_type == class="hl-string">'CREATE':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
        activity_record[class="hl-string">'JournalEntryStatus'] = class="hl-string">'Draft'
        return activity_record

    if event_type == class="hl-string">'ATTACHMENT_ADD':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Supporting Documentation Attached'
        return activity_record

    if event_type == class="hl-string">'REVERSAL_PROCESSED':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Processed'
        return activity_record

    if event_type == class="hl-string">'VALIDATION_RUN':
        status = event.get(class="hl-string">'details', {}).get(class="hl-string">'status')
        if status == class="hl-string">'SUCCESS':
            activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Automated Validation Run'
        elif status == class="hl-string">'FAILURE':
            activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Automated Validation Failed'
        return activity_record

    if event_type == class="hl-string">'UPDATE' and event.get(class="hl-string">'details', {}).get(class="hl-string">'field') == class="hl-string">'status':
        old_status = event.get(class="hl-string">'details', {}).get(class="hl-string">'oldValue')
        new_status = event.get(class="hl-string">'details', {}).get(class="hl-string">'newValue')
        activity_tuple = (old_status, new_status)
        if activity_tuple in STATUS_TO_ACTIVITY_MAP:
            activity_record[class="hl-string">'ActivityName'] = STATUS_TO_ACTIVITY_MAP[activity_tuple]
            return activity_record
        class=class="hl-string">"hl-comment"># Infer other activities based on status
        if new_status == class="hl-string">'In Review' and previous_event and previous_event.get(class="hl-string">'ActivityName') != class="hl-string">'Journal Entry Submitted for Review':
            activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Review Started' class=class="hl-string">"hl-comment"># Inferred event
            return activity_record

    if event_type == class="hl-string">'UPDATE' and previous_event and previous_event.get(class="hl-string">'JournalEntryStatus') == class="hl-string">'Rejected':
        activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Corrected' class=class="hl-string">"hl-comment"># Inferred event
        return activity_record
    
    class=class="hl-string">"hl-comment"># Fallback for unmapped status changes that might represent a review completion
    if event_type == class="hl-string">'UPDATE' and event.get(class="hl-string">'details', {}).get(class="hl-string">'field') == class="hl-string">'status':
        if event.get(class="hl-string">'details', {}).get(class="hl-string">'oldValue') == class="hl-string">'In Review':
             activity_record[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reviewed' class=class="hl-string">"hl-comment"># Inferred event
             return activity_record

    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting extraction from Workiva API...")
    try:
        access_token = get_access_token()
        headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
        
        class=class="hl-string">"hl-comment"># Fetch all journal entries within the specified date range
        print(fclass="hl-string">"Fetching journal entries from {START_DATE} to {END_DATE}...")
        journal_params = {class="hl-string">'createdAfter': START_DATE, class="hl-string">'createdBefore': END_DATE}
        journals = fetch_paginated_data(JOURNALS_API_ENDPOINT, headers, journal_params)
        print(fclass="hl-string">"Found {len(journals)} journal entries.")

        event_log = []
        last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

        for i, journal in enumerate(journals):
            journal_id = journal.get(class="hl-string">'id')
            print(fclass="hl-string">"Processing journal {i+1}/{len(journals)}: {journal_id}")

            class=class="hl-string">"hl-comment"># Fetch the detailed history for each journal entry
            history_url = fclass="hl-string">"{JOURNALS_API_ENDPOINT}/{journal_id}/history"
            try:
                history_events = fetch_paginated_data(history_url, headers, {})
            except requests.exceptions.HTTPError as e:
                print(fclass="hl-string">"Could not fetch history for {journal_id}: {e}")
                continue

            processed_activities = []
            for idx, event in enumerate(history_events):
                previous_event = processed_activities[-1] if processed_activities else None
                activity_record = map_history_to_activity(event, previous_event, journal)
                if activity_record:
                    activity_record[class="hl-string">'SourceSystem'] = class="hl-string">'Workiva'
                    activity_record[class="hl-string">'LastDataUpdate'] = last_data_update
                    processed_activities.append(activity_record)
            
            event_log.extend(processed_activities)

        if not event_log:
            print(class="hl-string">"No events were generated. The event log is empty.")
            return

        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'workiva_journal_entry_event_log.csv'
        df.to_csv(output_filename, index=False, encoding=class="hl-string">'utf-8')
        print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"An API error occurred: {e}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

if __name__ == class="hl-string">"__main__":
    main()

Siap untuk Memulai?

Mulai optimalkan proses Record to Report - Entri Jurnal Anda hari ini. Templat ini menyediakan semua yang Anda perlukan untuk mulai menggali insight yang berguna.

Kembali ke panduan perbaikan

Unduh template

Mulai Optimalkan Record to Report - Entri Jurnal Anda Hari Ini

Kurangi waktu siklus Entri Jurnal hingga 30% agar penutupan keuangan lebih cepat.

Mulai Uji Coba Gratis

Tidak perlu kartu kredit. Batalkan kapan saja.

Templat Data Record to Report - Entri Jurnal Anda

Templat Data Record to Report - Entri Jurnal Anda

Atribut Record to Report - Entri Jurnal

Aktivitas Record to Report - Entri Jurnal

Panduan Ekstraksi

Ekstraksi dengan Skrip Python melalui Workiva REST API

Langkah

Konfigurasi

Contoh kueri python

Siap untuk Memulai?

Mulai Optimalkan Record to Report - Entri Jurnal Anda Hari Ini