Một đơn giao sau năm ngày cần mười chiếc. Trong kho đang có đủ mười chiếc, nhưng dòng đơn vẫn ghi chưa giữ lượng nào. Người bán có thể nghĩ phần mềm đang lỗi hoặc vội nói với khách rằng hàng đã được dành riêng. Trước khi sửa, cần biết quy tắc của nghiệp vụ muốn giữ hàng ngay khi xác nhận hay chỉ gần ngày giao.
Giữ hàng trước ngày giao là lựa chọn về thời điểm phân bổ, không phải lời hứa hàng đã được lấy khỏi kệ hoặc khách chắc chắn nhận đúng lịch. Bài dùng Odoo 19 và một mẫu giả lập để đọc quan hệ giữa lượng có sẵn, lượng được giữ và ngày dự kiến. Không có thao tác giữ hoặc xuất hàng thật trong bài.
Có hàng trong kho nhưng chưa dành cho đơn này
Trong mẫu, SKU K01 có mười chiếc theo nguồn đã xác nhận, đơn cần mười chiếc và ngày giao dự kiến cách ngày lập đơn năm ngày. Người vận hành chọn cửa sổ giữ hàng trước ngày giao hai ngày. Ở thời điểm đầu, lượng có thể đủ nhưng lượng đã được giữ cho đơn vẫn bằng không. Hai thông tin không mâu thuẫn nếu cấu hình và dữ liệu đúng như giả định.
Đừng sửa số reserved để nó khớp số on hand trên một báo cáo ngoài phần mềm. Chúng trả lời hai câu hỏi khác nhau. Số có trong kho là đầu vào cho khả năng đáp ứng; số đã dành cho một đơn cần được đọc theo quan hệ và trạng thái của đơn đó. Một con số tổng không chứng minh người mua cụ thể đã có phần hàng được giữ.
Trong ví dụ này, thời điểm chuyển sang bước giữ còn phụ thuộc quy trình được cấu hình. Không suy một mốc ngày thành cam kết tác vụ nền chạy chính xác lúc không giờ hoặc bảo đảm không có cạnh tranh với các yêu cầu khác. Bản triển khai thực tế cần kiểm cách hệ thống xử lý lịch, nguồn tồn và các phiếu có liên quan.
Người phụ trách nên chốt trước kết quả mong đợi của từng mốc: trước cửa sổ, khi đến cửa sổ và sau một thay đổi lịch. Những mốc ấy giúp đánh giá hành vi, thay vì chỉ thử một đơn giao ngay và kết luận mọi đơn đặt trước đều được xử lý giống nhau. Không cần dùng dữ liệu khách thật để tạo mẫu có ý nghĩa này.
Chọn phương thức theo loại thao tác
Tài liệu Reservation methods của Odoo 19 mô tả ba phương thức: giữ khi xác nhận nếu có hàng, giữ thủ công và giữ trước ngày dự kiến theo khoảng được chọn. Cấu hình nằm trên operation type. Tài liệu cũng lưu ý phương thức này không xuất hiện với loại thao tác Receipt.
Điểm cuối dễ bị bỏ sót khi đội triển khai cố tìm cùng một tùy chọn ở mọi màn hình kho. Một luồng nhập và một luồng xuất không nhất thiết có cùng câu hỏi phân bổ. Trước khi bổ sung automation, hãy xác định phiếu đang thuộc loại thao tác nào, nguồn cấu hình nào áp dụng và đang kiểm một quyết định ở bước nào.
Giữ khi xác nhận có thể phù hợp với một chính sách nhận đơn đã chốt; giữ gần ngày giao có thể phục vụ cách điều phối khác. Bài không chọn một phương thức tốt nhất cho mọi doanh nghiệp. Quyết định cần tính cả cam kết thương mại, cách làm việc của kho và nguồn dữ liệu đủ tin cậy, không chỉ xem tùy chọn nào khiến màn hình chuyển sang màu mong muốn.
Giữ thủ công cũng cần người chịu trách nhiệm. Một cấu hình yêu cầu con người kiểm không có nghĩa công việc ấy tự được phân công, được thực hiện hoặc được giám sát đúng hạn. Nếu dùng báo cáo để nhắc việc, hãy nêu rõ đó là phần quy trình hay tích hợp cần thiết kế thêm, không gọi là tính năng đã có sẵn chỉ vì tài liệu mô tả nút thao tác.
Đọc cửa sổ giữ hàng trước ngày giao
Hướng dẫn Before scheduled date mô tả trường số ngày trước lịch giao và một giá trị riêng cho transfer được đánh dấu sao. Ví dụ tài liệu dùng hai ngày cho thông thường, ba ngày cho loại đánh dấu. Cấu hình đó không nên bị gộp thành một cột thời gian áp dụng cho mọi phiếu.
Tài liệu có một mẫu hàng đủ tồn nhưng chưa được reserved vì chưa tới khoảng giữ theo cấu hình. Điều hữu ích khi nghiệm thu là nhìn được cả ngày dự kiến, nhu cầu và lượng giữ cho đúng phiếu. Một nhãn Available đứng riêng dễ khiến người xem bỏ qua nguyên nhân tại sao lượng trên dòng vẫn chưa bằng nhu cầu.
Nếu doanh nghiệp dùng đánh dấu sao để xử lý sớm hơn, cần thống nhất ai được dùng và ý nghĩa vận hành. Không để mỗi nhân viên tự coi mọi đơn của mình là ưu tiên rồi đánh dấu hàng loạt mà không có chính sách. Đây là khuyến nghị tổ chức công việc, không phải mô tả cơ chế duyệt ưu tiên mặc định của phần mềm.
Khi ngày dự kiến thay đổi, người kiểm cần xem cấu hình và trạng thái phân bổ hiện tại trước khi kết luận. Không sửa trực tiếp một file tổng hợp rồi cho rằng lượng giữ trên hệ thống đã được điều chỉnh theo. Bài chưa kiểm thử trường hợp đổi lịch trên Odoo; cách xử lý cụ thể phải được xác minh trên phiên bản và luồng đang dùng.
Nguồn cũng mô tả có thể giữ sớm bằng thao tác Check Availability trong luồng mẫu. Không dùng chi tiết này như lời khuyên bỏ qua quyền hoặc chính sách của doanh nghiệp. Người được phép cần biết đang thay quyết định gì, lượng nào bị ảnh hưởng và kết quả sau lưu có đúng phạm vi không. Có một nút thao tác không thay bước phê duyệt nghiệp vụ cần thiết.
Thử bằng hai đơn có điều kiện khác nhau
Bộ mẫu nên có một đơn chưa tới cửa sổ và một đơn đã tới cửa sổ theo quy tắc được chọn. Giữ cùng mã hàng khi mục tiêu là so thời điểm, rồi ghi trước lượng mong đợi theo từng đơn. Nếu thay cả mã, kho, lịch và phương thức cùng lúc, kết quả khác nhau sẽ khó giải thích đang do nguyên nhân nào.
Tiếp theo, thêm trường hợp thiếu hàng hoặc nguồn tồn chưa cập nhật. Không dùng số của lần đọc trước rồi ghi vào báo cáo như lượng hiện hành. Cách xử lý khi thiếu căn cứ phải do nhóm chốt: yêu cầu kiểm lại, chuyển người có trách nhiệm hoặc một lựa chọn phù hợp khác. Bài không đặt cơ chế chặn đơn chung cho mọi website.
Với một phiếu được đánh dấu sao, giữ dữ liệu thử đủ để thấy quy tắc khác phiếu thông thường. Sau thao tác được phép, đọc lại lượng thuộc từng phiếu, không chỉ nhìn tổng SKU. Hai phiếu có thể cùng dùng một sản phẩm nhưng nguồn phân bổ cần được giải thích theo từng yêu cầu; không kết luận từ một tổng số rằng mọi khách đều được giữ đủ.
Người thử cũng cần phân biệt lượng giữ, hàng đã được lấy và hàng đã giao. Các bước sau có thể còn đóng gói, kiểm tra hoặc xác nhận vận chuyển theo quy trình thực tế. Bài FEFO và FIFO khi chọn lô xuất xử lý câu hỏi lấy từ lô nào; nó không quyết định thay thời điểm giữ hàng của bài này.
Kết quả bàn giao có thể ngắn: cấu hình loại thao tác, mốc lịch, mẫu đơn giả lập, lượng mong đợi và lượng đọc lại. Giữ mã tham chiếu đủ truy nguyên nhưng không xuất tên khách, địa chỉ giao hoặc giá thương mại vào log rộng quyền. Chỉ gọi là đã thử thành công khi có bằng chứng của môi trường được phép, không biến bản kế hoạch thành receipt thực thi.
Phần công khai cho khách cần một lớp diễn giải riêng. Thời gian giao hàng và tồn kho trên website B2B giải thích việc tách mốc chuẩn bị, xuất kho và đến nơi nhận. Không lấy nhãn reserved để hứa một ngày nhận chắc chắn hoặc đưa toàn bộ chi tiết phân bổ nội bộ ra trình duyệt chỉ vì API có các trường ấy.
Nếu cần nối website với nguồn kho, hãy chuẩn bị hai đơn giả lập cùng cửa sổ giữ mong muốn để Nhận tư vấn & báo giá. Giá: Liên hệ. Onter khảo sát nguồn, quyền, điều kiện nhận đơn và cách kiểm ngoại lệ trước khi xác nhận giải pháp; không mặc định mọi phần mềm đã có cùng cơ chế hoặc kết nối sẵn.
