Những con số chúng tôi bịa ra không thuộc về ai

Tôi mất 3 ngày đi tìm lỗi trong tệp mà chúng tôi xuất ra. Đến ngày thứ 4 mới rõ, thứ sai không phải là tệp, mà là những con số chúng tôi tự bịa ra để chạy thử. Cơ quan thuế không từ chối XML của chúng tôi; thứ bị từ chối là một bên đối tác không hề tồn tại.

Xin nói qua bối cảnh. Khi nộp chứng từ khấu trừ thuế lên Coretax ở Indonesia, có một ô dành cho mã số thuế của bên đối tác. Ô đó không xong chỉ với một con số đúng hình thức. Bên tiếp nhận kiểm tra xem con số ấy có trong cơ sở đăng ký hay không. Thứ màn hình của chúng tôi kiểm được chỉ là số chữ số và vị trí dấu phân cách; còn con số ấy có chủ hay không thì từ phía này chúng tôi không trả lời được.

Thứ chúng tôi muốn dựng là một bộ kiểm thử tự động chạy ban đêm. Mỗi đêm vào giờ cố định, máy sinh dữ liệu, tạo trọn bộ chứng từ rồi chạy đến tận bước gửi đi, để sáng ra chúng tôi chỉ việc đọc kết quả. Có nó rồi thì ngày chúng tôi làm hỏng thứ gì cũng là ngày chúng tôi biết. Những con số chúng tôi sinh ra đúng về hình thức: 16 chữ số, dấu phân cách đúng chỗ, chữ số kiểm tra được tính rồi gắn vào.

Ngày 18 tháng 8, 12 trong số 41 ca kiểm thử dừng lại ở cùng một chỗ. Thông báo trả về rất ngắn, và đọc lên như thể nội dung chúng tôi gửi không hợp lệ. Nó không nói mục nào sai. Tôi nghi tệp của chính mình: thứ tự, namespace, cách chúng tôi viết ngày tháng. Suốt 3 ngày tôi chỉ nhìn về phía XML.

Đến ngày thứ 4, tôi đặt 12 ca dừng lại cạnh 29 ca đi lọt. Những ca đi lọt mang các con số lấy thẳng từ chứng từ mà V từng xử lý. Những ca dừng lại mang các con số chúng tôi bịa ngay tại chỗ. Khác biệt không nằm ở cách viết tệp, mà ở chỗ con số ấy có tồn tại hay không. Cơ quan thuế vẫn đang đối chiếu: mã này có trong cơ sở đăng ký không, và hiện còn hiệu lực không.

Tôi kể chuyện này với V. Chị là kế toán ở Jakarta và đã thử KAZENA Books hơn 20 lần bằng dữ liệu thật của văn phòng mình. Câu trả lời của chị rất ngắn. Một hóa đơn có thật thì luôn có một đối tác có thật ở đầu bên kia. Điều mà trong công việc hằng ngày hiển nhiên đến mức không ai nói ra, lại chính là điều chúng tôi quên, và chỉ quên ở bên trong các bài kiểm thử.

Số sê-ri hóa đơn thuế cũng vậy. Số sê-ri mà một doanh nghiệp PKP ghi trên hóa đơn không phải con số họ tự đặt, mà là phần được cơ quan thuế cấp cho. Một con số nghĩ ra ở bàn làm việc thì hoặc đã được cấp cho người khác, hoặc chưa được cấp cho ai, và trong cả 2 trường hợp nó đều không phải của mình. Vì vậy khi một con số trông có vẻ hợp lý mà không đi lọt, đó là hệ thống đang làm đúng việc. Nếu nó đi lọt được thì mới là chuyện đáng lo.

Hình dạng sai lầm của chúng tôi thì rõ. Chúng tôi đã lấy việc kiểm thử đi lọt làm mục tiêu. Khi bạn cố đẩy cho lọt một thứ lẽ ra không được lọt, tay bạn sẽ luôn vươn về phía làm yếu bước kiểm tra. Thực tế, tôi từng một lần đi tìm xem có thiết lập nào cho phép bỏ qua bước đối chiếu ấy không. Việc tôi đi tìm thôi đã là sai hướng. Thứ cần đòi hỏi ở một bài kiểm thử không phải là nó đi lọt, mà là nó dừng đúng lúc cần dừng.

Đây là những gì chúng tôi đã sửa. Chúng tôi tách việc kiểm tra thành 2 lớp. Lớp thứ nhất là những gì chúng tôi tự trả lời được: số chữ số, dấu phân cách, chữ số kiểm tra, các trường bắt buộc, và việc tổng các dòng có khớp với tổng cuối hay không. Tất cả được kiểm ở đây, trước khi gửi bất cứ thứ gì. Lớp thứ hai là những gì chỉ cơ quan thuế mới có câu trả lời: chủ của con số ấy có tồn tại không, hiện có hiệu lực không, số sê-ri đó có được cấp cho chúng tôi không. Phần này không thể biết trước khi gửi. Chúng tôi thôi giả vờ rằng mình biết.

Chữ trên màn hình cũng được sửa. Trước đây chỉ ghi rằng gửi không thành công. Bây giờ nó ghi rõ là con số nào, và ai đã từ chối. Khi màn hình nói rằng không tìm thấy mã số của bên đối tác trong cơ sở đăng ký, việc người dùng làm tiếp theo sẽ khác. Xem lại phần mình đã nhập và đề nghị đối tác xác nhận mã số của họ là 2 hành động hoàn toàn khác nhau.

Cách chạy kiểm thử cũng đổi. Thứ chạy hằng đêm chỉ là lớp thứ nhất. Đường gửi lên cơ quan thuế được chạy có chủ đích, trên máy của người thực sự nắm những con số thật. Trước mỗi lần phát hành, E, đồng nghiệp của tôi, sẽ đi hết một lượt trên thiết bị của anh. Anh sống ở một thị trấn nhỏ cách Jakarta khá xa, và kiểm bằng đường truyền cùng chiếc máy mà người ở đó thực sự dùng. Chúng tôi kẻ một ranh giới rõ giữa phần máy chạy được hằng đêm và phần chỉ con người mới làm được.

Chính dữ liệu kiểm thử cũng được thay. Trong nhật ký công việc vẫn còn những con số chép lại từ chứng từ thật. Tôi từng nghĩ dùng chúng để chạy thử thì không sao, nhưng đó là con số của người khác. Giờ tất cả được thay bằng những con số nhìn một cái là biết không thuộc về ai, và không còn con số thật nào nằm trong bộ kiểm thử của chúng tôi. Lớp thứ nhất vẫn chạy tốt như thế. Còn lớp thứ hai thì nếu không phải hàng thật vốn dĩ chưa bao giờ có ý nghĩa.

Xin nói thẳng. Tôi không phải kế toán thuế. Số chữ số, biểu mẫu, và cách đối chiếu đều thay đổi, và chứng từ nào cần con số nào cũng khác nhau tùy nội dung giao dịch. Những gì viết ở đây là ghi chép về việc chúng tôi sửa lại cách kiểm thử của chính mình. Xin hãy xác nhận quyết định thực tế với chuyên gia.

Tôi có một đề nghị. Nếu bạn từng gặp một màn hình của KAZENA chỉ báo rằng không gửi được, và bạn không biết phải làm gì tiếp theo, xin hãy cho tôi biết. Việc dừng lại đôi khi là đúng. Nhưng lý do dừng nằm ở phía chúng tôi hay ở phía đối tác trong chứng từ, đó là điều chúng tôi phải viết ra. Nếu không viết, đó là thiếu sót của chúng tôi.