Triển khai hệ thống quản lý đơn hàng tồn trong sản xuất không chỉ để có một danh sách đơn hàng đẹp hơn. Sau khi một dòng đơn hàng được giao nhiều đợt, số lượng còn phải giao, ngày đã cam kết, hàng được phân bổ, lệnh sản xuất và câu trả lời cho khách hàng phải phản ánh cùng một sự thật. Tại nhà máy Thái Lan, phòng kinh doanh có thể giữ Excel riêng, ERP quản lý chứng từ, MES quản lý lệnh sản xuất, còn WMS ghi từng chuyến xuất kho. Bài viết này chuyển những chênh lệch đó thành yêu cầu RFP và tiêu chí FAT/SAT có thể nghiệm thu.
Bắt đầu bằng phương trình số lượng cho từng dòng đơn hàng
Quy tắc cốt lõi là số lượng đặt hàng ở phiên bản đã duyệt mới nhất = số lượng đã xác nhận giao + số lượng hủy đã duyệt + số lượng còn chưa giao. Phải chọn một sự kiện nghiệp vụ duy nhất làm mốc “xác nhận giao”. Bắt đầu lấy hàng, lên kế hoạch chuyến giao hay hoàn thành sản xuất chưa chắc đã là giao hàng. Trả hàng, ghi có và điều chỉnh hóa đơn là những sự kiện riêng, không nên âm thầm sửa lịch sử giao hàng. Nếu số lượng đặt hàng đổi, lưu cả phiên bản trước và sau để biết phương trình đang áp dụng cho phiên bản nào.
Mọi số liệu dưới đây đều là ví dụ giả định, không phải kết quả dự án thực tế. Khách đặt 1.000 chiếc, đã xác nhận giao 600 và hủy chính thức 100; còn 300 chiếc chưa giao. Dù kho đã lấy thêm 200 chiếc, số lượng chưa giao vẫn là 300. Màn hình có thể ghi “trong 300 chiếc còn mở, 200 chiếc đang chuẩn bị giao”. Trừ hàng đã lấy quá sớm sẽ khiến việc đối chiếu khó khăn nếu chuyến giao bị dừng.
| Số lượng/trạng thái | Giá trị minh họa | Ý nghĩa |
|---|---|---|
| Đặt hàng đã duyệt | 1.000 | Dòng bán hàng phiên bản hiện hành |
| Đã xác nhận giao | 600 | Tổng sự kiện giao hàng được xác nhận |
| Hủy đã duyệt | 100 | Số lượng hủy chính thức |
| Chưa giao | 300 | Nghĩa vụ còn phải thực hiện với khách |
| Đã lấy trong số còn mở | 200 | Phần của 300, không phải khoản trừ thêm |
Lưu số lượng theo đơn vị cơ sở đã thống nhất và quy định chuyển đổi, làm tròn đối với thùng/chiếc, kg/g hoặc mét/chiếc. Hàng thay thế, hàng tặng, bộ sản phẩm và quy cách đóng gói riêng cần dòng tham chiếu về đơn gốc. Mốc xác nhận giao có thể là xuất kho, bàn giao cho hãng vận chuyển hoặc sự kiện khác theo hợp đồng và kế toán. Phương trình này là nguyên tắc thiết kế của dự án, không phải mô tả cấu trúc bên trong của mọi ERP.
Tách số lượng còn mở, phân bổ và cam kết
Còn 300 chiếc không có nghĩa ngày mai giao được cả 300. Hãy hiển thị riêng số chưa giao, số đã phân bổ từ tồn kho, số gắn với kế hoạch sản xuất, số chưa hứa ngày và số đang chuẩn bị xuất. Cam kết với khách là quyết định được phê duyệt, không đồng nhất với tồn kho vật lý. Hướng dẫn đặt giữ tồn kho của Microsoft phân biệt đặt giữ tự động/thủ công, tồn kho hiện hữu/hàng đã đặt mua và trường hợp lô hàng [2].
Ngày khách yêu cầu, ngày đã cam kết với khách, ngày dự kiến mới nhất, ngày định xuất và ngày xác nhận giao thực tế phải là các trường riêng. Ghi đè ngày yêu cầu bằng ngày dự kiến mới sẽ xóa bằng chứng về mong muốn ban đầu và lời hứa đã thông báo. Dự báo thay đổi không đồng nghĩa khách đã nhận hoặc chấp thuận lời hứa mới. Nếu kinh doanh, kế hoạch và kho mỗi bên giữ một Excel, chỉ định nguồn chính thức dùng để trả lời khách.
Bài này tập trung vào nghĩa vụ còn mở sau khi giao từng phần. Quy trình sửa số lượng, ngày và thông số đơn hàng nằm trong hướng dẫn quản lý thay đổi đơn hàng sản xuất. RFP tổng thể cho ngày giao nằm trong hướng dẫn hệ thống quản lý tiến độ giao hàng.
Một dòng đơn thương mại, nhiều dòng thực hiện
Khi giao một dòng đơn thành nhiều đợt, giữ dòng thương mại cha và gắn các dòng lịch giao cùng chi tiết giao thực tế ở dưới. Microsoft Dynamics 365 mô tả lịch giao chia số lượng dòng gốc thành các dòng giao có ngày, số lượng, phương thức và kho khác nhau [1]. Hướng dẫn của Microsoft về giao trực tiếp giải thích việc tách số lượng còn lại sang dòng mới khi một phần đơn gốc đã được giao [3]. Ý ở đây là nhất quán nghiệp vụ, không phải yêu cầu sao chép cấu hình của một sản phẩm cụ thể.
Giả sử 300 chiếc còn mở được cam kết 200 chiếc ngày 12/10 và 100 chiếc ngày 20/10. Tổng hai dòng cam kết là 300; 600 chiếc đã giao và 100 chiếc đã hủy không được tính lại vào lịch mở. Nếu đợt đầu chỉ thực giao 150 chiếc, giữ 50 chiếc của đợt đó trong trạng thái chưa giao và thỏa thuận ngày mới với khách. Không tự ý kéo đợt thứ hai lên trước chỉ để bảng điều khiển trông cân đối. Lưu người sửa cam kết và thời điểm sửa.
Mỗi dòng thực hiện cần ID dòng đơn, thứ tự, phiên bản, lượng dự kiến, ngày yêu cầu, ngày cam kết, địa điểm giao, kho, cách vận chuyển, mức ưu tiên và trạng thái phê duyệt. Mỗi chi tiết giao cần lượng thực tế, lô và ID sự kiện xác nhận giao. Báo cáo không được cộng dòng cha và con như hai giao dịch bán độc lập. Nếu một dòng có nhiều nơi nhận hoặc nhiều loại tiền, người phụ trách nghiệp vụ phải quyết định có tách dòng thương mại ngay từ đầu hay không.

Hình 1 cho thấy một dòng đơn tách thành hai lịch giao và nhiều lần giao xác nhận, phần còn lại quay về số lượng chưa giao. Mọi con số đều để minh họa.
Xác định nguồn chính của từng sự kiện ERP, MES và WMS
Một cấu hình thường gặp là ERP quản lý đơn thương mại, MES quản lý lệnh và kết quả sản xuất, WMS quản lý phân bổ, lấy hàng và xác nhận xuất. Nhưng chức năng sản phẩm có thể chồng lấn, vì vậy hãy xác định hệ thống nào xác nhận từng sự kiện đầu tiên. ISA-95 là khung tham chiếu để trao đổi thông tin giữa cấp doanh nghiệp và vận hành sản xuất [6]; khung này không tự động gán mọi chức năng WMS vào một tầng cố định.
| Dữ liệu/sự kiện | Chọn nguồn chính | Tác động đến số còn mở |
|---|---|---|
| Dòng đơn và hủy đã duyệt | Quản lý đơn hoặc ERP | Sửa số đặt và số hủy |
| Ngày và số lượng cam kết | Quy trình phê duyệt kinh doanh/kế hoạch | Sửa lịch giao phần còn mở |
| Lệnh và hoàn thành sản xuất | Quản lý sản xuất hoặc MES | Cập nhật triển vọng cung ứng, chưa phải đã giao |
| Giữ hàng và lấy hàng | ERP hoặc WMS được chỉ định | Đổi phần bên trong số còn mở, không giảm tổng |
| Xác nhận giao | Một sự kiện chính ở WMS hoặc ERP | Tăng số đã giao và tính lại số còn mở |
| Trả lời khách | Hồ sơ liên lạc đã duyệt của kinh doanh | Lưu phiên bản cam kết và giờ thông báo |
Không được tính thông điệp xác nhận của WMS và chứng từ giao ERP thành hai lần giao. Nếu hệ thống này sinh chứng từ cho hệ thống kia, dùng cùng mã tham chiếu và xác định một sự kiện xác nhận duy nhất. MES báo hoàn thành có thể còn chờ kiểm tra chất lượng, chưa sẵn sàng giao. Với hàng trả lại, phải quyết định mở lại số còn giao ở đơn cũ hay tạo đơn thay thế.
Giữ backorder hiển thị và có người lập kế hoạch tiếp
Có số còn mở không đồng nghĩa đã có lịch cho chuyến tiếp theo. Ví dụ Oracle cho thấy đơn 10 chiếc, giao 6 chiếc rồi lập một chuyển động hoặc kế hoạch giao mới cho 4 chiếc còn lại; tài liệu cũng nêu bước thủ công khi sự kiện backorder không đi qua giữa các hệ thống [4]. Nếu giao diện chỉ nhận kết quả giao nhưng không tạo hành động tiếp cho phần còn lại, nghĩa vụ với khách có thể bị bỏ quên.
Hướng dẫn Oracle Order Management cũng mô tả giao một phần rồi để phần còn lại dưới dạng backorder [5]. Đây là ví dụ chức năng sản phẩm, không phải mặc định cho nhà máy ở Thái Lan. Yêu cầu cần kiểm thử là phần còn lại luôn nối với dòng đơn gốc, có người chịu trách nhiệm xác nhận lại ngày và hiện trong hàng đợi ngoại lệ nếu chưa được cam kết.
Số chưa giao không tự động là backorder. Đợt sau trong lịch chia giao đã được khách duyệt là dòng giao đang mở theo kế hoạch. Khi thiếu nguồn hàng khiến không thể thực hiện kế hoạch ban đầu và phải lên lịch lại phần còn lại, phần đó có thể được quản lý như backorder. Phần còn mở quá ngày cam kết mới là trễ. Danh sách ưu tiên nên phân biệt đúng kế hoạch, chưa cam kết, có nguy cơ và trễ; hiển thị ngày cam kết cũ nhất chưa thực hiện, ngày dự kiến tiếp theo và tình trạng thông báo. Chỉ đếm “số đơn còn dư” sẽ nhầm lịch chia giao bình thường thành lỗi.
Gắn phân bổ tồn kho và lệnh sản xuất với đúng đợt giao
Xác định giữ hàng cho toàn dòng đơn hay cho từng đợt. Với 300 còn mở và 200 đã giữ, hãy hiển thị “còn mở 300, đã giữ 200, chưa giữ 100”. Không hiển thị “còn mở 100” vì khách vẫn đang đợi đủ 300. Nếu lô đã giữ bị chặn chất lượng, chênh kiểm kê hoặc hết hạn, phải sửa giữ hàng và đánh giá lại ngày cam kết.
Sản xuất theo đơn cần liên kết lệnh sản xuất với từng lịch giao. Nếu một lệnh cấp cho nhiều khách, phải có bảng phân bổ. Đã lên kế hoạch, đã phát hành, bắt đầu, hoàn thành, chờ kiểm tra và nhập kho là các mức chắc chắn khác nhau. Không trình bày lượng dự kiến sản xuất là hàng vật lý sẵn có. Hỏng máy hoặc kết quả chất lượng có thể thay đổi ngày dự kiến, vì vậy lời hứa mới cần người có thẩm quyền duyệt.
Nhà máy vừa sản xuất dự trữ vừa sản xuất theo đơn cần phân biệt hàng hiện hữu, nguyên liệu đã đặt, sản phẩm dở dang và thành phẩm dự kiến dù cùng nằm trên một màn hình. Khi chuyển việc sang dây chuyền khác hoặc thuê ngoài, phát hiện giữ hàng hai lần với lệnh cũ. Khi ngày cam kết thay đổi, nêu rõ kế hoạch và giữ hàng tự cập nhật hay tạo nhiệm vụ chờ duyệt.
Thiết kế một màn hình để trả lời khách và truy nguyên
Nhân viên kinh doanh cần biết không chỉ còn bao nhiêu mà còn đã hứa bao nhiêu vào ngày nào, dựa vào tồn kho hay sản xuất, và khác câu trả lời lần trước ra sao. Hiển thị khách, đơn và dòng, mặt hàng, lượng đặt, tổng đã giao, đã hủy, còn mở, đang chuẩn bị, đã/chưa giữ hàng, lịch cam kết, ngày dự kiến, giờ cập nhật, trạng thái báo khách và lý do ngoại lệ. Giữ chế độ mặc định gọn, cho phép mở chi tiết giao, phân bổ và lệnh sản xuất.
Lịch sử phản hồi cần người nhận, thời gian, ngôn ngữ, số lượng/ngày đã báo, phiên bản dữ liệu, người duyệt và kênh liên lạc. Với người dùng tiếng Thái, Nhật và Anh, giữ một mốc thời gian bên trong rồi bản địa hóa cách hiển thị. Nếu chỉ cam kết một ngày, ghi rõ là ngày theo giờ nhà máy để chuyển múi giờ không làm lệch ngày. Lưu cả thay đổi địa điểm giao hoặc chuyến vận tải so với lời hứa trước.

Hình 2 mô tả dòng đơn ERP, lệnh MES, sự kiện giữ hàng/giao WMS đổ về một màn hình số còn mở. Mỗi loại sự kiện chỉ có một nơi xác nhận chính để tránh tính hai lần.
Chống tính trùng khi gửi lại và xử lý thông điệp sai thứ tự
Nếu mất kết nối rồi WMS gửi lại “đã giao 200”, bên nhận không được cộng thành 400. Dùng ID sự kiện nguồn, chứng từ, dòng và phiên bản để áp dụng một lần. Thành công ở tầng truyền không đồng nghĩa giao dịch nghiệp vụ tại hệ nhận đã ghi. Hãy thiết kế xác nhận, thử lại, cách ly, phát lại bằng tay và đối soát. Ghi log cả những sự kiện trùng đã bỏ qua.
Thứ tự cũng quan trọng. Nếu sự kiện hủy tới trước và cập nhật lời hứa phiên bản cũ tới sau, quy tắc “thông điệp nhận cuối thắng” có thể xóa kết quả hủy. Sự kiện cần ID dòng gốc, phiên bản, giờ phát sinh và giờ truyền. Phiên bản cũ phải cách ly. Nếu giao hàng vật lý và hủy diễn ra gần nhau, kiểm tra thực tế trước khi sửa sổ. Không viết lại lịch sử chỉ để phương trình nhìn đúng.
Hợp đồng giao diện phải nêu sự kiện nghiệp vụ, điều kiện phát, khóa, đơn vị, nguồn chính, xác nhận, timeout, thử lại, thứ tự, hàng đợi lỗi, quyền phát lại, đối soát hằng ngày và audit log. Với tích hợp theo lô, hiển thị độ mới dữ liệu. Một bảng trông như trực tiếp nhưng thực tế là số dư hôm qua dễ khiến kinh doanh trả lời sai.
Đối soát chênh lệch mỗi ngày
Đối soát hằng ngày kiểm phương trình tại từng dòng và so các sự kiện giao duy nhất giữa ERP/WMS. Hóa đơn có thể lập ngày khác nên không ép số hóa đơn bằng số giao cùng ngày. Tách chưa nhận, nhận trùng, cách ly và chờ duyệt; mỗi ngoại lệ cần người phụ trách, hạn kiểm tra và quyết định phát lại.
| Chênh lệch | Cách phát hiện | Kiểm tra đầu tiên |
|---|---|---|
| Giao bị tính hai lần | ID sự kiện/dòng trùng | Khóa chống trùng và thử lại |
| WMS đã giao, ERP chưa giảm dư | Đối soát sự kiện | Mất thông điệp, cách ly, đổi đơn vị |
| Số còn mở âm | Phương trình và kiểm giới hạn | Giao theo phiên bản đơn cũ |
| Tổng lời hứa vượt số còn mở | Cộng các lịch giao | Còn phiên bản cũ hoặc lịch trùng |
| Câu trả lời khách lệch màn hình | So phiên bản phản hồi | Chưa thông báo hoặc sửa tay |
Ngưỡng cảnh báo tùy nhà máy và hợp đồng. Đèn xanh tổng hợp không chỉ ra khách nào bị ảnh hưởng. Trước kỳ nghỉ, ưu tiên phần sắp đến hạn và hàng đợi lỗi. Sửa tay phải giữ sự kiện gốc, lý do, người duyệt để đồng bộ tự động ngày sau không xóa sửa chữa.
Tách giao chia đợt, hủy và trả hàng
Số còn mở đúng phải giải thích được vì sao nó thay đổi. Giao từng phần là thực hiện nghĩa vụ, hủy là giảm nghĩa vụ đã được duyệt, còn trả hàng là luồng vật lý ngược sau khi đã giao. Nếu cả ba đều được xử lý bằng một “điều chỉnh âm”, con số cuối có thể giống nhau nhưng nghĩa vụ với khách khác hẳn. Hiển thị thay đổi so với hôm qua theo đơn mới, sửa phiên bản, giao xác nhận, hủy, trả và nghĩa vụ được mở lại; giữ chứng từ nguồn và phê duyệt cho từng thay đổi.
Giả sử đặt 100, giao 60, còn 40. Nếu khách hủy 10 trong số chưa giao, kết quả là đã giao 60, hủy 10, còn 30. Nhưng nếu khách trả lại 10 trong số 60 đã giao, cách xử lý tùy theo việc khách muốn hàng thay thế hay hoàn tiền. Nếu phải giao thay, tạo hoặc mở nghĩa vụ giao và liên kết với đơn gốc, phiếu trả. Nếu hoàn tiền là kết thúc, không tự tăng số chưa giao của dòng gốc thêm 10. Quyết định còn liên quan đến kiểm chất lượng, khả năng nhập lại tồn kho và chỉnh hóa đơn. Hãy chỉ định ai được mở lại dòng backlog trước khi có vụ trả đầu tiên.
Đặt ID cố định cho mỗi lịch giao được tách
Nếu chỉ dùng số thứ tự trên màn hình, việc kinh doanh đổi vị trí ngày giao có thể khiến hệ thống khác hiểu nhầm sang đợt khác. Dùng ID lịch giao không đổi, ID dòng bán cha và phiên bản. Khi một lịch 200 được tách thành 150 và 50, lưu cách đóng dòng cũ và cách hai dòng mới tham chiếu về nó. Không dùng lại ID hoặc xóa dấu vết. Chi tiết giao phải gắn với phiên bản lịch đang có hiệu lực lúc giao, để việc sửa lịch sau này không đổi nguồn gốc giao hàng đã xảy ra.
Nếu hai nhà máy cùng cấp một số còn mở, tách phân bổ cho nhà máy khỏi lời hứa với khách. Kế hoạch 120 từ Thái Lan và 80 từ nơi khác không phải hai lời hứa 200 cho khách. Nếu một nhà máy trễ 50, đánh giá lại toàn bộ cam kết. Xóa lệnh sản xuất của một nhà máy không xóa nghĩa vụ thương mại. Vì vậy dòng bán, lịch giao, phân bổ nguồn cung và chi tiết giao phải là bốn cấp bản ghi khác nhau.
Tính lại số còn mở khi chuyển dữ liệu
Chỉ chuyển “số dư hiện tại” từ Excel cũ sẽ mất bằng chứng giao và hủy. Với mỗi đơn chưa đóng, đối soát lượng đặt đã duyệt, hủy chính thức, tổng giao xác nhận, lượng chưa giao, lịch giao, phiên bản cam kết và liên kết tới giữ hàng/lệnh sản xuất. Tính lại từ sự kiện nguồn khi có thể thay vì tin số dư cũ. Nếu hệ cũ ghi đè điều chỉnh và không còn lịch sử, ghi rõ “không thể kiểm chứng” và lưu bằng chứng nào từ kiểm đếm thực tế, chứng từ giao hoặc xác nhận khách đã duyệt số đầu kỳ.
Vào ngày cutover, đặt riêng giờ dừng sửa đơn và giờ dừng xác nhận giao. Nếu kinh doanh đã ngừng sửa nhưng kho vẫn xuất, tổng giao đưa sang hệ mới sẽ cũ. Hoàn tất trích xuất cuối, nhập delta, đối soát phương trình và thử trả lời một khách đại diện trước khi chọn hệ mới làm nguồn chính. Nếu phải giao khẩn trong lúc đóng băng, chuẩn bị chứng từ giấy, ID chống trùng và người nhập lại. Đưa các ranh giới này vào RFP để nhà cung cấp báo giá số dư đúng trong ngày đầu, thay vì chỉ nhập master data.
Cùng còn 50 nhưng cần ba hành động khác nhau
Hãy tưởng tượng ba đơn minh họa, mỗi đơn còn 50. Đơn A có đợt giao tháng sau đã cam kết và hàng đã giữ; B đến hạn hôm nay nhưng thiếu nguyên liệu và lệnh sản xuất chưa chạy; C có 50 đã lấy nhưng bị chặn chất lượng. Màn hình chỉ ghi “còn 50” không cho kinh doanh biết phải gọi ai trước. A theo dõi bình thường; B cần lập lại kế hoạch và liên hệ khách; C cần quyết định chất lượng và kiểm lô thay. Giữ nguyên nhân, việc tiếp theo, người phụ trách, hạn và tình trạng báo khách trên từng dòng.
Ưu tiên cần xét thời gian tới ngày hứa, thỏa thuận khách, nguồn thay thế và hậu quả hợp đồng bên cạnh số lượng. Tự động lấy hàng đã dành cho đơn khác có thể làm vỡ lời hứa với khách khác. Tách đề xuất phân bổ lại khỏi thao tác thực hiện, cho người duyệt thấy tác động trước và sau. Chỉnh ngưỡng cảnh báo theo nhà máy; theo dõi số lượng và tuổi cảnh báo chưa xử lý để đơn trễ nghiêm trọng không chìm trong thông báo thường ngày.
Đưa sơ đồ trạng thái và dữ liệu thực tế vào RFP
Câu “hiển thị đơn hàng tồn” không đủ để so đề xuất. Cung cấp ví dụ dòng đơn, lịch giao, phân bổ, lệnh sản xuất, chi tiết giao và các chuyển trạng thái bình thường/ngoại lệ. Nếu liên quan nhiều nhà máy hoặc kho, đưa tình huống đó vào. Trong demo, dùng cùng một chuỗi: đặt 1.000, giao 600, hủy 100, còn 300, giữ 200, rồi giao thêm 150. Kết quả cuối còn 150. Đây chỉ là số kiểm thử giả định.
Yêu cầu nhà cung cấp nêu hạng mục nào là chức năng chuẩn, cấu hình, phát triển thêm, tích hợp hoặc kiểm soát bằng người. Chữ “làm được” cần có màn hình, API, báo cáo, audit log hoặc bằng chứng test. Khi có ngoại lệ, ai trong kinh doanh, kế hoạch hay kho chịu trách nhiệm bước tiếp theo? So cả chi phí dọn dữ liệu, tích hợp, kiểm thử, đào tạo tại chỗ, hỗ trợ ban đầu và thay đổi về sau, không chỉ phí bản quyền.
Mười câu hỏi cho RFP
- Sự kiện nào thay đổi phương trình số lượng và lưu lịch sử sửa như thế nào?
- Sau giao từng phần, phần dư liên kết với dòng cha và lịch giao ra sao?
- Ngày yêu cầu, ngày hứa, ngày dự kiến và ngày định xuất có tách riêng không?
- Phân bổ và lệnh sản xuất gắn với đúng đợt như thế nào?
- Ai được cảnh báo khi chặn chất lượng hoặc dừng máy đe dọa cam kết?
- Sự kiện xác nhận giao duy nhất giữa ERP/MES/WMS nằm ở đâu?
- Xử lý gửi lại, trùng, sai thứ tự và mất mạng như thế nào?
- Phê duyệt và lưu trả lời khách bằng tiếng Thái, Nhật, Anh ra sao?
- Mô hình hóa trả hàng, hủy, thay sản phẩm và đổi nơi giao thế nào?
- Bằng chứng FAT/SAT và sau go live nào chứng minh số dư đúng?
Kiểm thử biên trong FAT/SAT
FAT cần thử phương trình và chuyển trạng thái trong môi trường kiểm soát: lượng bằng không, nhỏ, giới hạn lớn, chuyển đơn vị, giao từng phần, chặn giao vượt, hủy, trả, sự kiện trùng, phiên bản cũ và thông điệp đảo thứ tự. Chặn số dư âm thôi chưa đủ; người dùng cần hiểu vì sao giao dịch bị từ chối hoặc giữ lại. Cố ý làm lượng kế hoạch, lượng giữ và lượng đã giao khác nhau để bảo đảm màn hình không hứa nguồn hàng không có thật.
SAT dùng thiết bị và vai trò thực tế tại nhà máy Thái Lan, đi qua đơn ERP, lệnh MES, lấy/giao WMS và trả lời của kinh doanh. Bao gồm bàn giao ca, mất mạng và thử lại, quét nhãn, nhiều kho và khách hỏi gấp. Dùng dữ liệu khách được kiểm soát nhưng quyền và luồng gần vận hành thật. Phiếu nghiệm thu có số dư kỳ vọng, số thực, chênh lệch, ID sự kiện, bằng chứng, người kiểm và mức nghiêm trọng của lỗi còn mở.
| Kiểm thử | Thao tác giả định | Ví dụ điều kiện đạt |
|---|---|---|
| Giao từng phần | Đặt 100, xác nhận giao 60 | Đã giao 60, còn 40, có bước tiếp theo |
| Hủy | Hủy 10 trong số còn 40 | Giao 60, hủy 10, còn 30 |
| Gửi lại | Gửi cùng sự kiện hai lần | Tổng giao vẫn 60, có log trùng |
| Đảo thứ tự | Gửi phiên bản lời hứa cũ sau | Không ghi đè lời hứa hiện hành |
| Chặn chất lượng | Giữ lô đã phân bổ | Số còn không đổi, cảnh báo lời hứa |
| Mất kết nối | Phản hồi API mất sau WMS xác nhận | Thử lại chỉ áp dụng một lần |
Số trong bảng là giá trị minh họa, không phải chuẩn tỷ lệ đạt. Các trường hợp quan trọng phải đạt từng mục trước khi mở vận hành. Lỗi hiển thị nhỏ được mang sang sau chỉ khi không thể khiến trả lời khách sai và có người nhận sửa, ngày sửa.

Hình 3 thể hiện thử nghiệm giao từng phần và mất kết nối. WMS gửi lại sự kiện nhưng số còn trong ERP chỉ đổi một lần, câu trả lời khách phải khớp.
Xác định điều kiện kết thúc pilot và giai đoạn ổn định
Bắt đầu với một nhóm sản phẩm và một nhà máy thường có chia đợt giao, nơi các nhóm liên quan có thể cùng xử lý. Đừng chọn toàn đơn dễ; bao gồm hủy, thiếu hàng, chặn chất lượng, sản xuất trễ và gửi lại. Nếu giữ Excel để so tạm thời, nêu kỳ hạn, nguồn chính, người nhập và điều kiện bỏ để tránh vận hành song song vĩnh viễn.
Sau go live, xem hằng ngày số chênh lệch dư, lượng chưa cam kết quá hạn, số lần phải trả lời lại khách, tuổi của lỗi tích hợp và số chỉnh sửa bằng tay. Đây là chỉ báo để chẩn đoán, không phải lợi ích được bảo đảm. Một số chênh lệch chỉ xuất hiện cuối tháng hoặc lúc kiểm kho. Bàn giao nên có nghĩa đội ngũ Thái Lan tự điều tra, phát lại, duyệt và thông báo khách mà không phải chờ nhóm dự án ban đầu cho mọi sự cố.
Kết luận: giữ nghĩa vụ còn mở qua từng lần giao
Quản lý đơn hàng tồn trong sản xuất dựa vào quan hệ đúng giữa số đã đặt, đã xác nhận giao, đã hủy và còn phải giao. Mỗi lần giao từng phần, phần dư phải còn ngày hứa, phân bổ, nguồn sản xuất và việc cho chuyến tiếp. Chọn chủ sở hữu và ID sự kiện ERP/MES/WMS để mạng mất hay gửi lại không tính hai lần. Giữ cả lịch sử liên lạc khách. Bước đầu thiết thực là chọn một đơn thực đã giao nhiều lần rồi vẽ nơi số lượng và ngày khác nhau giữa Excel kinh doanh, ERP, MES và WMS.
TOMAS TECH có thể giúp nhà máy Thái Lan xác định yêu cầu đơn hàng tồn và giao nhiều đợt, ranh giới sự kiện ERP/MES/WMS, RFP và FAT/SAT. Khi chưa chọn phần mềm, bạn vẫn có thể trao đổi về dự án quản lý đơn hàng tồn cùng luồng đơn tới giao hiện tại.
Câu hỏi thường gặp
Quản lý đơn hàng tồn khác hệ thống quản lý ngày giao thế nào?
Hệ thống ngày giao nhìn rộng qua mua hàng, sản xuất và xuất hàng. Quản lý đơn hàng tồn tập trung vào lượng và cam kết còn nợ trên từng dòng sau khi giao từng phần hoặc hủy. Hai hệ thống liên kết nhưng màn hình ngày giao không đáng tin nếu lượng còn mở không có nguồn chính.
Sau giao từng phần, tính số còn mở ra sao?
Lấy lượng đặt đã duyệt trừ lượng giao xác nhận và lượng hủy chính thức. Lấy hàng, phân bổ, kế hoạch xuất và hoàn thành sản xuất thay đổi trạng thái hoặc triển vọng nguồn cung, không tự giảm nghĩa vụ chưa giao. Chọn một mốc xác nhận giao.
Backorder có luôn nghĩa là trễ không?
Không. Đợt sau trong lịch chia giao đã được duyệt là dòng chưa giao theo kế hoạch, không tự động là backorder. Thiếu hàng khiến phải lập lại lịch cho phần còn lại thì có thể gọi là backorder. Phần quá ngày cam kết là trễ. Tách các trạng thái này.
Điều quan trọng nhất khi kết nối ERP, MES và WMS là gì?
Chọn một sự kiện xác nhận giao có thẩm quyền và dùng ID sự kiện/dòng đơn để phát hiện trùng và thông điệp cũ. Không tính sản xuất xong hay đã lấy hàng thành giao thêm. Yêu cầu đối soát hằng ngày và khả năng phát lại lỗi cách ly.
FAT/SAT của hệ thống đơn hàng tồn cần chứng minh gì?
Chạy một đơn qua giao từng phần, hủy, sửa ngày hứa, thay phân bổ, mất mạng và gửi lại; kiểm phương trình và câu trả lời khách. FAT thử logic và biên tích hợp, SAT thử thiết bị, nhân viên, ca và kho thực tế.
Nguồn tham khảo chính
- Microsoft Learn, Delivery schedules.
- Microsoft Learn, Reserve inventory quantities.
- Microsoft Learn, Direct deliveries.
- Oracle Help Center, Backorder/Partial Ship.
- Oracle, Ship Order Lines in Shipment Sets.
- ISA, ISA-95 Standard.
Đã kiểm tra nguồn ngày 08/10/2026. Mọi số lượng, ngày và giá trị thử nghiệm chỉ để minh họa, không phải kết quả sản phẩm, ngưỡng pháp lý hay lợi ích được bảo đảm.