> Cải tiến quy trình liên tục > Ghi nhận đến báo cáo, bút toán nhật ký > Workiva > Mẫu dữ liệu

Mẫu dữ liệu quy trình từ ghi nhận đến báo cáo, bút toán

Workiva

Thuộc tính quy trình từ ghi nhận đến báo cáo, bút toán(18) Hoạt động trong quy trình từ ghi nhận đến báo cáo, bút toán(14) Hướng dẫn trích xuất(1)

Mẫu dữ liệu quy trình từ ghi nhận đến báo cáo, bút toán

Mẫu này hướng dẫn bạn thu thập dữ liệu cần thiết để phân tích quy trình từ ghi nhận đến báo cáo, bút toán. Mẫu nêu rõ các trường dữ liệu thiết yếu, những bước quan trọng cần theo dõi và cách trích xuất dữ liệu đó từ Workiva. Sử dụng mẫu này giúp bạn chuẩn bị đủ dữ liệu cho hoạt động process mining.

Các thuộc tính nên thu thập
Các hoạt động chính cần theo dõi
Hướng dẫn thực tế để trích xuất dữ liệu

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Thuộc tính quy trình từ ghi nhận đến báo cáo, bút toán

Đây là các trường dữ liệu nên đưa vào event log để phân tích quy trình từ ghi nhận đến báo cáo, bút toán.

5 Bắt buộc 5 Nên có 8 Không bắt buộc

	Tên	Mô tả
	Hoạt động ActivityName	Tên của bước quy trình hoặc sự kiện cụ thể đã diễn ra với bút toán.
Mô tả Thuộc tính này mô tả hoạt động diễn ra tại một thời điểm cụ thể trong vòng đời của bút toán. Thuộc tính ghi nhận các mốc quan trọng như 'Journal Entry Created', 'Journal Entry Submitted for Review', 'Journal Entry Approved' và 'Journal Entry Posted to GL'. Phân tích trình tự và tần suất của các hoạt động này là trọng tâm của process mining. Việc này giúp trực quan hóa luồng quy trình, xác định các đường đi phổ biến và hiếm gặp (biến thể), đồng thời tìm ra điểm nghẽn khiến bút toán mất nhiều thời gian nhất. Thuộc tính cũng được dùng để xác định điểm bắt đầu và kết thúc khi tính KPI, chẳng hạn như thời gian xử lý phê duyệt. Vì sao điều này quan trọng Thuộc tính này xác định các bước trong quy trình, giúp trực quan hóa và phân tích quy trình làm việc của bút toán, đồng thời tìm ra điểm nghẽn. Lấy dữ liệu ở đâu Thông tin này thường được lấy từ nhật ký sự kiện hoặc bản ghi thay đổi trạng thái trong Workiva. Có thể cần ánh xạ trường dữ liệu chính xác từ mã trạng thái hoặc mô tả sự kiện của hệ thống. Ví dụ Tạo bút toánGửi bút toán để xét duyệtBút toán được phê duyệtBút toán được ghi sổ vào sổ cái
	ID bút toán JournalEntryId	Mã định danh duy nhất của một bút toán, dùng làm mã hồ sơ chính để phân tích quy trình.
Mô tả ID bút toán theo dõi duy nhất mọi hoạt động và sự kiện liên quan đến một nhóm giao dịch tài chính cụ thể, từ lúc tạo đến khi ghi sổ và đối chiếu xong. ID này liên kết từng bước, như tạo, gửi, rà soát, phê duyệt và ghi sổ, thành một phiên bản quy trình thống nhất. Trong process mining, thuộc tính này là nền tảng để tái dựng toàn bộ hành trình của từng bút toán. Thuộc tính cho phép phân tích các biến thể quy trình, thời gian xử lý và vòng sửa lại theo từng bút toán, giúp bạn thấy rõ từng bút toán đi qua hệ thống như thế nào. Vì sao điều này quan trọng Đây là khóa thiết yếu để theo dõi toàn bộ vòng đời của bút toán, đồng thời phân tích luồng quy trình, thời lượng và các biến thể. Lấy dữ liệu ở đâu Đây là khóa chính của bản ghi bút toán trong Workiva. Hãy xem tài liệu Workiva để biết bảng hoặc điểm cuối API cụ thể. Ví dụ JE-2023-08-1001JE-2023-08-1002JE-2023-09-1003
	Thời gian bắt đầu EventTime	Dấu thời gian cho biết một hoạt động hoặc sự kiện cụ thể đã diễn ra khi nào.
Mô tả Thời gian sự kiện là dấu thời gian chính xác, gồm ngày và giờ, ghi lại thời điểm một hoạt động diễn ra. Dữ liệu này rất quan trọng để sắp xếp sự kiện đúng thứ tự và thực hiện mọi phân tích dựa trên thời gian. Trong process mining, thuộc tính này được dùng để tính thời lượng giữa các hoạt động, thời gian xử lý tổng thể của từng hồ sơ và thời gian chờ. Đây là dữ liệu thiết yếu cho các dashboard phân tích thời gian xử lý, chẳng hạn như 'Journal Entry Approval Cycle Time' và 'Document Attachment Lag Time', đồng thời là cơ sở để xác định chậm trễ và điểm kém hiệu quả trong quy trình. Vì sao điều này quan trọng Dấu thời gian này rất quan trọng để tính mọi khoảng thời gian, sắp xếp sự kiện đúng thứ tự và phân tích hiệu suất quy trình theo thời gian. Lấy dữ liệu ở đâu Thông tin này thường được lưu cùng mỗi sự kiện hoặc thay đổi trạng thái trong bảng giao dịch hoặc nhật ký của Workiva. Ví dụ 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Hệ thống nguồn SourceSystem	Hệ thống lưu trữ dữ liệu gốc mà dữ liệu bút toán được trích xuất từ đó.
Mô tả Thuộc tính này xác định ứng dụng nguồn nơi dữ liệu quy trình được tạo ra. Trong phân tích này, giá trị luôn là 'Workiva'. Dù có vẻ không thay đổi khi chỉ phân tích một hệ thống, đây vẫn là siêu dữ liệu quan trọng để quản trị và truy xuất nguồn gốc dữ liệu. Trong các doanh nghiệp lớn, quy trình thường đi qua nhiều hệ thống. Khi đó, trường này giúp hiểu đầy đủ nguồn gốc dữ liệu và tích hợp chính xác dữ liệu từ nhiều nguồn. Vì sao điều này quan trọng Cung cấp thông tin về nguồn gốc và bối cảnh dữ liệu, giúp xác định rõ dữ liệu quy trình đến từ đâu, nhất là khi có nhiều hệ thống. Lấy dữ liệu ở đâu Đây thường là giá trị cố định được thêm trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn dữ liệu. Ví dụ Workiva
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian cho biết lần gần nhất dữ liệu được làm mới từ hệ thống nguồn.
Mô tả Thuộc tính này ghi lại ngày giờ của lần trích xuất dữ liệu gần nhất từ Workiva. Nhờ đó, bạn biết dữ liệu đang phân tích mới đến mức nào. Trong mọi dashboard phân tích quy trình, thông tin này giúp người dùng biết dữ liệu có được cập nhật hay không. Bạn có thể xác định mình đang xem dữ liệu gần thời gian thực hay ảnh chụp tại một thời điểm cụ thể, từ đó đưa ra quyết định vận hành phù hợp. Vì sao điều này quan trọng Cho người dùng biết dữ liệu được cập nhật đến thời điểm nào, để họ hiểu phân tích có phản ánh trạng thái quy trình mới nhất hay không. Lấy dữ liệu ở đâu Dấu thời gian này được tạo và lưu trong quá trình trích xuất, chuyển đổi và tải dữ liệu (ETL). Ví dụ 2023-10-27T02:00:00Z
	Giá trị bút toán JournalEntryAmount	Tổng giá trị tiền tệ của bút toán, thường là tổng bên nợ hoặc bên có.
Mô tả Thuộc tính này thể hiện giá trị tài chính chính của bút toán. Giá trị có thể là tổng số tiền bên nợ, bằng với tổng số tiền bên có. Phân tích quy trình theo giá trị tài chính có thể cho thấy những xu hướng quan trọng. Chẳng hạn, bút toán có giá trị lớn có thể được kiểm tra kỹ hơn và đi theo luồng phê duyệt chặt chẽ hơn. Bạn có thể dùng thuộc tính này để lọc dashboard và xem giá trị bút toán có liên quan đến thời gian xử lý, tỷ lệ phải sửa lại hoặc chậm trễ khi phê duyệt hay không. Vì sao điều này quan trọng Cho phép phân tích theo tác động tài chính, giúp xác định bút toán giá trị lớn có được xử lý khác biệt hoặc dễ bị chậm trễ hơn hay không. Lấy dữ liệu ở đâu Đây là trường dữ liệu cơ bản trong phần đầu bút toán của Workiva. Ví dụ 15000.00250.50125000.75
	Loại bút toán JournalEntryType	Phân loại bút toán, chẳng hạn bút toán thông thường, trích trước hoặc điều chỉnh.
Mô tả Thuộc tính này phân loại bút toán theo mục đích nghiệp vụ. Các loại phổ biến gồm bút toán thông thường cho giao dịch định kỳ, bút toán trích trước để ghi nhận doanh thu và chi phí, bút toán phân loại lại và bút toán điều chỉnh. Chiều dữ liệu này rất quan trọng khi so sánh. Bạn có thể chia quy trình theo loại bút toán để xem loại nào mất nhiều thời gian hơn, có tỷ lệ bị từ chối cao hơn hoặc đi theo luồng khác. Ví dụ, dashboard 'Journal Entry Reversal Rate Trend' dùng thuộc tính này để phân tích các lần đảo bút toán theo loại, giúp xác định vấn đề riêng trong một số nghiệp vụ kế toán. Vì sao điều này quan trọng Cho phép chia quy trình theo loại bút toán để xác định loại nào gây chậm trễ, cần sửa lại nhiều hơn hoặc có nhiều sai lệch hơn. Lấy dữ liệu ở đâu Đây có thể là trường tiêu chuẩn trong phần đầu bút toán của Workiva. Ví dụ Thông thườngTrích trướcPhân loại lạiĐiều chỉnh
	Người dùng User	ID người dùng hoặc tên của người thực hiện hoạt động.
Mô tả Thuộc tính này xác định người chịu trách nhiệm cho một hoạt động, chẳng hạn người tạo, người rà soát hoặc người phê duyệt bút toán. Giá trị có thể là ID người dùng duy nhất, tên hoặc địa chỉ email. Phân tích dữ liệu theo người dùng giúp bạn hiểu cách phân bổ khối lượng công việc, hiệu suất và mức độ tuân thủ. Thuộc tính này hỗ trợ các dashboard như 'Journal Entry Workload Distribution' và 'Journal Entry Rejection Analysis', cho phép phân tích hoạt động theo từng người dùng và phát hiện nhu cầu đào tạo hoặc mất cân đối về tài nguyên. Vì sao điều này quan trọng Thuộc tính này giúp phân tích cách phân bổ khối lượng công việc, xác định người có hiệu suất cao và hiểu hành vi hoặc điểm nghẽn riêng của từng người dùng. Lấy dữ liệu ở đâu Thông tin này thường có trong nhật ký sự kiện hoặc giao dịch của Workiva, gắn với từng hoạt động được ghi nhận. Ví dụ asmithbjonescchen
	Phòng ban Department	Phòng ban hoặc trung tâm chi phí đã khởi tạo bút toán.
Mô tả Thuộc tính này xác định đơn vị trong tổ chức, chẳng hạn Tài chính, Kinh doanh hoặc Tiếp thị, có liên quan đến bút toán. Đơn vị thường được xác định dựa trên trung tâm chi phí hoặc người tạo bút toán. Phân tích quy trình theo phòng ban giúp so sánh hiệu suất giữa các bộ phận trong tổ chức. Qua đó, bạn có thể xác định phòng ban nào có quy trình hiệu quả nhất, tỷ lệ phải sửa lại cao nhất hoặc thời gian phê duyệt dài nhất, từ đó chia sẻ cách làm tốt hoặc hỗ trợ đúng nơi cần thiết. Vì sao điều này quan trọng Cho phép so sánh hiệu suất giữa các đơn vị kinh doanh, giúp xác định vấn đề hoặc cách làm hiệu quả riêng của từng phòng ban. Lấy dữ liệu ở đâu Thông tin này có thể có trong dữ liệu phần đầu bút toán, liên kết với hồ sơ người tạo hoặc được chỉ định dưới dạng trung tâm chi phí. Ví dụ Tài chínhKinh doanh Bắc MỹVận hành châu Âu
	Trạng thái bút toán JournalEntryStatus	Trạng thái hiện tại của bút toán trong vòng đời xử lý.
Mô tả Thuộc tính này cho biết trạng thái hiện tại của bút toán, chẳng hạn 'Draft', 'Submitted for Approval', 'Approved', 'Posted' hoặc 'Rejected'. Đây là ảnh chụp trạng thái của bút toán tại thời điểm trích xuất dữ liệu. Thông tin này cần thiết để theo dõi vận hành và hỗ trợ dashboard 'Current Journal Entry Status Overview'. Dashboard giúp nhà quản lý nắm rõ khối lượng công việc và lượng việc tồn ở từng giai đoạn, từ đó phân bổ tài nguyên và sắp xếp thứ tự ưu tiên. Vì sao điều này quan trọng Cung cấp ảnh chụp trạng thái hiện tại của các bút toán trong quy trình, rất quan trọng để theo dõi vận hành và quản lý công việc tồn đọng. Lấy dữ liệu ở đâu Đây là trường tiêu chuẩn trong phần đầu bút toán của Workiva, phản ánh trạng thái hiện tại. Ví dụ Bản nhápChờ phê duyệtĐã ghi sổBị từ chối
	Có phải sửa lại IsRework	Cờ cho biết bút toán đã từng bị từ chối hoặc chỉnh sửa trong vòng đời xử lý hay chưa.
Mô tả Đây là thuộc tính dạng đúng/sai được tính cho từng hồ sơ. Thuộc tính được đặt thành 'true' nếu chuỗi hoạt động của bút toán có các sự kiện như 'Journal Entry Rejected' hoặc 'Journal Entry Corrected'. Thuộc tính này giúp đơn giản hóa việc phân tích sửa lại bằng cách tạo cờ rõ ràng để lọc và tổng hợp dữ liệu. Đây là cơ sở để tính KPI 'Journal Entry Rework Rate' và hỗ trợ dashboard 'Journal Entry Rework Analysis', giúp nhanh chóng xác định các hồ sơ đi lệch khỏi luồng thông thường và cần thêm công sức xử lý. Vì sao điều này quan trọng Cung cấp cờ đơn giản để xác định và phân tích mọi bút toán cần chỉnh sửa, rất hữu ích khi đo chất lượng quy trình và tỷ lệ hoàn tất đúng ngay lần đầu. Lấy dữ liệu ở đâu Đây là thuộc tính được suy ra bằng cách kiểm tra nhật ký sự kiện của từng hồ sơ để tìm các hoạt động liên quan đến việc sửa lại, chẳng hạn 'Journal Entry Rejected'. Ví dụ truefalse
	Có tài liệu hỗ trợ HasSupportingDocumentation	Cờ cho biết tài liệu hỗ trợ đã được đính kèm trước khi gửi rà soát hay chưa.
Mô tả Thuộc tính dạng đúng/sai này kiểm tra xem hoạt động 'Supporting Documentation Attached' có diễn ra trước hoạt động 'Journal Entry Submitted for Review' đối với một bút toán hay không. Thuộc tính này hỗ trợ trực tiếp dashboard 'Journal Entry Documentation Compliance' và KPI 'JE Documentation Attachment Rate'. Đây là dữ liệu quan trọng để đảm bảo tuân thủ và khả năng kiểm toán, vì bút toán thiếu tài liệu phù hợp có thể bị từ chối, chậm trễ hoặc bị nêu trong kết quả kiểm toán. Phân tích thuộc tính này giúp thực thi chính sách và đơn giản hóa quy trình rà soát. Vì sao điều này quan trọng Đo trực tiếp mức độ tuân thủ chính sách về tài liệu, giúp giảm việc phải sửa lại và chậm trễ do thiếu thông tin. Lấy dữ liệu ở đâu Đây là thuộc tính được suy ra bằng cách kiểm tra trình tự hoạt động trong dữ liệu quy trình của từng hồ sơ. Ví dụ truefalse
	Có tự động hóa IsAutomated	Cờ cho biết hoạt động do hệ thống hay người dùng thực hiện.
Mô tả Thuộc tính dạng đúng/sai này phân biệt hoạt động do hệ thống tự động thực hiện, chẳng hạn 'Automated Validation Run', với hoạt động do người dùng thực hiện thủ công, như 'Journal Entry Reviewed'. Sự phân biệt này rất quan trọng để đo chính xác hiệu quả quy trình và tiềm năng tự động hóa. Thuộc tính giúp nhà phân tích tách điểm nghẽn do con người khỏi vấn đề của hệ thống, đồng thời tính được công sức thủ công thực sự cần cho quy trình. Đây là dữ liệu quan trọng cho các sáng kiến tăng tự động hóa và giảm số lần cần thao tác thủ công. Vì sao điều này quan trọng Giúp phân biệt hoạt động của hệ thống với hoạt động của con người, cần thiết để phân tích mức độ tự động hóa và xác định điểm nghẽn do thao tác thủ công. Lấy dữ liệu ở đâu Đây thường là thuộc tính được suy ra. Có thể xác định bằng cách kiểm tra xem 'User' của hoạt động có phải là tài khoản hệ thống hoặc tài khoản dịch vụ hay không, hoặc dựa vào tên hoạt động có hàm ý tự động hóa hay không. Ví dụ truefalse
	Lý do từ chối RejectionReason	Mã hoặc nội dung giải thích lý do bút toán bị từ chối trong quá trình rà soát hoặc phê duyệt.
Mô tả Khi bút toán bị từ chối, thuộc tính này ghi lại lý do do người rà soát hoặc người phê duyệt cung cấp. Lý do có thể là 'Sai tài khoản sổ cái tổng hợp', 'Thiếu tài liệu', 'Lỗi tính toán' hoặc 'Vi phạm chính sách'. Thông tin này rất hữu ích để tìm nguyên nhân gốc rễ của việc phải sửa lại. Phân tích các lý do từ chối phổ biến nhất giúp tổ chức xác định cách cải tiến, chẳng hạn đào tạo đúng đối tượng, làm rõ hướng dẫn hoặc tăng cường kiểm soát hệ thống. Đây là thuộc tính quan trọng cho các dashboard 'Journal Entry Rework Analysis' và 'Journal Entry Rejection Analysis'. Vì sao điều này quan trọng Cho biết trực tiếp nguyên nhân gốc rễ khiến phải sửa lại, giúp bạn cải thiện đúng trọng tâm việc đào tạo, tài liệu hướng dẫn và kiểm soát quy trình. Lấy dữ liệu ở đâu Dữ liệu này có thể được lưu trong một trường riêng hoặc trường nhận xét/ghi chú gắn với hoạt động 'Journal Entry Rejected' trong Workiva. Ví dụ Thiếu tài liệu hỗ trợSử dụng sai tài khoản sổ cái tổng hợpSố tiền vượt ngưỡng
	Mã công ty CompanyCode	Mã định danh pháp nhân cụ thể mà bút toán được ghi nhận cho pháp nhân đó.
Mô tả Mã công ty đại diện cho một pháp nhân riêng biệt trong tập đoàn. Các giao dịch tài chính được ghi nhận ở cấp này để lập báo cáo pháp lý và hợp nhất. Trong tổ chức có nhiều pháp nhân, phân tích quy trình bút toán theo Mã công ty là việc cần thiết. Cách này có thể cho thấy khác biệt về hiệu suất quy trình, mức độ tuân thủ và hiệu quả giữa các pháp nhân hoặc khu vực địa lý. Nhờ đó, bạn có thể triển khai các sáng kiến cải tiến quy trình phù hợp hơn. Vì sao điều này quan trọng Rất quan trọng để phân tích và so sánh hiệu suất quy trình giữa các pháp nhân trong tổ chức. Lấy dữ liệu ở đâu Đây là trường cơ bản và bắt buộc trong dữ liệu phần đầu bút toán của mọi hệ thống kế toán doanh nghiệp, bao gồm Workiva. Ví dụ 1000US01DE01
	Ngày ghi sổ PostingDate	Ngày bút toán được ghi nhận chính thức vào sổ cái tổng hợp.
Mô tả Ngày ghi sổ là ngày giao dịch có hiệu lực để lập báo cáo tài chính. Ngày này xác định kỳ tài chính mà bút toán được phản ánh trong báo cáo. Ngày ghi sổ có thể khác ngày tạo hoặc ngày phê duyệt bút toán. Thuộc tính này quan trọng khi phân tích tài chính và tuân thủ. Thuộc tính giúp đánh giá mức độ kịp thời của việc ghi sổ so với thời điểm kết thúc kỳ tài chính. Khoảng trễ giữa phê duyệt và ghi sổ có thể cho thấy điểm nghẽn trong hệ thống hoặc quy trình, ảnh hưởng đến việc khóa sổ tài chính. Vì sao điều này quan trọng Đây là ngày quan trọng để lập báo cáo tài chính, giúp phân tích việc ghi sổ có kịp thời hay không và ảnh hưởng thế nào đến chu kỳ khóa sổ. Lấy dữ liệu ở đâu Đây là trường ngày tiêu chuẩn trong dữ liệu phần đầu bút toán của Workiva. Ví dụ 2023-10-312023-11-302023-12-31
	Thời gian kết thúc EndTime	Dấu thời gian cho biết một hoạt động hoặc sự kiện cụ thể hoàn tất khi nào.
Mô tả Thời gian kết thúc ghi lại chính xác thời điểm một hoạt động hoàn tất. Nhiều sự kiện quy trình diễn ra tức thời và chỉ có Thời gian bắt đầu. Tuy nhiên, một số hoạt động có thời lượng đo được, chẳng hạn bước rà soát bắt đầu khi người dùng mở tác vụ và kết thúc khi họ gửi kết quả. Thuộc tính này chủ yếu được dùng để tính thời gian xử lý của một hoạt động, tức thời gian làm việc thực tế, và phân biệt với thời gian nhàn rỗi hoặc chờ. Thuộc tính hỗ trợ phân tích thời gian người dùng thực sự dành cho từng tác vụ, chẳng hạn như 'Journal Entry Reviewed'. Vì sao điều này quan trọng Thuộc tính này giúp tính thời gian xử lý thực tế của một hoạt động, tách thời gian làm việc khỏi thời gian chờ để phân tích hiệu quả chính xác hơn. Lấy dữ liệu ở đâu Hãy xem tài liệu Workiva. Có thể cần xác định thời điểm này bằng cách ghi nhận cả sự kiện bắt đầu và hoàn tất của một hoạt động. Ví dụ 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T14:10:00Z
	Thời gian xử lý phê duyệt ApprovalCycleTime	Tổng thời gian từ khi gửi bút toán để rà soát đến khi bút toán được phê duyệt cuối cùng.
Mô tả Chỉ số được tính này đo thời lượng của toàn bộ giai đoạn phê duyệt. Thông thường, chỉ số được tính bằng khoảng thời gian giữa sự kiện 'Journal Entry Submitted for Review' đầu tiên và sự kiện 'Journal Entry Approved' cuối cùng của mỗi bút toán. Đây là thước đo trực tiếp về hiệu quả của quy trình làm việc rà soát và phê duyệt, đồng thời là KPI chính của nhiều phòng ban tài chính. Chỉ số này hỗ trợ dashboard 'Journal Entry Approval Cycle Time', giúp xác định điểm nghẽn và theo dõi tác động của các sáng kiến cải tiến quy trình nhằm đẩy nhanh việc phê duyệt. Vì sao điều này quan trọng Đây là KPI quan trọng, đo trực tiếp hiệu quả của quy trình phê duyệt và giúp xác định chậm trễ. Lấy dữ liệu ở đâu Đây là chỉ số được tính từ dấu thời gian của các hoạt động 'Journal Entry Submitted for Review' và 'Journal Entry Approved' trong nhật ký sự kiện. Ví dụ 25920086400604800

Bắt buộc Nên có Không bắt buộc

Hoạt động trong quy trình từ ghi nhận đến báo cáo, bút toán

Đây là các bước và cột mốc chính cần ghi lại trong event log để khám phá và phân tích chính xác quy trình làm việc về bút toán.

6 Nên có 8 Không bắt buộc

	Hoạt động	Mô tả
	Bút toán bị từ chối	Người rà soát hoặc người phê duyệt từ chối bút toán do có lỗi, thiếu thông tin hoặc vi phạm chính sách. Bút toán được gửi lại cho người tạo để chỉnh sửa. Sự kiện này được ghi nhận qua thay đổi trạng thái thành 'Rejected' hoặc 'Needs Rework'.
Vì sao điều này quan trọng Hoạt động này thường khởi đầu các vòng sửa lại, vốn là nguyên nhân chính làm giảm hiệu quả quy trình. Phân tích các trường hợp bị từ chối giúp xác định nhu cầu đào tạo, lỗi thường gặp và hướng dẫn quy trình chưa rõ ràng. Lấy dữ liệu ở đâu Có thể suy ra từ thay đổi trạng thái trong nhật ký lịch sử của bút toán. Trạng thái được cập nhật thành 'Rejected', kèm dấu thời gian và người thực hiện thao tác. Thu thập Dấu thời gian khi trường trạng thái được cập nhật thành 'Rejected' hoặc 'Sent Back'. Loại sự kiện inferred
	Bút toán được ghi sổ vào sổ cái	Hoạt động này cho biết bút toán đã được phê duyệt và ghi sổ chính thức vào sổ cái tổng hợp (General Ledger). Đây là bước hoàn tất luồng quy trình chính, thường được ghi nhận bằng thay đổi trạng thái cuối cùng hoặc nhật ký giao dịch ghi sổ.
Vì sao điều này quan trọng Đây thường là sự kiện 'kết thúc' chính của một bút toán, rất quan trọng để tính thời gian xử lý từ đầu đến cuối và thông lượng. Sự kiện này đánh dấu thời điểm bút toán bắt đầu ảnh hưởng đến báo cáo tài chính. Lấy dữ liệu ở đâu Có thể tìm thấy sự kiện này trong nhật ký giao dịch ghi nhận các lần ghi sổ vào sổ cái tổng hợp hoặc qua thay đổi trạng thái bút toán thành 'Posted'. Trường ngày ghi sổ thường được điền vào thời điểm này. Thu thập Được ghi nhận từ bảng ghi sổ vào sổ cái tổng hợp, có dấu thời gian và tham chiếu đến ID bút toán, hoặc từ thay đổi trạng thái thành 'Posted'. Loại sự kiện explicit
	Bút toán được phê duyệt	Hoạt động này ghi nhận việc người dùng có thẩm quyền phê duyệt bút toán lần cuối, cho phép ghi sổ. Đây là một mốc quan trọng, thường được Workiva ghi nhận bằng thay đổi trạng thái rõ ràng thành 'Approved'.
Vì sao điều này quan trọng Đánh dấu hoàn tất thành công toàn bộ quy trình rà soát và phê duyệt. Đây là sự kiện quan trọng để đo thời gian xử lý phê duyệt và tỷ lệ được phê duyệt ngay lần đầu, đồng thời ảnh hưởng trực tiếp đến hiệu quả quy trình. Lấy dữ liệu ở đâu Được ghi nhận trong nhật ký lịch sử trạng thái của bút toán. Trường trạng thái của bản ghi được cập nhật thành 'Approved', kèm dấu thời gian và ID người dùng phê duyệt. Thu thập Dấu thời gian khi trường trạng thái của bút toán được cập nhật thành 'Approved'. Loại sự kiện inferred
	Đã xử lý đảo bút toán	Một bút toán đã ghi sổ trước đó được đảo bằng cách tạo bút toán mới để triệt tiêu bút toán ban đầu. Đây là loại giao dịch cụ thể được hệ thống ghi nhận rõ ràng.
Vì sao điều này quan trọng Hoạt động này là dấu hiệu rõ ràng cho thấy có thể đã xảy ra lỗi trong các bút toán đã ghi sổ. Tỷ lệ đảo bút toán cao có thể cho thấy bước rà soát và phê duyệt ban đầu có vấn đề, ảnh hưởng đến độ chính xác tài chính và làm phát sinh thêm công việc. Lấy dữ liệu ở đâu Được ghi nhận từ dữ liệu giao dịch, trong đó loại giao dịch hoặc cờ cụ thể cho biết đây là giao dịch đảo. Bút toán đảo thường tham chiếu đến ID bút toán ban đầu. Thu thập Một bản ghi bút toán mới được tạo với loại 'Reversal' và liên kết đến ID của bút toán ban đầu. Loại sự kiện explicit
	Gửi bút toán để xét duyệt	Đây là thời điểm người dùng gửi bút toán đã soạn cùng tài liệu liên quan vào quy trình xét duyệt và phê duyệt chính thức. Sự kiện thường được ghi nhận qua thay đổi trạng thái rõ ràng trên nền tảng Workiva, khi bút toán chuyển từ trạng thái 'Draft' hoặc 'New' sang 'In Review'.
Vì sao điều này quan trọng Đây là cột mốc quan trọng, đánh dấu lúc chu kỳ phê duyệt bắt đầu. Đo thời gian từ thời điểm này đến khi được phê duyệt cuối cùng giúp xác định điểm nghẽn trong khâu xét duyệt và tính thời gian của chu kỳ phê duyệt. Lấy dữ liệu ở đâu Có thể suy ra từ thay đổi trạng thái trên hồ sơ bút toán, chẳng hạn từ 'Draft' sang 'Submitted for Review'. Thay đổi này cùng dấu thời gian sẽ được ghi trong bảng lịch sử thay đổi hoặc nhật ký trạng thái. Thu thập Được xác định bằng cách theo dõi thay đổi trong trường trạng thái của bút toán sang 'Submitted' hoặc giá trị tương tự, sử dụng dấu thời gian của thay đổi đó. Loại sự kiện inferred
	Tạo bút toán	Hoạt động này đánh dấu thời điểm bắt đầu một bút toán mới trong Workiva. Sự kiện được ghi nhận khi người dùng tạo hồ sơ bút toán mới và hệ thống cấp một Journal Entry ID duy nhất để làm mã định danh trường hợp trong quy trình.
Vì sao điều này quan trọng Là điểm bắt đầu quy trình, sự kiện này rất cần thiết để đo thời gian xử lý từ đầu đến cuối của từng bút toán. Phân tích hoạt động này giúp bạn hiểu thời điểm phát sinh công việc và lập kế hoạch tài nguyên. Lấy dữ liệu ở đâu Sự kiện này thường được ghi lại trong nhật ký kiểm toán hoặc bảng giao dịch của Workiva, nơi lưu thông tin tạo đối tượng bút toán mới cùng dấu thời gian tạo và ID người dùng. Thu thập Được ghi trong nhật ký kiểm toán hoặc bảng dữ liệu khi tạo hồ sơ bút toán mới, kèm dấu thời gian 'Created On'. Loại sự kiện explicit
	Bắt đầu xét duyệt bút toán	Hoạt động này đánh dấu thời điểm người xét duyệt bắt đầu kiểm tra bút toán đã gửi. Có thể suy ra thời điểm này khi người xét duyệt mở hoặc nhận xử lý tác vụ xét duyệt trong danh sách công việc Workiva.
Vì sao điều này quan trọng Hoạt động này giúp phân biệt thời gian bút toán chờ trong hàng đợi với thời gian thực tế được xét duyệt. Đây là thông tin quan trọng để đo chính xác khối lượng công việc của người xét duyệt và xác định điểm nghẽn do chờ xử lý. Lấy dữ liệu ở đâu Sự kiện này thường không được ghi trực tiếp. Có thể suy ra khi hệ thống giao tác vụ cho một người dùng cụ thể hoặc khi người dùng lần đầu mở hồ sơ bút toán sau khi hồ sơ được gửi. Thu thập Có thể suy ra từ lúc trạng thái tác vụ chuyển thành 'In Progress' hoặc khi người xét duyệt được giao lần đầu mở hồ sơ sau khi bút toán được gửi. Loại sự kiện inferred
	Bút toán được chỉnh sửa	Sau khi bút toán bị từ chối, người tạo hoặc người dùng khác chỉnh sửa để xử lý các vấn đề được nêu. Thường không có sự kiện riêng cho thao tác này, nhưng có thể suy ra bằng cách phát hiện thay đổi dữ liệu sau trạng thái 'Rejected'.
Vì sao điều này quan trọng Hoạt động này là một phần quan trọng của vòng sửa lại. Đo thời gian chỉnh sửa bút toán giúp bạn biết lỗi được xử lý nhanh đến đâu và liệu một số người dùng hoặc loại bút toán có mất nhiều thời gian hơn để sửa hay không. Lấy dữ liệu ở đâu Có thể suy ra hoạt động này bằng cách phân tích nhật ký kiểm toán. Tìm các sự kiện sửa đổi trường dữ liệu của bút toán trong khoảng thời gian từ trạng thái 'Rejected' đến lần gửi lại tiếp theo. Thu thập Được xác định qua nhật ký thay đổi hoặc nhật ký kiểm toán cho thấy dữ liệu bút toán được sửa sau dấu thời gian của sự kiện 'Rejected'. Loại sự kiện inferred
	Bút toán được đối chiếu	Hoạt động sau khi ghi sổ này diễn ra khi bút toán được khớp và xác nhận trong quá trình đối chiếu. Hoạt động được ghi nhận trong công cụ đối chiếu hoặc chứng nhận tài khoản của Workiva.
Vì sao điều này quan trọng Phân tích khoảng thời gian từ lúc ghi sổ đến khi đối chiếu giúp đánh giá hiệu quả của quy trình khóa sổ tài chính. Chậm trễ ở bước này có thể ảnh hưởng đến tính kịp thời và độ chính xác của báo cáo tài chính. Lấy dữ liệu ở đâu Thông tin này thường đến từ một mô-đun hoặc bảng đối chiếu riêng trong Workiva, liên kết các mục đã đối chiếu với ID bút toán nguồn. Dấu thời gian khi trạng thái đối chiếu thay đổi sẽ được sử dụng. Thu thập Dấu thời gian của sự kiện hoặc thay đổi trạng thái trong mô-đun đối chiếu, đánh dấu bút toán là 'Reconciled'. Loại sự kiện explicit
	Bút toán được gửi để phê duyệt	Sau khi được rà soát ban đầu và đạt yêu cầu, bút toán được chuyển chính thức đến người phê duyệt được chỉ định hoặc nhóm phê duyệt. Sự kiện này được ghi nhận qua thay đổi trạng thái, chẳng hạn từ 'Reviewed' sang 'Pending Approval'.
Vì sao điều này quan trọng Hoạt động này phân biệt bước rà soát ban đầu với bước phê duyệt cuối cùng, vốn có thể do những vai trò khác nhau thực hiện. Nhờ đó, bạn có thể xác định riêng các chậm trễ ở giai đoạn phê duyệt cấp cao hơn. Lấy dữ liệu ở đâu Có thể suy ra từ thay đổi trạng thái trong bản ghi bút toán, được lưu trong bảng lịch sử thay đổi. Trạng thái sẽ chuyển từ giai đoạn rà soát sang giai đoạn phê duyệt. Thu thập Được xác định bằng cách theo dõi thời điểm trường trạng thái chuyển thành 'Pending Approval' hoặc giá trị tương tự, cùng với dấu thời gian. Loại sự kiện inferred
	Chạy kiểm tra tự động	Sau khi gửi bút toán, hệ thống tự động kiểm tra các trường, tổng số hoặc quy tắc tuân thủ. Đây thường là quy trình chạy nền tự động được hệ thống ghi lại.
Vì sao điều này quan trọng Phát hiện sớm vấn đề về chất lượng dữ liệu, giảm việc phải sửa thủ công ở các bước sau. Phân tích các lần kiểm tra không đạt có thể cho thấy lỗi người dùng thường gặp hoặc những điểm cần cải thiện trong hướng dẫn của hệ thống. Lấy dữ liệu ở đâu Sự kiện này thường có trong nhật ký hệ thống hoặc nhật ký giao dịch riêng gắn với quy trình làm việc của bút toán, ghi lại thời điểm chạy các quy tắc kiểm tra. Thu thập Được hệ thống ghi lại khi công cụ kiểm tra xác thực dữ liệu bút toán. Loại sự kiện explicit
	Đính kèm tài liệu chứng minh	Hoạt động này diễn ra khi người dùng đính kèm một hoặc nhiều tài liệu chứng minh, chẳng hạn hóa đơn hoặc hợp đồng, vào hồ sơ bút toán. Thông tin thường được ghi nhận qua việc theo dõi chức năng quản lý tài liệu hoặc đính kèm trong Workiva.
Vì sao điều này quan trọng Theo dõi hoạt động này rất quan trọng để giám sát việc tuân thủ và phát hiện chậm trễ. Khoảng thời gian từ lúc tạo bút toán đến khi đính kèm tài liệu có thể trở thành điểm nghẽn đáng kể, ảnh hưởng đến chu kỳ rà soát và phê duyệt. Lấy dữ liệu ở đâu Được ghi nhận từ nhật ký liên quan đến tính năng quản lý tài liệu của Workiva, theo dõi thời điểm một tệp được liên kết với Journal Entry ID cụ thể. Đây có thể là sự kiện được ghi trực tiếp trong nhật ký sự kiện hoặc được suy ra từ ngày tạo liên kết đính kèm. Thu thập Ghi nhận sự kiện khi người dùng tải tài liệu lên hoặc liên kết tài liệu với bút toán thành công. Loại sự kiện explicit
	Hoàn tất xét duyệt bút toán	Sự kiện này cho biết người xét duyệt đã hoàn tất đánh giá bút toán và thực hiện hành động, chẳng hạn chuyển bút toán đi phê duyệt hoặc từ chối. Sự kiện thường được suy ra từ thay đổi trạng thái tiếp theo.
Vì sao điều này quan trọng Đánh dấu hoàn tất một bước kiểm tra chất lượng quan trọng. Phân tích thời gian của giai đoạn rà soát giúp bạn phân bổ khối lượng công việc trong nhóm và xác định cơ hội đào tạo người rà soát hoặc đơn giản hóa quy trình. Lấy dữ liệu ở đâu Có thể suy ra thời điểm này từ dấu thời gian khi trạng thái của bút toán chuyển từ 'In Review' sang trạng thái tiếp theo, chẳng hạn như 'Pending Approval' hoặc 'Rejected'. Thu thập Dấu thời gian khi trạng thái chuyển từ 'Review' sang một trạng thái tiếp theo. Loại sự kiện inferred
	Xác thực tự động không đạt	Bước xác thực tự động của hệ thống phát hiện lỗi và ngăn bút toán tiếp tục trong quy trình làm việc. Hệ thống tự động chuyển trạng thái bút toán sang trạng thái lỗi hoặc cần sửa lại.
Vì sao điều này quan trọng Hoạt động này cho thấy các bước kiểm soát chất lượng tự động đang được thực hiện. Nếu lỗi xảy ra thường xuyên, có thể dữ liệu được nhập sai trên diện rộng hoặc chính các quy tắc xác thực có vấn đề, dẫn đến vòng sửa lại không cần thiết. Lấy dữ liệu ở đâu Sự kiện này có thể được ghi nhận trong nhật ký hệ thống hoặc qua thay đổi trạng thái do quy trình xác thực tự động kích hoạt. Trạng thái bút toán có thể chuyển thành 'Validation Error' hoặc giá trị tương tự. Thu thập Sự kiện được hệ thống ghi lại hoặc trạng thái tự động chuyển sang trạng thái lỗi khi quy tắc xác thực không đạt. Loại sự kiện explicit

Nên có Không bắt buộc

Hướng dẫn trích xuất

Cách lấy dữ liệu từ Workiva

Các bước

Tạo API Client trong Workiva: Mở bảng điều khiển quản trị Workiva. Trong phần Cài đặt tổ chức, mở 'API Clients' và tạo client OAuth2 mới. Cấp các phạm vi quyền cần thiết, chẳng hạn journals:read và audittrail:read. Lưu an toàn Client ID và Client Secret được tạo.
Thiết lập môi trường Python: Đảm bảo bạn đã cài Python 3.6 trở lên. Cài các thư viện cần thiết để gửi yêu cầu API và xử lý dữ liệu bằng lệnh pip install requests pandas trong terminal.
Viết tập lệnh xác thực: Trong tập lệnh Python, tạo hàm xử lý xác thực OAuth2. Hàm này cần nhận Client ID và Client Secret, gửi yêu cầu POST đến điểm cuối token của Workiva, chẳng hạn https://[YourWorkivaDomain].workiva.com/oauth2/v2/token, rồi lấy access token.
Xác định điểm cuối API: Tìm các điểm cuối REST API cụ thể để lấy bút toán và lịch sử chi tiết của chúng. Điểm cuối chính có thể có dạng https://[YourWorkivaDomain].workiva.com/api/v1/journals, còn điểm cuối lịch sử có thể có cấu trúc như .../api/v1/journals/{journal_id}/history.
Lấy danh sách bút toán: Viết phần tập lệnh gọi điểm cuối bút toán chính. Dùng tham số truy vấn để lọc theo khoảng ngày và các tiêu chí liên quan khác. Lệnh gọi này trả về danh sách đối tượng bút toán, mỗi đối tượng có một mã ID duy nhất.
Lặp qua từng bút toán và lấy lịch sử: Lặp qua từng bút toán lấy được ở bước trước. Với mỗi JournalEntryId, gửi một lệnh gọi API riêng đến điểm cuối lịch sử hoặc nhật ký kiểm tra tương ứng để lấy chuỗi sự kiện liên quan.
Ánh xạ sự kiện thô sang hoạt động: Xử lý dữ liệu lịch sử thô trong phản hồi API. Tạo logic ánh xạ tên sự kiện nội bộ hoặc thay đổi trạng thái của Workiva sang tên hoạt động cần dùng. Ví dụ, thay đổi trạng thái từ 'Draft' sang 'In Review' tương ứng với hoạt động 'Bút toán nhật ký được gửi để xét duyệt'.
Tạo các hàng nhật ký sự kiện: Với mỗi sự kiện đã ánh xạ, tạo một từ điển hoặc đối tượng đại diện cho một hàng trong nhật ký sự kiện cuối. Điền các thuộc tính bắt buộc như JournalEntryId, ActivityName, EventTime và Người dùng, cùng các thuộc tính nên có như JournalEntryAmount và Phòng ban lấy từ dữ liệu bút toán gốc.
Xử lý phân trang API: Thêm logic xử lý phản hồi API được phân trang. Kiểm tra liên kết 'next' hoặc mã trang trong tiêu đề hay nội dung phản hồi, rồi gửi các yêu cầu tiếp theo cho đến khi lấy hết dữ liệu trong khoảng thời gian đã chọn.
Tổng hợp và định dạng dữ liệu: Gộp tất cả hàng nhật ký sự kiện đã tạo vào một danh sách. Chuyển danh sách này thành pandas DataFrame để xử lý lần cuối.
Thêm cột siêu dữ liệu: Thêm các cột SourceSystem và LastDataUpdate vào DataFrame. SourceSystem cần có giá trị cố định như 'Workiva', còn LastDataUpdate là dấu thời gian hiện tại khi chạy tập lệnh.
Xuất sang CSV: Lưu DataFrame cuối cùng vào tệp CSV. Đảm bảo tệp dùng bảng mã UTF-8 và có cấu trúc phù hợp để tải lên công cụ process mining.

Cấu hình

Thông tin xác thực API: Script cần được cấu hình bằng CLIENT_ID và CLIENT_SECRET hợp lệ lấy từ bảng điều khiển quản trị Workiva. Đây là thông tin cần thiết để xác thực OAuth2.
Điểm cuối API: Script cần URL cơ sở của môi trường Workiva, chẳng hạn https://[YourWorkivaDomain].workiva.com, cùng đường dẫn cụ thể đến các điểm cuối token, danh sách bút toán và lịch sử bút toán.
Khoảng ngày: Chỉ định START_DATE và END_DATE để giới hạn phạm vi trích xuất. Khoảng thời gian thường dùng cho lần phân tích đầu tiên là 3 đến 6 tháng, nhằm cân bằng lượng dữ liệu và thông tin thu được.
Tham số lọc: Có thể cấu hình script dùng tham số truy vấn API để lọc bút toán. Các bộ lọc thường dùng gồm journalEntryType hoặc department để giới hạn dữ liệu theo lĩnh vực kinh doanh hoặc quy trình cụ thể.
Ánh xạ trạng thái: Script có từ điển STATUS_TO_ACTIVITY_MAP để chuyển các giá trị trạng thái thô từ Workiva API thành tên hoạt động chuẩn trong event log. Bạn có thể cần tùy chỉnh từ điển này nếu tổ chức dùng trạng thái riêng.
Điều kiện cần có: Bạn cần quyền quản trị tài khoản Workiva để tạo API client. Môi trường chạy Python script phải cài thư viện requests và pandas.

Truy vấn mẫu 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()

Bạn đã sẵn sàng bắt đầu?

Bắt đầu cải tiến quy trình từ ghi nhận đến báo cáo, bút toán ngay hôm nay. Mẫu này cung cấp những gì bạn cần để bắt đầu khai thác thông tin hữu ích.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Bắt đầu cải tiến quy trình từ ghi nhận đến báo cáo, bút toán ngay hôm nay

Rút ngắn 30% thời gian xử lý bút toán để khóa sổ tài chính nhanh hơn.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Bạn có thể hủy bất cứ lúc nào.

Mẫu dữ liệu quy trình từ ghi nhận đến báo cáo, bút toán

Mẫu dữ liệu quy trình từ ghi nhận đến báo cáo, bút toán

Thuộc tính quy trình từ ghi nhận đến báo cáo, bút toán

Hoạt động trong quy trình từ ghi nhận đến báo cáo, bút toán

Hướng dẫn trích xuất

Trích xuất bằng Python Script qua Workiva REST API

Các bước

Cấu hình

Truy vấn mẫu python

Bạn đã sẵn sàng bắt đầu?

Bắt đầu cải tiến quy trình từ ghi nhận đến báo cáo, bút toán ngay hôm nay