Chuyển workbook Excel sang Python: giữ Excel làm đáp án để kiểm thử từng ô

Trong thử nghiệm với workbook giả lập 20 sheet, 78.766 công thức được gom thành 469 mẫu logic và bản Python khớp 63.309 ô tính toán với Excel; điểm đáng học là dùng bảng tính cũ làm bộ đáp án để dò sai lệch, chứ không phải giao cả file cho AI rồi tin vào kết quả.

Đây là một câu chuyện cá nhân được công bố bởi XDA Developers, không phải benchmark độc lập. Workbook mô phỏng dữ liệu của một kênh YouTube công nghệ hư cấu trong 21 tháng, gồm 364 video và gần 10.000 dòng thống kê. Tác giả nói đã dùng Claude Opus 5.5 để hỗ trợ dựng lại phần tính toán bằng Python. Quy mô đủ lớn để làm lộ những chỗ công thức phụ thuộc lẫn nhau, nhưng dữ liệu vẫn do chính tác giả tạo.

Đếm mẫu công thức giúp thu nhỏ bài toán trước khi viết lại

Đếm từng ô công thức không cho biết có bao nhiêu quy tắc khác nhau trong workbook. Tác giả chuẩn hóa tham chiếu tương đối, nhờ đó những biểu thức như phép cộng ở hàng 2 và cùng phép cộng ở hàng 3 được nhận diện là một mẫu. Kết quả là 78.766 công thức rút xuống còn 469 cấu trúc logic.

Riêng sheet Video_Daily chứa 39.876 công thức nhưng chỉ có bốn mẫu. Điều này gợi ý một cách tiếp cận hữu ích: trước khi chuyển một file lớn, hãy lập danh mục công thức, tìm các mẫu lặp và xác định vùng nào thực sự chứa quy tắc khác biệt. Một thư viện như pandas có thể đọc dữ liệu từ nhiều định dạng Excel và chọn sheet theo tên hoặc chỉ số, nhưng đọc được dữ liệu không đồng nghĩa đã tái tạo đúng toàn bộ hành vi workbook.

Ở bước tiếp theo, dữ liệu thô được xuất một lần thành 12 file CSV, còn giả định được gom vào một file cấu hình. Cách tách này giúp dữ liệu không lẫn với logic tính toán, nhất là khi hai sheet Forecast và P&L phụ thuộc qua lại.

Excel làm bộ đáp án giúp phát hiện sai lệch khi chuyển đổi

Trong phép so sánh được mô tả, bộ test đọc kết quả Excel đã tính sẵn rồi đối chiếu với giá trị Python ở từng ô, với sai số đến một phần tỷ. Excel không được dùng để xác nhận mã nguồn Python; nó chỉ cung cấp kết quả tham chiếu của workbook cũ. Lần chạy đầu thất bại vì cách đọc danh sách ngày nghỉ bị sai điểm bắt đầu, khiến ngày đến hạn của hai hóa đơn tài trợ lệch sớm một ngày vào Veterans Day và Martin Luther King Jr. Day.

Sau khi sửa, tác giả báo cáo 63.309 ô trên 15 sheet khớp nhau và 27 bài test đều qua. Con số này cho thấy hai phiên bản tương đương trong phạm vi các ô và dữ liệu đã kiểm tra. Nó không chứng minh công thức ban đầu phản ánh đúng nghiệp vụ; nếu workbook cũ đã sai, khớp với nó chỉ giúp giữ nguyên lỗi đó.

Kiểm tra kiểu dữ liệu và quy tắc nghiệp vụ quan trọng hơn việc khớp số

Phép đối chiếu tương đương không thay thế kiểm tra chất lượng dữ liệu. Trong ví dụ của tác giả, một hóa đơn kế toán giả lập trị giá 1.800 USD bị lưu thành văn bản. Công thức tổng hợp bỏ qua giá trị đó, khiến chi phí tháng 6/2026 thấp hơn đúng 1.800 USD.

Lỗi thứ hai là mã tài trợ SPT-O122 dùng chữ O thay vì số 0, khiến một khoản thưởng lượt xem bị tính thành không. Báo cáo lỗi của Python đánh dấu để người vận hành xác nhận thay vì âm thầm dùng dữ liệu sai. Đây là lựa chọn đúng với dữ liệu tài chính: tự sửa một mã có vẻ gần giống có thể gắn nhầm giao dịch, còn dừng lại để kiểm tra nguồn thì tốn thêm vài phút nhưng an toàn hơn.

Bài học áp dụng được ngoài Excel là nên có kiểm tra kiểu dữ liệu, khóa định danh và các điều kiện nghiệp vụ độc lập với phép so sánh đầu ra. AI có thể giúp tạo mã chuyển đổi, nhưng người chịu trách nhiệm vẫn cần quyết định trường hợp nào được sửa tự động và trường hợp nào phải dừng để xác nhận.

Hàm volatile và lịch thanh toán cho thấy workbook mã hóa cả quy tắc ẩn

Workbook thử nghiệm sử dụng OFFSET để tính tăng trưởng so cùng kỳ và INDIRECT cho danh sách chọn phụ thuộc. Tài liệu Microsoft Learn xếp cả hai vào nhóm hàm volatile: Excel tính lại ô có các hàm này cùng những ô phụ thuộc mỗi lần recalculation. Việc dùng nhiều hàm volatile có thể làm chậm tính toán, nhưng sự hiện diện của chúng riêng lẻ không đủ để kết luận workbook cần viết lại; ảnh hưởng còn tùy cấu trúc và quy mô thực tế.

Phần thuế cũng minh họa rủi ro khi chuyển các quy tắc có lịch đặc thù. Các kỳ nộp thuế ước tính của IRS lần lượt kéo dài ba, hai, ba và bốn tháng, thay vì bốn quý bằng nhau. Đây là lịch tại Hoa Kỳ, không thể dùng làm hướng dẫn về thuế Việt Nam. Nếu tái tạo một workbook tương tự, lịch hạn và ngày nghỉ cần được kiểm tra như dữ liệu nghiệp vụ có phiên bản, thay vì coi là vài công thức phụ.

Trong thử nghiệm, Excel mất 3,4 giây để cập nhật ngày tham chiếu trên MacBook Air của tác giả, còn lệnh Python tạo báo cáo, biểu đồ và file Excel kết quả chạy trong 2,6 giây. Các số này chỉ thuộc môi trường demo và không đủ điều kiện để so thành benchmark chung. Tác giả vẫn giữ Excel làm đầu ra, để người dùng tiếp tục xem bảng tính trong khi Python đảm nhiệm tính toán.

Đừng chuyển workbook sản xuất chỉ vì một demo chạy nhanh

Với file nội bộ đang được dùng hằng ngày, phần tốn công thường không phải công thức nhìn thấy trên màn hình mà là lịch sử chỉnh sửa, ngoại lệ, quyền truy cập và giả định không được ghi lại. Một workbook demo do tác giả dựng không thể đại diện cho file đã được nhiều người sửa qua nhiều năm. Trước khi thay engine, cần có bản sao chỉ đọc, bộ dữ liệu kiểm thử đại diện, người xác nhận quy tắc nghiệp vụ và kế hoạch quay lại phiên bản cũ nếu kết quả lệch.

Cách ít rủi ro hơn là chuyển từng phần: lập danh mục công thức, trích xuất dữ liệu, viết kiểm thử đối chiếu với Excel, rồi bổ sung kiểm tra nghiệp vụ riêng. Chỉ khi cả hai lớp kiểm tra đều đạt mới cân nhắc đưa Python vào quy trình chính. Nếu mục tiêu chỉ là phân tích một lần, giữ phép tính trong Excel có thể đơn giản hơn; lợi ích của Python rõ hơn khi cần lặp lại, kiểm thử và quản lý mã nguồn.

Nguồn tham khảo: XDA Developers; Microsoft Learn; Internal Revenue Service; pandas documentation.