Giải bài toán bằng cấu hình: case hàng đang trên đường giữa hai kho

Lý do của cấu hình mặc định

Hiểu nguyên nhân trước thì phần giải pháp phía sau mới dùng lại được cho các bài toán khác.

Với cấu hình mặc định, một lần điều chuyển nội bộ được mô hình hóa thành một bước duy nhất, tức hàng rời vị trí tồn kho của kho gửi và tới thẳng vị trí tồn kho của kho nhận; vì chỉ có một bước nên cũng chỉ có một thời điểm ghi nhận, và thời điểm đó là lúc người của kho gửi xác thực phiếu, chứ không phải lúc hàng thật sự tới nơi. Cách mô hình hóa này đúng trong rất nhiều tình huống, chẳng hạn hai kho nằm cạnh nhau trong cùng một khuôn viên hoặc việc chuyển chỉ mất mươi phút, và ở những tình huống đó thì tách ra thành nhiều bước chỉ làm phiền người dùng chứ không mang lại gì.

Vấn đề chỉ xuất hiện khi quãng đường đủ dài để có một khoảng thời gian mà hàng không nằm ở kho nào cả. Lúc đó nghiệp vụ cần ba trạng thái gồm đã rời kho gửi, đang trên đường, đã vào kho nhận, trong khi cấu hình mặc định chỉ mô tả hai.

Do đó câu hỏi đúng không phải là hệ thống có tính năng quản lý hàng trên đường hay không, mà là hệ thống có cách nào phản ánh trạng thái thứ ba đó hay không.

Vị trí ảo và bảy loại vị trí

Câu trả lời nằm ở một khái niệm mà nhiều người dùng Odoo một thời gian vẫn chưa để ý tới, đó là không phải vị trí nào cũng là một chỗ có thật.

Trong hệ thống, mọi dịch chuyển hàng hóa đều là chuyển từ một vị trí sang một vị trí khác và tổng số lượng luôn được bảo toàn, nên bên cạnh các vị trí có thật còn có những loại vị trí ảo tồn tại chỉ để nguyên tắc đó không bị phá vỡ; bài về nguyên lý bảo toàn trong phân hệ kho đã đi hết bảy loại vị trí của Odoo 19. Ở đây bạn chỉ cần hai loại: loại trung chuyển dành cho hàng đang trên đường, là loại ít được dùng nhất trong các dự án và cũng là loại giải được đúng bài toán ở trên, và loại ảo dùng để gom nhóm mà bạn sẽ gặp ngay ở bước tiếp theo.

Nói cách khác, trạng thái thứ ba mà nghiệp vụ cần đã có sẵn một chỗ trong mô hình dữ liệu. Việc còn lại chỉ là dựng nó lên và nối vào luồng.

Ba bước cấu hình

Toàn bộ giải pháp gồm ba bước, và tôi ghi kèm lý do của từng bước để bạn biết chỗ nào được phép làm khác.

Bước thứ nhất là bật hai cấu hình trong phần cài đặt của phân hệ Kho, gồm vị trí kho và tuyến cung ứng nhiều bước. Cấu hình thứ nhất cho phép hệ thống làm việc với các vị trí chi tiết bên trong một kho thay vì coi cả kho là một khối; cấu hình thứ hai mở ra phần tuyến và quy tắc, tức phần bạn sẽ dùng ở bước ba.

Bước thứ hai là tạo vị trí trung chuyển cho từng kho. Mỗi vị trí như vậy được đặt nằm dưới vị trí ảo gom nhóm của chính kho đó, và loại vị trí chọn là loại trung chuyển. Nguyên tắc ở đây rất đáng nhớ: có bao nhiêu kho nội bộ thì tạo bấy nhiêu vị trí trung chuyển, kể cả những kho mà hiện tại bạn nghĩ sẽ không bao giờ nhận hàng từ kho khác. Lý do là chi phí tạo thêm một vị trí gần như bằng không, còn chi phí phát hiện thiếu một vị trí sau khi hệ thống đã chạy thì bao gồm cả việc sửa cấu hình lẫn việc xử lý những phiếu đã đi sai đường.

Bước thứ ba là tạo một tuyến cung ứng kèm quy tắc, để khi hàng tới vị trí trung chuyển của kho nhận thì hệ thống tự sinh phiếu nhập kho đưa hàng từ đó vào vị trí tồn kho của kho nhận. Quy tắc này dùng:

• hành động đẩy tới
• vị trí nguồn là vị trí trung chuyển của kho nhận
• vị trí đích là vị trí tồn kho của kho nhận
• và loại hoạt động là phiếu nhập kho của chính kho đó

Gói lại thành ba dòng để bạn mang đi làm:

• Bật vị trí kho và tuyến cung ứng nhiều bước trong phần cài đặt của phân hệ Kho
• Tạo một vị trí trung chuyển cho từng kho nội bộ, đặt dưới vị trí ảo gom nhóm của kho đó
• Tạo tuyến kèm quy tắc đẩy tới, từ vị trí trung chuyển vào vị trí tồn kho của kho nhận

Tuyến và quy tắc

Tuyến cung ứng quy định đường đi của hàng hóa, còn quy tắc là từng chặng cụ thể trên đường đi đó. Mỗi quy tắc trả lời bốn câu:

• hành động là gì
• loại hoạt động nào
• đi từ vị trí nào
• và tới vị trí nào

Trong bốn câu đó thì câu về hành động là câu quan trọng nhất, và hai giá trị bạn dùng nhiều nhất là đẩy tới với kéo từ, bên cạnh một giá trị thứ ba kết hợp cả hai mà bài này không cần tới. Đẩy tới nghĩa là khi hàng đã tới vị trí này thì hệ thống tự đẩy nó đi tiếp tới vị trí kế; kéo từ nghĩa là khi có nhu cầu ở vị trí này thì hệ thống tự kéo hàng từ vị trí trước về.

Diễn đạt bằng ngôn ngữ nghiệp vụ thì đẩy là hàng đã có rồi và cần đi tiếp, còn kéo là có người cần và phải đi lấy.

Bài toán ở đầu bài thuộc loại thứ nhất, bởi hàng đã tới vị trí trung chuyển của kho nhận và việc cần làm là đưa nó vào tồn kho, chứ không phải chờ ai đó phát sinh nhu cầu.

Cần lưu ý thêm một chuyện rất thực tế khi bạn ngồi cấu hình phần này. Bản dịch tiếng Việt của hai hành động đẩy và kéo cùng các dòng mô tả quy tắc đọc lên khá khó hiểu, nên tôi vẫn chuyển giao diện sang tiếng Anh khi làm việc với tuyến và quy tắc, rồi chuyển lại khi bàn giao cho người dùng.

Vận hành sau khi cấu hình

Cấu hình xong thì luồng làm việc đổi ở đúng một chỗ, và chỗ đó nằm trong tay người của kho gửi.

Kho gửi vẫn tạo phiếu điều chuyển nội bộ như trước, nhưng vị trí đích chọn là vị trí trung chuyển của kho nhận chứ không phải vị trí tồn kho của kho nhận. Đây là thay đổi duy nhất về thao tác, và nó cần được ghi vào tài liệu hướng dẫn cùng với một câu giải thích, vì nếu chỉ nói chọn cái này thay vì cái kia thì người dùng sẽ quên.

Khi phiếu được xác thực, hàng rời kho gửi và nằm ở vị trí trung chuyển, và báo cáo tồn kho lúc này phản ánh đúng thực trạng, tức số lượng đang trên đường được nhìn thấy rõ ở một chỗ riêng chứ không bị cộng nhầm vào kho nhận.

Cùng lúc đó, hệ thống tự sinh một phiếu nhập kho ở kho nhận với trạng thái sẵn sàng. Kho nhận không phải chờ ai báo, không phải tự tạo phiếu, và cũng không phải nhớ là có lô hàng nào đang tới.

Chỗ hay nhất của giải pháp này lộ ra khi có sai lệch. Nếu kho nhận đếm được chín trên mười cái thì họ nhập chín, và một cái còn lại vẫn treo ở vị trí trung chuyển thay vì tự biến mất. Số liệu vì vậy phản ánh đúng rằng có một đơn vị hàng đã rời kho gửi mà chưa tới kho nhận, và phần chênh lệch đó được xử lý theo quy định của doanh nghiệp là bồi thường, ghi nhận hao hụt, hay điều tra tiếp là chuyện của họ, nhưng nó không còn là một con số mất tích trong hệ thống.

Cái được thật sự

Nếu chỉ nhìn vào tính năng thì cái được là một trạng thái mới trên báo cáo. Nhìn theo nghiệp vụ thì cái được lớn hơn nhiều.

Trước hết là số liệu tồn kho đúng trong suốt thời gian vận chuyển, mà với doanh nghiệp có nhiều kho ở xa nhau thì khoảng thời gian đó chiếm phần đáng kể trong tháng; kế hoạch mua hàng, cam kết giao hàng cho khách và quyết định điều chuyển tiếp đều dựa trên con số này, nên sai ở đây là sai dây chuyền.

Bên cạnh đó, trách nhiệm được phân định rõ. Trước khi có vị trí trung chuyển, hàng thiếu khi tới nơi là một cuộc tranh luận giữa hai kho; sau khi có, hàng thiếu là một con số treo ở một chỗ cụ thể, có phiếu, có thời điểm, có người xác nhận ở cả hai đầu.

Và đặc biệt, kho nhận có việc để làm, đây là cái ít được nói tới nhất. Một phiếu ở trạng thái sẵn sàng nằm trong danh sách công việc của họ thì nó được xử lý; một lô hàng không có phiếu nào thì nó phụ thuộc vào việc ai đó nhớ ra.

Ba câu hỏi sàng lọc

Case này đáng nhớ không phải vì bài toán hàng trên đường, mà vì cách tiếp cận dùng lại được. Đây là ba câu tôi vẫn tự hỏi trước khi kết luận một dòng GAP là cần phải customize không, và nó chính là cách áp nấc thứ nhất trong thang bốn nấc mà tôi đã nói ở bài về việc chốt giải pháp với khách.

Đầu tiên, nghiệp vụ đang cần phân biệt bao nhiêu trạng thái, và hệ thống hiện đang mô tả bao nhiêu. Nếu con số thứ nhất lớn hơn con số thứ hai thì bài toán thường nằm ở chỗ thiếu một điểm dừng trong luồng chứ không phải thiếu một tính năng, và điểm dừng thì thường dựng được bằng cấu hình.

Tiếp theo, cái nghiệp vụ đang cần có phải là một chỗ để dữ liệu đi qua hay không. Nếu đúng thì rất có khả năng hệ thống đã có một loại đối tượng dành cho việc đó, và việc của bạn là tìm ra nó.

Và cuối cùng, có bước nào đang bị người dùng làm bằng tay mà thực chất là hệ quả tất yếu của bước trước hay không. Nếu có thì đó là ứng viên cho một quy tắc tự động, và bạn tiết kiệm được cho khách cả một thao tác lặp lại mỗi ngày.

Ba câu hỏi này không giải được mọi thứ, và có những yêu cầu thì lập trình vẫn là câu trả lời đúng. Tuy nhiên chúng lọc được kha khá những dòng mà nếu không hỏi thì bạn đã ghi vào tài liệu là phải code, rồi báo giá theo mức đó, rồi mang một khoản chi phí không cần thiết vào hệ thống của khách, mà chi phí đó, như bạn sẽ thấy, không chỉ phát sinh một lần.