Nhật ký điều chỉnh tồn kho: mã lý do và lịch sử kiểm toán

Tại sao cần giải thích rõ ràng các thay đổi tồn kho

Một điều chỉnh tồn kho là thay đổi thủ công trên số lượng hệ thống báo bạn có. Bạn không nhận hàng hay xuất hàng. Bạn sửa số vì thực tế và sổ sách không khớp.

Nghe có vẻ đơn giản, nhưng đó là một trong những cách nhanh nhất khiến người ta mất niềm tin vào dữ liệu. Nếu ghi chú chỉ là “đã thay đổi tồn”, không ai biết thay đổi đó là bình thường, do lỗi, hay cần điều tra. Trong kiểm toán, “chúng tôi đã sửa” không phải là bằng chứng. Quản lý và kiểm toán viên muốn thấy chuyện gì đã xảy ra, ai làm, khi nào và tại sao được phép.

Hầu hết điều chỉnh đến từ các tình huống thực tế giống nhau: hàng bị hỏng hoặc hết hạn, mất mát, đếm lại cho kết quả khác, nhà cung cấp giao thiếu, hoặc phát hiện lỗi chọn/đóng gói sau khi đã xong.

Mã lý do rõ ràng giúp bạn tách “tổn thất chấp nhận được” (như hư hỏng) khỏi “tổn thất không chấp nhận” (như trộm) và khỏi “nhiễu quy trình” (như hiệu chỉnh đếm). Điều đó giúp dễ nhìn ra xu hướng, dễ sửa nguyên nhân gốc, và bảo vệ số liệu của bạn.

“Lịch sử vĩnh viễn” nghĩa là bạn không ghi đè quá khứ. Mỗi thay đổi được lưu thành bản ghi riêng, với số trước và số sau cùng chi tiết quyết định. Nếu ai đó sau đó sửa lý do hoặc ghi chú, việc sửa đó cũng phải được ghi lại. Điều này quan trọng vì tồn kho ảnh hưởng đến kết quả tài chính. Nếu bạn không thể trình bày được lịch sử, bạn không thể chứng minh số liệu.

Nhiều nhóm bắt đầu với bảng tính. Khi khối lượng tăng, đưa nhật ký vào một app nội bộ đơn giản với quyền và audit trail giúp lịch sử nhất quán hơn và khó bị bỏ qua.

Mã lý do và audit trail: định nghĩa đơn giản

Nhật ký điều chỉnh tồn kho chỉ có tác dụng khi trả lời được một câu hỏi mỗi lần: tại sao hàng thay đổi? Hai công cụ làm điều đó khả thi: mã lý do và audit trail.

Mã lý do (và tại sao tốt hơn văn bản tự do)

Mã lý do là nhãn ngắn, chuẩn được chọn từ danh sách, ví dụ: Damage (hư hỏng), Theft (trộm), Recount correction (hiệu chỉnh đếm), Expired (hết hạn), hoặc Supplier short-ship (nhà cung cấp giao thiếu). Nó buộc tính nhất quán để báo cáo có thể gom nhóm thay đổi mà không phải đoán ý người ghi.

Ghi chú văn bản tự do vẫn quan trọng nhưng không thay thế được mã. Ghi chú giải thích chuyện gì đã xảy ra và đã kiểm tra gì. Mã lý do phân loại sự kiện. Nếu chỉ dựa vào ghi chú, bạn sẽ có mười cách khác nhau để viết cùng một ý (“broken”, “damaged”, “cracked”, “fell”), và dữ liệu trở nên không so sánh được.

Audit trail (không chỉ là activity log)

Activity log có thể ghi “Số lượng thay đổi từ 12 xuống 9.” Audit trail giải thích cách điều đó xảy ra và liệu nó có tuân theo quy tắc hay không.

Một audit trail tốt lưu ai đã thay đổi và khi nào, gì đã thay đổi (mặt hàng, vị trí, số lượng trước và sau), và tại sao nó thay đổi (mã lý do cộng với ghi chú).

Cho kiểm toán, bạn cũng cần bằng chứng hỗ trợ. Đó có thể là ảnh bao bì hỏng, phiếu đếm, giấy tờ trả hàng, biên bản tiêu huỷ, tham chiếu hóa đơn nhà cung cấp, hoặc số ticket/sự cố. Mục đích không phải gom giấy tờ cho thật nhiều, mà để làm cho điều chỉnh có thể bảo vệ được vài tháng sau.

Phê duyệt tăng cường truy vết. Nếu quản lý phê duyệt, audit trail phải cho thấy ai phê duyệt, khi nào, và họ phê duyệt điều gì (bao gồm cả sửa đổi nếu có). Nếu bạn xây luồng trong AppMaster, bạn có thể yêu cầu chọn mã lý do và giữ lịch sử vĩnh viễn để sửa đổi không ghi đè bản gốc.

Vai trò và trách nhiệm cho điều chỉnh

Một điều chỉnh không bao giờ chỉ là “thay đổi số”. Nếu không rõ ai được phép thay đổi tồn, khi nào được phép và ai kiểm tra sau, nhật ký điều chỉnh sẽ trở thành nơi giấu lỗi.

Bắt đầu bằng việc xác định ai được tạo điều chỉnh. Ở nhiều kho, đó là đội phát hiện vấn đề đầu tiên: nhận hàng (giao thiếu), trả hàng (hỏng), hoặc nhân viên sàn trong đợt kiểm kê. Riêng biệt, xác định ai được phê duyệt, ai được đăng, và ai xem xu hướng.

Phê duyệt là nơi bạn vạch ranh giữa “thông thường” và “nhạy cảm”. Một xóa sổ hư hỏng nhỏ có thể tự động được chấp thuận, trong khi mọi thứ có giá trị cao, lặp lại hoặc bất thường cần người thứ hai duyệt. Dùng ngưỡng rõ ràng (theo giá trị, số lượng, loại SKU hoặc mã lý do) để quy tắc luôn giống nhau.

Xem xu hướng là công việc khác với phê duyệt. Finance quan tâm tác động định giá, ops quan tâm lỗi quy trình, và loss prevention tìm mô hình trộm. Việc xem xét nên diễn ra theo lịch (hàng tuần hoặc hàng tháng), không chỉ khi có sự cố.

Để giảm lạm dụng, tách nhiệm vụ để không ai có thể tạo, phê duyệt và đóng vòng một mình. Giữ đơn giản: người tạo và người phê duyệt nên khác nhau, người phê duyệt không nên sửa chi tiết gốc (chỉ phê duyệt hoặc từ chối), và quyền “admin override” nên hạn chế và được ghi nhật ký.

Nếu sau này bạn tự động vai trò và phê duyệt trong AppMaster, bạn có thể dựng quy tắc quyền và luồng phê duyệt đơn giản không cần code trong khi vẫn giữ lịch sử vĩnh viễn ai làm gì và khi nào.

Những trường hồ sơ nên có trong nhật ký điều chỉnh

Nhật ký điều chỉnh chỉ hữu ích nếu người khác đọc được sau này và hiểu chuyện gì đã xảy ra, ai làm và tại sao được phép. Hãy coi nó như biên nhận cho mỗi thay đổi tồn kho.

Bắt đầu với phần header nhất quán: ngày giờ, vị trí (kho, cửa hàng, vùng thùng), người tạo, và nguồn (kiểm kê, trả hàng khách, báo cáo hư hỏng, đồng bộ hệ thống, v.v.).

Rồi lưu chi tiết từng dòng cho mỗi mặt hàng. Kiểm toán thường thất bại vì đội chỉ lưu thay đổi ròng, không có hình ảnh trước và sau.

Ở cấp dòng, lưu SKU (và lô/seri/hạn nếu dùng), số trước, thay đổi số lượng (+ hoặc -), số sau, và đơn vị đo (chiếc, thùng, kg) để chuyển đổi không làm sai dữ liệu. Thêm mã lý do cộng ghi chú ngắn. Nếu bằng chứng ở nơi khác, lưu tham chiếu tệp đính kèm (ID ảnh, số phiếu đếm, số ticket) để chuỗi chứng cứ còn nối được.

Phê duyệt quan trọng như con số. Theo dõi trạng thái phê duyệt, tên hoặc vai trò người duyệt, và dấu thời gian cho các trạng thái tạo, gửi, phê duyệt và đăng. Nếu cho sửa, ghi ai sửa và khi nào, và giữ lại giá trị trước đó.

Cuối cùng, mỗi điều chỉnh cần một ID điều chỉnh duy nhất không bao giờ thay đổi. Nó nên có thể tìm kiếm và xuất hiện trên tài liệu liên quan (phiếu đếm, giấy tờ trả hàng). Trong công cụ nội bộ, sinh ID tự động và khoá các điều chỉnh đã đăng để lịch sử sạch sẽ.

Thiết kế mã lý do mà mọi người sẽ dùng thực sự

Mã lý do chỉ có tác dụng nếu người ta có thể chọn đúng trong vài giây. Nếu danh sách dài, mơ hồ hoặc đầy “khác”, nhật ký thành đoán mò và kiểm toán rối.

Bắt đầu nhỏ. Một bộ mã ngắn tốt hơn một phân loại hoàn hảo mà không ai dùng. Chỉ thêm mã khi thấy cùng một giải thích xuất hiện nhiều lần trong ghi chú.

Một bộ khởi đầu thực dụng thường bao phủ các nhóm chính: hư hỏng (bao gồm hết hạn), trộm/mất, hiệu chỉnh đếm, sự cố nhà cung cấp (giao thiếu hoặc sai hàng), và trả hàng.

Giữ mã ít chồng chéo khi có thể. Ví dụ, “Recount correction” không nên dùng cho một món bị vỡ tìm thấy khi đếm lại. Đó vẫn là “Damage”. Việc đếm lại là cách bạn phát hiện, không phải lý do gây ra.

Hãy làm cho mỗi mã mang các chi tiết cần sau này. “Damage” một mình quá mơ hồ. Yêu cầu vài trường bổ sung phù hợp với mã, như loại hư hỏng (bẹp, rò rỉ, hết hạn) và nơi xảy ra (bến nhận, khu chọn/đóng gói, vận chuyển). Với “Supplier issue”, lưu số PO và là giao thiếu, sai hàng hay lỗi.

Việc chấp nhận tốt hơn khi mã dùng ngôn ngữ đơn giản, loại bỏ chồng chéo, giới hạn “Khác” (và luôn yêu cầu ghi chú), và rà soát sử dụng hàng tháng để loại mã không dùng.

Cuối cùng, quyết định mã nào cần phê duyệt. Trộm, xóa sổ lớn và mọi điều chỉnh trên ngưỡng thường cần chữ ký quản lý. Hiệu chỉnh đếm nhỏ thì có thể không.

Bước từng bước: cách ghi một điều chỉnh đúng

Một điều chỉnh không nên bắt đầu bằng “chỉ sửa số”. Nó bắt đầu bằng phát hiện sai lệch, rồi xác minh, và chỉ sau đó thay đổi tồn.

Một quy trình đơn giản chịu được kiểm toán

Đầu tiên, ghi lại sai lệch và ngữ cảnh: xuất hiện ở đâu (kho, thùng, SKU, tài liệu) và ai phát hiện.

Tiếp theo, xác minh trước khi thay đổi. Đếm lại nhanh, kiểm tra thùng xung quanh xem có đặt nhầm không, rà soát giấy tờ nhận và xuất, và xác nhận đơn vị đo (case vs each là bẫy phổ biến). Nếu sai lệch liên quan đơn hàng, ghi số đơn.

Rồi nhập điều chỉnh nhất quán: chọn đúng mặt hàng và vị trí (và lô/seri nếu dùng), nhập thay đổi số lượng với dấu đúng, chọn một mã lý do, và thêm ghi chú ngắn giải thích bạn đã kiểm tra gì và phát hiện ra điều gì. Thêm tham chiếu bằng chứng (ID ảnh, số phiếu đếm, RMA, số ticket) và nộp phê duyệt nếu chính sách yêu cầu.

Sau khi đăng, đảm bảo hệ thống giữ giá trị gốc, giá trị mới, dấu thời gian và người thực hiện. Nếu dùng phê duyệt, lưu người duyệt và thời gian duyệt.

Đừng bỏ qua bước theo dõi

Đặt lịch xem tóm tắt điều chỉnh hàng ngày hoặc hàng tuần. Tìm mẫu: hư hỏng lặp ở một khu, hiệu chỉnh đếm thường gặp ở một SKU, hoặc quá nhiều lý do “không xác định”. Nếu dựng quy trình trong AppMaster, bạn có thể bắt buộc mã lý do, áp ngưỡng phê duyệt và cung cấp màn hình rà soát đơn giản cho giám sát mà không thêm việc cho nhân viên.

Cách giữ lịch sử thay đổi vĩnh viễn

Lịch sử vĩnh viễn nghĩa là bạn có thể trả lời ba câu hỏi vài tháng sau mà không đoán: gì đã thay đổi, ai làm và tại sao. Cách đơn giản nhất là coi điều chỉnh như bút toán kế toán. Bạn ghi sự kiện. Bạn không viết lại quá khứ.

Làm cho mục đã đăng bất biến

Một khi điều chỉnh được đăng, giữ lại giá trị gốc và lưu mọi thay đổi như bản ghi mới. Tránh sửa số trên một dòng cũ, dù cảm thấy nhanh hơn. Ghi đè làm mất bối cảnh và khiến kiểm toán đau đầu.

Mỗi mục đã đăng nên bao gồm số trước và sau (không chỉ khác biệt), người tạo và người duyệt (nếu cần), dấu thời gian cho cả hai hành động, mã lý do và ghi chú, và ID điều chỉnh duy nhất.

Không cho phép xoá mục đã đăng. Nếu ai đó sai, dùng đảo ngược: tạo điều chỉnh mới huỷ điều chỉnh sai, rồi thêm điều chỉnh đúng. Điều này giữ lịch sử nguyên vẹn và cho thấy sửa là có chủ ý.

Khi sửa lỗi xảy ra thường xuyên (ví dụ, đếm lại phát hiện số lần đầu sai), liên kết điều chỉnh theo sau với bản gốc bằng trường “related adjustment ID”.

Thiết lập quy tắc lưu giữ và truy cập

Quyết định lưu lịch sử điều chỉnh và ghi chú hỗ trợ trong bao lâu. Nhiều đội giữ vài năm vì kiểm toán có thể quay lại xa.

Hạn chế ai có thể đăng, phê duyệt hoặc đảo ngược điều chỉnh, và ghi lại mọi thay đổi về quyền. Nếu tự động hóa trong AppMaster hoặc công cụ nội bộ nào đó, làm cho quy tắc “chỉ ghi thêm” là một phần của workflow, không chỉ là thói quen.

Lỗi phổ biến phá hỏng khả năng kiểm toán

Hầu hết vấn đề tồn kho không đến từ một lỗi lớn. Nó xảy ra khi các bước tắt ngấm dần, và rồi không ai giải thích được cái gì thay đổi, khi nào và tại sao.

Một vấn đề phổ biến là quá nhiều mã lý do. Khi danh sách dài hoặc khó hiểu, người ta ngừng suy nghĩ và bấm đại. Dữ liệu trông có tổ chức nhưng thực chất là ngẫu nhiên, báo cáo xu hướng trở nên không tin cậy.

Cạm bẫy khác là chỉ có ghi chú văn bản tự do. Ghi chú hữu ích, nhưng nếu mỗi điều chỉnh chỉ là một câu, bạn không thể gom, lọc hay so sánh nguyên nhân theo thời gian. Bạn sẽ phải đọc hàng trăm mục tay.

Những thay đổi tác động lớn cần kiểm soát hơn. Nếu ai cũng có thể xóa 500 đơn vị mà không qua người thứ hai, bạn có audit trail nhưng không chứng minh được tính hợp lệ.

Một vài mẫu workflow gây đau đầu lặp lại: chỉnh hàng loạt cập nhật nhiều mặt hàng cùng lúc mà không có lý do và số lượng theo từng dòng, thiếu chi tiết như vị trí hoặc lô/seri khi cần, và “dọn dẹp” bằng cách sửa các bản ghi cũ thay vì tạo mục sửa chữa mới.

Điểm quan trọng nhất là: audit trail là về lịch sử, không phải hoàn hảo. Nếu ai đó nhập -12 thay vì -2, cách sửa là tạo điều chỉnh mới đảo ngược lỗi, với mã lý do “sửa lỗi nhập liệu” và ghi chú ngắn. Điều đó giữ lịch sử rõ ràng.

Cách nhanh kiểm tra nhật ký: lấy mẫu 10 điều chỉnh và hỏi: một người mới có giải thích mỗi mục mà không cần hỏi không? Nếu không, thắt chặt các trường bắt buộc, giảm và làm rõ mã lý do, và thêm phê duyệt cho các thay đổi rủi ro thực sự.

Ví dụ tình huống: thiếu hàng sau đếm lại

Một đợt kiểm kê ở lối đi B phát hiện vấn đề: SKU “WIDGET-250” trên sổ phải có 200, nhưng người đếm thấy 188. Thiếu 12 đơn vị, và nhật ký điều chỉnh cần giải thích tại sao số thay đổi, chứ không chỉ rằng nó thay đổi.

Đầu tiên, người đếm kiểm tra cơ bản: xác nhận nhãn thùng trùng SKU, quét khu vực tràn, và kiểm tra không có đơn đang được lấy để ở trong tote. Người khác đếm lại. Kết quả vẫn là 188, nên không phải là đếm nhầm đơn thuần.

Bây giờ chọn mã lý do dựa trên bằng chứng. Nếu camera hoặc seal vỡ gợi ý mất mát, có thể chọn “theft”. Nếu khu vực giao hàng có đơn đã đóng gói nhưng chưa trừ tồn, đó là lỗi giao/ghi giao dịch. Nếu phát hiện số sổ sai do đếm trước đó, dùng “recount correction”. Quy tắc đơn giản: chọn lý do bạn có thể chứng minh.

Một mục mạnh sẽ khiến quyết định dễ theo dõi sau này. Nó bao gồm SKU và vị trí (và lô/seri nếu dùng), số trước (200) và sau (188), mã lý do và ghi chú ngắn tham chiếu bằng chứng (ID phiếu đếm, số ticket), ai yêu cầu và ai phê duyệt, dấu thời gian, và tham chiếu đính kèm nếu hệ thống hỗ trợ.

Kiểm toán viên sau đó có thể xác nhận ai đếm, ai phê duyệt, khi nào xảy ra, gì đã thay đổi (-12) và tại sao chọn lý do đó.

Danh sách kiểm tra nhanh cho quy trình điều chỉnh sạch sẽ

Quy trình điều chỉnh sạch không phải về đếm hoàn hảo mà là về ghi chép nhất quán. Nếu ai đó mở nhật ký sau sáu tháng, họ nên hiểu gì đã thay đổi, ai làm và tại sao chấp nhận được.

Trước khi đăng điều chỉnh, xác nhận những điều cơ bản: chọn mã lý do, thêm ghi chú ngắn giải thích chuyện gì xảy ra, ghi số trước và sau (để toán học rõ ràng), đảm bảo hệ thống tự động ghi người và thời gian, và đính kèm hoặc tham chiếu bằng chứng khi cần (ảnh, RMA, ID phiếu đếm, số ticket). Nếu mã yêu cầu phê duyệt, xin phê duyệt trước khi đăng.

Đặt các kích hoạt “cần phê duyệt” để nhân viên không phải đoán. Kích hoạt phổ biến: trộm hoặc nghi có trộm, xóa sổ trên ngưỡng, khác biệt đếm lớn, điều chỉnh gây tồn âm, và thay đổi ghi sổ về kỳ trước.

Bảo vệ lịch sử. Một khi điều chỉnh đã đăng, không được xoá. Nếu sai, đảo ngược nó bằng mục mới tham chiếu bản gốc và dùng mã đảo ngược/sửa chữa rõ ràng.

Bước tiếp theo: chuẩn hóa rồi tự động hóa

Chuẩn hóa những gì bạn đang làm. Lấy 30–90 ngày điều chỉnh gần nhất và liệt kê mọi “lý do” người ta gõ hoặc chọn. Bạn sẽ thấy lặp lại (và các mục mơ hồ như “misc” hoặc “fix”). Gom chúng thành một tập ngắn giải thích tại sao hàng thay đổi mà không gây tranh cãi.

Giữ danh sách đủ nhỏ để ghi nhớ. Nhiều đội kết thúc với 8–15 mã tên đơn giản phản ánh thực tế (damage, theft, supplier short-ship, recount correction, expired, customer return, production scrap). Giữ “Khác” chỉ khi nó luôn yêu cầu ghi chú.

Rồi khoá quyền ai làm gì. Nhật ký điều chỉnh không chỉ là bản ghi. Nó là công cụ kiểm soát. Xác định ai được tạo so với ai phê duyệt và đăng, đặt ngưỡng phê duyệt, quyết định bằng chứng cần cho các lý do rủi ro cao, và giữ rõ người chịu trách nhiệm cho từng vị trí.

Khi cơ bản ổn, thêm quy trình rà soát đơn giản. Một buổi rà soát 15 phút hàng tuần thường phát hiện sớm các mẫu: điều chỉnh lặp cho cùng một SKU, cùng ca hay cùng mã lý do.

Khi sẵn sàng vượt bảng tính, AppMaster có thể là cách thực tế để xây nhật ký điều chỉnh nội bộ với mô hình dữ liệu backed bởi PostgreSQL, trường bắt buộc, luồng phê duyệt và lịch sử chỉ ghi thêm ghi ai thay đổi gì và khi nào.