Nguyên lý bảo toàn trong phân hệ kho

Câu trả lời ấy không sai về mặt thao tác, tuy nhiên nó bỏ lỡ đúng chỗ người dùng đang vướng. Cái giá lộ ra vài tuần sau, khi báo cáo tồn kho lệch với cuốn sổ tay mà kho vẫn ghi song song: không ai trong kho tự truy được con số lệch nằm ở đâu, nên mọi câu hỏi dồn về đội triển khai, còn đội triển khai thì mở từng phiếu ra đọc như đọc một chồng chứng từ giấy.

Câu hỏi hôm đó không phải câu hỏi thao tác mà là câu hỏi về nguyên lý.

Toàn bộ phần cơ chế trong bài này tôi mô tả trên Odoo 19, và đây là loại nội dung bạn phải dựng lại trên đúng bản mình đang chạy chứ không nên tin theo trí nhớ.

Một quy tắc thay cho cả bảng danh mục phiếu

Phần kho chỉ có đúng một nguyên lý, và nó gọn tới mức đáng nói trước cả cái phiếu đầu tiên.

Hàng hóa không tự sinh ra và cũng không tự mất đi, mọi biến động tồn kho chỉ là một lần dịch chuyển từ vị trí này sang vị trí khác.

Nói theo ngôn ngữ của hệ thống thì mỗi dịch chuyển đều có hai đầu, một vị trí nguồn và một vị trí đích, và số lượng rời khỏi đầu này đúng bằng số lượng tới đầu kia. Do đó trong dữ liệu không tồn tại thao tác cộng thêm một trăm cái vào kho mà không kèm theo chỗ mà một trăm cái đó đi ra.

Cái lợi của cách nhìn này là nó thay được việc học thuộc. Người học phân hệ Kho theo lối đếm phiếu phải nhớ từng loại phiếu dùng vào việc gì, và tới lúc khách hàng đưa ra một nghiệp vụ mà danh sách kia không có tên thì người đó đứng lại. Còn người nắm nguyên lý thì với nghiệp vụ nào cũng chỉ hỏi hai câu, là hàng đi từ đâu và hàng tới đâu.

Có một chi tiết kỹ thuật củng cố thêm cho cách nhìn này, và tôi vẫn nhắc nó mỗi lần có người mới vào dự án kho. Trên Odoo 19, phiếu nhập kho với phiếu xuất kho về bản chất dùng chung một biểu mẫu trong cùng một đối tượng dữ liệu, chúng chỉ khác nhau ở loại hoạt động được chọn.

Vì vậy nếu bạn ngồi viết hai tài liệu phân tích tách rời cho hai loại phiếu đó thì bạn đang mô tả cùng một thứ hai lần, và hệ quả thường thấy là hai yêu cầu tùy biến trùng nhau được báo giá thành hai hạng mục.

Bảy loại vị trí trên Odoo 19

Để nguyên lý trên đứng vững, hệ thống buộc phải có chỗ đại diện cho những nơi nằm ngoài kho của doanh nghiệp.

Hàng mua về thì phải rời khỏi một chỗ nào đó, còn hàng bán đi thì phải tới một chỗ nào đó, và trên Odoo 19 trường Location Type có đúng bảy giá trị cho việc này.

• Loại Internal là các vị trí vật lý bên trong kho, tức nhóm duy nhất tương ứng với chỗ có thật
• loại Virtual dùng để dựng cây phân cấp cho kho bằng cách gom các vị trí con lại, và bản thân nó không chứa hàng trực tiếp
• loại Vendor là vị trí nguồn đại diện cho hàng đến từ nhà cung cấp
• loại Customer là vị trí đích đại diện cho hàng gửi tới khách.

Ba loại còn lại là:

• Inventory Loss, tức vị trí đối ứng cho các thao tác chỉnh mức tồn và trên giao diện tiếng Việt mang nhãn Thất thoát tồn kho
• Production, tức nơi nguyên vật liệu bị tiêu thụ và thành phẩm sinh ra
• và Transit, dành cho nghiệp vụ giữa hai kho hoặc hai công ty.

Cách dùng loại Transit cho bài toán hàng đang trên đường đã có bài riêng.

Hai chỗ nhỏ nên nhớ khi đọc màn hình thật: loại nhà cung cấp hiển thị bằng chữ Vendor chứ không phải Supplier, còn loại Transit trên bản 19 vẫn chưa được dịch nên giao diện tiếng Việt vẫn hiện nguyên chữ Transit.

Cần lưu ý rằng bạn sẽ gặp không ít bảng tổng hợp chỉ có sáu dòng, kể cả ghi chép cũ của chính tôi, và dòng hay bị sót là loại Virtual dùng để gom nhóm. Tôi nêu ra đây để bạn thấy rằng tài liệu đào tạo lẫn bài viết trên mạng đều có thể thiếu một dòng so với hệ thống thật, và cách chắc nhất là mở chính trường đó trên hệ thống của dự án ra đếm.

Năm nghiệp vụ đọc bằng cùng hai câu hỏi

Khi đã có bộ vị trí đó, các nghiệp vụ kho mà bạn vẫn học rời rạc hiện ra như cùng một việc lặp lại với hai đầu khác nhau.

Nhập hàng mua về là một dịch chuyển từ vị trí Vendor vào vị trí nội bộ của kho. Hàng không xuất hiện từ hư không, nên trong lịch sử dịch chuyển bạn luôn đọc được cả hai đầu chứ không chỉ một con số cộng thêm.

Xuất bán là chiều ngược lại, tức từ vị trí nội bộ tới vị trí Customer. Đặc biệt, ở đây có một cái bẫy mà người mới hay dính: nhìn thấy một phiếu xuất kho rồi mặc định đó là bán hàng, trong khi phiếu trả hàng cho nhà cung cấp cũng là phiếu xuất, chỉ khác ở chỗ vị trí đích của nó là Vendor chứ không phải Customer.

Trên Odoo 19, trường Source Document của phiếu trả hàng ghi tham chiếu tới phiếu nhập kho gốc, dạng Return of kèm số phiếu nhập, chứ không ghi số đơn mua, dù phía dưới hệ thống vẫn nối phiếu trả về dòng đơn mua để trừ số lượng đã nhận. Do đó khi truy vết, hai đầu của dịch chuyển nói cho bạn nhiều hơn là tên loại phiếu hay ô chứng từ gốc.

Kiểm kê là chỗ nguyên lý này thể hiện rõ nhất, bởi trực giác thông thường cho rằng chênh lệch kiểm kê thì bốc hơi khỏi hệ thống. Trên Odoo 19 thì không có gì bốc hơi cả. Khi số đếm nhỏ hơn số hệ thống, phần thiếu được ghi thành một dịch chuyển từ vị trí kho sang vị trí đối ứng kiểm kê thuộc loại Inventory Loss; khi số đếm lớn hơn, phần dư được ghi thành một dịch chuyển theo chiều ngược lại.

Nhờ vậy phần chênh lệch không biến mất mà nằm lại ở một chỗ đọc được, có thời điểm, có người thao tác. Việc dựa vào con số đó để quy trách nhiệm cho ai thì không thuộc phạm vi hệ thống, và ranh giới ấy đã có một bài riêng.

Sản xuất đi theo đúng khuôn ấy với vị trí đối ứng là loại Production: nguyên vật liệu chuyển từ kho vào vị trí sản xuất và rời khỏi tồn kho ở đó, còn thành phẩm chuyển từ vị trí sản xuất vào kho. Loại hoạt động Manufacturing chỉ xuất hiện sau khi phân hệ Sản xuất được cài đặt, nên trên hệ thống chỉ có phân hệ Kho thì trường Type of Operation chỉ có ba giá trị là Receipt, Delivery và Internal Transfer. Phần định mức nguyên liệu thì có bài riêng.

Hủy hàng dùng chung loại vị trí đối ứng với kiểm kê, tức hàng chuyển từ vị trí nội bộ sang một vị trí thuộc loại Inventory Loss, và trường Scrap Location trên phiếu hủy chỉ cho chọn đúng những vị trí thuộc loại đó. Đây chính là câu trả lời cho câu hỏi ở đầu bài. Hệ thống bắt chọn vị trí không phải vì thừa một ô, mà vì những món hàng hỏng kia phải đi đâu đó thì mới rời được khỏi tồn kho.

Muốn tự thấy nguyên lý này bằng số thì có một phép thử mất chừng mười phút trên database sạch:

1. tạo một sản phẩm mới
2. nhập mười cái từ nhà cung cấp
3. xuất ba cái cho khách
4. rồi kiểm kê đặt tồn thực tế xuống năm.

Đọc tồn theo từng vị trí, bạn thấy vị trí khách hàng mang số ba, vị trí đối ứng kiểm kê mang số hai, kho nội bộ còn năm, và vị trí nhà cung cấp mang số âm mười. Cộng lại đúng bằng không, và chính con số âm mười kia là cách hệ thống nói rằng mười cái hàng ấy được chuyển sang từ một vị trí ảo chứ không sinh ra từ hư không.

Đường truy một con số lệch

Khi khách hàng nói tồn kho sai, thứ bạn cần không phải một cuộc đối chiếu thủ công mà là một trình tự đọc dữ liệu, và trình tự đó rơi thẳng ra từ nguyên lý ở trên.

Điểm quan trọng nhất là đọc hai cột vị trí trước khi đọc tên phiếu. Lý do rất thực tế: tên loại hoạt động do người dùng đặt và người dùng sửa được, nên chuyện gặp một loại hoạt động mang tên kho tổng nhưng vị trí đích lại trỏ sang kho khác là chuyện tôi đã thấy xảy ra thật trong vận hành.

Tên phiếu là thứ người ta khai báo, còn cặp vị trí nguồn và vị trí đích là thứ đã thực sự diễn ra.

Trình tự dùng được khi phải truy một chênh lệch:

• Lọc lịch sử dịch chuyển theo đúng mã sản phẩm và khoảng thời gian đang nghi ngờ
• Đọc cột vị trí nguồn và vị trí đích trước, đọc tên loại phiếu sau
• Tách riêng những dòng có một đầu là vị trí ảo, vì đó là chỗ hàng ra vào khỏi phạm vi doanh nghiệp
• Mở chứng từ gốc của từng dòng còn lại để biết dòng đó sinh ra từ đơn nào và do ai xác nhận
• Rà các phiếu chưa xác nhận trên hệ thống trước khi kết luận, vì thao tác thật ở kho luôn chạy trước dữ liệu

Bên cạnh đó, hãy nhớ rằng con số ở mục số lượng hiện có là số của hệ thống chứ không phải số thực tế trên kệ, và hai con số chỉ bằng nhau khi mọi chứng từ đã được xác nhận đúng thời điểm. Không nói rõ chỗ này khi hướng dẫn thì tới lần kiểm kê đầu tiên người dùng sẽ tin rằng hệ thống ghi sai, trong khi thứ đang trễ là chứng từ.

Bộ câu hỏi khảo sát kho rút ra từ nguyên lý

Nguyên lý này cũng đổi cách bạn ngồi khảo sát, bởi nó thay câu hỏi liệt kê bằng câu hỏi về ranh giới.

Thay vì hỏi doanh nghiệp đang dùng những loại phiếu kho nào, một câu mà kho sẽ trả lời theo đúng những gì họ quen tay, bạn nên hỏi ba câu khác:

• hàng có thể vào kho từ những nguồn nào
• hàng có thể rời kho đi những đâu
• và có trạng thái nào mà hàng vẫn thuộc về doanh nghiệp nhưng không nằm trong bất kỳ kho nào không.

Hai câu đầu cho ra danh sách các đầu đối ứng phải được mô hình hóa, còn câu thứ ba là câu làm lộ ra những nghiệp vụ mà cấu hình mặc định không mô tả sẵn.

Trong trường hợp doanh nghiệp có hàng ký gửi tại đại lý, hàng cho khách mượn dùng thử, hoặc hàng gửi đi gia công ngoài, câu thứ ba sẽ bật ra ngay tại bàn họp. Mỗi tình huống như vậy buộc hai bên chốt một câu hỏi thiết kế trước khi nói tới thao tác: hàng ở trạng thái đó được coi là vẫn nằm trong tồn kho hay đã ra khỏi.

Câu trả lời quyết định báo cáo tồn hiển thị con số nào, và quyết định luôn việc bán hàng có được hứa giao phần hàng đó cho khách khác hay không.

Bộ câu hỏi khảo sát đầy đủ theo từng chu trình nghiệp vụ là một chủ đề đã có bài riêng, ba câu trên chỉ là phần rút ra từ nguyên lý cho nhóm kho vận. Chuyện hệ thống tự sinh các dịch chuyển tiếp theo theo tuyến cung ứng cũng là chủ đề riêng, ở đây bạn chỉ cần biết việc tự sinh đó không phá vỡ nguyên lý mà chỉ nối các chặng lại với nhau.

Giới hạn của cách nhìn này

Nguyên lý bảo toàn giải thích được đường đi của số lượng, và chỉ số lượng.

Trước hết, nó không nói gì về giá trị. Tổng số lượng luôn cân bằng qua hai đầu của một dịch chuyển, nhưng giá trị tồn kho lại phụ thuộc vào Costing Method được cấu hình ở danh mục sản phẩm, mặc định lấy theo thiết lập chung của công ty, nên hai lần xuất cùng một số lượng của cùng một mã hàng vẫn có thể cho ra hai giá trị khác nhau. Mọi tranh luận về con số giá vốn phải giải ở phần cấu hình đó, chứ không giải bằng cách đọc lịch sử dịch chuyển.

Tiếp theo, bảo toàn về mặt sổ sách không đồng nghĩa với hợp lý về mặt vật lý. Trên Odoo 19, tồn của một sản phẩm ở một vị trí nội bộ vẫn có thể xuống âm, chẳng hạn khi phiếu xuất được xác nhận trước phiếu nhập tương ứng, và hệ thống có sẵn bộ lọc Negative Stock trên danh sách tồn kho chính vì chuyện này xảy ra trong vận hành.

Màn hình Physical Inventory cũng liệt kê mọi dòng tồn khác không ở các vị trí nội bộ và trung chuyển, tức có cả những dòng âm chứ không chỉ dòng dương. Tổng mọi vị trí lúc đó vẫn bằng không, nhưng không cái kệ nào chứa được âm năm món hàng, nên trước khi đưa tình huống này vào tài liệu phân tích, bạn nên dựng lại nó trên hệ thống của dự án để thấy nó hiện ra thế nào và chốt với khách cách xử lý.

Nắm nguyên lý này rồi thì phân hệ Kho không còn là một tập hợp phiếu phải học thuộc; còn khi hàng đã rời kho tới vị trí đại diện khách hàng thì phần việc chuyển sang một chứng từ khác và một câu hỏi khác, đó là hóa đơn trong Odoo được sinh ra từ đâu và nó ăn khớp thế nào với tờ hóa đơn đỏ mà kế toán Việt Nam phải phát hành.