Hai lô cùng mã hàng đang nằm trong kho. Lô A đến trước nhưng lô B có mốc cần đưa ra khỏi kho sớm hơn. Nhân viên đã kiểm đúng số lượng và mã lô, vậy nên chọn lô nào cho phiếu xuất? Nếu quy trình chỉ nói “ưu tiên hàng cũ”, người vận hành có thể hiểu cũ theo ngày nhập, ngày sản xuất hoặc hạn dùng và đưa ra các lựa chọn khác nhau.
FEFO và FIFO giúp mô tả hai cách ưu tiên lấy hàng. Bài này dùng một tình huống giả lập để so lựa chọn, rồi chỉ ra dữ liệu cần kiểm khi triển khai trên Odoo 19. Các ngày và số lượng trong ví dụ không liên quan sản phẩm thật; chúng không xác nhận hàng đủ điều kiện sử dụng, đủ hạn giao khách hay được phép xuất.
Thử chọn sáu hộp từ ba lô
Giả sử cùng SKU P-01 có ba lô đã được xác nhận thông tin. Lô A còn bốn hộp, nhập ngày 01/03; lô B còn ba hộp, nhập ngày 05/03; lô C còn năm hộp, nhập ngày 08/03. Các mốc đưa hàng ra khỏi kho trong ví dụ lần lượt là 28/03, 22/03 và 02/04. Hôm xét yêu cầu là 10/03, chưa đến các mốc ấy.
| Lô | Ngày nhập minh họa | Mốc removal đã xác nhận | Còn lại |
|---|---|---|---|
| A | 01/03 | 28/03 | 4 |
| B | 05/03 | 22/03 | 3 |
| C | 08/03 | 02/04 | 5 |
Nếu chỉ ưu tiên thứ tự nhập của dữ liệu giả định, yêu cầu sáu hộp lấy bốn từ A rồi hai từ B. Nếu ưu tiên mốc removal sớm nhất, nó lấy ba từ B rồi ba từ A. Tổng xuất đều là sáu và tổng còn đều là sáu, nhưng phần còn ở từng lô khác nhau. Chỉ kiểm tổng số cuối cùng sẽ không phát hiện chọn sai chiến lược.
Ví dụ này cố ý để thứ tự nhập khác thứ tự removal. Nếu dùng một bộ mẫu mà lô nhập trước cũng luôn đến mốc removal trước, cả hai cách chọn có thể trả cùng kết quả. Một phép thử như vậy không đủ để biết cấu hình có đúng ý định. Khi nghiệm thu, hãy chọn dữ liệu mà hai quyết định thật sự tách nhau và ghi trước kết quả mong đợi theo lô.
Chưa xét giá vốn, chiết khấu hay số tiền trong ví dụ. Việc chọn vật lý để giao hàng là câu hỏi khác cách định giá hàng xuất và hạch toán. Không dùng tên FIFO trên màn hình kho làm bằng chứng rằng chính sách kế toán của doanh nghiệp đã được thiết lập hoặc thực hiện đúng.
FEFO và FIFO ưu tiên hai mốc khác nhau
Tài liệu FIFO removal của Odoo 19 mô tả việc ưu tiên hàng đến trước. Khi rà dữ liệu trên hệ thống này, cần chú ý tài liệu dùng trường Created on của lô hoặc serial để thể hiện mốc được coi là arrival date. Không mặc định cột “ngày nhập” từ một file bên ngoài đã khớp trường hệ thống sử dụng.
Điều đó đặc biệt quan trọng khi chuyển dữ liệu từ phần mềm cũ. Một lô được tạo trong lần chuyển đổi hôm nay có thể có hồ sơ nhận thực tế từ trước. Nhóm triển khai cần kiểm mốc mà chiến lược dựa vào và phương án chuyển dữ liệu được hỗ trợ, thay vì sửa ngày tùy tiện để buộc màn hình chọn đúng một ví dụ. Bài không cung cấp lệnh đổi dữ liệu production.
Tài liệu FEFO removal lại mô tả ưu tiên removal date sớm nhất. Trong cấu hình được trình bày, mốc này được tính trước expiration date theo số ngày người dùng đặt. Vì vậy khi giải thích FEFO trên Odoo, chỉ nói “chọn EXP gần nhất” có thể làm mất một thông tin cấu hình có ý nghĩa.
Các trường ngày cần được người phụ trách sản phẩm xác nhận. Một chiến lược ưu tiên không tự tạo ra ngày đáng tin khi dữ liệu còn thiếu. Nếu lô chưa có mốc phù hợp, cách xử lý phải được thử và ghi rõ trên phiên bản đang dùng. Không điền một ngày giả, ngày hiện tại hoặc hạn mặc định chỉ để lô lọt vào thứ tự sắp xếp.
Cấu hình nào đang quyết định một phiếu xuất?
Khi người thử thấy chọn lô không như mong đợi, trước hết cần tìm cấu hình thực sự áp dụng. Có thể người vận hành đang xem quy tắc tại vị trí trong khi danh mục sản phẩm có một lựa chọn khác. Hướng dẫn Odoo về hai chiến lược nêu Force Removal Strategy ở product category có ưu tiên khi cấu hình tại đó khác location.
Trong thiết kế nghiệm thu, nên giữ một bản ghi ngắn: SKU, vị trí, danh mục, cấu hình ưu tiên và thời điểm đối chiếu. Người đọc cần giải thích được vì sao phiếu lấy B trước A mà không phải mở nhiều màn hình rồi đoán. Đây là cách lưu căn cứ được đề xuất, không phải khẳng định phần mềm đã tự tạo một receipt như vậy cho mọi giao dịch.
Phải nhìn cả chi tiết phần được phân bổ cho phiếu. Một màn hình tổng sản phẩm có thể hiện đủ sáu hộp nhưng chưa cho thấy lấy từ lô nào. Người thử đối chiếu lượng theo lô với bảng kỳ vọng, rồi xem các bước tiếp theo có giữ quan hệ đó không. Nếu có thao tác chọn lại thủ công, cần phân biệt kết quả ban đầu với quyết định sau khi con người can thiệp.
Cũng không nên đổi chiến lược trên hệ thống thật chỉ để xem phiếu sẽ biến động thế nào. Các phiếu đã giữ hàng hoặc đang xử lý có thể cần cách xử lý riêng. Môi trường thử và mẫu tổng hợp giúp đánh giá hành vi mà không biến một phép thử tài liệu thành hành động xuất kho thực tế.
Chọn sớm vẫn phải đáp ứng điều kiện giao
Ưu tiên lấy một lô là một bước trong quyết định, không phải giấy phép giao mọi hàng thuộc lô ấy. Doanh nghiệp có thể còn phải xét tình trạng chất lượng, phạm vi bán, yêu cầu khách và điều kiện vận chuyển. Các yêu cầu này phải có người chịu trách nhiệm xác định; không thể suy toàn bộ từ tên chiến lược hoặc một ngày trên màn hình.
Chẳng hạn, yêu cầu giao ngày mai và yêu cầu giao sau hai tuần có thể cần dữ liệu đối chiếu khác nhau. Bài không đề xuất số ngày hạn dùng tối thiểu hay một ngưỡng an toàn. Nếu hợp đồng có điều kiện về thời gian còn lại, đội triển khai cần ghi chính xác mốc so, trường ngày và cách xử lý khi thiếu căn cứ trước khi tự động hóa nhận đơn.
Hướng dẫn expiration dates của Odoo phân biệt các trường expiration, best before, removal và alert. Không nên gộp chúng thành một cột “hạn” rồi dùng cho mọi quyết định. Đọc đúng ý nghĩa trường trên nền tảng là việc cần làm trước khi xây một thông báo công khai cho người mua.
Đặc biệt, một cảnh báo ngày và một quy tắc phong tỏa xuất hàng là hai cơ chế cần kiểm riêng. Không hứa rằng hệ thống chắc chắn chặn lô không phù hợp nếu mới xác nhận có cảnh báo. Cách khắc phục có thể nằm ở quy trình, cấu hình được hỗ trợ hoặc tích hợp có kiểm soát, nhưng phải được chứng minh trên phạm vi đã chốt.
Chốt bộ dữ liệu thử trước khi nối website
Mẫu thử ban đầu nên có trường hợp thứ tự nhập và removal trái nhau như bảng trên. Thêm một yêu cầu dùng hết lô đầu để xem hệ thống lấy phần còn lại từ đâu. Sau đó thử dữ liệu ngày thiếu hoặc chưa được xác nhận theo quy tắc được duyệt. Từng ca cần đáp án theo lô, không chỉ một ô tổng số lượng thành công.
Nếu hệ thống hiện có bước đọc nhãn tự động, hãy đặt ranh giới rõ giữa trích xuất và chọn xuất. Bài về đọc hạn dùng theo lô tập trung giữ LOT, MFG và EXP đúng nguồn. Sau khi trường ngày được xác nhận, bài toán ở đây mới bắt đầu: chiến lược và điều kiện nào sử dụng dữ liệu ấy cho một yêu cầu cụ thể.
Website không nhất thiết cần thấy toàn bộ bảng lô nội bộ. Nó có thể nhận một kết quả có phạm vi, thời điểm và trạng thái nguồn đủ cho nghiệp vụ đã duyệt. Trước khi gọi một SKU là đáp ứng được, cần biết dữ liệu kho hiện hành và điều kiện giao đã được kiểm. Không đưa các ngày hoặc tên lô vào giao diện chỉ vì API có trường đó.
Khi trao đổi với Onter, có thể mang một mẫu ba lô đã bỏ dữ liệu riêng tư và quy tắc chọn mong muốn. Mục tiêu ban đầu là giải thích được việc chọn từng phần số lượng, giữ nguyên căn cứ sau khi xử lý và chỉ kết nối website khi các tình huống quan trọng đã được kiểm chứng. Giá trị của tự động hóa nằm ở quyết định có thể đối chiếu, không ở việc hoàn thành nhanh một phiếu nhưng không biết vì sao chọn lô đó.
