INV-2026-0001. Trong 1 bộ sổ có 2 hóa đơn mang số này. Khách hàng khác nhau, số tiền khác nhau. Một tờ phát hành ngày 2 tháng 7, tờ kia ngày 4 tháng 8, và cả hai đều được màn hình của chính chúng tôi tạo ra đúng cách. Không ai gõ nhầm cả. Chính chúng tôi mới là bên phát hành cùng một số hai lần.
Người phát hiện ra là V. Chị là kế toán ở Jakarta và đã hơn 20 lần thử KAZENA Books bằng dữ liệu thật của văn phòng mình. Ngày 20 tháng 8, chị tìm lại một hóa đơn đã phát hành tháng trước theo số của nó, và kết quả trả về 2 tờ. Vậy chúng ta đang nói về tờ nào? Con số ấy không còn quyết định được nữa. Số hóa đơn là cái tên để về sau chỉ đúng 1 chứng từ. Ngay khi một cái tên bị dùng chung, nó đã thôi làm việc như một cái tên.
Xin nói qua bối cảnh. Trong KAZENA Books, mỗi bộ sổ tự quyết định cách tạo số hóa đơn của mình: tiền tố, năm và số thứ tự 4 chữ số. Còn 1 thiết lập nữa, là khi nào số thứ tự quay về 1. Trước đây chỉ có lựa chọn theo từng năm. Vì đề nghị đặt lại theo từng tháng cứ liên tục gửi đến, tháng 6 chúng tôi đã thêm lựa chọn đó.
Vấn đề là có 2 nơi tách rời cùng quyết định những chuyện liên quan đến con số. Nơi thứ nhất quyết định số được ghép lại ra sao, tức tiền tố, năm và số thứ tự nối với nhau thế nào. Nơi thứ hai quyết định khi nào số thứ tự quay về 1. Tháng 6 tôi chỉ sửa nơi thứ hai. Số thứ tự quả thật quay về 1 mỗi tháng, nhưng bản thân tháng thì chưa bao giờ đi vào trong con số. Hóa đơn đầu tiên của tháng 7 và hóa đơn đầu tiên của tháng 8 vì thế cho ra cùng một chuỗi ký tự.
Tôi đã định sửa cả hai nơi. Đó là sự thật: tôi không quên nơi còn lại, mà sửa xong một nơi là tôi tưởng đã xong. Bởi vì quy tắc ấy, với tôi, trông như 1 quy tắc. Trong đầu tôi, thứ giữ cho một con số không lặp lại là 1 ý niệm. Trong mã nguồn, nó bị tách làm 2 và hai nửa nằm cách xa nhau.
Các bài kiểm thử cũng bị chia y như vậy. Bài kiểm thử phần ghép kiểm tra xem tiền tố, năm và số thứ tự có nối đúng hay không. Bài kiểm thử phần đặt lại kiểm tra xem số thứ tự có quay về 1 khi sang tháng mới hay không. Sau thay đổi hồi tháng 6, cả hai đều xanh. Mỗi bên đều kiểm thử đúng nửa phần của mình. Một quy tắc bị cắt làm 2 thì cũng cắt luôn phần kiểm thử của nó làm 2, và nhìn từ cả hai phía của vết cắt thì không có gì trông sai cả.
Chúng tôi đã đếm. Có 612 bộ sổ đang hoạt động, và 31 bộ trong số đó chọn cách đặt lại theo tháng mà chúng tôi thêm hồi tháng 6. Từ ngày 1 tháng 7 đến ngày 20 tháng 8, có 58 hóa đơn trùng số với một hóa đơn khác trong cùng bộ sổ, trải trên 12 bộ sổ. Tôi có thể nói rằng như vậy là không nhiều. Chỉ có điều, 58 tờ ấy đã đến tay phía đối tác rồi.
Còn 1 nơi nữa. Người tìm ra là E, đồng nghiệp của chúng tôi. Anh sống ở một thị trấn nhỏ cách Jakarta khá xa, và trước mỗi lần phát hành anh luôn dùng thử toàn bộ ứng dụng trên máy của chính mình. Khi anh bấm nút nhân bản một hóa đơn, tờ mới hiện ra với số lớn hơn tờ gốc 1 đơn vị. Nhánh đó có đoạn mã cấp số riêng của nó, một cách đếm thứ ba, không nhìn tháng mà cũng không nhìn năm. Từ nhánh này phát sinh thêm 4 trường hợp trùng số.
Đây là những gì chúng tôi đã sửa. Bây giờ số chỉ được cấp ở 1 nơi. Màn hình tạo từng hóa đơn, tiến trình tạo hóa đơn định kỳ và nút nhân bản đều gọi cùng một đoạn xử lý. Bên gọi chỉ đưa vào bộ sổ, còn hình dạng, cách đặt lại và con số kế tiếp thì bên gọi không quyết định được. Với những bộ sổ chọn đặt lại theo tháng, nay tháng đã nằm trong con số.
Chúng tôi cũng viết quy tắc ấy vào chính dữ liệu: trong 1 bộ sổ, một số chỉ được dùng một lần. Mọi thứ ở trên là chuyện mã nguồn được viết ra sao; dòng này tồn tại để chúng tôi không phải dựa vào chuyện mã nguồn được viết ra sao. Nếu một ngày nào đó có người viết ra nhánh thứ tư, con số sẽ không lưu được và công việc dừng lại ở đó. Dừng lại vẫn hơn là lặng lẽ phát hành tờ thứ hai.
Chúng tôi không đánh số lại cho 58 hóa đơn đã phát hành. Từ lâu chúng tôi đã quyết định không tự ý sửa các con số trong sổ sách của người khác theo phán đoán của mình. Chúng tôi đã liên hệ riêng với 12 doanh nghiệp bị ảnh hưởng và gửi danh sách những hóa đơn trùng số. Việc có đổi số hay không liên quan đến chứng từ đã trao cho khách hàng, nên đó không phải là điều chúng tôi quyết định thay được.
Xin nói rõ: tôi không phải là chuyên gia thuế. Yêu cầu đối với số hóa đơn khác nhau tùy từng nước, và việc một số đã phát hành có được sửa hay không còn phụ thuộc vào quy định của nước đó và vào tình huống của giao dịch. Những gì viết ở đây là ghi chép về việc chúng tôi sửa lại sản phẩm của chính mình. Với bất cứ điều gì bạn thực sự phải quyết định, xin hãy xác nhận với một chuyên gia.
Ngay khi một quy tắc được viết ở 2 nơi, đã chắc chắn rằng một trong hai sẽ cũ đi. Chỉ còn lại câu hỏi là bao giờ. Tôi từng nghĩ mình là người cẩn thận. Điều tôi học được lần này không phải là tôi cần cẩn thận hơn, mà là chỗ này lẽ ra không nên được chống đỡ bằng sự cẩn thận. Nếu bạn thấy trong KAZENA có cùng một thứ mang 2 con số hoặc 2 cái tên, xin hãy cho chúng tôi biết. Từ chỗ chúng tôi đứng, cả hai đều trông đúng.
Hãy cho chúng tôi biết bạn nghĩ gì
Cảm giác khi dùng các ứng dụng KAZENA, điều gì chúng tôi nên sửa, những tính năng bạn ước có — nếu bạn đang điều hành một doanh nghiệp nhỏ hoặc vừa, hay làm nghề tự do ở Indonesia hoặc Philippines, tiếng nói của bạn chính là điều chúng tôi mong được nghe nhất. Những tin nhắn bằng tiếng Indonesia hoặc tiếng Anh sẽ được trả lời bởi các đồng đội hiểu thị trường của bạn từ bên trong. KAZENA Books đã được ấn định ra mắt tại Philippines và Indonesia — và nếu công ty của bạn muốn đưa nó đến các quốc gia khác với tư cách đối tác, hoặc quan tâm đến việc mua lại hệ thống, chúng tôi cũng rất mong nhận được liên hệ từ bạn. Chúng tôi cũng nhận phát triển hệ thống mới. Chúng tôi là một đội nhỏ, nên không phải lúc nào cũng có thể bắt tay ngay — nhưng những gì chúng tôi xây dựng đều mang chất lượng made-in-Japan và luôn bám sát cách công việc kinh doanh thực sự vận hành ở đây, từng dự án một.
Liên hệ với chúng tôi