Doanh nghiệp đã thống nhất mua một mã vật tư nhiều lần trong quý, nhưng kho chưa cần nhận toàn bộ ngay hôm nay. Người theo dõi nhìn thấy lượng 1.000 trên thỏa thuận và tưởng đã đặt đủ hàng; người khác lại cộng cả lượng thỏa thuận với các đơn phát sinh, làm nhu cầu bị tính hai lần. Vấn đề không nằm ở phép cộng mà ở việc các con số thuộc những lớp cam kết khác nhau.
Blanket order Odoo giúp tổ chức thỏa thuận mua lặp lại và các yêu cầu báo giá liên quan. Bài này giải thích cách đọc quan hệ ấy theo tài liệu Odoo 19, rồi xây một ví dụ quản trị giả lập. Nội dung không xác định hiệu lực pháp lý của hợp đồng khung, không thay chính sách phê duyệt mua và không coi trạng thái trong phần mềm là bằng chứng nhà cung cấp đã giao hàng.
Blanket order Odoo nằm trước từng lần đặt mua
Tài liệu Blanket orders của Odoo 19 mô tả thỏa thuận mua dài hạn với nhà cung cấp, dùng cho những lần mua có thời điểm và số lượng khác nhau theo giá đã xác định. Khi xác nhận thỏa thuận, người dùng có thể tạo yêu cầu báo giá mới từ đó. RFQ và bước xác nhận thành PO vẫn là những đối tượng cần được đọc riêng.
Không nên tự đồng nhất thỏa thuận với một phiếu giao; cần đọc từng RFQ/PO liên quan. Trước khi chọn mô hình, đội mua hàng cần trả lời bên nào được quyền phát hành từng lần mua, lượng trên thỏa thuận mang nghĩa dự kiến hay một nghĩa vụ đã thống nhất, và điều kiện nào phải được kiểm lại. Không tự gắn nhãn “hạn mức bắt buộc” cho trường số lượng chỉ vì tên tài liệu nội bộ gọi đó là hợp đồng khung.
Người thiết kế báo cáo nên giữ được đường từ thỏa thuận tới các RFQ hoặc PO liên quan. Nếu chỉ lưu mã hợp đồng trong một ô ghi chú, người tiếp quản có thể không biết một đơn đã dùng căn cứ nào. Chiều ngược lại, gắn cùng một tên nhà cung cấp cũng không đủ chứng minh hai đơn nằm trong cùng thỏa thuận, nhất là khi họ bán nhiều nhóm sản phẩm hoặc có các điều kiện hiệu lực khác nhau.
Phạm vi của bài là dữ liệu vận hành mua hàng. Quyền ký, nghĩa vụ mua tối thiểu, phạt hủy hay quyền đổi giá cần được xác định từ tài liệu được doanh nghiệp phê duyệt. Không thể suy những nội dung đó từ nút Confirm hoặc một chỉ số Ordered. Khi chưa rõ điều khoản, phần mềm nên giữ tham chiếu cần xác minh thay vì tự trình bày một kết luận pháp lý.
Một thỏa thuận 1.000 chiếc không tạo ra 1.000 chiếc trong kho
Giả sử thỏa thuận A-01 có dòng vật tư X, lượng tham chiếu 1.000 chiếc trong quý. Nhóm mua đã phát hành PO-01 với 200 chiếc và PO-02 với 150 chiếc; cả hai được giả định đã qua quy trình duyệt nội bộ. Một RFQ-03 với 100 chiếc mới đang được xem xét. Đây là ví dụ biên tập, không phải dữ liệu hay kết quả chạy trên bản cài Odoo.
Trong phạm vi mô hình này, hai PO đã xác nhận cộng thành 350 chiếc. RFQ 100 chiếc được giữ ở lớp đang xem xét, không cộng vào cùng nhãn “đã đặt” nếu quy tắc báo cáo chưa cho phép. Lượng 1.000 vẫn là số trên thỏa thuận. Cộng 1.000 với 350 để báo “đã đặt 1.350” là trộn căn cứ với các lần thực hiện căn cứ ấy.
Nếu đội muốn theo dõi phần còn có thể xem xét so với lượng tham chiếu, phép trừ 1.000 − 350 cho ra 650 chiếc trong ví dụ. Nhưng 650 không tự mang nghĩa được phép mua ngay, không phải lượng nhà cung cấp còn sẵn và không phải tồn chưa giao. Nó chỉ đúng với tập PO, đơn vị và quy tắc đã chọn; quyền phát hành đơn mới vẫn cần được xác định riêng.
Bây giờ giả sử kho mới nhận 120 chiếc từ PO-01 và chưa nhận PO-02. Lượng đã đặt 350, lượng đã nhận 120 và lượng trên thỏa thuận 1.000 trả lời ba câu khác nhau. Có thể tính chênh 230 trong mô hình để đặt câu hỏi về các đơn còn chờ, nhưng chưa được kết luận tất cả 230 đều quá hạn. Hạn giao, các lần nhận và ngoại lệ phải được đọc trên đúng chứng từ liên quan.
Ví dụ cũng chưa tính hủy, thay đổi đơn vị, hàng trả hoặc sửa lượng sau duyệt. Khi có một sự kiện ấy, cần giữ lại nguồn và thời điểm thay đổi trước khi tính lại. Không sửa thỏa thuận gốc để che một đơn đặt vượt kế hoạch, cũng không xóa RFQ khỏi báo cáo chỉ vì nó chưa trở thành PO. Từng lớp nên có nhãn đủ rõ để người nhận biết còn phải quyết định điều gì.
Đọc điều kiện được sao chép trước khi xác nhận RFQ
Tài liệu Odoo cho biết yêu cầu báo giá tạo từ blanket order được điền thông tin theo thỏa thuận; các RFQ hoặc đơn liên quan có thể được mở qua nút RFQs/Orders. Tính liên kết giúp lần theo nguồn, nhưng không nên được hiểu là mọi điều kiện luôn đúng mà không cần rà. Người mua phải xem đúng nhà cung cấp, công ty, tiền tệ, sản phẩm và thông tin giao nhận của lần mua đang chuẩn bị.
Một lưu ý cụ thể trong tài liệu là giá dòng sản phẩm trên thỏa thuận cần được nhập theo mức đã thống nhất; giá có sẵn không tự điền vào và có thể còn bằng 0. Vì thế, báo cáo không nên giải thích giá 0 như “hàng miễn phí” khi chưa có căn cứ. Kiểm giá cùng nguồn phê duyệt có giá trị hơn việc chỉ kiểm trường số có tồn tại hay không.
Ngày hiệu lực cũng cần được đọc đúng mục đích. Một kỳ đặt dự kiến, ngày cần nhận và thời hạn của thỏa thuận không nhất thiết là cùng một ngày. Nếu nhóm cần kiểm đơn phát hành sau khi thỏa thuận hết hạn, hãy mô tả rõ quy tắc mong muốn rồi thử trên đúng phiên bản và đường tích hợp. Bài này không khẳng định có sẵn một khóa cứng ngăn mọi giao dịch vượt thời gian hoặc lượng.
Tài liệu còn cho phép chỉnh sản phẩm, lượng và giá trên thỏa thuận đã xác nhận. Khả năng sửa đó làm việc lưu căn cứ của từng lần mua quan trọng hơn. Khi đọc một PO cũ, người rà cần biết thông tin nào thuộc chứng từ lúc phát hành và thông tin nào là cấu hình hiện tại. Không khẳng định việc sửa thỏa thuận sẽ tự cập nhật hồi tố mọi đơn, hay ngược lại luôn không ảnh hưởng, khi chưa thử hành vi cụ thể.
Không biến số Ordered thành một quy tắc duyệt tự động
Tài liệu mô tả Ordered được cập nhật theo các yêu cầu báo giá liên kết. Tuy nhiên, một đội vận hành vẫn cần kiểm đúng cách trường đó tính các trạng thái ở bản cài đang dùng trước khi gắn nhãn quản trị riêng. Không nên mặc định con số ấy tương đương tổng PO đã duyệt theo quy trình nội bộ của doanh nghiệp. Tên trường phần mềm không thay định nghĩa chỉ tiêu của người sử dụng.
Đợt thử nên có một RFQ nháp, một PO xác nhận và một trường hợp được phép hủy, rồi ghi lại chỉ số trước và sau từng bước. Mục tiêu là xác định tập nào được tính và khi nào thay đổi. Đây là đề xuất bài thử, chưa phải kiểm chứng đã thực hiện. Nếu có connector hoặc báo cáo tùy chỉnh, cần đưa nó vào phạm vi đọc lại thay vì chỉ nhìn giao diện native.
Thiết kế bảng theo câu hỏi của người mua
Người quản lý cần thấy lượng tham chiếu và các lần mua được đối chiếu, trong khi kho cần các chứng từ nhận và phần còn chờ của đúng PO. Một màn hình nhồi tất cả thành một cột “còn lại” sẽ khó giải thích. Có thể tách các khối theo quyết định: phần đã có căn cứ đặt, phần đang xin xác nhận và phần chờ đối chiếu giao nhận, kèm thời điểm chốt.
Giữ mã thỏa thuận, dòng sản phẩm, đơn vị và tham chiếu RFQ/PO để truy lại. Khi hai lần mua dùng hai đơn vị khác nhau, chỉ tổng hợp sau khi có quy đổi được duyệt. Tên vật tư gần giống không phải khóa ghép; một revision hoặc quy cách khác có thể làm phép cộng không còn có nghĩa dù cả hai dòng đều dùng từ “chiếc”.
Các quyền sửa cũng cần tương ứng với nhiệm vụ. Người được xem tổng theo dõi chưa chắc được sửa giá trên thỏa thuận hay xác nhận PO. Tích hợp website không nên biến một nút gửi yêu cầu thành quyền phát hành đơn mua thay người phụ trách. Hãy giữ bước tiếp nhận nhu cầu, xét điều kiện và thực hiện đơn thành những hành động có người chịu trách nhiệm rõ ràng.
Nếu nhu cầu còn là mô tả chưa đủ thông số, đó là lớp chuẩn bị yêu cầu mua hàng và quyền gửi RFQ, chưa phải một lần mua được chấp thuận. Sau khi đã có PO, phiếu nhận và hóa đơn, việc đối chiếu ba chứng từ mua hàng lại trả lời lượng và giá giữa các nguồn. Quan hệ với blanket order bổ sung căn cứ mua lặp lại, không thay hai bước ấy.
Bàn giao tốt có thể bắt đầu bằng một thỏa thuận giả, hai PO và một RFQ chưa xác nhận, đủ để người đọc chỉ ra ý nghĩa từng số. Thử thêm một lần sửa điều kiện và đọc lại chứng từ cũ để biết giới hạn hệ thống. Khi cần kết nối biểu mẫu B2B với quy trình mua hàng, Onter có thể khảo sát phạm vi dữ liệu, quyền và kiểm tra đầu ra. Giá: Liên hệ. Nhận tư vấn & báo giá.
