Kho nhận thêm 40 hộp linh kiện của nhà cung cấp để bán hộ. Trên cùng dãy kệ đã có 60 hộp doanh nghiệp mua trước đó. Nếu báo cáo chỉ giữ mã hàng và vị trí, cả hai nhóm có thể hiện thành 100 hộp. Con số ấy trả lời được câu hỏi về chỗ chứa, nhưng chưa đủ để trả lời phần hàng nào thuộc doanh nghiệp, phần nào đang giữ cho bên giao ký gửi.
Quản lý hàng ký gửi trong kho cần giữ chủ sở hữu cùng với số lượng. Đây là hướng dẫn thiết kế dữ liệu và đọc báo cáo kho, dùng Odoo 19 làm ví dụ phần mềm. Các số liệu dưới đây hoàn toàn giả lập; bài không xác định thời điểm chuyển quyền sở hữu theo hợp đồng, ghi nhận doanh thu hoặc nghĩa vụ thuế.
Một kệ hàng, hai phần cần theo dõi riêng
Trong ví dụ giả định, SKU K-01 có 60 hộp thuộc doanh nghiệp và 40 hộp nhận ký gửi từ đối tác A. Kho cần tìm đúng hàng để kiểm đếm, còn người phụ trách giao dịch phải biết phần nào được phép sử dụng cho từng yêu cầu. Dồn chúng vào một số tổng rồi bổ sung ghi chú “có hàng ký gửi” ở cuối báo cáo làm mất khả năng lần theo từng phần.
Thiết kế đề xuất là một dòng dữ liệu theo tổ hợp mã hàng, vị trí, lô nếu có, đơn vị và chủ sở hữu đã xác nhận. Hai dòng có cùng SKU và cùng kệ vẫn có thể khác owner. Giữ thêm mã chứng từ nhận và thời điểm chốt giúp người có quyền đối chiếu lại. Những trường này phục vụ nghiệp vụ kho; chúng không thay thế giấy tờ xác định quyền giữa các bên.
| SKU | Vị trí | Phần hàng | Số lượng | Căn cứ cần giữ |
|---|---|---|---|---|
| K-01 | Kệ A | Doanh nghiệp sở hữu | 60 | Chứng từ nguồn đã xác nhận |
| K-01 | Kệ A | Đối tác A ký gửi | 40 | Phiếu nhận và owner A |
| K-01 | Kệ A | Tổng vật lý trong ví dụ | 100 | Tổng của hai phần, không đổi owner |
Giả sử có yêu cầu xuất 12 hộp từ phần ký gửi. Bản ghi xuất cần giữ liên hệ tới đúng phần của A, thay vì chỉ giảm tổng K-01 từ 100 xuống 88. Khi giao dịch hoàn tất theo quy trình được duyệt, nhóm A còn 28 và nhóm doanh nghiệp vẫn 60 trong ví dụ. Đây là phép minh họa số lượng, chưa phải hướng dẫn hạch toán hay xác định khoản phải trả A.
Vị trí thực tế có thể giúp nhân viên tránh lấy nhầm, nhưng vị trí và owner vẫn là hai thuộc tính riêng. Chuyển 10 hộp sang kệ B không tự biến hàng của A thành hàng doanh nghiệp. Ngược lại, nếu có một giao dịch làm thay đổi chủ sở hữu, việc hàng vẫn nằm trên kệ A không có nghĩa dữ liệu owner được giữ nguyên. Quy trình phải nêu ai xác nhận thay đổi đó và căn cứ nào được dùng.
Đọc Owner của hàng ký gửi trong kho
Tài liệu hàng ký gửi của Odoo 19 mô tả cách nhận và lưu hàng do nhà cung cấp sở hữu. Trong báo cáo Stock On Hand, cột Owner giúp nhận diện phần hàng đó; tài liệu cũng cho biết hàng ký gửi có thể xuất hiện trong báo cáo kho nhưng không được đưa vào Stock Valuation của bên nhận giữ theo cơ chế được mô tả.
Điểm đáng chú ý khi thiết kế tích hợp là tên báo cáo không nói hết phạm vi. Một truy vấn lấy số lượng đang có và một truy vấn phục vụ định giá có thể tạo hai kết quả khác nhau mà không phải do thất thoát. Trước khi gọi một kết quả là “tồn của công ty”, người lập báo cáo cần chốt câu hỏi kinh doanh, bộ lọc và cách diễn giải trường owner trên hệ thống đang dùng.
Không nên suy ngược rằng mọi dòng owner trống trên mọi hệ thống đều là hàng doanh nghiệp sở hữu. Có thể phần mềm dùng quy ước đó, cũng có thể dữ liệu nhập cũ chưa đủ. Tích hợp phải đọc hợp đồng dữ liệu của nguồn cụ thể. Với dòng thiếu căn cứ, giữ trạng thái cần xác minh thay vì tự gán đối tác dựa trên tên sản phẩm hoặc nhà cung cấp thường mua.
Trong Odoo, mã lô còn phục vụ truy vết nhóm hàng. Tài liệu về lot numbers giải thích vai trò theo dõi nhóm sản phẩm qua các bước nhận, lưu và giao. Khi dữ liệu có cả lô và owner, cần giữ cả hai: cùng chủ sở hữu có thể có nhiều lô, và một mã hàng không thể thay thế cho mọi thông tin truy vết.
Một thử nghiệm phù hợp là dựng hai phần K-01 khác owner trong môi trường được phép, xem báo cáo, rồi đối chiếu các chuyển động đã thực hiện. Người kiểm tra cần đọc chi tiết, không chỉ chụp màn hình tổng số. Bài này chưa thực hiện thử nghiệm Odoo và không cam kết tên trường API, quyền thao tác hoặc giao diện giống nhau trên mọi bản cài đặt.
Đưa số lượng lên website mà vẫn giữ ranh giới
Website bán hàng thường chỉ cần một thông tin đơn giản như còn khả năng đáp ứng hay cần hỏi lại. Tuy nhiên, cách tạo thông tin đó có thể phụ thuộc loại thỏa thuận với bên giao ký gửi. Không lấy tổng vật lý rồi mặc định toàn bộ được phép bán ở mọi kênh, mọi địa điểm hoặc theo mọi bảng giá. Đội vận hành phải duyệt quy tắc sử dụng từng phần trước khi automation tính số công bố.
Ví dụ, đối tác A có thể cho phép một kênh nhất định bán phần hàng ký gửi; một trường hợp khác lại cần xác nhận trước mỗi yêu cầu. Đây là hai khả năng thiết kế giả định, không phải điều khoản mặc định của ký gửi hoặc tính năng sẵn có của website Onter. Brief tích hợp cần ghi lựa chọn thực tế thay vì để lập trình viên suy đoán từ nhãn “consignment”.
Dữ liệu trả ra công khai nên ít hơn dữ liệu vận hành. Tên đối tác, điều kiện thương mại và chi tiết chứng từ có thể chỉ cần ở màn hình nội bộ có quyền. Một API phục vụ nút đặt hàng không nhất thiết phải gửi toàn bộ bảng owner cho trình duyệt. Cách phân quyền, bộ lọc và thông tin hiển thị phải được kiểm riêng; việc có trường owner không tự bảo vệ dữ liệu.
Đặc biệt chú ý khi nguồn đang thiếu thông tin. Nếu kết nối kho thất bại, website không nên dùng số cũ rồi trình bày như vừa được xác nhận. Có thể chuyển sang yêu cầu tư vấn hoặc một cách hiển thị được doanh nghiệp chấp thuận. Bài không đặt ra một quy tắc chặn đơn chung; ý chính là trạng thái nguồn và quyền sử dụng hàng phải được thể hiện đúng trong quyết định của hệ thống.
Khi đổi đối tác giao hàng hoặc thêm một kho mới, cần rà lại khóa ghép. Dùng SKU đơn lẻ làm khóa chung dễ làm phần hàng của hai bên nhập thành một. Nếu cần công bố một tổng đã tổng hợp, hãy giữ đường truy ngược nội bộ từ tổng đó về các phần hợp lệ. Không cần đưa thông tin nhạy cảm lên website để có khả năng đối chiếu này.
Kiểm kê và bàn giao một báo cáo có thể giải thích
Đếm đủ 100 hộp không chứng minh cách chia 60 và 40 đã đúng. Có thể tổng vật lý khớp nhưng một lần nhập đã gán sai owner. Vì vậy cần hai câu hỏi riêng: số lượng thực tế có khớp dữ liệu không, và dữ liệu phân bổ chủ sở hữu có đúng căn cứ không. Cách kiểm thứ hai phải dựa vào hồ sơ, không thể giải quyết bằng cách đếm lại cùng một kệ.
Tài liệu inventory adjustments mô tả lớp đối chiếu số lượng và điều chỉnh trong Odoo. Trước khi áp dụng một chênh lệch, đội kho nên biết mình đang thay đổi phần nào và giữ căn cứ đã duyệt. Không dùng một điều chỉnh tổng để che việc chưa xác định được owner của từng phần hàng.
Với hệ thống đang vận hành, có thể bắt đầu bằng một báo cáo chỉ đọc trên mẫu đã được phép sử dụng. Chọn một SKU có hàng doanh nghiệp, một SKU ký gửi, một dòng chưa đủ owner và một giao dịch chuyển vị trí. Người phụ trách chỉ rõ kết quả kỳ vọng trước khi chạy; sau đó đối chiếu các dòng nguồn và báo cáo, không tự ghi điều chỉnh chỉ để thử cho nhanh.
Đầu ra bàn giao nên nói rõ mốc chốt, đơn vị, owner, số lượng và những trường hợp chưa phân loại. Các dòng cần xác minh phải còn nhìn thấy khi xuất file, không biến mất khỏi tổng mà không giải thích. Không sao chép hợp đồng, giá vốn hoặc thông tin liên hệ của đối tác vào log kỹ thuật chỉ để chứng minh chương trình đã chạy.
Onter đã có hướng dẫn về đối chiếu tồn kho và kiểm kê cho lớp so số lượng. Nếu nhu cầu của doanh nghiệp là giữ riêng hàng ký gửi trong báo cáo hoặc kết nối website, hãy mô tả thêm quy tắc owner và quyền sử dụng phần hàng khi trao đổi với Onter. Phạm vi hữu ích ban đầu là một mẫu báo cáo có thể truy lại căn cứ, trước khi giao quyền cập nhật dữ liệu hoặc nhận đơn tự động.
