Sửa lô sau khi xuất kho Business Central: ba cách và cái giá của từng cách
Sửa lô sau khi xuất kho Business Central khi hóa đơn đã post: so ba cách theo tồn từng lô, truy xuất theo khách, giá vốn và rủi ro lúc khách trả hàng.
Sửa lô sau khi xuất kho trên Business Central, lúc phiếu xuất và hóa đơn đã post, có ba cách. Item Reclassification Journal chỉ sửa tồn theo lô, tra lô vẫn ra sai khách. Cặp bút toán Item Journal loại Sale gắn mã khách sửa được cả tồn lẫn truy xuất, nhưng mỗi lần sửa sinh thêm bút toán kho. Cách thứ ba là customize: một bảng riêng ghi lô thực tế, sổ kho để nguyên.
Cách 2 tôi chạy trọn luồng trên một sandbox BC 28.1 ngày 24/09/2026, kể cả tình huống khách trả hàng sau khi đã sửa lô. Cách 1 là hành vi chuẩn của Item Reclassification Journal. Cách 3 đang ở mức thiết kế cho một dự án, không phải tính năng chuẩn của BC.
Vì sao lô trên hệ thống lệch lô thực tế#
Tình huống ở một khách hàng ngành thực phẩm và đồ uống: lô được gán trên phiếu xuất ở văn phòng, trước khi kho soạn hàng. Ngoài kho, người soạn lấy thùng nào tiện tay. Đơn gấp thì kho lấy hàng theo FEFO cho kịp xe, lô thực tế chỉ ghi nhanh trên giấy. Hàng đi đường phải có hóa đơn đi kèm, nên phiếu xuất bắt buộc post trước khi xe chạy, tức là post với lô hệ thống gợi ý.
Kết quả: tổng tồn của mặt hàng đúng, tồn theo từng lô sai. Lô đã ra khỏi kho thì hệ thống báo còn, lô còn trên kệ thì hệ thống báo đã xuất. Với hàng thực phẩm, chỗ đau nhất là thu hồi: tra một lô ra sai danh sách khách.
Dưới đây gọi lô A là lô hệ thống gợi ý và đã post, lô B là lô kho giao thật.
Cách 1: Item Reclassification Journal chỉ sửa tồn#
Item Reclassification Journal chuyển phần tồn đang nằm ở lô B sang lô A, cùng mặt hàng, cùng số lượng. Tồn theo lô khớp kệ hàng. Nhưng bút toán xuất bán không bị đụng tới: sổ kho vẫn ghi khách nhận lô A. Thu hồi lô B thì Item Tracing không ra khách đó.
Cách này đủ khi chỉ cần tồn kho đúng, không đủ cho thu hồi theo lô. Cách làm chuẩn ở Reclassify serial or lot numbers.
Cách 2: cặp bút toán Item Journal loại Sale, gắn mã khách#
Item Journal có Entry Type = Sale, không chỉ Positive Adjmt. và Negative Adjmt. Mỗi lần sửa lô cho một dòng phiếu xuất, post một cặp bút toán loại Sale, cùng số chứng từ với phiếu xuất gốc và cùng mã khách:
| Bút toán | Lô | Số lượng | Ý nghĩa |
|---|---|---|---|
| Gốc, đã post | A | -10 | Hệ thống ghi đã giao lô A |
| Sửa 1 | A | +10 | Khách trả lại lô A, áp vào bút toán gốc để hoàn đúng giá vốn |
| Sửa 2 | B | -10 | Khách nhận lô B |
Mã khách nằm ở hai field Source Type và Source No.. Bảng Item Journal Line có sẵn hai field này, giống bảng Item Ledger Entry, nhưng trang Item Journal chuẩn không hiện chúng và người dùng không Personalize thêm vào được. Vì vậy dòng journal phải tạo bằng code: lấy Source Type, Source No., Document No. từ bút toán xuất gốc rồi post. Cách khai Lot No. cho mặt hàng có lô trên Item Journal tôi đã viết ở bài import tồn đầu kỳ có Lot No. và hạn dùng bằng Item Journal.
Kịch bản đã chạy: mặt hàng tính giá Average, nhập 20 đơn vị lô A giá 40,000 vào bin 1 và 20 đơn vị lô B giá 50,000 vào bin 2. Bán 10 đơn vị lô A qua Warehouse Shipment, post kèm hóa đơn. Post cặp bút toán sửa sang lô B, rồi chạy Adjust Cost.
| Kiểm tra | Kết quả |
|---|---|
| Tồn theo lô | Lô A về lại 20, lô B còn 10, khớp kệ hàng |
| Tồn theo bin | Bin 1 (lô A) về lại 20, bin 2 (lô B) còn 10 |
| Hóa đơn, doanh thu | Không đổi. Hai bút toán sửa có doanh thu bằng 0 |
| Giá vốn sau Adjust Cost | Gốc -450,000, lô A hoàn +450,000, lô B xuất -450,000. Tổng vẫn -450,000 |
| Item Tracing, tra lô B | Ra đúng Sales Shipment của phiếu xuất gốc, đúng khách, -10 |
| Item Tracing, tra lô A | Giao -10, ngay bên dưới là dòng hoàn +10 |
Ba điểm kỹ thuật để dev làm đúng ngay lần đầu:
- Mặt hàng có lô thì bút toán gốc để hoàn giá vốn khai ở
Appl.-from Item Entrytrên Item Tracking Lines. Khai ởApplies-from Entrytrên dòng journal thì BC báo lỗi. - Bin của dòng hoàn lô A lấy từ Warehouse Entry của phiếu xuất gốc. Bin của lô B là bin lô đó đang nằm thật.
- Post lỗi giữa chừng thì phải xóa Item Tracking trước, sau đó mới xóa được dòng journal.
Ba chỗ cách 2 vẫn hở:
- Item Tracking Lines mở từ Posted Sales Shipment vẫn hiện lô A. Màn hình này đọc liên kết giữa dòng phiếu xuất và bút toán gốc, bút toán sửa không nằm trong liên kết đó.
- Bán tiếp lô A cho khách khác thì Item Tracing rối. Khách mới hiện bên dưới dòng khách cũ hoàn lô, nhìn như hàng khách cũ trả về rồi bán lại. Danh sách khách tính ròng vẫn đúng. Mọi cách hoàn rồi xuất lại trong BC chuẩn, kể cả Undo Shipment hay trả hàng thật, đều cho ra chuỗi này.
- Trả hàng thật dễ sai lô. Khách trả 4 đơn vị, hàng về thực tế là lô B. Bật Exact Cost Reversing thì copy từ hóa đơn không ra dòng nào, vì bút toán hoàn đã dùng hết số lượng được trả của dòng xuất gốc. Tắt đi thì copy ra lô A và BC vẫn cho post. Chỉ khi chọn lô B và áp vào bút toán sửa thì mới post đúng: giá vốn hoàn 45,000 mỗi đơn vị, số còn được trả của bút toán sửa giảm từ 10 xuống 6.
Sổ cái tôi chưa đối chiếu: sandbox tắt Automatic Cost Posting và tôi chưa chạy Post Inventory Cost to G/L. Lưu ý khi thử: post Warehouse Receipt và post chứng từ bán tự commit, nên thử trên sandbox vẫn để lại chứng từ thật.
Trả hàng bằng Get Posted Document Lines to Reverse còn một bẫy khác khi đơn có item charge âm, xem bài phân bổ Item Charge khi trả hàng.
Cách 3: bảng riêng ghi lô thực tế, sổ kho để nguyên#
Tôi không chọn cách 2 cho dự án này, vì mỗi lần sửa sinh thêm hai Item Ledger Entry, đơn nhiều thì Adjust Cost nặng thêm. Hướng khách chọn là một bảng riêng chỉ phục vụ truy xuất, không đụng luồng chuẩn của Undo Shipment hay trả hàng. Đây là customize, tôi chỉ nêu ý tưởng:
- Trong ngày, kho tải lên file Excel ghi lô thực tế theo từng phiếu xuất và mặt hàng, giống tờ giấy kho đang ghi.
- Hệ thống so với lô đã post và chỉ lưu phần lệch, mỗi dòng gắn vào Item Ledger Entry xuất bán. Ví dụ hệ thống post lô C 10, D 2, E 8, kho ghi lô D 2, E 8, F 10, thì hệ thống hiểu 10 đơn vị lô C thực ra là lô F.
- Truy xuất dựa trên Item Tracing chuẩn (Trace item-tracked items), thêm nhánh giao theo lô thực tế.
Cái giá: tồn theo lô trên sổ kho vẫn lệch. Khách chấp nhận điều chỉnh khi kiểm kê cuối kỳ, và điểm này phải ghi vào phạm vi của FDD. Không ghi thì sau này ai thấy lệch cũng tưởng là lỗi.
Hai bẫy dữ liệu gặp lúc thiết kế, áp cho mọi bảng tự làm có lô. Không lưu ký tự | trong dữ liệu, vì nó làm hỏng filter của BC. Khách dùng cùng một mã lô cho nhiều mặt hàng, nên mọi truy xuất phải đi theo cặp mặt hàng và lô, không đi theo mỗi lô.
So sánh ba cách#
| Cách 1: Item Reclassification Journal | Cách 2: cặp bút toán Sale | Cách 3: bảng lô thực tế | |
|---|---|---|---|
| Tồn theo lô | Đúng | Đúng | Vẫn lệch, điều chỉnh khi kiểm kê |
| Tồn theo bin | Đúng nếu khai bin mới trên dòng reclass | Đúng | Lệch nếu hai lô nằm ở hai bin |
| Truy xuất theo khách | Sai, vẫn ra lô cũ | Đúng, chuỗi rối khi lô cũ bán tiếp | Đúng, qua màn hình truy xuất riêng |
| Giá vốn, chạy giá | Thêm cặp bút toán chuyển lô | Tổng giá vốn không đổi, thêm hai bút toán mỗi lần sửa | Không thêm bút toán kho |
| Khách trả hàng | Phiếu trả lấy lô cũ | Copy ra lô cũ và BC vẫn cho post | Luồng chuẩn, phiếu trả lấy lô trên phiếu xuất |
| Phát triển | Không | Có, tạo journal bằng code | Có, bảng và màn hình mới |
Ô "Khách trả hàng" của cách 1 và cách 3 là suy ra từ việc BC lấy lô theo bút toán xuất gốc, tôi chưa chạy riêng hai trường hợp đó.
Điều kiện để cách nào cũng chạy được#
Công cụ sửa chỉ dùng được khi có người biết lô nào đã thật sự lên xe. Gấp tới mức không ai ghi lại thì không còn gì để sửa. Việc tối thiểu ngoài kho nhẹ hơn nhiều so với quét vào hệ thống: phiếu soạn hàng in sẵn một cột trống "Lô thực tế" để ghi tay, hoặc chụp ảnh tem thùng trước khi lên xe.
Hạn sửa là trong ngày. Để qua ngày thì đơn sau có thể đã xuất tiếp đúng lô cũ trên giấy, lúc đó lô cũ không còn tồn trên hệ thống để hoàn, và sai chồng lên sai.